今でも簡単に適用できる30年以上前の見積もり技法：山浦恒央の“くみこみ”な話（32）

「ソフトウェア技術者の最高の能力は、見積もりだ！」――“見積もり”をテーマにした新シリーズ「見積もり：ソフトウェア技術者の最高の能力」の第2回。今回は、過去30年以上ほとんど進歩していない、“今でも使える”見積もり技法について紹介。

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

※本記事はアフィリエイトプログラムによる収益を得ています

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

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

　シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、

昔の見積もり＝現在の見積もり

である場合がほとんどです。

最初で最後の超巨大ソフトウェア開発プロジェクト

　度々、本連載で、フレデリック・ブルックス著の『ソフトウェア開発の神話（第2版から「人月の神話」）』（注1）を取り上げていますが、今回もこの“永遠の名著”から始めたいと思います。

※注1：『人月の神話（The Mythical Man-Month：Essays on Software Engineering）』（1975年、1995年、2002年）／フレデリック・P・ブルックス Jr.（著）、滝沢徹ほか（訳）／ピアソンエデュケーション（出版社）

　1963〜1966年、IBMは「OS/360」の開発に取り組みました。これは、本格的に仮想記憶を採用したメインフレーム用のOSで、有史以来、人類が経験したプロジェクトの中で、圧倒的に複雑で巨大なソフトウェアだといわれています。全部で5000人年を超える人月を投入したので、現在の金額にして約600億円もかかったことになります。ピーク時には、1000人以上のエンジニアが開発に従事したそうです。単純計算で、開発ステップ数は50MLOCを超えるでしょう。現在、最も複雑怪奇なソフトウェアといえる携帯電話用のプログラムでおよそ10MLOCもありますが、それよりはるかに巨大なプログラム規模だったのです。もちろん、記述言語は全てアセンブラでした。

　当時は、“ソフトウェア工学”という言葉さえなく（注2）、「どうすれば高品質なプログラムを安く・早く開発できるか」という課題を手探りで模索していました。今なら、5000人年もかかる超巨大プロジェクトは、立ち上げた3秒後に壊滅しますので、誰も立ち上げようと思いませんが、当時はソフトウェア工学が未熟な時代だった故に、力任せに進めたのでしょう。OS/360は、ビジネス的には大成功し、IBM発展の基礎を築きましたが、ソフトウェア開発の面から見るとかなり厳しい状況であったことが想像できます。同書の行間から、何の武器も持たず素手で恐竜に立ち向かい、何万人もの犠牲を出しながら恐竜と格闘するような悲惨な様子がにじみ出ています。

　1975年、この巨大ソフトウェア開発のプロジェクト・マネジャーだったブルックスが、プロジェクトで起きた不可解な現象、大事件、失敗から得た貴重な教訓・法則を回想し、臨場感溢れる筆致でつづったのが『人月の神話』です。その内容は、30年以上たった現在でも、そのまま当てはまるものが少なくありません。

※注2：「ソフトウェア工学」が初めて出版物に登場したのは、1968年のNATOの会議でした。“Engineering”は、日本語にすると、必ず（あるいは、自動的に）“工学”と訳されますが、私の経験ですと80％の確率で“開発”と訳す方が適切です。

見積もりでの「ブルックスの法則」

　同書でブルックスは、「遅延プロジェクトに人員を投入すると、さらに遅れる」のような意外性とインパクトのある箴言（しんげん）をたくさん残しました。これが、いわゆる「ブルックスの法則」で、30年以上たった現代のソフトウェア開発でも、そのまま当てはまるものが少なくありません。

　以下に、見積もりに関するブルックスの法則を紹介します。

（1）工数の「人数」と「月数」は交換可能ではない

　通常、開発量を見積もるとき、工数（人月）を予測し、その人月からコストを算出します。しかし、この人月が“くせ者”で、「人」と「月」は交換可能ではありません。例えば、

例：

3人 × 12カ月 ≠ 36人 × 1カ月

　これは極端な例なので、36人投入すれば1カ月でできるとは誰も思わないでしょうが、6人×8カ月＝8人×6カ月と考える人は少なくありません。発注側はもちろんのこと、ソフトウェア開発を担当するプロジェクト・マネジャーでさえも、この“交換”が可能だと考えている人はたくさんいます。開発期間を10％以上短縮することは、長時間残業では対応不可能で、ましてや、「やる気があれば何でもできる!!」といった“根性論”は論外です。

（2）開発要素の短縮が10％以内の場合、他の開発要素をそれだけ増やす

　ソフトウェアの開発要素とは、「人数」「期間」「コスト」です。10人×10カ月のプロジェクトを9カ月で完成させるには、コスト、あるいは、人数を10％増やす、すなわち、11人に増員する必要があります。単なる長時間残業や休日出勤だけでは対応できないことに注意すべきです。

（3）開発要素の短縮が10％以上の場合、「n²分の1の法則」を適用する

　デスマーチ・プロジェクトのように、開発期間を半分以下に短縮されたプロジェクトに適用できるのがこの法則です。開発期間をn％短縮したい場合、人員をn²分の1増員すべきというものです。

　従って、開発期間を50％短縮するには、人員を4倍に増やす必要があります。すなわち、

例：

12人 × 12カ月（144人月） ＝ 48人 × 6カ月（288人月）

となります。ここで注意すべきは、1．開発期間を半分にすると、コストが2倍になること、2．品質が悪くなることの2点です。

1．開発期間を半分にすると、コストが2倍になる

　上記の例の場合、投入人員が4倍になるので、工数は2倍、当然、コストも2倍になることを明確に意識する必要があります。それ以前に、開発期間を半分にすることは、ほとんどのプロジェクトで不可能でしょう。この理論的な理由は、以降の連載で解説します。

2．開発期間短縮すると、品質が悪くなる

　品質を確保するには“時間”が必要です。正常機能やエラー対応処理の検証は、大勢のテスト要員を投入すれば期間短縮が可能でしょうが、組み合わせテスト、タイミング関係、長時間連続稼働などは、時間がかかります。「そこを何とかするのが、プロジェクト・マネジャーとしての君の責務だろう!!」と上司に言われても、テストの実施方式をいかに工夫しても、品質確保にはある程度の時間が必要です。

　開発期間を半分にすると、コストが2倍になるだけでなく、品質も最悪になります。これは、30年以上前に指摘されていることです。従って、「それでも、開発期間を半分にしたいのか？」という議論になります。実際、この“30年以上前の法則”をキチンと理解して適用しているプロジェクト・マネジャーはほとんどいないと思われます。まずは、「開発期間の短縮は“ものすごく大変”であること」を十分認識する必要があります。

---

　次回、“見積もり・シリーズ”第3回では「見積もりの基本知識」について解説します。お楽しみに！ （次回に続く）