ついに登場！ 究極の見積もり技法（その3：最短開発期間）：山浦恒央の“くみこみ”な話（40）

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」のトレードマークといえる“最短開発期間”の概要を解説する。

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

　「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。

　今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。

　見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。第38回のコラムから、パラメトリックス法の1つとして、「SLIM（Software Life Cycle Management）」を取り上げています。そして、前回は「工数（コスト）」「開発期間（月）」「機能総量（規模）」「（プロセス）生産性」の4つの関係を分析できるよう、マイクロソフトの表計算ソフト「Excel」の計算式を使った算出方法を解説しました。これにより、例えば機能総量が20％増えたり、開発期間が18カ月から14カ月に短縮した場合に、スケジュールや人月にどのような影響を及ぼすのかを簡単に計算することができます。

　今回は、前回の予告通り、SLIMのトレードマークといえる「最短開発期間」の概要を解説します。これはSLIMの中核ともいうべき非常に重要な概念です。

SLIMと最短開発期間

　SLIMの非常にユニークな特長の1つがこの“最短開発期間”です。この最短開発期間とは、「開発エンジニアを何千人・何万人投入したとしても、『この期間』よりも絶対に短く開発することはできない」という「時間（月）」のことです。

　例えば、プロジェクト管理者が顧客から提示された仕様を基に、FP（Function Point）試算法を適用して規模見積もりをしたところ（参考：FP試算法について）、「開発にはどう頑張っても16カ月かかる」との計算結果が出たとします。これまで、同じ開発メンバーで同じ分野のソフトウェアを長年開発してきたプロジェクト管理者としての知識と経験から、この16カ月という結果は、かなり精度が高く信ぴょう性のある数字だとします。

　さて、この結果を正直に顧客へ提示したらどうなるでしょう。恐らく、「16カ月もかけられない。絶対に、何が何でも、死ぬ気になって12カ月で開発してほしい」といわれ、同時に上司からの呼び出しもくらって、「顧客の要望通り、12カ月でやれ!!」と厳命されてしまいます。

　ここで頑張って反論して、「これだけの機能を12カ月で開発することは、絶対に無理です！」と答えたとしても、必ず上層部から「何の工夫もしないでできない何て言うな！ そんなことでは、君をプロジェクト管理者にした意味がないではないか!!」と長時間にわたってネチネチと叱責を受けることになります……。

　結局、顧客や上司の無理難題に対して“根拠のある反論”ができないまま、最後には「はい、分かりました」と言わざるを得なくなります。“絶対無理な12カ月”をのんでしまい、「ああ、これで1年間、土日は全部出勤、毎朝9時から終電まで働かなきゃ……。チームの皆に何と説明しようか……」と、暗い気持ちでプロジェクトルームへ帰っていくのです。世界中のデスマーチ・プロジェクトでよく見掛ける光景ですね。当然、プロジェクトのメンバー全員が毎月200時間残業したとしても、12カ月では開発し切れず、プロジェクト管理者の見積もった通り16カ月かかってしまうというのが大抵のオチです。

　このように、人類のソフトウェア開発は過去40年以上、ずっと「精度の高い見積もりを顧客が値切る」→「プロジェクト管理者が無理なスケジュールをのまされる」→「結局、当初の見積もり通りの期間が必要だった……」を繰り返してきました。

　「12カ月でできるように工夫をしろ！」と言われたプロジェクト管理者も、20年経てば逆の立場となり、部下に「何の工夫もしないでできない何て言うな!!」とゴリ押しすることでしょう……。この悪循環を断ち切らねば、「健康で文化的なソフトウェア開発」はあり得ません。

　先に示した例のように、どう見ても無理な“緊縮スケジュール”を強制された場合、究極の反撃法となるのが今回紹介するSLIMにおける最短開発期間です。

　「最短開発期間を計算したところ16カ月となりました。ですので、12カ月で開発することは絶対に不可能です。出荷日を最優先にし、12カ月で出荷したければ、開発規模を縮小する必要がありますし（どれだけ縮小すればよいかもSLIMで計算できます）、フルスペックでリリースするのであれば、開発期間を延長しなければなりません（開発期間も算出可能です）」と根拠のある反撃と解決策の提案が可能です。

　緊縮スケジュールを強制されるようなケースの場合、このような“工学的な妥協”ができないと、開発側と発注側が確実に共倒れしてしまうでしょう。

最短開発期間の詳細

　図1に、最短開発期間と工数（人月）、開発期間（月）の関係を示します。この図では、以下のように、いろいろな要素を示しています。

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

（1）開発人数が多いほど、開発期間は短くなる

　1人でプログラムを作るより、10人で開発する方が短期間で完成します。これは、当たり前の経験則ですが、増員でどこまで期間を短くできるかが問題です。“際限なく短くなる”ということはあり得ません。

（2）最短開発期間を越えてまで、開発期間は短縮できない

　プログラム開発は分業が難しい作業です。図2に、分業の可能性と作業の関係を示しました。

図2　作業と分業の可能性

