#13.2.1 「DXの本質」 なぜ、システム開発プロジェクトは失敗するのか？
なぜプロジェクトは失敗するのでしょうか？
PMBOK等の体系だった知識が共有され、プロジェクトが失敗する確率は減ってきていると思います。
様々な対策が練られてきたはずです。
対策本が出版されたり、トレーニングを受けたり、セミナーが開催されたり、企業内で標準化されたり…
しかし、未だに多くのプロジェクトが失敗します。
・要件が決められなかった
・上流工程の問題
・技術力不足
・コミュニケーション不足
・プロジェクトマネジャーの問題
・変更を管理できなかった
・見積もりが甘かった
上記のような多くの理由があるでしょう。
そして、関係者はこの原因を解決すれば良いのでは？と思い、対処するはずです。
でも、失敗します…
なぜ、このようなことが起きるのでしょうか？
それは、プロジェクト構造自体に欠陥があるのではないでしょうか。
ユーザーとベンダーの目的の違いです。
そもそも、ユーザー側とベンダー側の目的が異なるのです。
ユーザ企業は、企業の業務を効率化したり、売上を上げたり、利益を上げたり、その先には企業価値を増大することが目的です。
そのためにシステムを構築します。
では、ベンダーの目的は、どうでしょうか？
ベンダーの目的は、納品して、検収もらうことです。
それはつまり、決まった要件を作って納品することです。
最初から双方の目的に相違があります。
目的が異なれば、ゴールも異なるのは当然です。
一般的な請負契約では、ユーザー企業が要件を伝え、その要件を定義し、両者間で合意をします。これが、「要件定義」というものですね。
そして、決まった要件に対して、範囲、費用、スケジュールを見積り、システムを開発し納品します。
ここで、問題が生じます。
これだけ世の中の変化がはやく、複雑な環境において、完璧な要件を決定することが、できるでしょうか…
「請負で契約してれば、よしなにやってくれるでしょ！」って丸投げしていると痛い目にあいます。
ここに一括請負の罠があるのです。
・要件が間違っていたら...
・要件が途中で変更になったら...
・要件を全て決めきれなかった...
要件とは、その要件を決定した時点でのスナップショットにすぎません。
要件が決定されたその瞬間から、すでに陳腐化が始まります。
そして、その要件も決めきれず、時間切れとなり、曖昧模糊とした状態で、プロジェクトが開始されます。
このようなプロセスは、ウォーターフォールのアプローチで発生します。
まさに、壮大な「ビジネス伝言ゲーム」です…
伝言ゲームは企業を越えて続きます。二次請、三次請け、さらにはオフショア（国境も越えます）と…
もはや、どこの誰が開発しているのか分かりません。
これだけ壮大な伝言ゲームを確実伝えられる自信ありますか？
プロジェクトが進むと、さらに様々な問題が発生します。スケジュールが遅延し、予算をオーバーし、品質が守られなくなります。
要件や範囲が変わったり、大幅に膨らみ、さらなる遅延と費用が増大します。
ベンダー側からは「要件が変更になったので追加費用です。」とどんどん費用が膨らみます。
当然、スケジュールも伸びます。
（時には裁判になったりします。もうこうなると、システムを作るとかの問題ではありません。不毛な泥沼の争いです。）
すると、ユーザー企業側も追い詰められます。いつの間にか、ビジネスをよくすることから、とにかくシステムを作って動かすことが目的に変わっています。
最初の「ビジネスを良くしたい」という目的とは、かけ離れたものが出来上がり、納品されます。
なんとか、プロジェクトは終わった（いや、終わらせた...）
どうなるか...
とにかく、動かしたけど…
・使い勝手が悪い…。
・当時決めた要件はもう古い…。
・ちょっと変更するのに、なんでそんなに時間とお金がかかるんだ？？？
・あんなに費用をかけたのに…（当初の予算を大きくオーバーしている）
・なんで、システムはそんなに金がかかるんだと経営者は怒り出す！
・さらなる、悪循環が発生し、負のスパイラルに…
こうして、プロジェクトは失敗します。
振り返ってみましょう、ここで悪い人は、一人も出てきていません。
みんな一生懸命に働いているのです。
では、なぜ失敗するのでしょう？
目的が違うからです。
これは、プロジェクトの構造の欠陥なのです。