株式会社ラフティ | Time Craft Consulting
ITプロジェクトは、なぜ8割が失敗するのか
― 責任・役割・判断を構造化する実務プロジェクトマネジメントWiki ―
Chapter 0
プロジェクトを始める前に知っておくべき、たった一つの事実
世の中のITプロジェクトの8〜9割は失敗します。
これは、技術力が足りないからでも、
現場が頑張らないからでもありません。
失敗の本質は、ほぼ例外なく「責任・役割・判断」が曖昧なまま始まっていることです。
0-1. 失敗するプロジェクトの共通点
多くの失敗プロジェクトには、次の特徴があります。
-
課題が「人」に紐づいている
-
経営者が「任せた」と言って関与しない
-
誰が決めるのかが曖昧
-
問題が起きた時、責任の押し付け合いになる
そして最後は、こう終わります。
「想定外だった」
「現場がもっと頑張るべきだった」
「PMがちゃんと管理していなかった」
しかしこれは、すべて後付けの言葉です。
0-2. 成功している1割のプロジェクトが最初にやっていること
成功しているプロジェクトは、
最初から技術やツールの話をしません。
彼らが最初にやっているのは、
「誰が、何を、いつ判断するのか」を決めることです。
多くの現場では、次のような言葉が飛び交います。
-
「とりあえず進めましょう」
-
「あとで調整しましょう」
-
「現場で何とかしてください」
しかし成功しているプロジェクトでは、
これらの言葉はほとんど使われません。
代わりに、次のことが明確にされています。
-
最終判断者は誰か
-
期限・コスト・品質の優先順位
-
判断ができなかった場合の代替案
PMBOKは、これらを
スコープ管理、リスク管理、ステークホルダー管理
といった形で体系化しています。
重要なのは、PMBOKを知っていることではなく、
「判断と責任を構造として使えているかどうか」です。
0-3. プロジェクト開始前に必ず確認すべきこと
プロジェクトを始める前に、
以下の項目が合意されていない場合、
そのプロジェクトは高確率で失敗します。
-
絶対的なプロジェクト責任者は誰か
-
その責任者が異動・不在になった場合の代替責任者
-
納品物の定義（成果物・状態・範囲）
-
開発と運用のルール
-
規模が膨らんだ場合の判断者
これらが曖昧なまま契約を交わすことは、
「判断を放棄したまま走り出す」ことと同じです。
実際、数億〜数十億規模に膨らんだプロジェクトでは、
-
責任者が途中で交代する
-
判断が宙に浮く
-
最終的に現場やPMに責任が押し付けられる
という事態が珍しくありません。
合意できない場合は、引き受けない。
これもPMの重要な仕事です。
0-4. 経営者の関与姿勢がプロジェクトを決定づける
「ITはよく分からないから、全部任せる」
この言葉は、一見すると信頼のように聞こえます。
しかし実際には、責任を引き受けない姿勢を意味することが多い。
経営者に求められるのは、ITリテラシーの高さではありません。
-
自社で使うアプリやシステムを知ろうとする姿勢
-
従業員と同じ目線で理解しようとする態度
-
判断から逃げない覚悟
経営者が関与しないプロジェクトでは、
問題が起きた瞬間に責任の所在が曖昧になり、
結果として責任転嫁が始まります。
責任転嫁を前提とした組織から、
イノベーションが生まれることはありません。
0-5. このWikiの使い方
このWikiは、工程順に読んでも、
必要な章だけを参照しても構いません。
各章では、次の点を扱います。
-
よくある失敗パターン
-
事前に決めておくべきこと
-
実務で有効だった判断やルール
ここに書かれている内容は、
理想論や机上の空論ではありません。
実際に、数億〜数十億規模のITプロジェクトで起きた
失敗と判断をもとに構成しています。
Chapter 0 の締め
プロジェクトは、
「頑張り」や「根性」で成功するものではありません。
人に寄り添うのではなく、
役割・責任・判断に寄り添う。
それが、このWikiが一貫して伝えたいことです。