見積もり精度を高める実践テクニック

<pre>

ーザー企業に納得してもらい、かつプロジェクトの利益を確保するためには、どんな見積もりを行えばよいのか。そのカギを握るのが、システム特性とリスクをしっかりと検証、分析し、すべての費用項目を洗い出すことだ。

中村 一世（なかむら いっせい） 東洋ビジネスシステムサービス　取締役 テクニカルダイレクター

　「標準的な見積もり技法を使って見積もりを行っているのに、大きなずれが生じることが多い」──。見積もりに関して、こうした悩みを抱えるITエンジニアは多い。

　第1部でも触れたように、システムに求められる要件やシステム構築の手法はますます複雑化し、見積もりもどんどん困難になっている。そうした状況で精度の高い見積もりを行うためには、標準的な見積もり技法を的確に使いこなす必要がある。ただし、それだけでは十分ではない。標準的な見積もり技法を使っていても、(1)システム特性を十分に考慮した見積もりを行っていない、(2)リスクの徹底的な洗い出しとその対策を実施していない、(3)投入資源や経費などを含めたすべての費用項目を洗い出していない、といった理由で、結果的に大きなずれが生じてくるからだ。

　言い換えれば、精度の高い見積もりを行うためには、これらをきちんと実施することが欠かせない。見積もりに「王道」や「近道」は存在しないのだ。そこでここでは以上の3つのポイントについて、具体的に実施すべき作業や、作業時の注意点を解説する。

システム特性の把握が前提

　まず見積もりの作業手順を確認しておこう（図1）。「システム特性の見極め」や「見積もり対象のスコープ決定」から、「利益を算出」までの大きく9つのステップから成る。

　この中で、最初の「システム特性の見極め」は、見積もりの前提となる非常に重要な作業である。システム特性は見積もり工数に大きな影響を与えるだけに、できるだけ詳細に検証することが欠かせない。

　見積もり技法によっては、確認すべきシステム特性の項目を独自に定義しているものがある。例えばFP法では、「性能目標」や「トランザクション量」など14項目を定義している。しかし、「データ通信」や「利用制約（セキュリティ）」などの項目は、今や常識的なものであり、複雑度の指標としてはそぐわない。

　そこで筆者は、各種見積もり技法が定義しているシステム特性から現時点で有効と思われるものを選択し、それに自身の経験をプラスして、システム特性のチェックリストを作成した（表1）。ここでは、システム特性を「システムの形態」や「ユーザー要件」、「データ処理量」など大きく7つに分類した。ウエイト計算を加味する定量化部分ができていないため、まだまだ未完成だが、これを使えばシステム特性に関する項目の見落としが減るはずだ。またユーザー企業にとっても、RFP（提案依頼書）作成時の参考になるだろう。

図1●実践的な見積もりの手順 見積もりの精度を高める際のポイントは、採用する見積もり技法にかかわらず、「システム特性」と「リスク」をいかにして見極め、見積もりに反映させられるかにある。システム特性については、検討もれがないようにチェックリストを作成するなどして対応すべきだ

表1●見積もりの前提となるシステム特性のチェックリストの例 見積もりを行う際は、ベンダーがRFPを基にして、以下の項目について詳細を洗い出す必要がある。洗い出した結果は「複雑度」として係数化して、見積もりに反映させることが望ましい [画像のクリックで拡大表示]

前提条件が見積もりを左右

　表1に掲げたシステム特性の項目の中で、見積もりを左右するものとして最も重要なのが「システムの形態」だ。システムの形態とは、システムの種類やデータ・ファイル数、パッケージの利用有無などを指す。

　システムの種類には、企業の基幹業務をこなす基幹系や、ビジネス上の意思決定や判断を支援する情報系、マスターデータの登録に特化したリソース系などがある。これらの種類によって、扱うデータの種類や量、確保すべき品質、作成するドキュメントなどが異なってくる。それらが工数の違いにつながることは言うまでもない。

　システムの種類を十分に見極めた上で、次に行うのがシステムを構成する機能の洗い出しだ。把握すべき機能の種類は、見積もり技法によって異なるので注意が必要である。

