勘・経験・度胸による「類推法」 〜見積もりの基本技法 その1〜：山浦恒央の“くみこみ”な話（34）

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、見積もりの3つの基本技法のうち「類推法」について取り上げ、その概要とメリット・デメリット、利用時の注意点について詳しく紹介する。

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

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

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

　今回は、3つの基本的な見積もり方法のうち、「類推法」を取り上げます。

KKDと「機能要件」「非機能要件」「性能」の見積もり

　前回の「見積もり値の『幼虫』『サナギ』『成虫』」で、見積もりの基本値となるのが、機能要件、非機能要件、性能であると紹介しました。家を建てる場合に例えると、機能要件は「どんな形態の家を建てるか（50坪の平屋 or 12階建てのマンション）」、非機能要件は「台所の動線をスッキリさせる。家族のプライバシーを配慮する」、性能は「震度7クラスの揺れに耐えられる」などが相当します。これらをベースに、どの品質レベルで作るか、誰が作るかを考慮して、最終的な見積もり値を算出するのです。

　現実の見積もりで、最も重視しているのは機能要件の規模、すなわち、要求仕様書に記述した機能を開発した場合、プログラムはどれぐらいのステップ数になるか、あるいは、ファンクションポイントが幾つになるかを見積もることです。世界の大部分のプロジェクトでは、「規模見積もり＝見積もり」と考えているようです。

　非機能要件と性能も、本当はキチンと考慮すべきなのですが、明確に分けて見積もりをしている組織やプロジェクトはほとんどないのではないでしょうか。非機能要件と性能は、最終的にはプログラムの一部に落とし込まれるので、機能要件を規模見積もりする場合の“オマケ”とか“誤差範囲”と見なす場合がほとんどです。本当は、非機能要件や性能もちゃんと見積もらねばならないのですが、皆サボっています。気分としては、「良い子はマネをしないでください」ですが、「見積もったステップ数に5％上乗せしとくか……」という、いわゆるKKD法（注1）でやっつけるプロジェクトが大部分でしょう。

※注1：KKD法とは、「勘、経験、度胸」をベースにソフトウェアを開発する石器時代方式の総称。「根性、根性、ド根性」の略との説もある。

見積もりの3つの基本技法

　機能要件の規模をベースに、何人月必要か、コストがどれくらい掛かるのかを計算し、人集めに走り回り、詳細の開発スケジュールを立てます。この規模見積もりで適用する代表的な方法として、「類推法」「積み上げ法」「パラメトリックス法」の3つがあります。

　類推法とは、過去の類似プロジェクトを参考にして見積もる方法で、最も簡単に適用することができます。積み上げ法は、プロジェクトで開発しなければならない成果物の構成要素を洗い出し、それぞれの作成に必要な工数を積み上げる方法で、ソースコードの行数見積もりや積み上げ法がこれに該当します。積み上げ法は、ある意味、“見積もり技法の王様”といえます。パラメトリックス法とは、必要工数を目的変数とし、開発規模や開発特性をパラメータとする数学的な関数で表現する方法です。PCショップで販売しているような見積もり専用ソフトのほとんどが、この手法をベースにしています。

　ソフトウェアの規模を見積もる場合、3つの見積もり方法の1つだけを適応するのは、“桁違いの見積もりミス”の原因になります。この“桁違いの見積もりミス”の予防策として理想なのは、原理の異なる見積もり法から最低2つ以上を選んで併用することです。例えば、類推法と積み上げ法で同時に見積もると、桁違いの見積もりミスを防ぐことができます。

　今回からそれぞれの規模見積もり法について、概要を説明し、適用の可能性、精度、適用の容易性を検討します。今回は、類推法を取り上げます。

類推法

　類推法と聞くと、複雑な方法論が背後に潜んでいるような印象を受けますが、要は、今までの経験や過去の類似プロジェクトでの実績をベースに見積もる方式です。人類最古の規模見積もり技法がこれでしょう。

　「以前、同じようなプログラムを開発したことがある」「別のプロジェクトで、類似ソフトウェアを作っていた」という過去のデータを基にして、新たに開発する機能や、不必要な機能を考慮し、過去のプロジェクトでの規模を増減させ、これから開発するプログラムの規模を見積もります。機能要件、非機能要件、性能の違いをどのように反映させればよいのか？ このあたりのサジ加減は、まさしくKKD法であり、高度な個人技に依存します。見積もりをすること自体に高度な技が必要ですが、見積もり値を検証する場合には、それ以上に高度な技術・知識・経験が必要です。ただ、現実には、類推法により計算した見積もり値の正当性を検証していないプロジェクトがほとんどでしょう。

