営業はなぜ「お任せください」と約束してしまうのか：不具合大量発生中なのに（4/4 ページ）

　キックオフの直前、社内のプロジェクト計画レビューに立ち会った私は、あることに気付きました。A社は複数のキーメンバーが兼任であるにもかかわらず、それをリスクとして挙げていなかったのです。兼任ということは、「片方のプロジェクトに問題が起きたらその対応に工数を取られて、もう片方の作業が手薄になる」というリスクがある、ということです。

　これをX社と共有するリスク管理台帳に記載しないのかと問う私に、プロマネは、「これは内部で対処すべき問題だからと開示しない」と話しました。私は「問題が発生した後にX社に知られたら、その方が信頼を損ねるし、協力も得られない」と考え、半ば強引に「兼任メンバーが他プロジェクトに時間を取られて十分な工数を割けないかもしれない」というリスクと、「その際には、追加メンバーの投入と作業の組み換えで対応する」という対策を、X社に持っていかせました。

　数日後、説明から戻ってきたプロマネは笑顔で私に報告しました。「X社から『これで御社も本当のパートナーになってくれた』と褒められた」と。顧客を信頼してリスクを開示したことが、かえって信頼を増す結果となったのです。

　プロジェクトがスタートすると、リスクは顕在化しました。予想通り掛け持ち先のプロジェクトがうまく進まず、こちらへの関与率が下がったのです。X社はいい顔はしませんでしたが、A社の出したリスク対応策の実施を承認したばかりか、一部のテストデータの作成などを自ら行ってくれたのです。

　ここで得た信頼は何にも代えがたく、プロジェクトはQCDを順守して完走しました。A社はX社と今でも良好な関係を続けているそうです。まさに顧客を信頼した効用であり、X社も信頼に足る顧客だったといえます。

ベンダーのプロジェクト管理能力不足はなぜ起きるのか。

　「そんな顧客は稀（まれ）であり、多くは協力などしてくれない」とお考えの方もいるかもしれません。

　確かに、X社はソフトウェアの導入経験が豊富で、開発プロジェクトのユーザーとしての成熟度が高い企業でした。だからこそA社の提示したリスクを正しく理解したのかもしれません。

　しかし、プロジェクトが破綻しそうになったとき、自分たちも何とかしたいと考えるのは、ユーザーとしても自然なことです。ベンダーが困っているのをただ、突き放しても何も良いことはないという認識は、ほとんどのユーザーが持ち合わせているはずです。

　それを信頼せずに、「お客さんに怒られるかもしれない」とひるみ、見せ掛けの行動で表面的な顧客信頼度を維持しようとする行動こそが、失敗プロジェクトを生み、また、その傷を深めてしまう、というのが私の率直な思いです。

　これはエンジニアと上司の関係でも同じです。

　評価や叱責（しっせき）を恐れて上司を信頼せずに、自分がいかに苦しいか、どんな困難に直面しているかを、率直に、相手が分かってくれるまで訴えられないエンジニアは、不幸なだけです。そのためには相手を信じる必要があります。上司だって、プロマネだって、多くはかつてエンジニアだったわけですから、信じてみる価値はあるはずです。

　プロジェクト管理能力とは結局、開発中に起こるさまざまなリスクや課題に、どううまく対処できるのかということです。それがうまくいかないのは、ベンダーが顧客を信頼していないこと、そしてベンダー内部ではエンジニアが上司やプロマネを信じていないことに大きな原因があるのではないでしょうか。

　プロジェクトがうまくいかなければ、怒られても仕方ないですし、一時的には信頼を落とすかもしれません。しかし、それにひるんで逃げ回るようなベンダーやエンジニアであるなら、それは最初からITなど生業（なりわい）とすべきではないと、私は思います。

細川義洋

政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる