ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出）：山浦恒央の“くみこみ”な話（41）（2/2 ページ）

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は筆者お手製のExcelシートの計算式を使い、“開発エンジニアを何千人・何万人投入したとしても、「この期間」よりも絶対に短く開発することはできない”というSLIMのトレードマーク「最短開発期間」の計算方法を解説する。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

（1）プログラムサイズとプロセス生産性から最短開発期間を求める

　算出手順は、以下の通りです（Excelファイルの「計算式2-1」を使用）。

1. 過去のソフトウェア開発データから、プロセス生産性を求める　
   これは、前々回に述べたプロセス生産性の算出方式と全く同じ方法で計算しますので、詳細はそちらを参照してください。
2. 開発対象のソフトウェアのプログラムサイズ（LOC）を見積もる　
   規模見積もりの方法も過去のコラムで幾つか解説しましたので、そちらを参照してください。なお、プログラムサイズはFP（Function Point）でも構いません。
3. 組織構築率として最大値「5」を選ぶ（人月係数は「128」になる）　
   Excelの計算式では、既に「5」に設定してあります。
4. 「計算式2-1」に代入し、最短開発期間を求める　
   これで最短開発期間が月単位で算出されます。

　計算した最短開発期間と、発注側が希望するリリース日（開発期間）までの月数を比較し、最短開発期間の方が長い場合、このプログラム開発は必ず失敗します。すなわち、発注側が要求する開発期間は、図1の「不可能領域」に入っていることになります。

図1　SLIMにおける「最短開発期間」

　不可能領域に入ったプロジェクトが、その月数内で開発完了した例は、世界6300に及ぶ納期の厳しいプロジェクトの中で1つもありません。ですので、開発側のプロジェクトマネジャーは、「このソフトウェア開発は、最短開発期間よりも短い期間での開発を要求されております。この期間では開発不可能ですので、お引き受けできません」と言って断ることも可能です……が、これは“大人の態度”ではありませんね。「厳しい要求です」という断りを入れながらも、“発注側と受注側の双方が満足できる開発プランを提案する”ことが非常に重要です。このトピックスは次回、詳細に検討します。

（2）プログラムサイズとプロセス生産性から、最短開発期間でのコストを求める

　算出手順は、以下の通りです。

1. 上記の1〜4の手順により、最短開発期間を求める　
   これは、前々回に述べたプロセス生産性の算出方式と全く同じ方法で計算しますので、詳細はそちらを参照してください。
2. 前々回に添付した「Excelの式1−4」に、この最短開発期間とプログラムサイズ、プロセス生産性を代入し、工数を求める
3. 求めた工数に、人月単価、例えば100万円/人月を乗じる

　以上のステップで、総コストを計算できます。

　図1からも分かるように、最短開発期間に近づくほど、工数（人月）は急激に増加します。さらに、品質も大きく損なわれます。例えば、12カ月かかるプロジェクトを10カ月で完成させるには、総コストがおよそ2倍になり、品質が劣悪になる可能性があります。「そんな犠牲を払ってまで、2カ月短縮させる意味が本当にあるのか？」――プロジェクトマネジャーはそんな判断をしなければなりません。

（3）プロセス生産性と開発期間（最短開発期間）から、この期間で開発可能なプログラムサイズを求める

　これは発注側が「何が何でも、絶対に、死んだ気になって、この期間で開発してほしい!!」と強引に要求をねじ込んできた場合に、開発可能なプログラムの最大ステップ数を求めるためのものです。Excelの「計算式2-2」を使用し、以下の算出手順で計算します。

1. 過去のソフトウェア開発データから、プロセス生産性を求める　
   これは、前々回に述べたプロセス生産性の算出方式と全く同じ方法で計算しますので、詳細はそちらを参照してください。
2. 組織構築率として最大値「5」を選ぶ（人月係数は「128」になる）　
   Excelの計算式では、既に「5」に設定してあります。
3. 「計算式2-2」に、プロセス生産性と発注側が希望する開発期間を最短開発期間として代入し、プログラムサイズを求める

---

　今回は、Excelを用いて、SLIMの最大の特長である最短開発期間の計算法を解説しました。

　実際の開発現場の場合、発注側が希望するリリース日では、開発月数が最短開発期間よりも短くなるケースがほとんどでしょう。これに当てはまるものの多くが「デスマーチ・プロジェクト」だと思います……。何かよい手はないのでしょうか？ 次回は、実践的な立場に立って、いろいろな角度からその対処法を検討します。（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。