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

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

[辻 大輔，豆蔵]

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

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

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

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

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

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

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

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

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

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

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

見積もりは、プロジェクト遂行の足かせ？

　先にA社の基幹システムを開発したソフトウェア会社の見積書を見て、Y氏はがくぜんとした。見積書には「基幹システム 一式　\○○,○○○,○○○、設計書 一式　\○○,○○○,○○○」とだけ書かれていたのだ。

　Y氏は、X社では少なくとも「納品するシステムの機能や成果物の種類を明確にして、それぞれの算出根拠を明示した見積書を提示している」とB氏に説明した。しかし、「果たしてわれわれの見積もりで、顧客は納得するのだろうか？」と不安に感じた。

　そこで見積もりに対する不信感について聞いてみると、B氏は次の2点を挙げた。

• 見積もりに基づく発注の段階では、ベンダーを信用するしかない。納品されてみないと、何を手にすることができるのかが分からない
• おおよその予算やサービス開始時期はあるが、状況によっては変更の余地はある。こちらの要望が難しいなら「難しい」と言うなど、もっと相談してほしかった。わたしはCIOという立場上、その権限もある

　その一方でY氏は、これまでの自社の見積もりとその履行について自問した。時に、見積もり時に想定した規模がだんだんと膨れてきたにもかかわらず、コストやスケジュールは据え置かれることがある。顧客に相談しても見積もり（＝契約）を盾に一蹴されてしまうのだ。その場合、ベンダーは最も重要である機能や品質を犠牲にして、コストとスケジュールを死守することで、自身を防御せざるを得ないこともある。

　B氏へのヒアリングを終えたY氏は、「顧客とベンダーの双方にとって、見積もりがプロジェクト遂行上の制約となっている」という思いに至った。

　上記のような「顧客の不信感とベンダーの防御姿勢」を踏まえると、見積もりとは「金額の側面だけでなく、機能を含めた品質、納期の側面を含めた複合的なものでなければならない」といえる。また、両者の間で締結される契約（特に見積もり）に関しては、「双方を縛り付けるコミットメント」ととらえるよりも「双方が目指すゴールのベースラインを共有するもの」であるととらえるべきである。

　さらに、目指すべきゴールとは「その時点で最良だと考えられるもの」であり、時間の経過とともに変わるのは当然のことで、双方合意の下でコントールされるべきものだといえよう。

まず、見積もり方法を見直した

　Y氏は見積もりプロセスを見直すために、まず自社の現行の見積もり方法を分析した。現在、X社ではファンクションポイント法を用いた見積もりを実施しており、どのような機能がシステムに盛り込まれるかを明記している。WBS（Work Breakdown Structure）においては、成果物作成以外の付帯作業を明確にしていた。Y氏は、これらを初期ゴールとして設定することで、その後の変更プロセスのベースとしても顧客と共有できると考えた。

　また、見積もりはシステムの機能や成果物だけで決定されるものではなく、機能に表れない性能や利便性などの「非機能要件」と、顧客側の参画度合いや開発場所の分散度合いなどの「環境要因」などにも影響を受ける。

　X社ではそれらを「コスト変動要因」として扱い、システムの機能や作業などの「機能規模」と「コスト変動要因」に一定の「生産性係数」を掛けて最終的なコストの見積もりを算出していた。そのため、同じ機能でも高い利便性が要求されたり、過度のドキュメントが要求されたりすると「コスト変動要因」が増加し、見積もりコストに反映されるようになっていた（図1）。

図1：現行のコスト見積もり

　しかし、コスト変更要因の基準は、顧客に実際に明示されることはあまりなかった。なぜなら、現行の技術に即さない指標であったり、あいまいさを残した説明性の薄いものであったりするなど、実情に合っていなかったからだ。

　Y氏は、A社の不信感を一掃して納得のいく見積もりとその後の合意に基づく調整を行うためには「顧客の実情に合致した指標を過不足なく設定し、それらを双方で共有する必要がある」と判断した。

顧客の調整可能範囲を明確にする

　次に、Y氏はCOCOMOII（※1）やCoBRA法（※2）を参考にして、現行の変動要因を「プロダクト・プロセス・プロジェクト・人」の4つのグループに分類し、要因項目にヌケ・モレがないかを確認して、必要な項目を追加した。さらにそれぞれの変動要因について、顧客とベンダーのどちらで調整が可能であるかを整理した。

変動要因項目の整理

グループ	変動要因	調整担当
プロダクト	性能	顧客
	採用するプラットフォーム	顧客
	文書化の度合い	顧客
	：	：
