見積もり仮想体験、準備から始めるべし：プロジェクトの闇、見積もりに光を！（2）（2/2 ページ）

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

RFPから読み取れる要素をまとめる

　まずRFP（Request For Proposal：提案依頼書）から読み取れる要素をまとめましょう。

　次の表は、RFPと顧客へのインタビューの結果のダイジェストを、機能の広さ、タスクの深さ、品質の重さにまとめたものです。記事で紹介するために圧縮してまとめたことをご了承ください。

機能の広さ
入室時タッチ機能（クライアントアプリケーション） 利用者機能 IC情報の読み取り（IC認証、操作結果の表示）
端末管理機能（クライアントアプリケーション ネットワーク設定機能 ICデバイス設定機能 表示画面・文言設定機能
Web管理画面機能（Webシステム） ID・パスワード認証機能 IC情報データベース機能 端末操作情報データベース機能 利用者管理機能 管理者機能 メールテンプレート機能 メール配信機能 端末管理機能
そのほかの機能 情報保護期間の経過したデータの抹消機能

 

タスクの深さ
インフラの選定・構築も施工範囲
クライアント機能のパフォーマンスが重要なため、パフォーマンステストと継続運用テストが重要（レポートも必要）
オンサイト顧客ではないため、設計書・仕様書を充実させる必要があり

 

品質の重さ
クライアント機能 設置端末のため機能停止はNG。再起動なども困難
Web管理画面機能 管理者のみ使用のため、再起動も可能 パフォーマンスも重要ではない
可用性 物理的なサーバのダウンもリスクとして認知→多重化は行わない 情報管理システムのためバックアップによる情報保全は絶対

　さて、これらの要素を、早速複数の見積もり手法を利用して流し込んでいきましょう。

概要設計の結果
実装行数 データベース点数、項目数	テーブル数9
画面点数、項目数	管理画面30画面程度
クライアント画面（非常に複雑）	3画面程度（普通は8画面程度）

　開発後に計測したこのプロジェクトの実費用は、コストが12人月程度、作業人員数が2?4人体制で、工数が15人月でした。

　機能の広さから見積もりを計測するFP（ファンクションポイント）法、タスクベースのアプローチによるタスク積み上げ法による見積もり、ユースケースポイント法による見積もりを比べてみます。

りFP法による見積もり

　FP法自体の詳細な説明は省きます。このFP法ですが、非常に多数に枝分かれし、さまざまな方法が並存しているのが実情です。

　FP法の基本は、インターフェイスに着目し、その数を数えることにより機能の広さを見積もる方法です。つまり、「画面の数は何枚、想定されるデータベーステーブル数はいくつ」という数を数えることからファンクションポイントという見積もりのポイントを割り出します。

　さらにこの方法では、画面を「複雑」「平均的」「簡易」などの段階に分けていきます。

　FP法のメリットとしては、次のようなことが挙げられます。

1. 画面やテーブルの数など顧客からも分かりやすく客観的である
2. その使いやすさから、非常に実績があり最も用いられている
3. 実績が多いので係数などが比較的正確である

　逆にデメリットとしては、次のようなことが挙げられます。

1. ロジックの複雑さなどを盛り込みにくい
2. インターフェイスを持たないシステムに向かない
3. タスクの深さや、品質の重さを盛り込みにくい
4. 外部設計がある程度進まないと見積もりができない

　特に多くの場合に問題になるのが、Dでしょうか。外部設計がある程度進んだ段階では、見積もりが比較的正確にできますが、本格的にプロジェクトがスタートしていないような初期の「ザックリと見積もりをお願いします」といわれるようなケースなどでは用いにくい手法です。

　また、プロジェクトが大きくなると画面やデータベースのおよその数が分かるまでに多くの時間とコストを費やしてしまいます。

　それでは次回、具体的な計測方法や見積もりを行っていきたいと思います。

筆者プロフィール

佐藤 大輔（さとう だいすけ）株式会社オープントーン社長。会社設立前は大手システム会社などで多くのシステム開発に、主にマネージャとして携わった経験を持つ。

「プロジェクトの闇、見積もりに光を！」バックナンバー

• 見積もり仮想体験の旅へ、いざ出発！
• 見積もり仮想体験、準備から始めるべし
• 見積もり、まずはざっくり理解せよ