見積もりの段階で要求事項や仕様が確定していることはほとんどない。だから,ベンダーがユーザーから完全なRFP(提案依頼書)を提示されることは少ない。

 だが「こんな感じの機能(業務)を実現してほしい」というユーザーからの要求に対し,前提条件もなく,見積もりの根拠も提示しないで概算見積もりを提出したプロジェクト・マネージャ(PM)は,私の知る限り,例外なく不採算プロジェクトへと導いている。

 なぜ,不採算プロジェクトとなるのか。それはベンダー,ユーザーお互いが,見積もりに明示されていない前提条件を都合よく解釈するからである。

 勤務表のシステム開発を例に挙げてみよう。ベンダーは,当月の就業時間の集計処理(バッチ処理)までを実装できればよいと考える。ところが,ユーザーは人件費を計算する基幹システムへの伝送処理までが見積もりに含まれていると解釈する。その結果,開発が終わった後でユーザーは「既存システムへの伝送処理が含まれるのは当たり前だ!」とクレームを付ける。

 「その作業は見積もりに入っていると思った」「こんな性能や操作性では仕事にならない」といった会話が交わされる現場は,残念ながら少なくない。そうした事態は,開発のスコープやシステムの性能,操作性,信頼性,移行,日程,作業分担,責任範囲などが不明確,すなわち前提条件として列挙されていないために起こる。

 では,どうすればよいか。要件があいまいな部分や決定していない事項については,仮の要件を設定して見積もればよい。仮の部分を「前提条件」として明文化し,前提条件が変われば見積もりも変わることをユーザーとベンダーが合意しておくことがポイントである()。

表●前提条件の例
表●前提条件の例

 見積もりは,システムのイメージがわきやすい形で提示しなければならない。重要なことは,これから開発するシステムのイメージをユーザーとベンダーとの間で共有することである。プロジェクトの間,常に「前提条件」をお互いに意識できれば,後でもめるという事態は減る。

 そのためには,例えば変更管理委員会(CCB:Change Control Board)のような組織を設置する。そこに,ユーザーにも参加してもらう。仕様変更が発生したら,常に前提条件と照らし合わせて判断できるよう変更の手順を明確にし,意識し続けるようにするのである。

千種 実(ちくさ みのる)
日立システムアンドサービス
プロジェクト推進部 部長
1985年,日立中部ソフトウェア(現 日立システムアンドサービス)に入社。入社以来,一貫してプロジェクト管理に従事。PMOの立場でトラブル・プロジェクト支援を数多く経験した後,社内のプロジェクト管理制度の構築やプロジェクト管理システム(PMS)開発およびプロジェクト支援,プロジェクト・マネージャ教育講師に携わる。また,他社のプロジェクト管理に関するコンサルティングや研修講師,講演などを経験し,現在もPMOの立場からITプロジェクトを成功へ導くために幅広く,社内外で活動中。1962年,三重県出身。岡山理科大学理学部応用物理学科卒。