　例えばLOC（Line of Code）法では、オンライン系（3種類）とバッチ系（4種類）に分けて機能を洗い出す。またファンクション・ポイント法の場合は、外部入力、外部出力、外部照会など5種類について洗い出す。

　洗い出した結果は、見積もりのベースとなり、各技法で定義している手順に従って、システム規模や工数に換算する（図2、図3）。

　どれほど工数を正確に積み上げたところで、システム特性を見誤ると見積もりはずれてしまう。システム特性の的確な把握が精度の高い見積もりにつながることを忘れないでほしい。

図2●LOC法による規模と工数の算出手順 LOC法では、「1機能当たりのステップ数」と「生産性係数」はプログラミング言語ごとに別途用意する。LOC法はメインフレーム時代の標準的な見積もり技法だったが、システムの主要な形態がクライアント・サーバーシステム、Webシステムへと変化するに伴い、使われなくなってきている

図3●Dファンクション・ポイント法による規模と工数の算出手順 国際標準の「IFPUG」に沿った流れを示した。FP法を用いる際のポイントは、過去の開発実績を蓄積して、「一般調整係数」と「生産性係数」の精度を高めることである

リスク分は原価の20％以下に

　見積もりの精度を高める第2のポイントが、リスク分析の実施である。具体的には、リスクの洗い出しと、その対策を立てることを指す。

　リスク分析は、「利益」に大きな影響をもたらす極めて重要な作業である。見積もり時に、利益は通常、「予想利益＝契約額－予想原価」として想定する。しかし予想原価と実際の原価は異なり、「予想原価＜実際原価」となる場合がほとんどだ。

　この差は結局、リスクが現実のものになってしまった結果である。見積もりの段階で、きちんとリスクを洗い出し、対策を講じていれば、実際の原価はほぼ予想通りになるはずだ。

　筆者の経験では、リスク対策として発生する費用が、予想原価の20%にあたる額を超えなければプロジェクトは失敗しない。言い換えれば、ベンダーにとっては、「予想原価の20％以内」に押さえられるようなリスク対策を講じることが、利益確保の最大のカギとなる。

　リスク分析は一度だけで終わらせるべきではない。システム特性を検証する場合、システム規模を見積もる場合など、見積もり作業のあらゆるフェーズにおいて、リスクを洗い出し、その対策を立てる必要がある（表2）。

　例えばシステム規模を見積もる際の最大のリスクは、当初のシステム要件の捉え方が浅く規模を過小評価するというものだ。実際に設計を始めたら見えていなかった部分が見えてきて、予想以上にシステムの範囲が肥大化するというケースがある＊1）。

　具体的には、システム要件としてRFPには記載されていないが、ユーザー企業が「レガシー・システムの機能の保証」を求めているという場合が、それに当たる。プロジェクト・メンバーにレガシー・システムに詳しい人がいないときには、必ずと言っていいほど発生するリスクだ。運用テスト段階で次々と例外処理が表面化して、レガシー・システム機能の保証に手こずってしまうのである。対策としては、企画段階で経験豊富なメンバーが業務構造をしっかりと見極めると同時に、RFPの記載精度を向上させる必要がある。経験者による見積もりレビューも欠かせない。

　必要な人材と要員数を確保できるかどうかも、大きなリスク要因である。どのベンダーもプロジェクトへの投入リソースを切り詰めている現在、むしろ確保できない場合の方が多い。その場合を考えて、経験豊富な人材をプロジェクト・メンバーとは別にアドバイザー役としてアサインしたり、バックアップ体制を整備するなどの対策をとる必要がある。

　システム開発の過程で作成する様々なドキュメントも、工数を増やすリスクの温床となる。案件によっては、ドキュメントをISO9000（国際標準品質基準）、FDA（米国食品医薬局）規制のコンピュータ利用基準、薬事法GMP（医薬品製造基準）のコンピュータバリデーションなどに対応させなければならない場合がある。ドキュメント記載内容を基準に合わせなければならないので、こうした要件には注意が必要だ。一般に、規制対応ドキュメントは、通常の1.5倍位の手間がかかると考えてよい。またユーザー企業が本番業務で支障をきたすものは、ベンダーの「瑕疵責任」として保証を求めるケースがある。この場合はリスクが高くなるので、業務に精通したレビュアーを「クオリティ・エンジニア」としてアサインすることだ。

