本メディアにはプロモーション広告が含む場合があります。但し、掲載内容は事実に反して優遇されることはありません。

システム開発の見積や工期を定量データから分析する

技術全般

普段、大規模なシステム開発の見積をする際に、少ない情報から概算見積が必要になる場面があると思います。

過去のプロジェクト実績データを分析することで、類似したプロジェクトの進行状況や費用、期間などの情報を得ることができます。これにより、実際の実績を元にした正確な見積もりが可能となります。

今回はIPAが作成および公開しているソフトウェア開発分析データを私自身が今後業務に使えそうな点を整理しています。もしければ参考にしてください。

インプット資料

 

スポンサーリンク

ソフトウェア開発の提供データ

IPAがこの資料で分析対象としてデータは以下の通り

  • FP実績値
  • 実行SLOC実績値
  • 実績月数
  • 実績工数
  • テストケース数_結合
  • テストケース数_総合
  • 検出バグ現象数_結合
  • 検出バグ現象数_総合
  • 検出バグ原因数_結合
  • 検出バグ原因数_総合
  • 発生不具合数

実行SLOC実績値
SLOC=SourceLinesofCodeの略
ソースコード行数という意味
1,000 行の単位は「KSLOC」と表記

FP実績値
・FP=Function Pointの略
・機能を
 ・外部入力(EI)
 ・外部出力(EO)
 ・外部照会(EQ)
 ・内部論理ファイル(ILF)
 ・外部インターフェースファイル(EIF)
 の5つに分類し、それぞれの数をカウント

本記事では筆者が普段SLOCベースで見積や品質を評価することが多いためSLOCに関する情報を主に抜粋してます。

FP値を扱う場合は、元資料をご確認ください。

 

プロジェクトの開発規模・工数・工期に関する考察

工数と工期の関する指標を整理したいと思います。

補足

  • 改良開発は母体規模は含まず、改良したステップ数を指す
  • 1人月160時間
  • 開発5工程(設計〜総合テスト)

 

プロジェクトのSLOC 規模と工数

以下はSLOC規模あたりの工数を示した図である

新規開発
改良開発
  • 新規開発と改良開発で大きく差はないが若干改良開発の方が工数が大きくなる傾向にある
  • 200KSLOC(=200,000SLOC)で信頼曲線50%で312.5人月(=50,000人時)を超える
  • 開発対象の難易度なども考慮が必要だが信頼曲線50%以上の人月で見積らないと赤字リスクが発生しそうな分布である
  • 信頼曲線50%の値を見ると200KSLOC→400KSLOCにかけて生産性が上がっているように見えるが、200KSLOC→100KSLOCにかけては生産性が下がっているように見える

 

プロジェクトのSLOC 規模別 SLOC 生産性

以下は人時あたりのSLOC、人時あたりのKSLOCを示した表である

新規開発
改良開発
  • 新規開発の100KSLOC以上300KSLOCの中央値は1人月あたり0.83KSLOC開発できることがわかる
  • 例えば200KSLOCの新規開発は開発生産性の中央値でみると240人月と計算できる

  

プロジェクトの工数と工期

以下はの図は新規開発プロジェクトの

  • 全体(開発5工程含む)
  • 開発5工程

の2通りの工数と工期の関係を示す

新規開発(全体)
  • 50,000人時(312人月)で信頼曲線50%で20ヶ月超えとなる

 

新規開発(設計〜総合テスト)
  • 50,000人時(312人月)で信頼曲線50%で15ヶ月超えとなる
  • とはいえ、50,000人時の半分の25,000人時(161人月)あたりでも信頼曲線50%で15ヶ月付近であるため、100人月越えのプロジェクトはそれなりの期間確保が必要である

  

色々とデータを見てきましたが、過去のデータを見ると200KSLOCくらい開発するプロジェクトでは

  • 開発5工程で300人月くらいかかることが多い
  • 開発5工程の工期は最低でも1年半くらいみておかないと危険
  • プロジェクト全体では2年くらいかかる

という感覚になりました。

 

工程別の工期・工数に関する考察

工程別の工期と工数の比率を見ていきましょう。

 

工程別の工期

開発 5 工程における工程別の実績月数の比率になります。あくまで工期のため工数ではないのは注意。

新規開発
改良開発
  • 最近のプロジェクトだと「詳細設計」の工程が存在しなくて、その役割が「基本設計」と「制作」に分散されることが多いように思えます。
  • 私の経験するプロジェクトの実態としては、「基本設計」に少し詳細部分も持たせ、「制作」時に多少ロジックやアルゴリズムの検討も委譲するのが実態です。

 

以下は「詳細設計」を「基本設計」と「制作」に均等に割り振って見た時の数値です。

工程新規開発(中央値)新規開発(中央値)補正
基本設計0.1900.271
詳細設計0.1630
制作(実装+単体テスト)0.2440.325
結合テスト0.1920.192
総合テスト0.1730.173

