株式会社ラフティ | Time Craft Consulting
Chapter 1 企画前
プロジェクトを始めてはいけない条件
ITプロジェクトは、
企画が始まる前の段階ですでに成否が決まっています。
この章では、
「どう進めるか」ではなく、
「そもそも始めてよいのか」
を判断するための条件を整理します。
ここに書かれている条件を満たしていない場合、
どれだけ技術力が高く、現場が優秀でも、
プロジェクトは高確率で破綻します。
1-1. 絶対的なプロジェクト責任者が不在
プロジェクトには、
最終的な意思決定を行い、結果に責任を持つ人物が必要です。
よくある失敗パターンは次の通りです。
-
「部長が責任者と聞いている」
-
「経営会議で決めることになっている」
-
「状況に応じて判断する」
これらは、すべて
責任者が存在しない状態です。
責任者とは、
-
期限を延期する判断ができる
-
人員を追加する判断ができる
-
予算を増減する判断ができる
このすべてを 自らの名前で決断できる人 を指します。
この人物が明確でないプロジェクトは、始めてはいけません。
1-2. 責任者の「権限」と「役職」が一致していない
責任者が形式上存在していても、
実際の権限が伴っていないケースがあります。
例えば、
-
課長が責任者だが、人事権も予算権もない
-
現場マネージャが調整役だが、決裁権がない
-
外部PMが任命されたが、社内を動かせない
この状態では、
問題が起きた瞬間に判断が止まります。
結果として、
-
会議が増える
-
判断が先送りされる
-
現場にしわ寄せがいく
という典型的な失敗ループに入ります。
責任と権限が一致していないプロジェクトは、
構造的に失敗が約束されています。
1-3. 責任者が異動・不在になる前提がない
長期プロジェクトにおいて、
人事異動や退職は必ず起こります。
それにも関わらず、多くのプロジェクトでは、
-
責任者が途中で変わる前提がない
-
代替責任者が決まっていない
-
引き継ぎルールが存在しない
という状態で契約が結ばれます。
実際には、
-
プロジェクト終盤で責任者が異動
-
判断できる人がいなくなる
-
トラブル時に誰も責任を取らない
という事態が頻発します。
責任者の代替ルールが定義されていないプロジェクトは、
引き受けるべきではありません。
1-4. 納品物の定義が曖昧なまま契約しようとしている
「納品物」が曖昧なまま進むプロジェクトは、
必ずトラブルになります。
よくある曖昧な定義は、
-
「システム一式」
-
「業務が回る状態」
-
「運用できる形」
これらは 納品物ではありません。
最低限、次が定義されている必要があります。
-
何をもって「完成」とするのか
-
誰が確認し、誰が受け入れるのか
-
不足があった場合の扱い
納品物が決まっていない状態での契約は、
ゴールのないマラソンと同じです。
1-5. 規模拡大時の判断ルールが存在しない
プロジェクトは、
ほぼ例外なく当初想定より膨らみます。
問題は「膨らむこと」ではなく、
膨らんだ時に誰が何を判断するかです。
次が決まっていない場合、要注意です。
-
予算が超過した場合の判断者
-
スコープが増えた場合の対応
-
リリース日を守るか延期するかの基準
これが決まっていないと、
-
「とりあえず進める」
-
「今回は特別対応」
-
「現場で何とか」
が繰り返され、
最終的に破綻します。
1-6. 経営者が「任せた」と言って関与しない
「ITは分からないから任せる」
この言葉が出た瞬間、
プロジェクトは危険な状態に入ります。
ここで問題なのは、
ITリテラシーの有無ではありません。
問題は、
-
自社で使うシステムを知ろうとしない
-
判断から距離を取ろうとする
-
責任を引き受ける姿勢がない
という 姿勢そのものです。
経営者が関与しないプロジェクトでは、
問題が起きた瞬間に責任転嫁が始まります。
1-7. この章のまとめ
プロジェクトを始めてはいけない条件は、
技術的な問題ではありません。
すべて、
-
責任
-
役割
-
判断
が 構造として定義されていないことに起因します。
これらが揃わない場合、
最も誠実な選択は 引き受けないことです。