「炎上している」と誰かから聞かされて初めて、自分の担当箇所の遅れに気づいたことが、これまでに何度かあります。
SESエンジニアとして5年あまり、4社の客先常駐を経験してきました。炎上と呼べる局面に当たったのは2社目の一時期で、3社目でも移行作業の時期は負荷が高くなりました。
今回は、三次請け・二次請けという下流の席から見えた炎上案件の3つの兆候と、体調を崩す前に知っておきたい残業の目安、そして自分が実際にやってきた自衛策をお伝えします。
この記事で分かること
- 主に2社目で見た炎上の3つの兆候と、メンバーの席から「何が見えて、何が見えていなかったか」
- タスクの増え方や課題管理票の滞留など、下流の席から観測できる炎上の手がかり
- なぜ下流のメンバーには炎上の予兆が見えにくいのか、という構造上の理由
- 日経xTECHとJUAS(日本情報システム・ユーザー協会)の調査で見る、システム開発の遅れや失敗の実際
- 厚生労働省が示す残業の目安と、医師の面接指導を申し出る先
- 自衛策(記録とエスカレーション)の具体的なやり方と、抜けたいと思ったときの現実
目次
- SES客先常駐で経験した炎上案件、二次請け・三次請けから見た景色
- 炎上案件に共通していた3つの兆候
- 要件定義の詰めが甘く、終盤になって仕様が変わる
- 上流工程の遅れを、下流工程の圧縮で取り戻そうとする
- 特定の人がいないと現場が回らない、属人化・キーマン依存
- 3つの兆候は絡み合って現場を追い詰める
- 忙しいだけの現場との違いをどう見分けているか
- 下流のメンバーの席から観測できる炎上の兆候
- なぜ下流のメンバーには炎上の予兆が見えにくいのか
- システム開発の遅れや失敗は、調査でどう示されているか
- 日経xTECHの調査:成功率52.8%は「半分が炎上」ではない
- JUASの2025年度調査:規模が大きいほど、遅延や超過が増える
- 体調を崩す前に知っておきたい、残業の目安と面接指導
- 厚生労働省が示している、時間外労働と脳・心臓疾患の関連
- 2社目の5か月を、この目安に当てはめてみる
- 自分の時間外は、自分で記録しておく
- 面接指導を申し出る先は、客先ではなく自社
- 炎上した現場でメンバーとして実践してきた自衛策
- 1つ目:指示と確認事項を、その日のうちにテキストで残す
- 2つ目:遅れの見込みが出た日に、現場のリーダーへ言う
- 炎上した現場を抜けたいと思ったときの現実
- 契約の更新・終了は、会社同士で決まる
- 相談先は客先ではなく、自社の営業
- 伝えても、現場が変わるとは限らない
- 同じ兆候が出ていたら、まず何を確認すればいいか
- まとめ
SES客先常駐で経験した炎上案件、二次請け・三次請けから見た景色
私が経験した4社の現場を、先に並べておきます。全部の現場が荒れたわけではなく、当たり外れは運次第でバラバラでした。
| 現場 | 商流 | 担当 | 炎上の実感 |
|---|---|---|---|
| 1社目(約4か月) | — | 研修後、Javaの業務システム開発 | 比較できるほど記憶が残っていない |
| 2社目(約1年半) | 三次請け | 業務システムの設計・実装・単体テスト(ウォーターフォール) | 手戻りが重なった時期があった |
| 3社目(約2年半) | 二次請け | 金融系Webサイトの旧システムからのデータ移行(約1年)、保守改善(約1年半) | 移行期は夜間・休日対応が重なり、負荷が高かった |
| 4社目(現在・約9か月) | 二次請け | 社内向け業務システムの保守・改修 | 今のところ荒れていない |
役割はいずれもリーダーやサブリーダーではなく、手を動かすメンバーです。元請けと直接やり取りする立場ではなく、情報は自社の上司や現場のリーダーを経由して降りてくる構造の中にいました。
この記事で書くのは、特定の1つの現場の内幕ではありません。主に2社目で見た場面を材料に、3社目・4社目との違いも交えながら、下流のメンバーという立場から見えたパターンを書きます。
炎上案件に共通していた3つの兆候
2社目を中心に振り返ると、炎上に至る前触れには3つの特徴がありました。どれか1つが単独で炎上を引き起こすというより、2つ以上が同じ時期に重なって現場を追い詰める、というのが実感に近いです。
要件定義の詰めが甘く、終盤になって仕様が変わる
もっともよく見た兆候は、仕様が詰め切れていないまま、設計・開発の工程に進んでしまうことでした。2社目の三次請けの現場では、設計・実装・単体テストを担当していた間に、数日分の手戻りが2〜3回ありました。
手戻りの原因が、上流での仕様の詰めの甘さだったのか、顧客側の要望の変更だったのか。私は今も把握していません。そこで原因ではなく、メンバーの席から「どの時点で何が見えていて、何が見えていなかったか」を時系列で並べてみます。
| 時期 | 見えていたこと | 見えていなかったこと |
|---|---|---|
| 参画直後 | 詳細設計書の一部に「確認中」「別途協議」の注記が残っている | その項目を誰が、いつまでに決める予定なのか |
| 実装の序盤から中盤 | 質問票に出した確認事項が、2〜3週間「確認中」のまま動かない | 質問の先で何が起きているのか |
| 手戻りの発生 | 「この部分を作り直してほしい」という指示 | なぜ仕様が変わったのか |
| 手戻りのあと | 期限は動かないまま、残業が増えていく | 上流で期限を見直す話が出ていたのか |
見えていたことは少しずつ増えていきましたが、見えていなかったことは、最後まで埋まりませんでした。
今になって整理すると、一番早い予兆は参画直後の注記でした。当時は「そのうち決まるのだろう」と受け止めていました。
確認中の項目が、実装に入っても減らない。この状態を見たら、手戻りが来る可能性を頭に置いて作業計画を見ておくほうがいい、と今は考えています。
手戻りで増えた残業の数字は、36協定の記事にまとめています。
上流工程の遅れを、下流工程の圧縮で取り戻そうとする
もう一つ繰り返し見てきたのが、スケジュールの無理な圧縮です。要件定義や設計といった上流工程が当初の予定より遅れているにもかかわらず、全体の納期そのものは動かない。
2社目では、手戻りが出たあとも期限は動かず、増えた作業は残業で吸収する形になりました。定例でも、日程を見直す話は出ず、作業を前倒しするよう求める指示だけが続きました。
なぜ今になってこのペースが求められるのか、その理由を説明されないまま、とにかく前倒しで進めてほしいという指示だけが降りてくる。上流で何がどれだけ遅れたのかは、最後まで下流のメンバーに届きませんでした。
3社目の移行期も、期限が先に決まっている仕事でした。本番の切り替えは24時間以上かかり、連休に置かれます。リハーサルを3〜4回重ね、作業の時間超過や手順書の誤り・漏れが出ても、見直せるのは手順書とやり方のほうで、切り替えの日程そのものは動かしにくい性質の作業です。ここは炎上というより、期限が固定された仕事の負荷として受け止めています。
特定の人がいないと現場が回らない、属人化・キーマン依存
3つ目の兆候は、属人化とキーマン依存です。この兆候は、私自身は炎上の渦中で強く体験したわけではありません。
3社目の保守改善の時期には、5年以上現場にいる40代くらいの協力会社の方がいました。ただ、質問や課題は整理するExcelに記録されていて、チャットや口頭でも聞けたので、確認できる相手がその方だけ、という状態にはなっていませんでした。
4社目にも、似た気配はあります。前任は別案件に異動した社員で、引き継ぎは実質5営業日でしたが、前フェーズの課題管理票が共有フォルダに残っているので、経緯を自分で追えます。経緯が記録に残っているかどうかが、平時の属人化と、炎上時のキーマン依存を分けていると私は見ています。
3つの兆候は絡み合って現場を追い詰める
2社目では、要件の手戻りと動かない期限が重なり、残業が積み上がっていきました。3社目には質問や課題を整理するExcelがあり、4社目には課題管理票が残っていて、同じ形では荒れていません。
兆候が3つ全部揃っていたわけではありません。2つが同じ時期に重なれば、現場は十分に荒れる、というのが私の実感です。
断定できないこと
この兆候がどういう順番で、どの程度の重みで絡み合っていたのかを、因果関係として細かく分析できるほどの情報を、当時のメンバーという立場の自分は持っていませんでした。あくまで結果として、2つ以上が同時に出ていた時期ほど荒れていた、という傾向として受け止めています。
忙しいだけの現場との違いをどう見分けているか
3つの兆候は、単体では珍しいものではありません。要件定義に多少の甘さがあることも、繁忙期にスケジュールがきつくなることも、特定の人に頼る場面があることも、平常運転の現場でよく見かけます。
私が違いを意識するようになったのは、兆候が同じ時期に重なった現場に限って、空気が明らかに変わっていくのを繰り返し体感してきたからです。
| 現場 | 同じ時期に重なっていた兆候 | その後 |
|---|---|---|
| 2社目 | 要件の手戻り、動かない期限(2つ) | 月45時間を超える残業が5か月続いた |
| 3社目 | 該当する兆候は確認していない(移行期は夜間・休日対応が重なった) | 兆候が重なった形の荒れ方はしなかった |
| 4社目 | 属人化の気配のみ(経緯は課題管理票に残る) | 荒れていない |
平常運転の忙しさなのか、炎上に向かっている兆候なのかを判断する明確な基準を、当時の自分が持っていたわけではありません。それでも、複数の兆候が短い期間に重なったときは、後から振り返ると炎上へ向かっていた、という経験則は自分の中に残っています。
下流のメンバーの席から観測できる炎上の兆候
3つの兆候は、後から振り返ればはっきり見えます。ただ、渦中でも、下流の席から観測できる手がかりはいくつかあります。統計ではなく、私が自分の画面や定例で実際に見てきた観測点です。
| 観測点 | 落ち着いている現場 | 荒れ始めた現場で見えたこと |
|---|---|---|
| タスクの増え方 | 件数が増減しても、理由が付いている | 理由の説明がないまま、週をまたいで積み上がる |
| 作業の消化ペース | 週ごとの件数が報告されるだけ | 計画との差を気にする聞かれ方に変わり、日ごとの消化数を聞かれる |
| 質問票・課題管理票の滞留 | 起票から回答まで平均2営業日(4社目) | 「確認中」が2〜3週間動かない(2社目) |
| 定例の中身 | 今週やったこと、来週やること | 日程の話は出ず、作業の前倒しの指示だけが続く(2社目の後半) |
| 前任者の抜け方 | 異動と説明があり、引き継ぎは実質5営業日(4社目) | 炎上と結びつけて見たことはない |
一番手応えがあったのは、質問票・課題管理票の滞留です。回答が返ってくるまでの日数は、自分の画面で数えられます。平時の数字を知っておけば、「いつもより遅い」が数字で分かります。
逆に、前任者の抜け方は、私は炎上と結びつけて見たことがありません。理由の説明がないまま人が入れ替わり続けるなら、聞いてみる価値のある視点だと考えている、という程度です。
1つだけで判断するのは危険です。件数が増えるのも、定例が短くなるのも、平時に起きることがあります。2つ以上が同じ時期に重なっていないかを見る、という使い方をしています。
なぜ下流のメンバーには炎上の予兆が見えにくいのか
結論情報が会社をまたいで降りてくる間に、背景や経緯が削られ、結論だけが届くからです。
ここまで書いた3つの兆候は、いずれも渦中にいる時よりも、後から振り返った時のほうがはっきり見えるものでした。渦中にいる時は、目の前のタスクをこなすことに集中していて、それが炎上の予兆だと気づけていないことのほうが多かったというのが正直なところです。
この見えにくさには、二次請け・三次請けという立場が関係していると考えています。元請けと直接やり取りをする立場であれば、上流工程の遅れや仕様変更の背景を、その場でリアルタイムに把握できるはずです。しかし下流の会社に所属するメンバーには、そうした情報は自社の上司や現場のリーダーを経由してからでないと届きません。
情報が降りてくる経路
- 元請け仕様変更や遅れの背景を、その場で把握できる
- 二次請け・三次請けの自社上司・現場のリーダーを経由して伝わる
- 現場のメンバー=私「とにかくこの通りにやってほしい」という結論だけが届く
情報が会社をまたいで降りてくるまでに、背景や経緯の部分から少しずつ削れていくのを、現場を変えるたびに感じてきました。「なぜこの仕様変更が起きたのか」「なぜこの納期は動かせないのか」といった、判断の前提になる情報は上の階層にとどまりやすく、下流に届く頃には結論だけが残っている、という場面を何度も経験してきました。
進捗会議や週次の定例でも、伝わってくるのは主に「今週やったこと」「来週やること」といった作業レベルの内容にとどまることが多く、その背景にある元請けとのやり取りや、上流での判断の経緯まで共有される場面は多くありませんでした。会議の場そのものが、下流のメンバーに背景まで伝えるための場として設計されていないのだと感じています。
この構造の中にいると、炎上の予兆に気づくタイミングは、どうしても遅れます。上流で仕様がもめている段階では何も伝わってこず、スケジュールが圧縮されると決まった段階になって初めて、下流のメンバーはその決定を知らされる。気づいた時にはすでに、対応するための選択肢がほとんど残っていない、ということが少なくありませんでした。
ポイント: 下流のメンバーが炎上に気づくのが遅れるのは、個人の観察力や経験の問題というより、情報が伝わる経路そのものの構造によるところが大きいと考えています。
元請けに近い立場ほど早く動ける情報を持っていて、下流に降りるほどその情報は結論だけに圧縮されていく。この構造を理解しておくだけでも、「自分の察知が遅かった」と過度に自分を責めずに済むはずです。
システム開発の遅れや失敗は、調査でどう示されているか
自分の経験が特殊なものでないかを確かめるために、公開されている調査を2つ見ました。どちらも、発注側やユーザー企業側を含む調査であり、下流のメンバーの実感を測ったものではない点は、先に書いておきます。
日経xTECHの調査:成功率52.8%は「半分が炎上」ではない
日経xTECH(日経コンピュータ)が2018年2月27日に掲載した「ITプロジェクト実態調査 2018」は、企業のIT部門・業務部門・ベンダーに所属する1201人から、1745件のシステム導入・刷新プロジェクトについて回答を得たものです。成功率は52.8%でした(出典: システム開発プロジェクトの5割が失敗、1700件を独自分析|日経クロステック)。
ここでの「成功」は、スケジュール(計画通りまたは前倒し)、コスト(計画通りまたは計画より少ない)、満足度(経営層とエンドユーザーが共に「満足」か「やや満足」)の3条件をすべて満たしたものです。
日経xTECH「ITプロジェクト実態調査 2018」。図の注記には「3条件を個別に見ると7割以上がクリア」とあります。
記事タイトルにある「5割が失敗」は、3条件のどれか1つでも欠ければ成功に数えない、という厳しい物差しの結果です。成功に当たらない約47%には、納期と予算は守ったが、経営層かユーザーのどちらかが満足しなかった案件も含まれます。
成功の基準を満たさなかったからといって、炎上していたとは限りません。2018年の調査でもあるので、この数字だけで「今の現場の半分が炎上している」とは読まないようにしています。失敗理由の内訳は有料部分にあり、私は確認できていません。
JUASの2025年度調査:規模が大きいほど、遅延や超過が増える
もう一つのJUAS「企業IT動向調査報告書2026」(2025年度調査)は、2025年9月5日から10月24日にかけて実施されたアンケートです。対象は東証上場企業とそれに準じる企業の4500社で、ユーザー企業のIT部門長に依頼し、957社から回答がありました(有効回答率21.3%)。
プロジェクト規模別に、品質・予算・工期が予定どおりにならなかった割合を並べると、次のとおりです(出典: 企業IT動向調査報告書2026(第7章 7.1 システム開発におけるQCD)|JUAS)。
| 規模 | 品質「不満」 | 予算「予定より超過」 | 工期「予定より遅延」 |
|---|---|---|---|
| 10人月未満 | 5.4% | 6.0% | 9.6% |
| 10〜50人月未満 | 8.2% | 10.4% | 16.2% |
| 50〜100人月未満 | 15.6% | 19.6% | 25.4% |
| 100〜500人月未満 | 26.0% | 36.2% | 38.8% |
| 500人月以上 | 29.6% | 42.2% | 47.8% |
報告書の本文には、QCDのすべてで、規模が小さいほど不良の割合が低く、大きいほど高いと書かれています。10人月未満ではどれも10.0%を下回る一方、500人月以上では品質29.6%、予算42.2%、工期47.8%です。
ただし、調査には「ある程度は予定どおり完了」という中間の選択肢もあります。遅延が47.8%だからといって、残りの52.2%がすべて予定どおりだったわけではありません。
予定どおりにならなかった要因(複数回答)も示されています。次の3項目が高い割合で、どれも前年度の調査より1.4〜9.7ポイント増えています。
| 要因 | 品質 | 予算 | 工期 |
|---|---|---|---|
| 計画時の考慮不足 | 48.8% | 51.0% | 52.5% |
| 想定以上の現行業務・システムの複雑さ | 48.8% | 51.4% | 48.8% |
| 仕様変更の多発 | 30.2% | 48.6% | 42.4% |
QCDの悪化に影響を与えている工程としては、「要件定義」(57.4〜69.0%)と「設計・実装・テスト」(51.7〜74.1%)の2つが高い割合です。
私が見てきた兆候との重なりは、次のように整理できます。
- 要件定義の詰めの甘さ、終盤の仕様変更 「計画時の考慮不足」「仕様変更の多発」「要件定義」の工程と重なります
- 上流の遅れを下流の圧縮で取り戻す 工期の遅延が、大規模案件ほど多いという数字とつながります
- 属人化・キーマン依存 対応する項目は、私が確認した範囲では見つかりませんでした。統計で裏づけられないので、この兆候は体験として書いています
品質の要因では、「ベンダーのスキル不足」が59.9%と、先の3項目より高く出ています。発注側から見た評価で、下流のメンバーとして読むと耳が痛い数字ですが、あくまで発注側の回答です。
この数字の読み方
JUASの調査は、ユーザー企業のIT部門長が答えたものです。私が入っていた現場が何人月の規模だったのかも、私は聞かされたことがありません。数字は私の肌感覚と矛盾しませんが、自分の現場に当てはめて「だから炎上する」とは言えません。
こうした調査は、発注者・PM・コンサルタントといった上流の立場からのものがほとんどです。二次請け・三次請けのメンバーの席から、炎上がどう見えるのかを書いたものは、あまり見かけません。この記事で書きたいのは、数字では拾いきれない、その部分です。
体調を崩す前に知っておきたい、残業の目安と面接指導
結論ここで紹介するのは、労災認定の評価の目安です。「ここまでは安全」という線ではありません。
炎上した現場では、残業が増えることがあります。私は、残業を断ったことが一度もありません。この節も、断るための話ではなく、自分が今どのあたりにいるのかを知っておくための話です。
厚生労働省が示している、時間外労働と脳・心臓疾患の関連
厚生労働省のリーフレット「脳・心臓疾患の労災認定」には、時間外労働の長さと発症との関連性について、次の評価が示されています(出典: 脳・心臓疾患の労災認定|厚生労働省)。
| 時間外労働の状況 | 業務と発症との関連性 |
|---|---|
| 発症前1か月ないし6か月にわたって、月おおむね45時間を超える時間外労働が認められない | 弱いと評価できる |
| おおむね45時間を超えて、時間外労働時間が長くなるほど | 徐々に強まると評価できる |
| 発症前1か月におおむね100時間、または発症前2か月ないし6か月にわたって、1か月当たりおおむね80時間を超える | 強いと評価できる |
ここでの「時間外労働」は、1週間当たり40時間を超えて労働した時間です。労働時間以外の負荷要因も、あわせて総合的に評価されます。
80時間や100時間のラインは「過労死ライン」と呼ばれることもありますが、これは通称です。労災認定の評価の目安であって、これを下回れば安全、という意味ではありません。
2社目の5か月を、この目安に当てはめてみる
2社目で、5か月連続で月45時間を超えた時期がありました。月ごとの数字は先ほどの36協定の記事に載せていて、その5か月の平均は約61時間、ピークは87時間です。
目安に当てはめると、2か月ないし6か月の平均が80時間には届いておらず、単月も100時間未満でした。一方で、45時間を超える月が5か月続いたことは、「長くなるほど関連性が徐々に強まる」帯の中にいた、ということになります。
私の残業の数え方が、厚労省の言う「時間外労働」と一致しているかどうかは、分かりません。目安の数字に届いていなくても、体への負荷は別だと、87時間の月に実感しました。
当時の私は、自分の時間外を、記憶に頼って追っていました。勤怠が二重管理になる構造の中で、忙しい月ほど定時のまま申告していたことは、別の記事に書いたとおりです。
自分の時間外は、自分で記録しておく
2社目の反省から、3社目以降は、自社の勤怠とは別に、自分用の記録を残しています。残業が少ない月も付けています。
私が付けている時間外の記録
- 何を 日付、始業と終業の時刻、休憩、その日の作業の中身を1行で
- いつ 退勤する前に、その日のうちに。月末にまとめると、2社目の二の舞になります
- どこに 自分だけが見られるメモ。自社の勤怠入力とは別に持ちます
記録の使い道は、数字を自社に見せることです。月の途中で45時間が見えてきたら、その時点で自社の営業か上長に伝えます。
面接指導を申し出る先は、客先ではなく自社
医師による面接指導の仕組みも、知っておく価値があります。厚生労働省の「こころの耳」によると、対象は、月80時間超の時間外・休日労働を行い、疲労の蓄積が認められる者(申出)です(出典: 長時間労働者への医師による面接指導|こころの耳)。
同じページの注記には、事業者についての記述が2つあります。
- 月80時間超の時間外・休日労働を行った者については、申出がない場合でも、面接指導を実施するよう努める
- 月45時間超の時間外・休日労働で、健康への配慮が必要と認めた者については、面接指導等の措置を講ずることが望ましい
数え方が、労災の目安の「時間外労働」ではなく「時間外・休日労働」である点が違います。
面接指導を実施する「事業者」は、私たちの場合、雇用主であるSES企業のはずです。客先ではありません。申し出る先も、客先の担当者ではなく、自社です。
自社が自分の時間外を把握していなければ、この仕組みに乗りようがないと私は考えています。「線を知る」「自分で記録する」「自社に伝える」の順に進めるのは、そのためです。
月45時間・年360時間の上限や、特別条項の数字は、この記事では並べ直しません。
炎上した現場でメンバーとして実践してきた自衛策
炎上の兆候そのものを、下流のメンバーである自分が止められたことは、正直ありません。要件定義のやり直しも、スケジュールの再調整も、自社と元請けの間で決まることであり、現場でタスクをこなしているメンバー個人が動かせる範囲の外にあります。それでも、自分の消耗をできるだけ減らすために、続けてきたことがあります。
炎上現場でメンバーとして続けてきた自衛策
- 気づいたこと、受けた指示を、その日のうちにテキストで残し、自分の担当範囲を明確にしておく
- 遅れの見込みが出た日に、1人で抱え込まず、現場のリーダーと自社の上長に伝える
1つ目:指示と確認事項を、その日のうちにテキストで残す
残す対象は、3種類です。誰からいつ何を指示されたか、確認事項とその回答、そして自分の担当範囲に入るかどうかの線引きです。
いつ残すかは、口頭で受けたその日のうちです。後回しにすると、言い回しの細部から消えていきます。
誰宛てに残すかは、指示を出した本人です。2社目のように、元請けの担当者が個人に直接作業を割り振ってくる現場では、その担当者に確認を返し、自社の営業や上長にも別に共有しました。
書き方は、毎回ほぼ同じ型です。
- 書き出し:「本日、〇〇さんからご依頼いただいた件、以下の理解で進めます」
- 中身:依頼の内容を2〜3行で、変更前と変更後の違いも添える
- 影響:作業が増える場合は、見込みの工数(たとえば「追加で1日」)
- 結び:「認識に相違があればご指摘ください」
返信が来なくても、「この日にこう伝えた」という記録は残ります。チケットのコメントやチャットなど、どの経路に残すかの使い分けは、質問の置き場所を整理した記事に書きました。
2つ目:遅れの見込みが出た日に、現場のリーダーへ言う
伝える中身は、「このタスクはあと〇日余計にかかりそうです。理由は〜です」という見込みの差と、その理由です。可能なら、優先順位をどうするかの相談も添えます。
いつ伝えるかは、見込みが1日分を超えてずれると分かった時点で、その日のうちです。誰に伝えるかは、まず現場のリーダー、次に自社の上長です。自社の上長には、チャットで事実だけを送ります。
正直に書くと、伝えたからスケジュールが戻ったことは、ほとんどありません。2社目も、手戻りのあとに期限が見直されることはありませんでした。2社目で残業が87時間に達した月に、自社の営業へ不安を伝えたときも、具体的な数字の返事はもらえていません。
それでも、共有した事実が残っていれば、あとで「聞いていない」という話になりにくくなります。
自衛策として、やらなかったこと
自衛策の軸は、この2つです。残業を拒否する、契約内容を盾に業務範囲を主張する、といったもっと踏み込んだ対応を取ったことはありません。メンバーという立場で、元請けと直接の契約関係にもない自分には、そこまで強く出られる材料も権限もなかったというのが実情です。
これらは炎上そのものを止めるための行動ではありません。 あくまで、すでに炎上している、あるいは炎上しかけている現場の中で、メンバーとしての自分の消耗を減らすための立ち回りです。テキストに残したからといって仕様変更がなくなるわけではなく、早めに共有したからといってスケジュールの圧縮が解消されるわけでもありません。
それでも、自分の担当範囲を後から示せる記録があることや、抱え込まずに共有したという事実は、自分自身を守る材料にはなってきたと感じています。
炎上した現場を抜けたいと思ったときの現実
結論契約の更新・終了は会社同士で決まるので、伝える先は客先ではなく自社の営業で、動くのは更新のタイミングです。
私は、炎上した現場で「この現場を抜けたい」と自社に伝えたことがありません。自分の意思で現場を辞めたことも一度もなく、現場を変えたのは3回とも、契約終了・案件終了によるものです。
そのため、「伝えたら抜けられた」という成功談は持っていません。ここで書くのは、私が見てきた仕組みの範囲です。
契約の更新・終了は、会社同士で決まる
SESの契約は、3か月更新が基本です。3社目の2年半では、更新の判断が9〜10回繰り返されたことになります。連絡は更新月の前月に、自社の営業から届きます。
終了が決まったときの通知は、3回とも、1か月前後でした。更新も終了も、決めているのは会社同士で、本人がその場にいることはありません。
相談先は客先ではなく、自社の営業
現場のリーダーや客先の担当者に「抜けたい」と言っても、決めるのは客先と自社の契約です。伝える先は、自社の営業になります。営業は窓口であって、客先との契約そのものを動かす人ではありません。
3社目の移行期は、移行チームの中で自社の人が私1人だけでした。自社との接点は、月1回の近況チャットと半年に1回の評価面談くらいで、営業から見ても現場の空気は見えにくかったのではないかと思います。この現場の話は、一人配置の現場について書いた記事にまとめています。
そこで伝えるときは、事実と希望を分けるようにしたいと考えています。事実は、先ほどの時間外の記録や、遅れの経緯のテキストです。希望は、「次の更新のタイミングで、体制や現場を見直せないか」という相談です。
営業の役割と、できること・できないことは、別の記事に整理しています。
伝えても、現場が変わるとは限らない
更新のタイミングを待つと、最長で3か月近くかかります。待てないほど体調が悪いなら、現場を変える相談よりも先に、体調のことを自社に伝えるほうが先です。先ほどの面接指導のように、雇用主の側に対応を求められる仕組みがあります。
伝えたから現場が変わる、という保証はありません。契約途中で自分の意思で辞める話は、制度の面だけを別の記事に整理しましたが、私自身に経験はなく、条文と伝聞の範囲です。
転職の話には、あえて寄せません。まず、記録を残して自社に伝える。その結果を見てから考えても、遅くはないと思っています。
同じ兆候が出ていたら、まず何を確認すればいいか
炎上を止める権限が下流のメンバーになくても、自分の現場が今どのあたりにいるのかを把握しておくことには意味があります。3つの兆候と観測点を、確認の視点として整理し直すと、次のようになります。
炎上の兆候をセルフチェックする視点
- 要件定義が本当に「確定」しているか。「確認中」の項目が、実装に入っても減っていないか
- 上流工程の遅れを、下流のスケジュール圧縮だけで取り戻そうとしていないか。テストの消化ペースの聞かれ方が変わっていないか
- 特定の人がいないと止まってしまう工程が、そのまま放置されていないか。経緯は資料に残っているか
- 質問票や課題管理票の回答が、いつもより遅れていないか
- 自分の時間外を、自社の勤怠とは別に記録しているか
1つだけ当てはまる現場は、これまでの経験ではそれほど珍しくありませんでした。ただ、2つ、3つと重なっていくほど、後から振り返ると炎上に向かっていた、という感覚があります。
今の現場がどの段階にあるのかを、この視点で一度整理しておくだけでも、テキストで記録を残すタイミングや、上長に伝えるタイミングを、少しだけ早められるかもしれません。自分が何次請けの位置にいるのかを確かめる方法は、別の記事にまとめています。
まとめ
主に2社目で見た炎上案件のパターンは、次の3つでした。
- 要件定義の詰めの甘さ、終盤の仕様変更(2社目の手戻り)
- 上流の遅れを下流の圧縮で取り戻そうとするスケジュール運用(2社目の動かない期限)
- 特定の人に依存した属人化・キーマン依存(3社目・4社目では、質問や課題の記録が残っていました)
これらは単独ではなく、2つ以上が重なって現場を追い詰めていきます。下流の立場では、この予兆に早い段階で気づくこと自体が難しいというのも、正直な実感です。情報は上の階層から降りてくる過程で、背景や経緯が削られ、結論だけが届くようになります。
調査を見ると、システム開発の遅れや超過は、大規模な案件ほど増える傾向があります。ただし、日経の「成功率52.8%」は3つの条件をすべて満たした割合で、残りの約47%がそのまま炎上の割合になるわけではありません。数字の読み方は、慎重にしておきたいところです。
もし今、同じように下流のメンバーとして現場にいて、タスクの増え方やスケジュールの変わり方に違和感を覚えているなら、それは思い過ごしではない可能性があります。自分の力で要件定義のやり直しやスケジュールの再調整を止めることはできなくても、指示と確認事項をテキストで残し、遅れの見込みを早めに共有し、自分の時間外を自分で記録することはできます。
線を知る、記録する、自社に伝える。炎上そのものを防ぐ力は下流のメンバーにはなくても、体調を崩す前に動く順番は、自分で決められます。




