「『ソフトウェア開発データ白書』の活用」

今回サンプルとして、すでに開発が終了している改良（派生）開発の案件2つのSLOC規模を使用してみたいと思います。案件の具体的な説明は控えますが、小規模な開発案件Ａと大規模な開発案件Ｂの2つです。どちらも組込みソフト、Ｃ言語での開発になります。以下に具体的なステップ数を記載します。

表1.  サンプル案件のSLOC規模

表のうち総ステップ数は、コメント行を含む行数を指しており、実ステップ数はそこからコメントの行数を除いたものです。「組込みソフトウェア開発データ白書2019」におけるSLOC規模は、”コメント行および空行を含まないコード行数”と規定されています。実ステップ数＝SLOCとなっていないのは、実ステップ数からさらにOSやパッケージソフトなど自社で開発を行っていないプログラムや、流用したプログラムのステップ数を差し引いているためです。SLOC規模の定義では、”「改良（派生）開発」においては、改修部分（追加・変更・削除）のみを規模の対象範囲とし、母体は対象範囲外とする” との記述がありましたので、追加・変更部分のステップ数のみをSLOCとしました。

それでは実際に、「組込みソフトウェア開発データ白書2019」に記載されているデータをもとに工数を算出してみたいと思います。開発言語C/C++のSLOC規模別SLOC生産性のデータは以下の通りです。

表2.  SLOC規模別SLOC生産性の基本統計量（改良（派生）開発、開発5工程、開発C/C++）

※出典　IPA「組込みソフトウェア開発データ白書2019」、再転載不可、引用不可

なお、比較のため、ここでもう一つの生産性指標を紹介したいと思います。同じくIPAが発行している「ソフトウェア開発データ白書2018-2019　製造業編」（※2）に主開発言語別のSLOC生産性（新規開発）のデータが記載されています。こちらのデータはSLOC規模別にはなっておらず、C言語については全体で11.21[SLOC/人時]という、改良（派生）開発と比べて高い数値になっています。
以上のデータをもとに案件Aと案件Bについて、該当するSLOC規模の生産性から算出した開発工数は以下の通りとなります。

表3.  サンプル案件の工数算出結果

※算出工数は実際の開発にかかった工数を示すものではありません。

ここで算出された工数は、設計からテストまでの「開発5工程」（アーキテクチャ設計、詳細設計、実装・単体テスト、結合テスト、総合テスト）にかかる時間を指します。また、人月工数は、1ヵ月の労働時間を160時間（20日×8時間）として人時工数を除した値です。
改良（派生）開発前提と新規開発前提では、工数に大きな開きがあることがみてとれます。生産性の数値を比べると、案件Bの規模で3倍近く、案件Aの規模では6倍の差があります。この差の理由については複数の要因が考えられますが、新規開発に比べて、改良（派生）開発がいかに難しいかを表した結果ととらえても、差し支えないと思います。
なお、答え合わせではないですが、案件Aと案件Bの実際の開発工数はどうだったかというと、案件Aは約5人月、案件Bは約50人月の規模でした。どちらも　新規開発と改良（派生）開発　の間の工数に収まってはいますが、例えば50人月と100人月では、開発にかかる予算が倍（しかもかなりの額）違ってしまうわけで、概算見積もりとしてはもう少し精度がほしいところです。母体に対する改良（派生）の比率や、個々の案件の事情によるところも大きく影響してきますので、そこは簡易的な計算に頼らず、案件ごとに精査するしかないのかなと思います。

「組込みソフトウェア開発データ白書2019」には、工程別の工数に関するデータも記載されています。これらのデータから案件Aと案件Bについて、工程別の工数を逆算してみたいと思います。表3で算出した改良（派生）開発前提の全体工数[人時]に、工程別の実績工数比率の平均値をかけて、算出した数値が以下になります。

表4.  サンプル案件の工程別工数

※算出工数は実際の開発にかかった工数を示すものではありません。（）内は[人月]。

案件A程度の規模であれば、プロジェクトにかかわる人数は、1〜2名程度が妥当と思います。上のデータをもとに各工程でアサインする担当者の人数を決めることで、全体の大まかな工期も算出が可能です。アーキテクチャ設計など開発初期段階には複数人の参入が難しいことを考慮すると、工期は半年以上必要であることがわかります。
一方、案件Bほどの大規模な開発になると、プロジェクトにかかわる人数は数名〜10名程度まで膨れるため、各工程に参入できる人数で工期は大きく変動します。工期の算出には、具体的な担当者の確保状況など踏まえて、詳細な検討が必要です。

「組込みソフトウェア開発データ白書2019」に話を戻しますが、工程ごとの工期算出のもとになっているサンプルプロジェクトは、全体の86.3％が品質面で成功したプロジェクト（＝リリース後の不具合数が0件、または予測の範囲内に収まっている）となっています。残りの13.6%が品質面で失敗したプロジェクト（＝リリース後の不具合数が予測値を超過）になりますが、失敗したプロジェクトには、工程ごとの工数配分に特徴があるそうです。案件Aの全体工数をもとに、成功例、失敗例、それぞれの工数配分を計算した結果が以下になります。

表5.  成功例と失敗例の工程別工数

※算出工数は実際の開発にかかった工数を示すものではありません。（）内は[人月]。

失敗例の工数配分の特徴として、設計工程、テスト工程にかける工数の比率が低い一方で、実装・単体テストにかける工数の比率が極めて高いことがおわかりいただけるかと思います。ウォーターフォール型の開発においては、”品質を上流で作り込む”ことが基本と考えると、納得のいく結果と言えるのではないでしょうか。結果論ですが、失敗例では、実装・単体テストにかかる工数を基準に考えた場合、それに見合う分の設計工程、テスト工程への工数積み増しが必要だったのではないかと思います。失敗例のような工数配分を行わないよう、弊社の今後の開発でも、参考にしたいデータです。