プロジェクトが混乱する要因の多くが見積もりのミス。RFP(提案依頼書)の曖昧性を精査しないと大きなロスコストを招く。誰もが分かっていることだが、抜本的な対策を打つのは決めて難しい。

 「見積もり=不幸の始まり」、これは筆者が実施している見積もりセミナーで、見積もりに対するイメージを聞いたときに受講者から出てきた言葉です。

 プロジェクトが混乱する要因を分析すると、見積もりミスが必ず上位に登場してきます。発生したときのインパクトも大きくなります。筆者らがロスコストマネジメントに取り組むきっかけとなったのも見積もり起因のSロスを防止したいということでした。

 アンチパターンに入る前に、読み進むうえで必要な見積もりに関する知識を解説します。図1に見積もりのタイミングを示しました。

図1●見積もりのタイミング
[画像のクリックで拡大表示]

 見積もるタイミングによって留意点は変わってきますので、「○○見積もり」というように修飾語とともに表す必要があります。ここでは要件定義前に行う「試算見積もり」、要件がほぼ固まった段階で行う「概算見積もり」、基本設計終了後、ソフトウエアの形が固まったところで行う「詳細見積もり」と名づけています。

 それぞれの見積もりの主な目的は、試算見積もりが予算確保、概算見積もりがプロジェクトのスタート、詳細見積もりが下流工程の発注です(見積もりの全体像や詳細は拙著『本当に使える見積もり技術』を参照ください)。3つの見積もりの中で、プロジェクトのロスコストに大きく影響するのは、プロジェクトの条件やITベンダーが決まる概算見積もりです。概算見積もりは、RFP(提案依頼書)に基づいて行います。

 図2に示すようにRFPには、要件定義の成果物であるシステム概要やシステム要件、制約条件、プロジェクト計画が記述されています。中心になるシステム要件には、業務の階層や業務間の関連(業務プロセス)、業務の流れ(フロー)を定義する業務要件、データの構造やデータ関連、データ項目を定義するデータ要件、システム機能やシステム間の連携を定義するアプリケーション要件、非機能要件、技術要件が記述され、概算見積もりの入力になります。

図2●RFPに記載する項目
[画像のクリックで拡大表示]

 RFPの質は見積もり精度に直接影響しますが、要件をどこまで掘り下げて定義するかの基準はなく、大きくバラついているのが現状です。これがロスコストの要因となりますので、何に気をつければよいか、アンチパターンを基に見ていきます。以降、単に「見積もり」といった場合は、概算見積もりを指します。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら