プロジェクトマネジャーに贈るプロセス改善事例 第4回顧客を納得させた見積もりプロセスの秘訣とは？

見積もった計画の通りにプロジェクトを遂行することは難しいが、その精度が低いとプロジェクトの失敗や顧客の信頼失墜に直接つながってしまう。今回は顧客と協力して見積もりプロセスを改善した事例を紹介する。

[辻 大輔，豆蔵]

　システム開発の現場において、プロジェクトの早期に見積もった内容に基づき締結された契約が確実に履行され、かつ顧客の期待を十分に満たしているかというと懐疑的だと言わざるを得ない。顧客が不満足なシステムを渋々受け入れるケースや、開発ベンダー側が工数超過を受け入れるケースなど、さまざまである。いずれにしても顧客とベンダーは、どちらかに不満を残す「Win-Lose」の関係で決着を見る。ひどい場合には、ベンダーが人員の追加投入や時間外労働を重ねてようやく作り上げたシステムが、顧客の満足を得られないという「Lose-Lose」の関係となり、誰も得をしないといったことも散見される。

　こういったことが起こる一因として、システムが複雑すぎて可視化しづらいことによる「システム要件の不明確性」や人間系が絡むことによる「不確実性」などが、見積もりや契約に織り込まれていないことが考えられる。

　今回は、顧客とベンダーが見積もり内容を共有し、モニタリングを通して双方にとって納得のいく変更が行えるようにした事例を紹介する。見積もり活動や変更活動を改善しようと考えている読者にとって、少しでも参考となれば幸いである。

発注者に不信感を与えた“見積書”

　「ベンダーさんの見積もりってこんなものですか？」

　システム開発を請け負うX社のプロジェクトマネジャーであるY氏は、中堅人材サービス会社A社のCIOであるB氏からこう尋ねられた。

　A社は自社の基幹システムの構築をあるソフトウェア開発会社に一括発注したが、納品されたシステムは業務に耐えうる機能とパフォーマンスを兼ね備えているとはとても言い難いものであった。

　このシステムを廃棄して再構築することを決めたB氏は、新たな発注先としてX社を選定し、Y氏と打ち合わせを行っていた。

　B氏は失敗した原因を分析し、「契約前の見積もり」を大きな原因の1つとして挙げた。その経緯は以下の通りであった。

• もともとA社はシステム構築の経験が浅かったこともあり、見積もりを含めたシステム開発プロセスがどういうものであるか分かっていなかった
• 受注側とは、要件定義でヒアリングした内容に基づいたシステムとその設計書を納品するという契約をした
• A社には使えないシステムとその断片的な設計書、見積書通りの金額が記載された請求書が残った

　どうやらB氏は見積もりに端を発して、ベンダーに不信感を抱いているようであった。

関連ホワイトペーパー

ベンダー | 基幹システム | 開発プロセス | コミュニケーション | 顧客満足 | システム構築