SES客先常駐で炎上案件が起きる原因｜下流から見た共通パターン

「炎上している」と誰かから聞かされて初めて、自分の担当箇所の遅れに気づいたことが、これまで一度や二度ではありません。エンジニア歴数年の間にウォーターフォールの現場をいくつも渡り歩いてきましたが、そのたびに似たような構図で現場が荒れていく場面に出くわしてきました。日経コンピュータの調査ではシステム開発プロジェクトの成功率は52.8%にとどまるとされており、炎上そのものは特別珍しい現象ではないようです。今回は、二次請け・三次請けという下流の立場で見えてきた「炎上案件に共通するパターン」と、メンバーとして自分がどう身を守ってきたかを、実体験を交えてお伝えします。

目次

1. SES客先常駐で経験した炎上案件、二次請け・三次請けから見た景色
2. 炎上案件に共通していた3つの兆候
3. 要件定義の詰めが甘く、終盤になって仕様が変わる
4. 上流工程の遅れを、下流工程の圧縮で取り戻そうとする
5. 特定の人がいないと現場が回らない、属人化・キーマン依存
6. 忙しいだけの現場との違いをどう見分けているか
7. なぜ下流のメンバーには炎上の予兆が見えにくいのか
8. システム開発の半分は炎上している、という調査結果をどう見るか
9. 炎上した現場でメンバーとして実践してきた自衛策
10. 同じ兆候が出ていたら、まず何を確認すればいいか
11. まとめ

SES客先常駐で経験した炎上案件、二次請け・三次請けから見た景色

私はこれまで、二次請け・三次請けというSESの下流の立場で、複数のウォーターフォール現場を経験してきました。役割はいずれもリーダーやサブリーダーではなく、手を動かすメンバーです。元請けと直接やり取りする立場ではなく、情報は自社の上司や現場のリーダーを経由して降りてくる構造の中にいました。

この立場から見ると、炎上案件というのは特定の1社だけで起きる特殊な出来事ではありません。会社を変え、現場を変え、担当する工程を変えても、似たような荒れ方をする現場に何度も出くわしてきました。単発のエピソードとして「あの現場でこんなことがあった」と語れるほど、当時の自分は上流の意思決定に関与していたわけではありません。それでも、複数の現場を通じて見えてきた共通点は確かにあります。

この記事で書くのは、そうした共通点です。特定の1つの現場の内幕を暴露するような話ではなく、いくつもの現場を渡り歩く中で、下流のメンバーという同じ立場から繰り返し見えてきたパターンとして読んでいただければと思います。

炎上案件に共通していた3つの兆候

複数の現場を振り返ってみると、炎上に至る前触れには、いくつか共通する特徴がありました。どれか1つが単独で炎上を引き起こすというより、これらが絡み合いながら現場を追い詰めていく、というのが実感に近いです。

要件定義の詰めが甘く、終盤になって仕様が変わる

もっともよく見た兆候は、要件定義の段階で仕様が十分に詰め切れていないまま、設計・開発の工程に進んでしまうことでした。案件のスタート時点では固まっているはずの仕様が、終盤になって「実はここが要件と違っていた」という指摘で覆ったり、そもそも決まっていなかった仕様が今になって発覚したりする場面に、複数の現場で遭遇してきました。

下流のメンバーとして手を動かしている立場からすると、この手戻りは唐突に降ってくるように感じられます。なぜ今になってこの仕様が変わるのか、その背景にある元請けとの調整や上流工程での経緯までは、自分のところまで詳しく伝わってきません。ただ結果として、決まっていたはずの仕様がひっくり返り、作業のやり直しが発生する、という現象だけが目の前にあります。

上流工程の遅れを、下流工程の圧縮で取り戻そうとする

もう一つ繰り返し見てきたのが、スケジュールの無理な圧縮です。要件定義や設計といった上流工程が当初の予定より遅れているにもかかわらず、全体の納期そのものは動かない。その結果、後ろに控えている開発やテストといった下流工程の期間が、削られる形でしわ寄せを受けます。

この構図は、上流で何が起きているかを直接知らないメンバーの目にも、はっきりと見える形で現れます。ある時期から急にタスクの数が増える、テスト項目の消化ペースを求められる速さが変わる、といった変化として体感するのです。なぜ今になってこのペースが求められるのか、その理由を説明されないまま、とにかく前倒しで進めてほしいという指示だけが降りてくる、という場面を何度も経験してきました。

特定の人がいないと現場が回らない、属人化・キーマン依存

3つ目の兆候は、属人化とキーマン依存です。特定の担当者でなければ分からない仕様、その人にしか触れない設定、その人が休むとレビューが止まる工程。こうした状態になっている現場を、複数の案件で見てきました。

属人化そのものは、炎上していない平時の現場でもよく見かける光景です。ただ、炎上案件ではこの依存度がより深刻な形で表に出ます。仕様変更やスケジュール圧縮でただでさえ余裕がなくなっている中、キーマンが休んだり、別のタスクに引っ張られたりすると、その工程だけが完全に止まってしまう。1人の不在が、チーム全体の進捗に直結してしまう脆さを、何度も目の当たりにしてきました。

