IT ベンダーを締め上げろ!-失敗プロジェクトと如何につきあうか-

興味深い記事-共感と違和感

最近、興味深い記事を見つけました。

今や「失敗が当たり前」のプロジェクトとどう付き合うか 管理強化よりも解釈の幅を埋める努力を [JBPress, 2012/05/22]

私も同じ業界に身を置いているので、この記事は多分に考えさせられるものがあります。残念ながら「失敗が当たり前」というのは認めざるをえない。殆どのプロジェクト(特に大規模になればなるほど)は炎上してしまいます。

筆者の主張は端的に副題に表れています。つまり「管理強化よりも解釈の幅を埋める努力を」するべきであるということです。私も筆者の主張に共感する部分が多々あります。しかしながら、違和感を感じる部分があることも事実です。

その違和感とはどのようなものでしょうか?

違和感の正体

まず、「解釈の幅を埋める努力」をするべきなのは誰かということです。ここでは、その主体が明示されていません。文脈を汲み取るならば、その主体は「ユーザ」であると考えるのが自然です。即ち、(ベンダー側ではなくユーザ側が)解釈の幅を埋める努力をするべきだ、ということです。

また、読んでいて、ん?と思う箇所がありました。以下はその引用です。

 あるプロジェクトで大損失を被ったシステム開発企業から、次のような依頼があった。「当初は2年でシステムが完成する予定だったが、結局5年かかってしまった。それもスコープを縮小して。一体何が問題だったのか、繰り返さないためにどうすればよいのかを明らかにしたい。ついては、第三者として調査に協力してもらえないか」という。

 当社は、関係者30名ほどにインタビューを行い、事実関係の確認をしていった。すると、システム開発会社のほぼ全員が「自分にもよくないところがあったんですよね」と能力の面などで自らに否があることを認めた。

 それでも話を聞いていくと、「自分たちはお客さんのニーズに沿って作ったが、なかなかOKを出してくれないので、思った通りにできなかった」という、「自分たちも悪いが、お客さんも悪い」という結論に行き着いた。

この最後の「自分たちも悪いが、お客さんも悪い」という箇所が私には引っ掛かります。ここには暗黙の内にベンダー側の視点(もっと言えば本音)が埋め込まれています。つまり、ベンダー側からユーザ側への譲歩の要求が暗示されています。

私が違和感を感じるのは、この記事がベンダー視点から語られていることです。

複数の視点

少し視点を変えてユーザ側から眺めてみたいと思います。ベンダー側の「自分たちも悪いが、お客さんも悪い」という言い草はユーザ側から見れば噴飯もの以外の何物でもありません。まぁ、噴飯ものだから訴訟にまで発展するわけですが…

「失敗が当たり前」のプロジェクトは大きな問題です。この問題にどのように対処するかは重要な課題です。この問題を扱う際に大切なのは複数の視点で物事を眺めることだと私は思います。

ベンダーの視点から見た場合(私もその立場なのですが…)、確かにこの記事に私は深い感銘を覚えます。ユーザ側がもう少し擦り寄ってくれればプロジェクトがうまく行くのにと感じたことは多々あります。また、ユーザの「実現したいこと」がうまく伝わらずにヤキモキしたことも当然あります。ですから、この記事の内容は私の心に沁みいるものです。

しかし、もう一方のユーザからの視点もキチンと検討する必要があります。ユーザ側からすれば「失敗が当たり前」のプロジェクトをどのようにコントロールしていけばよいのか?という問題です。

やり方が生温い!

まず、ユーザ側は何故プロジェクトを自前で行わずに外部にお願いするのかをよくよく考えてみるべきです。

一般に何らかのリソースを手に入れるためには 2 つの手段があります。まず 1 つ目は市場からリソースを買ってくることです。もう 1 つの手段は自分たちでリソースを内製することです。前者を市場アプローチ、後者を組織アプローチと呼ぶことにしましょう。(*1)

どちらのアプローチにもメリットとデメリットがあります。ここでは細かい話は省略しますが、重要な点は、市場アプローチの方が有利だと判断したからこそ、あなた(ユーザ)はプロジェクトを外部に委託しているのだということです。そして、市場アプローチのコントロールメカニズムは「競争」です。その点を腹の底に落とし込んでください。

ユーザとベンダー間の契約では「プロジェクトの完了をもって契約の完了とみなす」ようになっているはずです。所謂、請負契約です。この契約の場合、「プロジェクトの完了」が争点になります。プロジェクトが完了したことに合意してしまえば、たとえそれが「失敗」プロジェクトであってもお金を支払わなければなりません。

普通、この手のプロジェクトは 1 社とだけ契約するはずです。ですが、これだと「競争」というコントロールメカニズムを生かすことができません。1 社しか参加しないのですから競争なんて起こりようがない。

市場アプローチの「競争」というコントロールメカニズムを最大限に生かすためには、契約を見直して成果報酬型にすることです。そして複数社が並行で参入できるようにすることです。各社に好きなようにプロジェクトを進めさせて、一番デキの良かったものにお金を支払う仕組みを作ればよいのです。そのプロジェクトの価値が正確に計算できるのならば、プロジェクトの価値に従ってベンダーに成果分を分配すればよい。これだと物凄いインセンティブになります。もう「お客さんが悪い」なんて言わせません。「お客さん」が悪ければ結果的に「自分たち」も損するわけですから。

「失敗が当たり前」の買い物に最初から一定金額でコミットするのはユーザ側にとって得策ではありません。この製品はすぐに故障します、と言われて納得して契約するなんてありえない。ですから、「成功すれば儲けもの」と考えて成功したときだけお金を払うようにすればよいのです。

結局、「失敗が当たり前」のプロジェクトをコントロールするには市場原理を活用せよ、ということです。

不愉快な結論?ベンダー側から見れば別の絵も描ける

これは、少々、過激な結論かもしれません。相当反感を買うことも予想されます。特にベンダーサイドから見れば実に不愉快な結論でしょう。

誤解されては困るのですが、私は「ユーザはベンダーを締め上げるべきだ」と言っているのではありません。そうではなく、外部ベンダーを使う意思決定をしたユーザは市場原理を活用するのが合理的だと言っているだけです。

また、この結論が過激に見えるのはユーザ側から見た絵を描き出したからです。ベンダー側から見れば全く違う絵(というか、こういうことが実は戦略なのですが…)を描き出すことができます。とは言え、どうやら紙幅も尽きてきました。その辺りの事はまた別の機会にでも書いてみたいと思います。

(*1)勘の鋭い読者の方ならお気づきでしょうが、ここでの議論は「組織の経済学」を下敷きにしています。