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

　今回は、見積もり値の“3つの状態”について解説します。

見積もり値の3つの状態

　昆虫の特徴の1つが、卵からかえると「幼虫」→「サナギ」→「成虫」に変態することです。例えば、カブトムシは、幼虫からサナギへと姿を変えると、幼虫時の内臓が溶けて別の臓器が形成されるなど、大きくその様相が変わります。ソフトウェア開発における見積もり値も、この昆虫と同じで、「見積もりの基本値」→「品質を考慮した見積もり値」→「実装能力を考慮した見積もり値」の3つに状態が大きく変わります。

　まず、機能をベースに、見積もりの“基本値”を計算し、次に、どの程度の品質に仕上げるかにより基本値を調整し、最後に、どんな能力や経験を持ったエンジニアが開発するかにより、どれぐらいの人数、コスト、期間が必要か？を見積もるのです。

　「このプロジェクトで、あのソフトウェアを開発するには、何人を何カ月投入すればよいか？何カ月で出荷できるか？」を高精度で見積もる場合、見積もり値の幼虫・サナギ・成虫の3つの状態を明確に意識して、見積もることが非常に重要です。

　以下、見積もり値の3つの状態について詳しく見ていきましょう。

その1：見積もりの基本値

　“見積もりの基本値”は、「何を作るか？」をベースにして推定した値で、見積もりの基本中の基本です。この値は、実装する機能（および、非機能と性能も）が大きく、複雑なほど、見積もり値は大きくなります。例えば、「2階建てで、建坪が70坪の家を建てる」という要求を基にして、基本値を予測します。

　基本値を見積もる上で、考慮するのが「機能要求」「非機能要求」「性能要求」です。

機能要求　
これは、ソフトウェアの機能そのものであり、例えば、要求仕様書や、操作説明書に記述してあることを実装する場合に必要となる「基本工数」です。この値は、実現する機能が同じであれば、誰が見積もっても、あるいは、開発を担当するエンジニアがどの程度のスキルを持っているかにかかわらず、同じ数値になるはずです（実際には、見積もり者のスキルにより、値に大きなバラツキが生じます）。また、基本工数は、品質の高い・低いを考慮していないことにも注意してください。基本工数は、あくまで、“素の値”です。見積もりでは、機能の大きさや複雑さと、品質は切り離して考えます。
非機能要求　
機能以外の要求事項、例えば、ユーザーフレンドリネス（マニュアルを熟読しなくても、ソフトウェアを操作できるか？）、理解容易性（プログラムを分かりやすく作っているか？）、保守性（プログラムを改造しやすいか？）などがあります。非機能要求も、要求仕様書に記述しますが、機能要求に比べると優先度は圧倒的に低く、きちんとソフトウェアの中に実装されることは稀（まれ）で、努力目標で終わることも少なくありません。
性能要求　
応答時間、データ処理量、メモリ占有量など、性能に関する要求です。通常、性能要求は、要求仕様書にも明記しますので、必ず守らねばならない“重要項目”ですが、リアルタイムOS系の製品以外では、真剣に考慮されていないような印象を受けます。ハードウェアが日進月歩の進歩を続けているため、「高性能なハードウェアを導入すれば、性能要求は満足できるだろう」と考えるソフトウェア開発者が少なくありません。

　ソフトウェア開発における見積もりの第一歩が、機能要求・非機能要求・性能要求を基にした“基本値”です。この3つの要求は、必ず、要求仕様書に明記してあるはずです。

　世の中には、いろいろな見積もり技法がありますが、大部分はこの見積もりの基本値を予測しています。例えば、見積もりの王様といわれるほど、大昔から圧倒的多数で使われている「LOC（Lines of Code：ソースコードの行数）の見積もり」や、LOCには及ばないものの、精度の高さで一部から熱烈な支持を受け、新勢力として注目されている「FP法（Function Point：ファンクションポイント法）」などです（LOCとFPの詳細については、本シリーズの後半で説明する予定です）。LOCによる見積もりもFPによる予測法も、まずこの基本値を見積もるのが第一歩です。

その2：品質を考慮した見積もり値

　“品質を考慮した見積もり値”とは、その家をどの程度の品質で建築するかを考慮して、基本値を調整した値です。例えば、同じ70坪の2階建て家屋であっても、雨風が凌げさえすれば、倉庫みたいに居住性が悪くてもよいのか、きちんと設計し、最高の建材を使用して1ミリも狂いのない精密な家を建てるのかにより、投入工数は大きく（数倍？）変化します。

　基本値が、「What（ソフトウェアの何を作るか？）」を基に算出した値とすると、「品質を考慮した見積もり値」は、「How（ソフトウェアをどう作るか？）」を考慮した“推定値”といえます。

その3：実装能力を考慮した見積もり値

　“実装能力を考慮した見積もり値”は、その「機能要求＋品質要求」を誰が作るのかにより、変化する見積もり値です。基本値を求め、品質レベルを考慮して調整し、さらに、開発を担当するエンジニアの能力・経験を考えて、最終的な見積もり値を計算するのです。

　この見積もり値は、「Who（ソフトウェアを誰が作るか？）」により、大きく変化します。同じ家を建てるにしても、経験3カ月の見習いばかり10人で作るのか、経験20年で超一流の腕を持った大工の棟梁ばかりが10人集まって建てるのかでは、工数やスケジュールは大きく異なります。

　ソフトウェア開発の場合、この“人的要素”は、個人の経験や能力だけでなく、プロジェクト全体として、きちんとした開発プロセスが確立されているかに大きく依存します（正確に表現すると、CMMIにおける「プロセスの成熟度」が関係します。CMMIに関しては、別テーマとして取り上げる予定です）。素人が料理をする場合、毎回、順序が違い、味や調理にかかる時間は一定しません。一方、プロの調理人は、毎回カツ丼を同じ調理順序で作り、同じ味、同じ分量、同じ外見のものを同じ時間で仕上げます。これが、プロの技であり、ソフトウェア開発でも同様です。

　この実装能力を考慮した見積もり値は、「生産性」や「プロセス成熟度」を基に計算します。

　昆虫が卵からかえり、幼虫・サナギ・成虫に変態するように、ソフトウェアの見積もりも、「What」「How」「Who」を考慮して、調整やチューニングをしなければなりません。これにより精度の高い見積もりが可能になるのです。

　次回は、見積もりの基本技法として、「類推法」「積み上げ法」「パラメトリックス法」の3つについて解説します。ご期待ください！（次回に続く）

【筆者紹介】

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

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

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

「山浦恒央の“くみこみ”な話」バックナンバー