炎上案件に入ると、だいたい最初に聞く一言

炎上したプロジェクトに助っ人で入ると、最初の打ち合わせでだいたいこう言われます。
「この案件、ちょっと事情がありまして…」

事情を聞くと、確かにそれぞれの案件には個別の背景があります。クライアントの事情だったり、組織の事情だったり、人の入れ替わりだったり、技術的な制約だったりします。現場の人から見れば、どれも実際に起きていることです。

ただ、こうした案件にいくつか入ると、だんだん別のことに気づきます。何度か炎上案件に入るうちに分かってきたのは、「特殊なプロジェクト」ではなく「よくある条件がいくつか重なったプロジェクト」だったということでした。表面の事情は違っていても、炎上の理由の構造はかなり似ています。

最初によく見かけるのは、要件が固まりきっていない段階で実装が進んでいるケースです。仕様の調整と開発が同時に進んでいるため、仕様が変わるたびにコードの修正やテストのやり直しが発生します。

作業は進んでいるのですが、全体の進捗の見通しが立ちにくくなります。途中からは誰も「このプロジェクトはあとどれくらいで終わるのか」を説明できなくなります。

もう一つよく見かけるのが、計画の前提が更新されないケースです。

本来イテレーション型の開発では、実装してみて分かったことを次の計画に反映していきます。しかし実際の現場では、最初のスケジュールの前提がそのまま残ってしまうことがあります。

開発が進むにつれて作業量の認識は変わっているのに、計画だけが更新されない状態です。現場では違和感が少しずつ積み上がっていき、どこかの時点で一気に表面化します。外から見ると突然の炎上に見えますが、現場では前提のズレが少しずつ広がっています。

炎上案件をいくつか見ると、次のような状態が重なっていることも少なくありません。

・仕様の優先順位が決まっていない
・誰が最終判断をするのかが曖昧
・レビューが形骸化している
・テスト工程が圧縮されている
・途中から人員が増えてコミュニケーションが複雑になる
・問題の共有が遅れる
・「とりあえず進める」が積み重なる

どれも珍しい問題ではなく、多くのプロジェクトで起き得ることです。

こうした状態を見ていると、「この案件には事情がありまして…」という説明の裏に、実はかなり共通した構造があると感じます。案件ごとに炎上した事情一つ一つは違いますが、問題の形そのものはそれほど珍しいものではありません。

むしろ炎上は、特殊な出来事というより、起きやすい条件がいくつか重なった結果なのだと思います。

大きなプロジェクトほど問題は突然起きるように見えますが、実際には小さな前提や判断の積み重ねが後半で効いてくることが多いように感じます。

そして振り返ってみると、「特殊な案件だった」というより、途中の前提が少しずつ現実とズレていったプロジェクトだった、ということがほとんどでした。

X（旧Twitter）やBlueskyを中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。

炎上案件に入ると、だいたい最初に聞く一言

Sota ICHINO