これら3つの兆候は、私の経験してきた現場ではどれも単独では終わりませんでした。要件定義が甘いまま進んだ案件は、終盤の手戻りでスケジュールを圧迫し、圧縮されたスケジュールの中で属人化した工程がボトルネックになる。そうやって絡み合いながら、現場全体が徐々に炎上状態へと向かっていく、というのが複数の現場に共通して見えてきた流れです。

ただし、正直に言うと、この3つがどういう順番で、どの程度の重みで絡み合っていたのかを、因果関係として細かく分析できるほどの情報を、当時のメンバーという立場の自分は持っていませんでした。あくまで結果として、この3つが同時に揃っている現場ほど荒れていた、という傾向として受け止めています。

忙しいだけの現場との違いをどう見分けているか

ここまで書いた3つの兆候は、単体では珍しいものではありません。要件定義に多少の甘さがあることも、繁忙期にスケジュールがきつくなることも、特定の人に頼る場面があることも、平常運転の現場でよく見かけます。この違いを意識するようになったのは、3つが同時期に重なって出てきた時に限って、現場の空気が明らかに変わっていくのを繰り返し体感してきたからです。

たとえば、要件定義の甘さだけが単独で表面化した現場では、手戻りが発生してもその工程の中で吸収され、後工程まで大きく波及しないことがありました。逆に、要件定義の甘さとスケジュール圧縮が同時に起きている現場では、手戻りの分を取り戻す余白がそもそも残っておらず、その先の属人化した工程にまで一気にしわ寄せが及んでいく、という流れを何度か経験しています。

平常運転の忙しさなのか、炎上に向かっている兆候なのかを判断する明確な基準を、当時の自分が持っていたわけではありません。それでも、複数の兆候が同時に、しかも短い期間の中で重なって出てきた時は、後から振り返ると炎上へと向かっていた、という経験則は自分の中に残っています。

なぜ下流のメンバーには炎上の予兆が見えにくいのか

ここまで書いた3つの兆候は、いずれも渦中にいる時よりも、後から振り返った時のほうがはっきり見えるものでした。渦中にいる時は、目の前のタスクをこなすことに集中していて、それが炎上の予兆だと気づけていないことのほうが多かったというのが正直なところです。

この見えにくさには、二次請け・三次請けという立場が関係していると考えています。元請けと直接やり取りをする立場であれば、上流工程の遅れや仕様変更の背景を、その場でリアルタイムに把握できるはずです。しかし下流の会社に所属するメンバーには、そうした情報は自社の上司や現場のリーダーを経由してからでないと届きません。

情報が会社をまたいで降りてくるまでに、背景や経緯の部分から少しずつ削れていくのを、現場を変えるたびに感じてきました。「なぜこの仕様変更が起きたのか」「なぜこの納期は動かせないのか」といった、判断の前提になる情報は上の階層にとどまりやすく、下流に届く頃には「とにかくこの通りにやってほしい」という結論だけが残っている、という場面を何度も経験してきました。

進捗会議や週次の定例といった場でも、伝わってくるのは主に「今週やったこと」「来週やること」といった作業レベルの内容にとどまることが多く、その背景にある元請けとのやり取りや、上流での判断の経緯まで共有される場面は多くありませんでした。会議の場そのものが、下流のメンバーに背景まで伝えるための場として設計されていないのだと感じています。

この構造の中にいると、炎上の予兆に気づくタイミングは、どうしても遅れます。上流で仕様がもめている段階では何も伝わってこず、スケジュールが圧縮されると決まった段階になって初めて、下流のメンバーはその決定を知らされる。気づいた時にはすでに、対応するための選択肢がほとんど残っていない、ということが少なくありませんでした。

ポイント： 下流のメンバーが炎上に気づくのが遅れるのは、個人の観察力や経験の問題というより、情報が伝わる経路そのものの構造によるところが大きいと考えています。元請けに近い立場ほど早く動ける情報を持っていて、下流に降りるほどその情報は結論だけに圧縮されていく。この構造を理解しておくだけでも、「自分の察知が遅かった」と過度に自分を責めずに済むはずです。

システム開発の半分は炎上している、という調査結果をどう見るか

ここまでは自分が経験してきた現場の話でしたが、これが特殊な体験ではないことは、業界の調査からもうかがえます。日経コンピュータの調査によると、システム開発プロジェクトの成功率は52.8%にとどまり、1700件を超えるプロジェクトを分析した結果として報告されています(出典: 日経クロステック)。

この調査は発注者側・PM側の視点から「成功」「失敗」を評価したもので、私のような下流のメンバーがその内訳を直接検証したわけではありません。ただ、半数近くのプロジェクトが何らかの意味で計画通りに進んでいないという数字は、複数の現場で炎上に遭遇してきた自分の肌感覚と、大きくは矛盾しません。