プロセス	顧客の参画度合い	顧客
	レビューの実施度合い	顧客
	開発プロセスの成熟度	ベンダー
	：	：
プロジェクト	要求のあいまいさ	顧客
	スケジュールの厳しさ	顧客
	チーム内の役割分担	ベンダー
	：	：
人	分析者のスキル	ベンダー
	プログラマのスキル	ベンダー
	メンバーのモチベーション	ベンダー
	：	：

　（※1）COCOMOII法：1997年に提案された工数見積もりモデル。ソフトウェアで想定されるプログラム行数に開発者のスキルや要求の信頼性などを掛け合せて算出する。コスト変動要因が体系的に示されている。

　（※2）CoBRA法：ドイツのFraunhofer IESE（Institute for Experimental Software Engineering：フラウンホーファー協会 実験的ソフトウェア工学研究所）で開発された、見積もりモデルの構築手法。過去のプロジェクトデータとプロジェクトマネジャーの経験則をベースにして、工数に与える影響要因とその度合いを導出してモデルを構築する。

　この作業によって、顧客が調整できる項目をお互いで共有しモニタリングすることで、双方が合意した上で円滑なプロジェクトコントロールを促進することができる。

図2：変動要因を調整可能性で分類

　Y氏はベンダー側で調整できる項目については、コスト見積もりの観点では重要な項目であっても、顧客にはあえて開示しないことにした。例えば、分析者のスキルが低かった場合はコストが増加するが、この増分を顧客に提示したとしても到底納得してもらえないからだ。

　また、顧客の立場からみると、ベンダー依存の変動要因が生産性係数に包含されることで、ベンダー選定の基準となる「競争力」としてとらえることもできる（図3）。

図3：双方の共有範囲とベンダー競争力

　次に、Y氏は社内の有識者の意見と自身の経験を織り交ぜながら、これらの変動要因の尺度とコストに与える変動幅を明らかにした。例えば、「文書化の度合い」の項目を設定する場合、X社規定のサンプルと同じレベルであればコスト変動はないと見なし、「記述レベルの大小によって、±1％〜±1.5％の変動を見込む」といった具合である。

プロセス改善の効果

　Y氏のプロジェクトチームは、現時点で明らかとなっている機能と変動要因に基づき、見積書をB氏に提出した。その内容は以下の通りである。

1.　実現する機能の一覧

2.　設計成果物の一覧

3.　機能以外に含まれる作業

4.　顧客に最終決定権のある変動要因項目の評価

5.　上記1〜4を前提としたスケジュール

6.　上記1〜5を前提とした金額

　その上でY氏は、「見積もりとは品質（機能を含む）・コスト・納期が三位一体となったもので、どれか1つに変更があればほかにも影響を及ぼす」ことをあらためてB氏に説明した。

　この見積もりの内容を確認したB氏は、次のように評価した。

　「何を作ろうとしているのか理解できた。今後詳細を詰めていく上で明らかになる機能は、これをベースに状況の変化に応じて相談すればよい」

　既存の見積もりプロセスの効用ではあるが、満足してもらえた。また、

　「見積もりに含まれるX社の担当作業が明確になり納得した。ただ、われわれはシステム導入の経験が浅いので、見積もりには含まれないがこちらでやらなくてはならない作業が見えるとさらによい」

とも語った。

　そこでY氏は、A社が担当する作業をWBSに追記した。これらの項目は見積もり活動の対象外ではあるが、そもそも見積もり範囲を定義する際に範囲外を意識していなければ、本当の意味で範囲を定義したことにはならない。また事前に役割分担を明確にしておくことで、後の分担変更がやりやすくなるなど、今後プロジェクトをコントロールし調整する上でも選択の幅を広げることにつながった。

　B氏：「変動要因を明示してくれたことで、どういったことがコストやスケジュールに影響を与えるのかが理解できた」

　これはまさに「環境や状況の変化によっては相談してほしかった」というB氏の不信感をぬぐい去るためにプロセス改善を施した効果である。

　コストやスケジュールは機能の追加・変更だけでなく、非機能要件や外部環境要因によっても大きく影響される。Y氏が行ったように、機能以外の変動要因を可視化することで、顧客自らがプロジェクトの状況をコントロールでき、また顧客とベンダー、両者のコミュニケーションを促進させる効果もある。

二人三脚のプロジェクトコントロール