　ただしベンダーがこうした「リスク」を洗い出して対策を費用化しても、見積書に記載してユーザー企業に納得してもらうことは難しい。そこで、リスク対策費を作業者の単価に盛り込んで計算することが多い。許容範囲外のリスクはレビュアーの追加コストや、場合によってはリスク分を開発期間に組み込んで提示額に反映させるという方法もある。

表2●見積もり時に考慮すべき主なリスクとリスク回避策の例 リスクの分析は1度だけでは終わらない。見積もりの各ステップに応じて、随時リスク分析を行う必要がある [画像のクリックで拡大表示]

最適なマシン環境を準備する

　発生し得るすべての費用項目についてコストを算出するのは、見積もりの基本である。だが、規模と工数の見積もりに目がいくあまり、見落とされがちな費用項目がある。「投入する資源」と「経費」がそれだ。

　システム開発プロジェクトに投入する資源には、「体制」、「設備」、「資材」の3つがある（図4）。体制とは、プロジェクトにどのような要員で臨むかを意味する。つまり、プロジェクト・マネジャーの候補者やSE、プログラマのスキルレベルや数などをリストアップする。

　体制」は人件費に直結するので、見落とす人はあまりいないだろう。しかし、設備と資材の見積もりは、おろそかになりがちである。

　設備とは、「マシン環境」と「作業環境」から成る開発環境を意味する。見積もりを行う際は、どのような開発環境が必要になるのかを考慮しなければならない。ポイントとなるのは、「開発担当者、テスト担当者が快適に作業できるだけの性能、容量があるか」、「大量のテストデータを誰がどのようにして準備するのか」などだ。

　マシン環境は以前に比べて、構築方法の種類や選択肢が増えている。メインフレーム時代は、開発環境とテスト環境が同じマシン上にあることが一般的であり、テストデータも作成しやすい環境にあった。だがオープン・システム時代になると、開発、テスト、本番と利用目的ごとにサーバーを分離することが一般的になった。また高速ネットワークが廉価になったおかげでサーバー設置場所と開発場所が同一場所でないケースも多い。それらを考慮して適切な環境を構築しなければならない。

　またマシン環境をユーザー企業とベンダーのどちらが用意するのかも、決めておく必要がある。例えば開発用のPCは、最近ではベンダーが持ち込むのが当たり前になっている。テスト機や本番機をホスティング（レンタルサーバーとも呼ぶ）としてベンダー側が用意するケースも出ている。だが、セキュリティの観点から、外部のマシンの使用を認めないユーザー企業もあるので、確認が必要だ。

　作業環境として考えるべきなのは、開発および会議の場所と、スペースの大きさだ。開発者の作業スペース不足、会議スペースや数の不足で、必要な会議や打ち合わせが十分にできない光景をよく目にする。作業場所の劣悪さはシステムの品質に跳ね返ってくることを忘れてはならない。

　また「ユーザー教育場所」の確保も忘れてはならない。ユーザー教育場所の大きさ、機材、対象者数など、教育場所としての適合性が重要だ。教育環境は忘れがちだが、システムの効果的な運用を考える上で、欠かせないファクターである。

　資材とは、事務机、コピー機、印刷用紙などの備品を指す。これらについてもユーザー企業とベンダーのどちらが資材を負担するのかを詳細に決めておく。最近はドキュメント類をCDに格納するケースも出てきたが、まだまだ紙での納品は多い。レビュー者数が多い場合など、ドキュメントは結構な枚数になり、紙代やコピー代も決して馬鹿にならない。

図4●資源見積もりの3要素 プロジェクトに投入する資源には、大きく「体制」、「設備」、「資材」の3つがある。資源を見積もる際のポイントは、それぞれに潜むリスクを十分に考慮すること。そして、顧客とベンダーのどちらが用意するかを明確にすることである

