見積もり仮想体験、準備から始めるべし：プロジェクトの闇、見積もりに光を！（2）（2/2 ページ）
見積もりに必要な情報とはどのようなものだろうか？ 具体的なシステム・モデルを例題として見ていこう。
RFPから読み取れる要素をまとめる
まずRFP（Request For Proposal：提案依頼書）から読み取れる要素をまとめましょう。
次の表は、RFPと顧客へのインタビューの結果のダイジェストを、機能の広さ、タスクの深さ、品質の重さにまとめたものです。記事で紹介するために圧縮してまとめたことをご了承ください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
開発後に計測したこのプロジェクトの実費用は、コストが12人月程度、作業人員数が2?4人体制で、工数が15人月でした。
機能の広さから見積もりを計測するFP（ファンクションポイント）法、タスクベースのアプローチによるタスク積み上げ法による見積もり、ユースケースポイント法による見積もりを比べてみます。
りFP法による見積もり
FP法自体の詳細な説明は省きます。このFP法ですが、非常に多数に枝分かれし、さまざまな方法が並存しているのが実情です。
FP法の基本は、インターフェイスに着目し、その数を数えることにより機能の広さを見積もる方法です。つまり、「画面の数は何枚、想定されるデータベーステーブル数はいくつ」という数を数えることからファンクションポイントという見積もりのポイントを割り出します。
さらにこの方法では、画面を「複雑」「平均的」「簡易」などの段階に分けていきます。
FP法のメリットとしては、次のようなことが挙げられます。
- 画面やテーブルの数など顧客からも分かりやすく客観的である
- その使いやすさから、非常に実績があり最も用いられている
- 実績が多いので係数などが比較的正確である
逆にデメリットとしては、次のようなことが挙げられます。
- ロジックの複雑さなどを盛り込みにくい
- インターフェイスを持たないシステムに向かない
- タスクの深さや、品質の重さを盛り込みにくい
- 外部設計がある程度進まないと見積もりができない
特に多くの場合に問題になるのが、Dでしょうか。外部設計がある程度進んだ段階では、見積もりが比較的正確にできますが、本格的にプロジェクトがスタートしていないような初期の「ザックリと見積もりをお願いします」といわれるようなケースなどでは用いにくい手法です。
また、プロジェクトが大きくなると画面やデータベースのおよその数が分かるまでに多くの時間とコストを費やしてしまいます。
それでは次回、具体的な計測方法や見積もりを行っていきたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.