　Y氏が作成した見積もりを初期のゴールとして、A社のシステム再構築プロジェクトが開始された。進ちょく会議の場では、機能や変動項目について「ゴールとズレがないか、ブレを発生させるような事項はないか」を双方でチェックした。

　プロジェクトの設計工程の中盤あたりから、要件定義工程で定義した内容が変更されたり、要件が追加されたりすることが目立つようになってきた。これを危惧（きぐ）したY氏は、変動要因として挙げていた「要求のあいまいさ」を取り上げ、「当初見積もっていた評価よりも事態を重くみなくてはならない」とB氏に伝えた。

　これに同意したB氏は、業務を熟知したキーパーソンを設計レビューに必ず参加させることを決め、「要求のあいまいさ」のリスクをコントロールした。また、開始時に決めた機能のうち重要度の低い機能をプロジェクト対象から除外したり、顧客が許容できる範囲でドキュメントの記述レベルを落としたりすることで、それまでの変更や追加によるコストの増分を吸収させた。

　その後、結合テスト工程において、法改定の外部要因により機能追加を余儀なくされる事態が発生した。Y氏は、追加機能とそれに伴って影響を受ける変更機能を定量的に把握するとともに、生産性を少しでも向上させるべく開発プロセスの改善策を模索した。

　一方、B氏は導入計画をユーザー部門と相談して許容できる時期を明らかにし、またA社の経営陣と予算の上方修正の交渉を行った。これらの材料をそろえてから、この変更に対し、次のような決断を下した。

• 法改正による追加機能とそれに伴い変更を要する全機能の対応
• 当初18カ月間であったスケジュールの1.5カ月後ろ倒し
• 5％のコストアップ
• 結合テスト、総合テストの一部自動化

　この決断は、品質向上（機能性）という外部環境の変更に対して、開発ベンダー側での生産性向上コントロールと、顧客側でのスケジュール／コストコントロールによって「双方が納得のいく見積もり（ゴール）を調整した」といえる。

「Win-Win」プロジェクトのその後

　このプロジェクトは最終的に顧客の納得のいく品質、コスト、期日でサービスインを迎えることができた。B氏は非常に満足した様子で、今後もX社との付き合いを継続したいと提案してくれた。また、別のベンダーを選定する際にも「単に見積もりの総額を判断基準とするのではなく、機能や顧客変動要因とベンダー競争力をきっちり分けて判断できるような仕組みを整備していきたい」と語った。

　一方、Y氏も「見積もりの根拠となるコスト変動要因を顧客と共有することで、その後の変更に対する合意プロセスが協調的な形で促進されるメリットがある」と感じていた。また、今後の課題として、変動要因の尺度とその変動幅の精度を上げていく必要性があると考えた。

　X社では、この見積もりプロセスを組織として横展開し、実績データを収集して分析することで精度をさらに上げていく予定だという。

見積もりプロセスの改善ポイント

　今回は、顧客の見積もりに対する不信感を契機として、現行の見積もりプロセスをベースに機能以外の変動要因を可視化し、それらを顧客とベンダーで共有してモニタリングやコントロールすることで、双方が納得する変更プロセスを実現した事例を紹介した。

　以下に、今回の事例における「見積もりと変更の合意プロセス」の改善ポイントをまとめてみよう。

　・見積もりとは、プロジェクトの早期に提示した契約金額だけに注目するのではなく、Quality（品質）・Cost（コスト＝金額）・Delivery（納期＝スケジュール）の3方向から総合的に検討するものであり、プロジェクトのゴールそのものとして認識する必要がある

　・100％予測可能な見積もりはあり得ない。発注者と受注者が見積もりに対する変動要因とその設定方法に関するリスク内容を共有し、一緒にプロジェクトの変動要因をモニタリングしコントロールすることで、見積もったゴールに近づけることが重要である

　プロセス改善という観点では、生産性向上やコスト削減というベンダー内部の視点からだけでなく、顧客の立場に身を置き、顧客が「何に困っていて、何を求めているのか」という視点からプロセスを改善することも重要である。その効果は顧客満足度の向上、ひいてはビジネス関係の継続、ビジネス機会の拡大という形で表れるはずである。

＜筆者紹介＞

辻 大輔

株式会社豆蔵 BS事業部　エンタープライズチーム コンサルタント

専門分野：開発プロセス、要求開発

ソフトウェアベンダー数社でソフトウェア開発やSPI活動などに携わった後、2008年より株式会社豆蔵に在籍。現在はコンサルタントとして、ソフトウェア開発プロセスのアセスメントや適用支援に従事している。

関連ホワイトペーパー

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