類推法の利点

　類推法の利点は、簡単に見積もることが可能で、特に、ソフトウェアの詳細機能が固まっていない初期段階で威力を発揮します。また、いいかげんな方法に見えますが、意外に精度が高く、適切に使えば“桁違いの見積もりミス”という最悪の結果（注2）になることはありません。

※注2：見積もり値より小さく安く開発できた場合も、一応は見積もりミスですが、誰も文句はいいません。問題は増える方の見積もりミスで、天井知らずの莫大な赤字になる可能性があります。筆者は、これまでいろいろなソフトウェア開発会社のエンジニアと話をしてきましたが、“見積もり値の数倍もコストが掛かる「問題児プロジェクト」がどんな組織にも最低1〜2％は存在し、残り98％のプロジェクトで稼いだ利益をキレいに食い潰してしまう……”というケースによく遭遇します。こうしたことから、実際、見積もり値の“50％増”程度ならそれほど問題にしない組織も少なくないようです。

類推法の欠点

　類推法には大きな欠点が2つあります。まずは、「客観性の欠如」です。KKD法をベースにした見積もりなので、見積もり値に客観性がありません。発注側との契約交渉でコストを提示する場合、「なぜ、この金額ですか？」と質問されて、「昔の類似プロジェクトから計算しました」と回答すると、「どうせ、私達に分からないと思って、保険として適当に30％ほど上乗せしてるんでしょう？」と勘繰られたりします（実際には、少なくとも10％は上乗せするのが一般的なので、「いえ、正味の値です」と否定できないのがツラいところですが）。見積もり値計算の基となった数値を全て公開し、見積もりの計算方法も提示できれば、誰が計算しても同じ値になり、説得力があるのですが、残念ながら類推法には客観性がありません（パラメトリックス法で算出した値には、客観性があります）。これは非常に大きな問題です。

　2番目の欠点は、当たり前ですが、「開発経験のないソフトウェアを見積もることができない」点です。例えば、コンパイラばかりを設計してきた開発会社が、リアルタイムOS系の携帯電話用ソフトウェアを開発しなければならなくなったら……。そこには、自動車の設計者が潜水艦のデザインをするほど劇的な違いがあることでしょう。設計者としての健全な常識は「いきなり、これほど分野が違うソフトウェアの開発は無理だから、断るのが本筋だろう」ですが、今の不景気な世情を考えると仕事をえり好みする余裕はなく、とても「できません！」といえる雰囲気ではありません。結果、無理やり見積もることになりますが、精度は極めて低くなることでしょう。このようにして、桁違いの見積もりミスを起こし、“デスマーチ・プロジェクト”が誕生するのです。

類推法の注意点

　類推法は、過去のよく似たシステム開発をベースに見積もる方法なので、誰にでも、短時間で簡単に見積もることが可能ですが、注意点が幾つかあります。

　まず、経験したシステムが、見積もり対象システムに“どの程度”類似しているかが重要です。理想は、同じ技術分野の同じ機能を持ったソフトウェアを同じ技術レベルのプロジェクト人員で開発した経験がある場合です。この3つの要素の1つでも異なると、その差異を意識して慎重に見積もる必要があります。通常は、同じ技術分野の同じ機能を備えたソフトウェアでないと、怖くて見積もり時に参考にしないでしょう。

　また、当たり前ですが、参考にする過去のプロジェクトの開発背景、開発条件を明確に把握していることが必須となります。すなわち、過去のプロジェクトの詳細データ、例えば、ソースコード以外に、最新版の機能仕様書、設計書、テスト仕様書、テストの実施状況、バグレポート、スケジュール管理関係の資料、品質の状況、プロジェクトの人員構成など、いろいろなデータが必要になります。このようなデータがそろっていないと、類推法の適用は難しいでしょう。過去のプロジェクトの実績データが、キチンと蓄積されていることが類推法の大前提になります。さらに、過去のプロジェクトの関係者と共同で見積もる必要があります。

---

　次回は、見積もり法の王道であり、世界中で最も多く使われている積み上げ法について解説します。（次回に続く）

【 筆者紹介 】

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

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

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