ITプロジェクトは、「決めない組織」から先に壊れていく
- 奧村 哲次
- 22 時間前
- 読了時間: 6分
― 「任せた瞬間」に、判断が消えていく組織構造
ITプロジェクトに関わったことがある人なら、
一度はこんな感覚を持ったことがあるのではないでしょうか。
会議を重ねているのに、なぜか前に進まない
SlackやTeamsのやり取りは増える一方なのに、決まった感じがしない
Backlogはあるのに、結局「誰が何を決めたのか」が曖昧
トラブルが起きると、最終的に現場やベンダーに責任が押し付けられる
しかも不思議なことに、
真面目で、優秀で、責任感のある人ほど消耗していく。
この違和感は、個人の能力不足や努力不足が原因ではありません。
そして、ツール選定や進捗管理手法の問題でもありません。
原因は、もっと根の深いところにあります。
問題の正体は「人」ではなく「構造」
ITプロジェクトが止まる本当の理由。
それは、
コミュニケーション・判断・行動が、構造的に分離されていないこと
です。
多くの現場では、
会話の中で
なんとなく決まり
その流れで誰かが動く
という状態が常態化しています。
一見すると、
「ちゃんと話し合っている」
「コミュニケーションが活発」に見えます。
しかし実際には、
どこで判断されたのか分からない
誰が決めたのか記録に残らない
行動が“善意”や“空気”に依存する
という、極めて不安定な運用になっています。
この状態では、
どれだけ人を入れ替えても、
どれだけ会議を減らしても、
どれだけツールを変えても、
本質的な解決にはなりません。
よくある「間違った改善」がなぜ失敗するのか
現場では、次のような改善がよく行われます。
会議が多い → 会議を減らそう
決まらない → ファシリテーションを強化しよう
混乱している → ツールを統一しよう
抜け漏れが多い → ドキュメントを増やそう
これらは、一見もっともらしい対策です。
しかし、実際にはこうなります。
会議は減ったが、裏で個別調整が増える
ファシリが疲弊し、結局属人化する
ツールは統一されたが、使い方がバラバラ
ドキュメントは増えたが、誰も読まない
なぜか。
理由は単純です。
判断の所在が固定されていないから
です。
判断が「人」や「場」に依存している限り、
どんな改善もノイズを増やすだけになります。
本当に必要なのは「会話を減らすこと」ではない
ここで、多くの人が誤解します。
「じゃあ、コミュニケーションを減らせばいいのか？」
答えは、NOです。
必要なのは、
会話を減らすことではなく、判断を固定し、行動が自動で起きる構造を作ること
です。
会話は、ゼロにする必要はありません。
しかし、会話の役割を限定する必要があります。
会話は「情報共有」のため
判断は「構造」によって行われる
行動は「ルール」によって自動的に発生する
この分離ができていない限り、
プロジェクトは必ずどこかで詰まります。
判断と行動が自動連動するとはどういうことか
理想的な状態は、こうです。
課題が1つ起票された時点で
誰が判断するかが明確で
判断の結果によって
次に取るべき行動が決まっている
つまり、
1課題＝1判断＝1行動
この関係が、最初から設計されている状態です。
このとき重要なのは、
「その場で考えない」ことです。
その場で考える＝属人化
その場で決める＝再現性がない
その場で調整する＝責任が曖昧になる
だからこそ、
運用が始まる前に、判断と行動の関係を決め切る
必要があります。
Backlogが「作業管理表」になった瞬間、破綻は始まる
多くの現場で、Backlogはこう扱われています。
タスクを並べる場所
進捗を確認する場所
作業漏れを防ぐチェックリスト
しかし、本来Backlogが果たすべき役割は違います。
Backlogとは、
判断コミュニケーションの正本
であるべきものです。
つまり、
何が課題で
誰が判断し
何が決まり
その結果、何をするのか
これが一元的に残る場所です。
ここがブレると、
会話はSlack
判断は会議
行動は個人メモ
という分断が起こり、
プロジェクト全体の可視性は一気に失われます。
運用フェーズで「判断」を持ち込んではいけない
もう一つ、非常に重要なポイントがあります。
それは、
運用フェーズに判断を持ち込まないこと
です。
運用とは、本来、
想定内の事象に
決められた対応を
迷わず実行するフェーズ
です。
それにもかかわらず、
毎回相談が発生する
「どうします？」が頻発する
判断待ちで手が止まる
こうした状態が起きている場合、
それは運用設計の失敗です。
判断すべきことは、
すべて事前に構造として決めておく。
判断が必要になった瞬間、
それは「設計のやり直し」を意味します。
判断と結果を残さない組織は、必ず同じ失敗を繰り返す
多くの現場では、
「何が決まったか」は記録されません。
残るのは、
作業ログ
チャット履歴
断片的な議事メモ
しかし、本当に残すべきなのは、
なぜその判断をしたのか
他にどんな選択肢があったのか
結果としてどうだったのか
という判断と結果のログです。
これが残らない限り、
同じ議論を何度も繰り返し
同じ失敗を何度も踏み
そのたびに人が疲弊します。
学習しない組織ではなく、
学習できない構造になっているだけなのです。
ここまでの話は、すべて「体系」として整理できる
ここまで読んで、
どれか一つだけやればいい話ではない
全部がつながっている
部分改善では意味がない
そう感じた方も多いはずです。
その感覚は正しいです。
これらはすべて、
個別ノウハウではなく、運用設計の体系だからです。
この構造を、最初から体系として理解したい方へ
ここまで述べてきた
「コミュニケーション・判断・行動を分離し、
判断と行動が自動連動する構造」は、
現場経験と失敗の積み重ねから、体系として整理されています。
全体像の入口としてまとめているのが、以下のページです。
Chapter 0
コミュニケーション・判断・運用基盤
― 役割と責任を固定し、判断と行動が自動連動する構造https://www.laughtey.com/portfolio/communication-decision-operation-wiki
※この先は、
「とりあえず試す」ではなく、
本気で構造から変えたい人向けの内容です。
最後に：ツールでも、気合でも、解決しない領域がある
この手の問題は、
ツール導入
進捗管理強化
気合と根性
では解決しません。
なぜなら、構造の問題だからです。
自分たちだけで設計できる場合もあります。
しかし、多くの場合、
利害関係
立場の違い
暗黙の責任
が邪魔をして、設計そのものが進みません。
そのとき初めて、外部の視点が意味を持ちます。
このブログが、
「なぜうまくいかなかったのか」を
自分を責めずに理解するための一助になれば幸いです。
そして、
構造から見直す必要性を感じたなら、
次の一歩として、体系に触れてみてください。
コメント