普段、大規模なシステム開発の見積をする際に、少ない情報から概算見積が必要になる場面があると思います。
過去のプロジェクト実績データを分析することで、類似したプロジェクトの進行状況や費用、期間などの情報を得ることができます。これにより、実際の実績を元にした正確な見積もりが可能となります。
今回はIPAが作成および公開しているソフトウェア開発分析データを私自身が今後業務に使えそうな点を整理しています。もしければ参考にしてください。
ソフトウェア開発の提供データ
IPAがこの資料で分析対象としてデータは以下の通り
- FP実績値
- 実行SLOC実績値
- 実績月数
- 実績工数
- テストケース数_結合
- テストケース数_総合
- 検出バグ現象数_結合
- 検出バグ現象数_総合
- 検出バグ原因数_結合
- 検出バグ原因数_総合
- 発生不具合数
本記事では筆者が普段SLOCベースで見積や品質を評価することが多いためSLOCに関する情報を主に抜粋してます。
FP値を扱う場合は、元資料をご確認ください。
プロジェクトの開発規模・工数・工期に関する考察
工数と工期の関する指標を整理したいと思います。
補足
- 改良開発は母体規模は含まず、改良したステップ数を指す
- １人月160時間
- 開発５工程（設計〜総合テスト）
プロジェクトのSLOC 規模と工数
以下はSLOC規模あたりの工数を示した図である
- 新規開発と改良開発で大きく差はないが若干改良開発の方が工数が大きくなる傾向にある
- 200KSLOC（＝200,000SLOC）で信頼曲線50%で312.5人月（＝50,000人時）を超える
- 開発対象の難易度なども考慮が必要だが信頼曲線50%以上の人月で見積らないと赤字リスクが発生しそうな分布である
- 信頼曲線50%の値を見ると200KSLOC→400KSLOCにかけて生産性が上がっているように見えるが、200KSLOC→100KSLOCにかけては生産性が下がっているように見える
プロジェクトのSLOC 規模別 SLOC 生産性
以下は人時あたりのSLOC、人時あたりのKSLOCを示した表である
- 新規開発の100KSLOC以上300KSLOCの中央値は１人月あたり0.83KSLOC開発できることがわかる
- 例えば200KSLOCの新規開発は開発生産性の中央値でみると240人月と計算できる
プロジェクトの工数と工期
以下はの図は新規開発プロジェクトの
- 全体（開発５工程含む）
- 開発５工程
の２通りの工数と工期の関係を示す
- 50,000人時（312人月）で信頼曲線50%で20ヶ月超えとなる
- 50,000人時（312人月）で信頼曲線50%で15ヶ月超えとなる
- とはいえ、50,000人時の半分の25,000人時（161人月）あたりでも信頼曲線50%で15ヶ月付近であるため、100人月越えのプロジェクトはそれなりの期間確保が必要である
色々とデータを見てきましたが、過去のデータを見ると200KSLOCくらい開発するプロジェクトでは
- 開発５工程で300人月くらいかかることが多い
- 開発５工程の工期は最低でも１年半くらいみておかないと危険
- プロジェクト全体では２年くらいかかる
という感覚になりました。
工程別の工期・工数に関する考察
工程別の工期と工数の比率を見ていきましょう。
工程別の工期
開発 5 工程における工程別の実績月数の比率になります。あくまで工期のため工数ではないのは注意。
- 最近のプロジェクトだと「詳細設計」の工程が存在しなくて、その役割が「基本設計」と「制作」に分散されることが多いように思えます。
- 私の経験するプロジェクトの実態としては、「基本設計」に少し詳細部分も持たせ、「制作」時に多少ロジックやアルゴリズムの検討も委譲するのが実態です。
以下は「詳細設計」を「基本設計」と「制作」に均等に割り振って見た時の数値です。
| 工程 | 新規開発（中央値） | 新規開発（中央値）補正 |
|---|---|---|
| 基本設計 | 0.190 | 0.271 |
| 詳細設計 | 0.163 | 0 |
| 制作（実装＋単体テスト） | 0.244 | 0.325 |
| 結合テスト | 0.192 | 0.192 |
| 総合テスト | 0.173 | 0.173 |
工程別の工数
開発 5 工程における工程別の実績工数の比率になります。
以下は「詳細設計」を「基本設計」と「制作」に均等に割り振って見た時の数値です。
| 工程 | 新規開発（中央値） | 新規開発（中央値）補正 |
|---|---|---|
| 基本設計 | 0.165 | 0.243 |
| 詳細設計 | 0.157 | 0 |
| 制作（実装＋単体テスト） | 0.316 | 0.394 |
| 結合テスト | 0.201 | 0.201 |
| 総合テスト | 0.119 | 0.119 |
私もまさに工数を見積もる時は上記のような比率で計算するので、過去の他プロジェクトの数値と裏付けできました。
工期も今までの自分の経験と一致するので、この比率は非常に信ぴょう性が高いと思いました。
その他各工程における定量値
プロジェクト管理で使用できそうな定量値を抜粋しました。
SLOC 規模あたりの設計書ページ数
ソフトウェア開発の生産物のひとつとして設計書を取り上げ、SLOC 規模あたりの設計書のページ数を紹介する。
設計工程における設計書文書量に関して、SLOC 規模あたりの設計書ページ数(設計文書化密度)を分析した結果を示す。
個人的には設計書ページ数ってあまり好きではない定量値です。（１ページの記述量が膨大である場合見誤ることがあるので）
進捗が測りづらい設計工程において無いよりはあった方が良いとして大きなプロジェクトでは採用することがありますね。
大体１機能500SLOCという感覚なので、１機能あたり５〜６ページは妥当ですね。
SLOC 規模あたりのテストケース数
ソフトウェア開発の生産物のひとつとしてテストケースを取り上げ、SLOC 規模あたりのテストケース数を紹介する。
新規開発だと1KSLOCあたり
・結合テスト：40ケース
・総合テスト：10ケース
です。
レビューに関する考察
レビューに関する定量値の抜粋になります。
基本設計のレビュー実績工数
基本設計の人時あたりのレビュー実績ページ数になります。
１ページあたり30分の時間を見込むのがよさそうです。
１機能500SLOCだとしたら5ページくらなので、１機能あたり2.5時間くらいであれば妥当な気はします。
基本設計のレビュー指摘件数
基本設計の１ページあたりのレビュー指摘件数になります。
１ページあたりの指摘件数が0.2なのですね。
１機能500SLOCだとしたら5ページくらなので、１機能あたり指摘件数が１件くらいが中央値ですね。
制作のレビュー指摘件数
制作（実装・単体テスト）の1000人時（＝6.25人月）あたりのレビュー指摘件数になります。
6.25人月あたりのレビューで496件の指摘件数なので
1人月あたり79件
1人日あたり4件
になります。
これが果たして何の数値の参考になるのかはよくわかりませんでした。
１KSLOCあたりのレビュー工数がわかれば計算ができるのですが、、、
品質に関する考察
品質に関するデータを抜粋しました。
SLOC 規模のテスト検出バグ
SLOCあたりの結合テストと総合テストでのバグに関する数値になります。
結合テストで1KSLOCあたり1.5件くらいですね。
テストケース40件あたりバグは1件出るような計算になります。
SLOC 発生不具合密度
SLOCあたりのリリース後の不具合件数になります。
リリース後の不具合発生についてですが
100KSLOCの開発をしたとしても0.7件と非常に品質の良い結果になりました。
なんとなくですが、大きな障害以外はカウントされていないのではと思いました。流石に品質良すぎです。
最後に
意外と世間一般のプロジェクトの品質や生産性が良いのでは？と思いましたが、本資料には以下の注意点の記載がありました。
定量的管理が行われている組織で定量的管理されたプロジェクトのデータが多く含まれていることから、本書および補遺の統計情報は、定量的管理されたプロジェクトの統計情報と見るのが妥当である。したがって、生産性および信頼性に関する統計情報は、世間相場観よりも良い値を示している可能性がある。
また、冒頭でも述べましたが、あくまで参考資料という位置付けにして、プロジェクト特有の難易度に応じてしっかりと見積もりをすべきだと私は考えます。
ただ、参考にはなると思います。
自分の感覚と大きくづれてないこと、それを踏まえて目の前のプロジェクトの特性を見極めて、根拠のある見積もりを作ることが、精度向上に繋がると思います。