Technical Notes
テクニカルノーツ
共通フレーム2013をベースに開発プロセスを見直してみた
共通フレーム2013を購入するところから
「独立行政法人 情報処理推進機構（IPA）著 共通フレーム2013」をようやく購入しました。
会社にお願いして昨年手に入れようとしたのですが、書店ではすでに在庫がなく、図書館の蔵書まで探していただきました。司書曰く、「北海道には蔵書がありません。国会図書館か近畿の大学の蔵書ならあります。郵送で貸出しすることができますよ。」
すばらしい。図書館ネットワーク恐るべし。
さらに曰く、「出版社に問い合わせたところ、近々増刷の予定があるそうで、・・・（増刷予定の親切な説明）・・・、お急ぎなら、蔵書を郵送しますか？」
すばらしい。接客の鑑だ。図書館司書あなどりがたし。
結局、増刷後、IPAから直接購入しました。
どう見直すのか
前置きがながくなりましたが、既存開発プロセスを見直し、「共通フレーム2013」を反映します。
現状の自社開発プロセスは独自基準。「共通フレーム２０１３」をベースにIPAの各種ガイドラインで再構成します。
長年、当社ではKKD手法をベースとした。。。古代バビロニアから伝わる。。。。プリンシプルな開発手順が数パターン存在しております。それらを案件に応じてテーラリング・実行といったスタイルです。今回の取り組みは「共通フレーム2013」のソフトウェア実装プロセスを中心にマッピングしなおし、不足している基準を検討します。
現状の開発手順「簡便なツール開発レベル」の手順（抜粋）
1. 提案・見積時
1.1 適用業務範囲の妄想
1.2 ツール摘要作業範囲の妄想
1.3 ソフトウェア構成の妄想
1.4 ツール機能一覧洗い出し
1.5 開発規模算出
1.6 WBS作成
1.7 要員スケジュール作成
1.8 開発スケジュール作成
1.9 前提条件作成
2. 受注
3. 設計～テスト
4. 納品～検収～売上
共通フレームのソフトウェア実装プロセスに強引にマッピングすると、、、
共通フレーム2013のソフトウェア実装プロセスのアクティビティを自社の「簡便なツール開発レベル」に当てはめてみると、小規模開発の場合、要件定義は見積、引合段階で行うことがほとんどで、以下のようになりました。
2.4 ソフトウェア実装プロセス
2.4.1 ソフトウェア実装プロセス開始の準備プロセス
→1.6 WBS作成
2.4.2 ソフトウェア要件定義プロセス
→1.1 適用業務範囲の妄想
→1.2 ツール摘要作業範囲の妄想
→1.3 ソフトウェア構成の妄想
→1.4 ツール機能一覧洗い出し
→1.9 前提条件作成
2.4.3 ソフトウェア方式設計プロセス
→1.3 ソフトウェア構成の妄想
→1.9 前提条件作成
マッピング結果をベースに社内で検討した結果
- ソフトウェア要件定義プロセスは、設計の開始時点もしくは、基本設計の初期段階で「発注者ビューガイドライン システム振舞い編」に従った作業が終わった状態とイコール。小規模でも（ドキュメントとしては枚数がすくないかもしれないが）、ソフトウェアをブラックボックスとした発注者視点のできることとできないことを書面で合意しておくことが必要ではないか。
- ソフトウェア実装プロセス開始の準備プロセスは、小規模であるからといってタスクをまとめるだけではなく、「EVM活用型プロジェクト・マネジメント導入ガイドライン」に従った管理指標を設定する必要があるのではないか。
- 小規模案件はとくに顧客に費用転嫁しないよう、管理資料に時間をかけすぎない工夫が必要。
等々
検討してわかったこと
- 小規模だからと言って、要件定義をさぼっていないか？
- 要件定義が不要なのではなく、設計開始時点で明確になっているから工程として設けていないだけ。
- 少人数だからと言って、実績工数管理をさぼっていないか？
- だいたいでは済まされない、積み重ねが見積精度の改善・向上につながる。
