見積もり、まずはざっくり理解せよ：プロジェクトの闇、見積もりに光を！（1）（1/2 ページ）

2009年度から適用される工事進行基準が、ソフトウェアの開発現場に大きな影響を与える。そこで本連載では、工事進行基準を採用する際に重要になるいくつかの項目のうち、見積もりに関して解説する。

[佐藤大輔，株式会社オープントーン]

　最初に、工事進行基準に関して簡単におさらいしておこう。

　工事進行基準とは、＠ITのニュースによると「会計基準の変更によって2009年4月にシステムインテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進ちょく度に応じて、分散して計上する仕組み」とあります（「デスマーチがなくなる？ IT業界に義務付け『工事進行基準』ってなんだ」を参照）。

　この工事進行基準を適用するためには、「工事収益総額」「工事原価総額」「決算日における進ちょく度」の3つを、信頼性をもって見積もることが必要となります。この3つの条件を工事進行基準適用の3点セットと呼ぶことにしましょう。工事進行基準に関しては、前述の記事のほかに下記の記事を参考にしてください。

関連記事
・工事進行基準（＠IT情報マネジメント用語事典）
・工事進行基準を分かりやすく解説してみよう【基本編】（＠IT News）
・“とりあえず”が通用しなくなる『工事進行基準』の世界（＠IT News）
・5分で絶対に分かる工事進行基準（＠IT情報マネジメント）

　この3点セットを見ても分かるように、どれもプロジェクトに関係が深いものばかりです。まさにプロジェクトの動向が企業の決算に大きな影響を与えるわけです。これを機に、いい加減な見積もりや進ちょく管理から脱却を図ろうとする企業が多くなりそうです。

　つまりこれを機会に3点セットをクリアできるような体制作りを会社、組織で行っていけば、開発現場にとっても大きなチャンスにもなる可能性が高いと思います。例えば、工事進行基準にきちんと対応できる企業の方が信用度が高くなる、そんな企業に開発を依頼したいと考えるユーザー企業が増えるかもしれないなどです。

　そこで本連載は、この3点セットのうち見積もりに焦点を当て、何回かにわたって解説していきたいと思います。

　それでは、見積もりの世界に皆さんを招待しましょう。

さまざまな見積もりの手法

　1960年代以降、主にIBMや米国の政府機関などがコンピュータソフトウェアの重要性と規模の高まりに応じて見積もりについての研究を始めています。

　見積もり手法の代表的なものとしては、1979年にIBMのアラン・J・アルブレクト（Allan J. Albrecht）が提案し、その後改良されたファンクションポイント（FP）法があります。このファンクションポイント法の特徴の1つは、プログラミング以外のものを見積もりのための尺度としたところです。そのほかにもCOCOMO、さらにその発展系のCOCOMO IIやオブジェクトポイント法、ISBSG、ユースケースポイント法など、それこそさまざまな見積もり手法が存在します。

　複数の見積もり手法が登場したことから、それら同士で情報共有するために変換可能な見積もりの尺度の共通化が図られてきました。その一般的な尺度として定着したのがLOC（Lines Of Code）とFP、そしてMM（人月）です。

　これら共通の尺度を用いることで、プロジェクトの「予実」、つまり見積もりと実コストの差異などの実績を比較検討できるようになったのです。

　皆さんには今回、「見積もり」を見直さざるを得ないこの機会に、ぜひ「ソフトウェア業界全体の資産」ともいえるこれらの実績を利用し、「客観的」でかつ「実績」と「信頼できる精度」を得られるよう、見積もり手法を身に付けていただけたらと思います。

複数の見積もり手法を使う

　ところでなぜ、さまざまな見積もり手法を使わなければいけないのでしょうか。

　ソフトウェア開発のプロジェクトとひと口にいっても、基幹業務、WebのECサイト、ドライバソフト、携帯ソフト、ゲームソフトなど、見積もりの対象の要素が異なるソフトがたくさんあります。

　まったく画面のないドライバソフトと、基幹業務のソフトを同じ手法で見積もるのは困難です。ですので、まずソフトの特性によって使うべき見積もり手法も分かれるのが普通です。

　さらに、ソフトウェアの見積もりのさまざまな切り口からも、使うべき見積もり手法が異なることが多いのです。

　見積もりに対するアプローチの仕方で最も重要なのが、見積もりの対象を数えることでしょう。主要な数える要素として考えられるのは機能の数です。私はこれを「広さ」ととらえています。また作業の工数を「深さ」と例えます。そして非機能要件などをシステムの「重さ」としてみましょう（図）。

図　立方体で機能の数である広さと、作業（タスク）の深さ、非機能要件などの重さで、システムの大きさを表す

　このように、見積もりに対するアプローチはさまざまです。これをまとめると、以下のように分かれます。

1. 機能ベース：画面の数やコード行数によって機能の「広さ」を見積もるアプローチ
2. タスクベース：WBS（Work Breakdown Structure）を引き、それぞれの作業時間・人数からタスク「深さ」を見積もるアプローチWBS（Work Breakdown Structure）を引き、それぞれの作業時間・人数からタスク「深さ」を見積もるアプローチ
3. 要求品質ベース：非機能要件、特に要求品質の重要さで見積もりの重さを見積もるアプローチ

　この3つのアプローチの見積もり方法について、例を挙げてみましょう。