制作(実装・単体テスト)を「1」として見た時、各工程の割合は以下の通り
・基本設計:0.83
・制作:1
・結合テスト:0.59
・総合テスト:0.53

  

工程別の工数

開発 5 工程における工程別の実績工数の比率になります。

新規開発
改良開発

以下は「詳細設計」を「基本設計」と「制作」に均等に割り振って見た時の数値です。

工程新規開発(中央値)新規開発(中央値)補正
基本設計0.1650.243
詳細設計0.1570
制作(実装+単体テスト)0.3160.394
結合テスト0.2010.201
総合テスト0.1190.119

制作(実装・単体テスト)を「1」として見た時、各工程の割合は以下の通り
・基本設計:0.61
・制作:1
・結合テスト:0.50
・総合テスト:0.30

私もまさに工数を見積もる時は上記のような比率で計算するので、過去の他プロジェクトの数値と裏付けできました。

工期も今までの自分の経験と一致するので、この比率は非常に信ぴょう性が高いと思いました。

  

その他各工程における定量値

プロジェクト管理で使用できそうな定量値を抜粋しました。

 

SLOC 規模あたりの設計書ページ数

ソフトウェア開発の生産物のひとつとして設計書を取り上げ、SLOC 規模あたりの設計書のページ数を紹介する。

設計工程における設計書文書量に関して、SLOC 規模あたりの設計書ページ数(設計文書化密度)を分析した結果を示す。

新規開発
改良開発

個人的には設計書ページ数ってあまり好きではない定量値です。(1ページの記述量が膨大である場合見誤ることがあるので)

進捗が測りづらい設計工程において無いよりはあった方が良いとして大きなプロジェクトでは採用することがありますね。

大体1機能500SLOCという感覚なので、1機能あたり5〜6ページは妥当ですね。

  

SLOC 規模あたりのテストケース数

ソフトウェア開発の生産物のひとつとしてテストケースを取り上げ、SLOC 規模あたりのテストケース数を紹介する。

新規開発
改良開発

新規開発だと1KSLOCあたり

・結合テスト:40ケース
・総合テスト:10ケース

です。

  

レビューに関する考察

レビューに関する定量値の抜粋になります。

基本設計のレビュー実績工数

基本設計の人時あたりのレビュー実績ページ数になります。

新規開発
改良開発

1ページあたり30分の時間を見込むのがよさそうです。

1機能500SLOCだとしたら5ページくらなので、1機能あたり2.5時間くらいであれば妥当な気はします。

 

基本設計のレビュー指摘件数

基本設計の1ページあたりのレビュー指摘件数になります。

新規・改良開発

1ページあたりの指摘件数が0.2なのですね。

1機能500SLOCだとしたら5ページくらなので、1機能あたり指摘件数が1件くらいが中央値ですね。

  

制作のレビュー指摘件数

制作(実装・単体テスト)の1000人時(=6.25人月)あたりのレビュー指摘件数になります。

新規・改良開発

6.25人月あたりのレビューで496件の指摘件数なので

1人月あたり79件

1人日あたり4件

になります。

これが果たして何の数値の参考になるのかはよくわかりませんでした。

1KSLOCあたりのレビュー工数がわかれば計算ができるのですが、、、

   

品質に関する考察

品質に関するデータを抜粋しました。

 

SLOC 規模のテスト検出バグ

SLOCあたりの結合テストと総合テストでのバグに関する数値になります。

新規開発
改良開発

結合テストで1KSLOCあたり1.5件くらいですね。

テストケース40件あたりバグは1件出るような計算になります。

 

SLOC 発生不具合密度

SLOCあたりのリリース後の不具合件数になります。

新規開発
改良開発

リリース後の不具合発生についてですが

100KSLOCの開発をしたとしても0.7件と非常に品質の良い結果になりました。

なんとなくですが、大きな障害以外はカウントされていないのではと思いました。流石に品質良すぎです。

 

最後に

意外と世間一般のプロジェクトの品質や生産性が良いのでは?と思いましたが、本資料には以下の注意点の記載がありました。

定量的管理が行われている組織で定量的管理されたプロジェクトのデータが多く含まれていることから、本書および補遺の統計情報は、定量的管理されたプロジェクトの統計情報と見るのが妥当である。したがって、生産性および信頼性に関する統計情報は、世間相場観よりも良い値を示している可能性がある。

また、冒頭でも述べましたが、あくまで参考資料という位置付けにして、プロジェクト特有の難易度に応じてしっかりと見積もりをすべきだと私は考えます。

ただ、参考にはなると思います。

自分の感覚と大きくづれてないこと、それを踏まえて目の前のプロジェクトの特性を見極めて、根拠のある見積もりを作ることが、精度向上に繋がると思います。