前回の記事で、

「なぜプロジェクトは失敗するのか？」

について書きました。

ITの受託業界の有識者によれば、

失敗原因は

・合意形成がうまくいかない、対立関係を解消できない
・計画が甘い、指示・伝達がまずい
・プロジェクトのゴール、情報システムのプロジェクトにおける役割や導入の効果などをあいまいにしたままスタート
・発注側は進ちょく報告だけ受け、要件定義～開発工程は受託会社に丸投げ

といったことに集約され、

ITの受託業界は、

・要件定義手法の確立
・プロジェクト支援組織（駆け込み寺）の整備
・さまざまなルールの順守
・メトリクス（尺度）の導入
・失敗を教訓に変える取り組み

といった受託側の取り組みによって改善を図ろうとしています。

一方、

コンサル＆開発支援で著名なプロジェクトサポート企業は、

多くの失敗原因は

　「発注側の準備＆仕切り不足」

であり、

　「発注側のマインドやプロジェクトの進め方を見直す」

ことで改善を図る、としています。

僕が思うに、

失敗プロジェクトを減らしていくためには、

・受託側の取り組みや努力

と

・発注側の取り組みや努力

の、

両方が必要なんだと思うのです。

しかし、多くのメディアでは「受託側の取り組みや努力」については言及していても、

「発注側の取り組みや努力」については、あまり言及されていないように思います。

というかですね、

発注側と受託側の力関係が、どうしても

　発注側　＞　受託側

になっているので、受託側からあからさまに

　「発注側にも改善のための取り組みや努力が必要です」

とは、言えない状況にあるのではないか、と思うのです。

受注前の提案段階で、

「発注側にもプロジェクト失敗の原因があり、それを改善しなければプロジェクトは成功しない」

などと言おうものなら、

「自分たちの能力を棚に上げて、プロジェクト成功の要因をこちらに押し付けるとは、

　この会社はプロジェクトを成功させるスキルが不足しているに違いない」

と思われてしまうことを懸念して、

受託側からそのような提言がなかなかできないのは、心理的にもわかるような気がします。

だからこそ、上述したような「コンサル＆開発支援で著名なプロジェクトサポート企業」が活躍する場が市場にはあるのでしょう。

僕自身、受託業界に15年携わってきて、プロジェクト失敗の原因は

上述したものだと思ってきましたし、

自分なりにそれを改善する試みもしてきたつもりです。

ですが、何も変わらなかった。

相変わらず、プロジェクトは失敗し続けています。

（まぁ、全部が全部ではないですけど）

僕は、全く違う視点にたどり着きました。

プロジェクトが失敗する原因、

それは

　「請負契約」

にある、と。

ITの受託業界では「常識」である、

この「請負契約」こそ、

プロジェクトを失敗たらしめる諸悪の根源である、

と考えています。

ではなぜ、

　「請負契約がプロジェクト失敗の原因なのか」

長くなりましたので、それについては次回以降に書きたいと思います。