プラント建設プロジェクトでは,コントラクタ(元請けのエンジニアリング会社)は契約前はいろいろと顧客の要求を受け入れますが,契約後は要求を断ります。要求を受け入れざるを得ないときは,顧客に追加費用を請求して,赤字にならないようにプロジェクトを運営します。なぜ要求を断れるのかというと,契約書に「技術仕様と範囲」が明示されているからです。

 第2回で述べたように,プラント建設プロジェクトでは詳細なRFPが作成されます。エンジニアリング会社は,このRFPに基づいて,どんな範囲のサービスを提供するのか,どんな機器設備を提供するのか,どんな性能を保証するのかを見積書に明記します。RFPに書かれていない機器やサービスについても,性能を保証するために必要であれば,見積書に明記します。これを見落とすと,コントラクタの責任になるからです。内容があいまいで将来問題を起こしそうなところも,提供範囲を明確に書きます。

 見積書には「○○を提供します」というように,提供範囲を肯定的に書きます。「XX以外は提供しません」「XXは入っていません」というように否定的に書くと,顧客から見積もりに入れるよう要求されることがあるからです。そうなると見積額が高くなって競争上不利になったり,見積額はそのままで範囲だけが広がったりします。

 こうした見積書の書き方は,エンジニアリング会社の社内で徹底されていますし,見積もりから契約までに責任を持つプロポーザル・マネジャーは,担当者の甘い表現を徹底して修正します。

「顧客満足」を誤解しているシステム開発プロジェクト

 このようにプラント建設プロジェクトでは,見積書提出時にコントラクタが提供範囲を明示して,契約後に仕様が膨らむのを防御します。もちろん,契約後に仕様を決定する段階では,システム開発プロジェクトと同様に「受注者と発注者の攻防」があります。しかし仕様を詰める段階で,コントラクタの担当者が勝手に仕様を膨らませることはありません。

 一方,システム開発プロジェクトでは,契約後に仕様を詰める段階で,ベンダー側の開発担当者がユーザー企業の担当者(ユーザー)の要望を取り込みながら仕様を確定していきます。この仕様確定作業は,ベンダーが見積もり時に想定した仕様や範囲とは関係なく進められることがほとんどです。これは,私がシステム開発プロジェクトに関与するようになって非常に驚いたことの一つです。ユーザーの中には,今まで思っていてもできなかったことを「この際だ」と思って仕様に盛り込むよう求めてくる人がいます。その結果,当初計画と比較するとはるかに膨らんだ仕様になってしまいます。

 さらに悪いことには,多くの場合,全体がある程度まとまるまで,仕様の膨らみが誰にもわかりません。開発担当者からの報告がないため,プロジェクト・マネジャーには「どんな風に仕様を詰めているのか」が見えないからです。まとめて工数を積算して初めてコストが大幅に膨らんでいることに気づき追加費用についてユーザー企業と交渉することになりますが,その時には膨らんだ仕様に従って開発が進んでいるので後戻りできません。このため「誰がこんな予算をはるかに越えた仕様を決めたんだ!」とトラブルになります。

 筆者は,こうしたトラブルの発生を加速させている原因の一つに「顧客満足」に対する誤解がある,と考えています。

 ベンダーの開発担当者は「顧客満足」第一という考え方をたたき込まれています。それはいいのですが,気になるのは「ユーザーの要求を聞き漏らさないようにしてすべて取り込むのが顧客満足」と思っている節が見受けられることです。もしそうなら,「顧客は誰か」ということを誤解しています。顧客は,「ユーザー」ではなく「オーナー」です。多くのITエンジニアは,この違いが理解できていません(図1)。

図1●すべてのユーザーの要求を取り込むことが「顧客満足」?
図1●すべてのユーザーの要求を取り込むことが「顧客満足」?