　資源は、どのようにしてコストとして見積もるのだろうか。その方法は主に2つある。第一に、人件費や設備費、資材費を合算した「人月単価」を設定して工数に乗じる方法。第二に、人月単価は労務費部分だけにとどめ、工数に人月単価を乗じた金額と、設備と資材にかかる金額を合算する方法だ。

　第一の方法は、高額な設備や資材をユーザー企業に負担してもらうことを前提とした場合や、中小規模の手組みによる開発案件などで用いる。一方、第二の方法は、設備や資材をベンダーが用意するケースや、大型案件、パッケージ・ソフトを利用したシステム開発などで用いる。その場合の人件費は、アサインされた期間と工数積算の両面から算出する。具体的にはプロジェクト・マネジャーやコンサルタント、運用テスト担当者などの人件費は、アサインされた期間から算出し、開発者は工数を積み上げて計算する。

　なお、ベンダーによっては、両方の方法でコストを算出し、「ユーザー企業に提示する金額」と「自社の管理用の金額」として使い分けるところもある。

見落としがちな必要経費

　プロポーザル費や旅費宿泊費、会議費、通信費、保険料といった経費も見落としがちな項目である。

　プロポーザル費とは、受注前の情報収集や提案書の作成といった作業にかかる費用を指す。通常は、案件を受注した場合は案件の原価に計上し、失注した場合は販売費とする。

　最近は、一定予算以上の案件は、ユーザー企業が相見積もりを取るのが一般的になっており、競合するベンダー数も増加の傾向にある。このためベンダーはプロポーザル費を案件に計上できないケースが多い。これらのコストを抑えるためには、提案書を標準化したり、提案力の強化によって成約率を上げる努力を続けるしかない。

　パッケージ・ソフトを採用し、海外から技術者を招へいする場合は、通信費や旅費宿泊費の扱いに注意したい。費用をベンダーが持つのか、ユーザー企業が持つのかで、もめるケースがあるからだ＊2）。

納得感を高める記載方法

図5●理想的な見積書の様式例 ポイントは大きく3つ。1つ目は作業内容を「システム開発」と「環境関連」に分け、作業に対する価格の根拠を示した。2つ目はユーザー企業が金額の妥当性を評価しやすいよう「生産性指標」とフェーズごとの「作業分類」を記載した。3つ目は品質面の体制強化のために「クオリティ・エンジニア」を置いた [画像のクリックで拡大表示]

　「見積もった内容を、見積書にどの程度の詳細さで記述すればよいのか」という声をよく聞く。筆者の経験を踏まえて言うと、見積書に示す項目の詳細さは、ユーザー企業が見積もりを評価する際の大きなポイントになる。「一式いくら」では金額の根拠が全く分からない。かと言って詳細すぎてもユーザー企業がすぐに内容を理解できない。

　そこで最後に、今までの内容を踏まえて、筆者が作成した理想的な見積書のサンプルを示す（図5）。項目としては、作業内容を「システム開発」と「環境関連」に分けて列挙した。各項目には「作業分類」を示し、ユーザー企業が具体的な作業内容を理解しやすいようにした。項目の記述は、このようにユーザー企業が理解できると思われるレベルまで詳細にすることが大切だ。逆にあまりにも詳細に記述すると、専門的になりすぎて「難解」な見積書になってしまうので注意してほしい。

　またこの見積書では、ユーザー企業が金額を評価しやすいように「生産性指標」を記載した。「ステップ当たりの生産性」と「FP当たりの生産性」の両方を記載し、各作業の費用への納得感を高めてもらおうとしている。品質を高める体制作りとして「クオリティ・エンジニア」を加えたのも、ユーザー企業の納得感を高める工夫の1つである。なお、提示した見積書は、実際に利用されているものではないことをお断りしておく。

　今、ベンダーには、ユーザー企業のニーズを実現しながら、しっかりと利益を確保する見積もりの方法を確立することが求められている。そのためには、理論を学ぶと同時に、現場で様々な経験を重ねることが欠かせない。そのことを理解し、バランスのよい実践的な見積もり技術を身に付けてほしい。

</pre>