この数字を最初に知った時、それほど意外には感じませんでした。むしろ、自分が経験してきた現場の割合と近い数字だと感じたくらいです。ただ同時に、この手の調査結果を目にする機会自体、これまでほとんどありませんでした。下流のメンバーとして働いていると、自分の現場が「よくあること」なのか「特殊なこと」なのかを、外部の情報と照らし合わせて確認する機会そのものが少ないというのが、これまでの実情です。

正直に言うと、この手の調査や解説記事の多くは、発注者・PM・コンサルタントといった上流の立場から書かれたものがほとんどです。プロジェクト管理の失敗要因を分析する記事は数多くありますが、二次請け・三次請けの下流に配置されたメンバーの目から、炎上がどう見えているかを書いたものは、あまり見かけません。この記事で伝えたかったのは、まさにその「下流から見た景色」の部分です。

炎上した現場でメンバーとして実践してきた自衛策

炎上の兆候そのものを、下流のメンバーである自分が止められたことは、正直ありません。要件定義のやり直しも、スケジュールの再調整も、自社と元請けの間で決まることであり、現場でタスクをこなしているメンバー個人が動かせる範囲の外にあります。

それでも、炎上した現場の中で自分の消耗をできるだけ減らすために、いくつか続けてきたことがあります。

1つ目は、気づいたことを必ずテキストで残すことです。仕様の疑問点や、指示された内容の確認事項を、口頭のやり取りだけで済ませず、メールやチャットの形で記録に残すようにしています。これは自分がどこまでを担当し、どこから先は自分の範囲外だったのかを、後からでも確認できるようにするためです。

2つ目は、問題に気づいたらできるだけ早く、自分だけで抱え込まずに上長やリーダーにエスカレーションすることです。判断がつかない仕様の食い違いや、スケジュール的に厳しいと感じたタスクを、自分の中だけで抱えて対応を遅らせるのではなく、早い段階で共有するようにしてきました。

自衛策として挙げているのは、この2つだけです。残業を拒否する、契約内容を盾に業務範囲を主張する、といったもっと踏み込んだ対応を取ったことはありません。メンバーという立場で、元請けと直接の契約関係にもない自分にとって、そこまで強く出られる材料も権限もなかったというのが実情です。できることの範囲がそもそも狭い中で、せめてこの2つだけは徹底しよう、というのが自分なりの落としどころでした。

これらは炎上そのものを止めるための行動ではありません。 あくまで、すでに炎上している、あるいは炎上しかけている現場の中で、メンバーとしての自分の消耗を減らすための立ち回りです。テキストに残しておいたからといって仕様変更がなくなるわけではありませんし、早めにエスカレーションしたからといってスケジュールの圧縮そのものが解消されるわけでもありません。それでも、自分の担当範囲を後から示せる記録が残っていることや、抱え込まずに早く共有したという事実は、炎上した現場を渡り歩く中で、自分自身を守る材料にはなってきたと感じています。

同じ兆候が出ていたら、まず何を確認すればいいか

炎上を止める権限が下流のメンバーになくても、自分の現場が今どのあたりにいるのかを把握しておくことには意味があります。ここまで書いた3つの兆候を、確認の視点として整理し直すと次のようになります。

この3つのうち1つだけが当てはまる現場は、これまでの経験ではそれほど珍しくありませんでした。ただ、2つ、3つと当てはまる数が増えていくほど、後になって振り返ると炎上に向かっていた、という感覚があります。今の現場がどの段階にあるのかを、この3つの視点で一度整理しておくだけでも、テキストで記録を残すタイミングや、上長にエスカレーションするタイミングを、少しだけ早められるかもしれません。

まとめ

複数のウォーターフォール現場を渡り歩く中で見えてきた炎上案件の共通パターンは、要件定義の詰めの甘さ、上流の遅れを下流の圧縮で取り戻そうとするスケジュール運用、そして特定の人に依存した属人化の3つでした。これらは単独ではなく、絡み合いながら現場を追い詰めていきます。

二次請け・三次請けという下流の立場では、この予兆に早い段階で気づくこと自体が難しいというのも、正直な実感です。情報は上の階層から降りてくる過程で、背景や経緯が削られ、結論だけが届くようになっていきます。これは個人の察知力の問題というより、多重下請けという構造そのものが持つ性質だと考えています。

もし今、同じように下流のメンバーとしてウォーターフォールの現場にいて、タスクの増え方やスケジュールの変わり方に違和感を覚えているなら、それは思い過ごしではなく、炎上の兆候である可能性があります。自分の力で要件定義のやり直しやスケジュールの再調整を止めることはできなくても、気づいたことをテキストで残し、早めに共有するという立ち回りだけは、今日からでもできます。炎上そのものを防ぐ力は下流のメンバーにはなくても、その中でどれだけ自分の消耗を減らせるかは、日々の小さな行動の積み重ねで変わってくるはずです。