　例えば「穴を掘る」は、人員とシャベルの数を2倍増やせば、時間は半分になりますし、10倍に増やせば10分の1になるでしょう。しかし、「家を建てる」はどうでしょう。大工さんの数を10倍に増やしても、建築日数が10分の1にはなりません。これは、“作業に順序性がある”ためで、コンクリートの基礎が固まらないと柱が立てられないし、柱が立たないと梁を渡せず、屋根も作れません。

　プログラム開発も同様で、「仕様の凍結」→「設計書の作成」→「コーディング」→「デバッグ」→「テスト」の手順をきちんと踏み、しかも、各フェーズで品質を上げておかないと、稼働に耐えられるソフトウェアは開発できません。

　SLIMでは“開発エンジニアの数を無限に増やしても、最短開発期間を越えてまで、開発期間は短くならない“との立場を取っています。事実、世界の6300以上のプロジェクトを分析した結果、これより短くなったプロジェクトは1つも存在しないのです。

　最短開発期間に近づくほど、工数（人月）が指数関数的に増加します。このあたりの事情は、ブルックスの法則、「ソフトウェア開発における『人月』では、『人数』と『期間』は交換可能ではない」「開発要素の短縮が10％以上の場合、『n2乗分の1の法則』を適用する」とよく似ています。すなわち、開発期間を半分にするには、投入人数を4倍にしなければならず、結果、工数と開発コストが2倍になります。

（3）開発期間が短いほど、品質が悪くなる

　短期開発の弊害は、コストの急上昇だけではなく、品質にも甚大な悪影響を与えます。短期間で品質を確保するのは簡単なことではありません（いや、不可能でしょう）。中には「効率の良いテスト項目を大量に設計し、それを実行すればいいのではないか？ これはデバッグ期間の長短の問題ではなく、単にテスト技術の問題ではないか？」と反論する人がいるでしょうが、そう簡単にバグはなくなりません。

　特に、複数の特殊条件が発生した場合（例えば、携帯電話で大容量の画像データをダウンロードしている最中にメールを受信し、同時に音声通話が着信したケース）や、長時間稼働の末に判明するバグ（メモリの解放モレが少しずつたまって、メモリを食いつぶしたケース）、最大構成時のバグ（処理できる上限値で、いろいろな条件の組み合わせが起きる場合）などは、短期間でバグを検出することはできません。

　以上の理由により、開発期間を短縮すると、必然的にコストの大幅な増大と品質の低下を招くのです。特に、最短開発期間に近づくほど、コスト増加と品質低下は非常に大きな値になります。

　先ほどの例では、当初見積もりの16カ月なら、10人×16カ月＝160人月（約1億6千万円、人員単価：100万円／月）、バグ密度4件／KLOCで開発できるでしょうが、最短開発期間の14カ月なら、30人×14カ月＝420人月（約4億2千万円）、バグ密度13件／KLOCになったりします。たった2カ月短縮するだけなのに、コストが3倍近く掛かり、しかも、品質も実稼働に耐えられないものになる可能性があるのです。

　では、どうすればいいのでしょうか？ スケジュールを重視するならば、開発規模を縮小する必要がありますし、フルスペックで出荷しないと意味のない製品ならば、スケジュールをずらさねばなりません。このあたりの“工学的な妥協策”や“デスマーチ・プロジェクト管理”は、非常に難しい課題ですので、別の機会にあらためて解説したいと思います。

　開発期間を見積もる場合、最短開発期間を意識することは非常に重要です。最短開発期間は、プロセス生産性と開発規模から算出できます（算出法の詳細は次回）。

最長開発期間

　一方、SLIMには「最長開発時間」という概念があります（図3）。

図3　SLIMにおける「最長開発期間」

　開発人数が少ないほど開発効率が上がり、最も開発効率が良いのは、フレデリック・ブルックスも書いているように「1人」です。1人であれば、分業に伴う「他人とのコミュニケーションミス」や「インタフェースの不一致」がなくなり、生産性は、1人月で2〜3KLOCと、非常に高い値になることでしょう。しかし、10MLOCの携帯電話の機能を1人で開発するとなると、300年以上かかってしまいます。これではビジネスになりません。

　最長開発期間は、ビジネスチャンスから見たもので、プロジェクト管理の重要度としては、最短開発期間にはおよびませんが、ある程度意識しておく必要があるでしょう。SLIMでは「最長開発期間は、最短開発期間の40％増し」として計算しています。

現実的な開発期間

　図1における「不可能領域」は最短開発期間より短いため、この期間内で開発しようとしても確実に失敗します。一方、最長開発期間を越えた「非現実的領域」ではビジネスが成り立ちません。

　見積もった期間が、「現実的開発期間」の中に納まっていることが重要で、少なくとも、最短開発期間より短い時間になっていないことを確認する必要があります。

---

　今回は、SLIMの代表的な特長である最短開発期間について解説しました。次回は、「プロセス生産性」と「開発規模」から最短開発期間を算出する方法について、Excelの計算式を用いて解説します。ご期待ください！ （次回に続く）

【 筆者紹介 】

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

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

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