開発対象の規模などいくつかの要素が決まれば、理論上、見積もり結果は一意に決まります。この記事では見積もり手法とその実施タイミングについて、私がよく実践していたやり方を説明します。
見積もりを行なうタイミング
システム開発は、システム化提案～基礎検討～要件定義～基本設計～詳細設計～コーディング～単体テスト～結合テスト～システムテスト～移行～リリース～保守の流れで進みます。
見積もりを行なうタイミングは、システム化提案、基本設計中盤、基本設計完了時の３つです。
システム化提案
まだ、仕事として正式受注しておらず、他の開発ベンダーと仕事の取り合いをしていたりする時期です。あなたのシステム化提案が投資効果の観点で採用基準を満たすかどうか、それがユーザー企業の気になっているポイントで、何かあれば「で、結局いくらなの？」「もっと安くならないの？」といった質問がたくさん飛んできます。
この段階では、RFP（提案依頼書：Request for Proposal）というユーザー企業が作成したシステム化要件の概要が記載された資料を受領しているだけで、要件の詳細はヒアリングできていません。それでも、上記の通り、なんらかの金額を提示しないと話が進みませんので、「概算見積もり」の手法で、見積もりを実施します。
基本設計中盤
画面・帳票設計、データベース設計・他システム連携のインターフェース設計がだいたい終わったタイミングで、「ファンクションポイント法見積もり」を使って、見積もり精緻化を行ないます。
システム化提案時の「概算見積もり」の見積もり精度はかなり荒く、後工程の見通しはあまり立っていないです。この基本設計前半のタイミングで「ファンクションポイント法見積もり」を行なうことで、やっと後工程に対して、精度の高い計画を立てることができます。
基本設計完了
基本設計完了時に、詳細設計以降の開発計画を立て、WBSを作成します。その際、各タスクの作業を見積もり、各作業の総合計として総開発量を算出します。これが「ボトムアップ見積もり」です。
ただし、新しい技術・処理方式を使うほど、未確定要素が増えます。また、開発規模が大きいと開発メンバーが増え、その力量を正確に測ることができません。そういった要因が多いほど、WBSの各要素の見積もりの精度は落ちていく点は念頭に置きましょう。
見積もり手法
上述の通り、フェーズ毎で、別々の見積もり手法を使います。
システム化提案段階では「概算見積もり」、基本設計中盤では「ファンクションポイント法見積もり」、基本設計完了時は「ボトムアップ見積もり」です。それぞれの見積もり手法について説明していきます。
見積もり精度は、「概算見積もり」＜「ファンクションポイント法見積もり」＜「ボトムアップ見積もり」の順で、開発後半になるほど見積もり精度が上がり、見積もりミスに起因する開発リスクが低減していきます。
概算見積もり
ユーザー企業から受領した「システム化要件の概要」をインプット情報として見積もります。従って、その情報の記載粒度次第で、見積もり手法も変わってくるのですが、多くのケースでは「類推見積もり」で行います。つまり、似たシステム・機能の開発実績値を元に見積もりを行ないます。
見積もり精度は最も低く、私の経験上、誤差2～5割くらいです。類似開発のサンプルが少ないほど精度は低くなりますが、誤差2割で収まるなら、かなりうまく見積もりできた方だと思います。誤差2割は、例えば1000万円と見積もったなら、実際の開発実績が、下限1000万円×0.8＝800万円、上限1000万円×1.2＝1200万円で、上下に200万円振れる可能性があるという意味です。
この見積り結果を元に、ユーザーに金額提示を行ないますが、上記の通り、上振れリスクが相当ありますので、それを考慮する必要があります。多めの金額を提示しておくか、見積もり書類の特記事項に、上振れリスクについて明記しましょう。（金額については、後工程での値上げはトラブルになるケースが少なくないので、上振れを考慮した多めの金額を提示しておく方が無難です。）
ファンクションポイント法見積もり
ファクションポイント法は、入出力の項目数に着目した見積もりです。例えば、画面の入力項目が多ければ、その分、入力チェックやサーバーへの項目連携が増え、開発量は大きくなります。他システムに連携するファイルの項目が多ければ、チェック処理とかデータベースへの格納処理が増えるのでやはり開発量は増えます。このように、画面・帳票・他システム連携で、機能・項目が多ければ多いほど開発量は増えますが、それを過去の開発実績から公式化し、項目数を入力値として機械的に計算、見積もりを出す手法がファクションポイント法です。
利用上の注意点が２つあります。
１つ目は、ファクションポイント法の精度が高い範囲は、詳細設計～接続テストの工程です。システムテストや移行にかかる開発工数は、品質や移行データ等に対する要件がプロジェクト毎に異なるため、機械的には見積もれません。簡易的に算出するには、ファクションポイント法で算出した詳細設計～接続テストの見積もり結果をインプットとして、一般的な工程別の工数比率割合を使い、算出します。
2つ目は、ファクションポイント法はビジネスロジックの複雑度は考慮できていないということです。従って、例えば、何かのシミュレーション計算など、高度な計算ロジックを持つシステムは、見積もり値が過小となるので、この見積方法は不向きです。
ボトムアップ見積もり
ボトムアップ見積もりは、個々の作業タスクの要素を見積もり、その合計を総開発量とします。この見積もり手法は、最も見積もり精度は高いですが、一つ一つの要素を見積もるのでもっとも時間がかかります。
この時、メンバーの力量を加味できると更に精度が上がります。新人がやるならちょっと多めに時間がかかるとか。ここで、プレイヤーとして優秀な人がプロマネだと、「なんで俺はできるのに、お前らできないの？」となって、過小見積もりしてブレが大きくなってしまいます。メンバーの力量を反映した見積もりを出すのがポイントになります。
進行中プロジェクトの計画フォロー
見積もりは、あくまでそれぞれの工程で入手できる最新情報を元に算出した予想値に過ぎません。普通は、予想通りに開発が進むことはなく、個々のタスクについて、見積もりの上振れ／下振れが発生します。（だいたい上振れが多いですが。）
1週間単位で、開発実績を計測し、見積もり値との誤差を確認し、必要があれば、残っている類似タスクに対して再見積もりをするなど誤差を修正して下さい。誤差が大きくなりそうな場合は、担当メンバーの力量不足、対象タスクの難易度の見極めが甘いなどの理由が考えられるため、メンバー交代・要員投入、リスケジュールなどの抜本的な対策が必要となります。
ポイントは、誤差が大きくなってから(開発が遅延してから)対応するのではなく、誤差が大きくなりそうだと予見できた時点で、事実確認の上、できるだけ早く対応することです。対応が遅れるほど、リカバリが大変になります。この予兆把握能力は、優秀なプロジェクトマネージャの必要条件の一つです。
リスクマネジメント
プロジェクトマネジメントとリスクマネジメントはセットで考えます。
つまり、開発が進むにつれ、見積もりと実績がズレていくのですが、そのズレを生む最大の要因がリスク(不確定要素)です。
例えば、新技術を採用するが実績がない、メンバーが新人ばかり、ユーザーの利害調整が大変、とかがリスクです。リスクは早期に潰す／小さくするのがセオリーで、一般的には、基礎検討・予備検討・POCと呼ぶ工程を要件定義の前段階で設けて、少なくとも新技術の検証とか、早めに低減できるリスクは潰しこんでおきます。
保守工程の見積もり
そもそも新規開発と、リリース後の保守工程での追加開発は難易度が全く違い、後者の方がずっと簡単です。上記の説明は、全て新規開発の際の説明でしたが、保守工程では、対象システムの過去プロジェクトを元に類推見積もりをすれば、実務上はあまり困らないと思います。
まとめ
システム開発では、見積もりを行なうタイミングは3か所あると説明しましたが、小規模のプロジェクトであったり、ユーザー交渉の状況次第では、見積もりのタイミングは減らしても構いません。
システム開発を円滑に進めるためには、見積もり算出やそれに基づいたスケジュール作成は、成功の一要素に過ぎず、リスク管理など他の要素も大事です。ひとまず、PMBOKの要素を全て押さえておけばよいのですが、実践レベルでどう使っていくかについては、また、別のコンテンツで説明したいと思います。
