エンジニアであればできる限り避けたい仕事、それが「炎上プロジェクト」です。
ところが、現実には予期せぬ形でうっかり巻き込まれることが多々あるのが現実でしょう。
そこで今回は、炎上プロジェクトが発生する原因と特徴、炎上プロジェクトから上手く撤退する方法について、現役のSESエンジニアが詳しく解説します。

【この記事を書いた人】
＜hide＞
情報系工学部の大学を卒業後からIT業界で仕事を続けている経歴10年以上のエンジニア。
案件自由選択制SESという様々な経験と幅広いスキルを追及できる働き方と、お客様とHappy-Happyの関係を築きたいという理念に共感してIDHに転職。
これまでWeb系エンジニアとしてフロントエンドからサーバーサイドまでJava、Ruby、Pythonを中心に設計、プログラミング、テストまで幅広く担当し、通信インフラ、広告配信、人材派遣業、金融、ECサービス、IoTなど数多くのプロジェクトを経験。

すべてのエンジニアが恐れる”炎上プロジェクト”とは？

炎上プロジェクトとは、大きなトラブルや問題を抱えているプロジェクトのことで、スケジュールに遅延が発生して想定通りに完了するのが非常に困難なプロジェクトのことを指します。
現役エンジニアはもとより、エンジニア志望者の方も一度は聞いたことがある言葉ではないでしょうか。もちろん、いい意味で使われているはずがなく、「絶対に避けたい仕事」として恐れられているわけです。

なぜ……炎上プロジェクトが発生する原因

ではこの炎上プロジェクト、なぜ発生してしまうのでしょうか。

1. 要件とは異なる成果物が出来上がってしまった

顧客が求める要件を実現するのがプロジェクトの目的であり、ゴールです。しかし、最終的に出来上がった成果物が要件とは異なったものだった場合は作り直しが発生します。
そのときの状況にもよりますが、最初から作り直しになった場合は最悪、設計・製造・テストの工程を一から行うことになりますので、当初予定していた工数より大幅にオーバーすることになります。

アジャイル開発の場合には小単位で実装とテストを繰り返して開発を進めて、短期間で顧客に成果物を確認してもらうこともあるので、要件と異なる成果物が出来上がってしまうような事態は避けられます。しかし、ウォーターフォール開発のような上流工程から下流工程へと順番に開発が進められていく開発手法ではあり得るリスクであるため、そうならないように気を付ける必要があります。

2. 上流工程で想定以上の工数をかけた結果、下流工程の時間が足りなくなった

多くのプロジェクトでは最初から納期やリリース日は決まっています。その期日までにプロジェクトを遂行するのですが、上流工程の要件定義や設計がなかなか決まらずに時間がかかると、プログラミング言語で実装する製造工程やテスト工程の時間がどんどん短くなってしまいます。

そうなると、当初は想定していなかった残業が必要になったり、納期に追われて集中力とパフォーマンスが低下したり……といった負の連鎖に繋がってしまいます。

3. 当初の見積が甘かったことで想定外の作業が多発した

要件を実現するために設計して、いざ製造工程となりますが、設計の段階で見積や技術調査が甘く、技術的に難しいことが発覚した場合は技術調査からやり直しになります。その結果、現状の設計のままでは対応できないことがわかると代替案を考えた上で顧客に提案し、妥協案を検討することに。要は、要件定義または設計からやり直しになってしまうのです。

わかりやすい例を挙げると、技術的に難しいことというのは、「0.1秒以内にデータの取得処理を実現しなければならない」という要件に対して既存システムのデータ量のままでは設計書に記載されている技術を駆使しても「10秒以上」はかかってしまうため、要件定義や設計書に記載されているデータの構造自体を変えたり、既存システムで使われているサーバやフレームワークの入れ替えが必要になったりするようなことです。

4. 結合テストで致命的な不具合や考慮漏れが多発した

設計、製造、単体テストと順調に進んでいたプロジェクトであったはずなのに、他システムとの連携部分といった致命的なバグや考慮漏れが多発してしまい、他システムへの影響を伴う設計からやり直しになるようなことが必要になったとします。すると、大幅なプロジェクト遅延が確定し、炎上プロジェクトにつながっていきます。

5. 人手・スキル不足

プロジェクトを完遂するために納期までの日数を計算した工数管理では人日、人月が割り当てられます。もし、途中でプロジェクトメンバーが離脱した際にはメンバーが増員されますが、増員されたメンバーの引継ぎがうまくいかなかったり、増員されたメンバーのスキルが不足していたりすると想定外の工数がかかってしまい、炎上プロジェクトの火種となってしまう恐れがあります。

離脱したメンバーのスキルが突出して高くプロジェクトの中核を担うようなメンバーだった場合や、数名が同じ期間に離脱してしまう場合など、離脱したメンバーの状況によってプロジェクトの炎上度は変わってきます。

6. リリース後に致命的なバグが発生し、至急システム改修が必要になった

全ての工程が完了し、納期にリリース作業が完了した……と思っていたら、リリース後にテストでは発見できなかった致命的なバグが発生してしまった場合、至急システムを改修する必要があります。

リリース前であれば、納品前のモジュールのみを修正すれば良いですが、リリース後の場合、Webシステムであればデータベースの修正作業が発生する必要がありますし、モジュールの修正も運用中のシステムのため、影響が出ないようにより慎重に作業を行わなければなりません。

バグの内容にもよりますが、システム障害に伴う停止、エンドユーザーのお金、企業の売り上げに関連するような重大なバグだった場合には昼夜に関係なく大至急対応する必要があります。そして炎上プロジェクトになってしまうのです。

7. メンバーのコミュニケーションが不足していた

プロジェクトの各工程ではプロジェクトメンバーとコミュニケーションを取って進めることが多いです。たとえば、設計する人、設計書を元に製造する人、製造した成果物をテストする人が異なることは珍しいことではありません。そういったときに製造する人は設計書の意図を理解して進めなくてはならないのですが、コミュニケーションが不足していると設計者の意図を勝手に誤解して製造してしまったり、テストする人が正しい動作を誤解して誤ったテスト仕様書を作成して誤った動作をテストで合格判定としてしまったりすることが発生します。

その結果、戻り作業が発生して納期までの時間がなくなり、炎上プロジェクトに……。

9. 進捗報告会が適切に行われていない

多くのプロジェクトでは戻り作業が発生しないよう、PMやPLは進捗報告会を開いてメンバーの進捗状況を日々確認しています。

ただし、この進捗報告会を「ただ聞いているだけ」「ただ報告しているだけ」のようになっている場合、困っていることや進捗状況が悪いことを見逃してしまい、後日になってから「実は全然終わっていませんでした」ということが起きて炎上プロジェクトの原因になります。

10. レビューが適切に行われていない

先程、下流工程で致命的な問題が発生した場合は上流工程の要件や設計からやり直しになることについて説明しましたが、それを避けるためにエンジニアの世界ではレビューを行う文化があります。

各工程でレビューを行うことでやり直しを避けられますが、プロジェクトによってはレビュー自体が行われていなかったり、レビューが行われていてもレビュアーのスキル不足や何らかの原因でレビューが適切に行われていなかったりするすると、やり直しを避ける抑止力にならず、後工程で炎上プロジェクトになる確率が上がってしまいます。

11. 資料が充実していない

プロジェクトメンバーの離脱は事前に予測できませんが、病気やケガなどさまざまな理由で誰にでも起きることなので、あらかじめ離脱のリスクは考えておく必要があります。

もし、離脱してしまった場合には新規参画者を受け入れることになりますが、開発環境作成手順書など、参画後すぐにプロジェクトに入れるようにするためにはドキュメントや設計書が充実しているに越したことはありません。
ところが、もしドキュメント類が一切なく、属人化されているプロジェクトに新規参画した場合、参画者にとっても既存プロジェクトメンバーにとっても炎上プロジェクトへの入り口となってしまう可能性は高いと言えます。

13. PM（プロジェクトマネージャー）が無能

PMはプロジェクトを管理して最終的なプロジェクトの目標達成に責任を負うマネジメント業務になります。

納期までのスケジュール調整から予算の管理やメンバーの業務負担の調整を行うため、PMが無能だった場合は、スケジュール調整のミスや問題が発生しても納期を顧客と調整することができずに開発者を急かすことで長時間残業になりがちになり、メンバーの士気を低下させることで炎上プロジェクトになってしまいます。

PMはプロジェクトの命運を握る非常に重要なポジションを言っても良いでしょう。

14. クライアントの都合で要件が変わってしまった

これまではエンジニア側に原因があるパターンについて説明してきました。一方、エンジニアには責任はなく、顧客の都合によって途中で要件が変わってしまい、設計や製造がやり直しになってしまうクライアント起因の炎上プロジェクトもあります。

炎上プロジェクトにうっかり参画してしまったエンジニアに起こりうる事態とは！？

プロジェクトは団体戦。一度炎上プロジェクトとなってしまった以上、誰しもが何らかの影響を受けることは避けられません。
図らずも“渦中の人”となってしまったエンジニアにはどのようなことが起こり得るのでしょうか。

仕事のパフォーマンスが低下する

炎上プロジェクトは残業が毎日続いて忙しく疲れるので、体力的が削られて集中力や判断力が低下します。
個人差はありますが、普段発揮できる能力が100％だとしたら80％…50％…30％と日々低下していきますので、いつもならできることができなくなり、負のスパイラルに陥るようになります。

病気になる

炎上プロジェクトはかかわる全員がとにかく忙しくなります。
イライラする人も続出するので、メンバーに話かけても雑多な対応をされることもあります。加えて、仕事のパフォーマンスが下がれば疲弊して身体的な病気からうつ病のような精神的な病になってしまう可能性もあるのです。
うつ病は一度なってしまうと回復までに時間がかかりますし、再発する可能性も高いので、エンジニアの身に起こりうる最悪な事態の一つと言っても過言ではありません。

低スキルのエンジニアになってしまう

炎上プロジェクトでは猫の手も借りたいほど忙しいので、新人が入った場合はひたすらテストをやらされることが多いです。

テストは品質を担保するための大切な工程であり、学べるスキルもあります。しかし、だからといってずっと炎上プロジェクトでテストばかりやらされていたら、いつまでたってもプログラミングのスキルが身に付きません。

ある程度経験があるプログラマーでも、ちょっとした改修を依頼されて「コードの質は問わずレビューなし、スピード重視」という形でひたすら不具合を修正する状況になることも。このようなことが続けばスキルが落ちてしまうのも必至です。

炎上プロジェクトの特徴を知ろう！

 

炎上プロジェクトかどうかは実際に参画してみないとわからないことが多く、事前に把握するのは難しいものです。
ですが、次のような炎上プロジェクトの特徴が参画前、または参画直後にわかれば、ダメージを最低限に抑えられることがあります。参画検討中や参画直後にチェックしてみましょう。

1. 直近でメンバーが離脱した

炎上プロジェクトは撤退する人が多いので、代わりのメンバーがアサインされることになります。その代替メンバーとしてアサインされてしまえば、炎上プロジェクトに巻き込まれる……といった流れに。
代替メンバーを募集する背景を確認するのはなかなか難しいと思われますが、直近で辞めたメンバーがプロジェクト起因の精神的な病や過労だったことが判明した場合は要注意。炎上プロジェクトである可能性が高いです。

2. メンバーが皆とにかく忙しい

参画してからすぐにわかる目印として「メンバーがみんな忙しい」「常にイライラしている」「話を聞いてくれない」「扱いが雑」といった状況が見られます。というのも、通常のプロジェクトであればゆとりがあるので、新規参画者に対して丁寧に扱ってくれますし、話を聞いてくれないなんてことはないからです。

3. コードの品質がひどい

炎上プロジェクトではメンバーのスキルが低かったり、とにかく納期に間に合わせるためにスピード重視の実装をしたりすることが多いので、プログラムのコードの質が悪い傾向があります。
多少のスキルがあればプロジェクトのコードの質を判断できるので、参画したらまずはコードを見てみましょう。

また、エンジニアの負担を軽減するために、「レビューの文化があるか」「テストコードを書いて自動テストを行って不具合を自動検知できる仕組みがあるか」「モダンな技術を積極的に取り入れているか」といったホワイトなプロジェクトが積極的に採用している制度・仕組みを取り入れているかどうかもチェックポイントになります。

4. 面談で“ 誰でもいいから人が欲しい感”が出ている

炎上プロジェクトには「スキルは関係なく、とにかく誰でもいいから欲しがっている」「面談者が妙に疲れ切っている」という特徴があります。
通常、SESは客先常駐の面談で了承を受けてから参画になるので、面談で失礼にならない程度にプロジェクトの状況を聞き、「人が足りなくて……」「皆ちょっと疲れていて……」というような言葉が先方から出てきた場合は注意しましょう。

5.　開発手法や技術が古い

古い歴史を持つウォーターフォール開発は、スケジュールを管理しやすくプロジェクト開始前後で変更が少なく変化に対する柔軟性を重視しない場合には適していますので、プロジェクトによっては悪いということではありませんが、近年ではエンジニアと顧客の要望のズレを軽減できるアジャイル開発のフレームワークの一つであるスクラム開発、試しながら開発を進めていくプロトタイピング型開発、設計とテストを繰り返して品質に重きを置くスパイラル型開発など新しいトレンドの開発手法が生まれています。

それなのに、プロジェクトに適していない古い開発手法や陳腐化した技術に固執している場合、炎上プロジェクトの要因となる下流工程から上流工程のやり直しが生まれやすい環境になっている可能性があるので注意した方が良いでしょう。

炎上プロジェクトから上手く逃げる＜撤退する＞方法とは？

スキルの低下、過労による体調不良、ギスギスした人間関係、うつ病……。
このような負の要素が凝縮された炎上プロジェクトから上手く逃げる（撤退する）にどうすればいいのか。
ベテランエンジニアの立場から次のようなアドバイスを送りますので、万が一のときに参考になさってください。

担当営業に相談して現場を変えてもらう

実は炎上プロジェクトにもメリットがあるので（この点については後で詳しく説明します）、がんばって参画し続けるのもアリだと思います。
ただし、無理は禁物です。「これ以上は無理だ」と感じたら、まずは担当営業に相談して現場を変えてもらうことを考えましょう。
この点、アイ・ディ・エイチであれば、担当営業がしっかり相談に乗ってくれます。

撤退する手順としては自分から直接先方へ伝えるのではなく、担当営業経由で炎上プロジェクトに撤退の連絡を入れてくれるので、“話を切り出す勇気”は不要。スムーズに撤退できると思います。
しかし、これは事が上手く行ったときの話。担当営業から何らかの理由で撤退NGと言われた場合は次のような方法になるかもしれません。

病名の診断書をもらって退職する

プロジェクトの単価が高かったり、常駐先の顧客と出向元で仲が良かったり……といった理由で撤退NGとなった場合は炎上プロジェクトで頑張るしかありません。

このような状況のときは、とりあえず仕事を続けて体が耐え切れなくなる直前、体調が本格的に悪化する前に病院で病名の診断書をもらって退職するのです。あまりおすすめできませんが、万が一のときに備えて覚えておいて損はない方法です。
なお、アイ・ディ・エイチで担当営業に相談して撤退NGになることはないと思いますのでご安心を。

スキルを身に付けて転職する

炎上プロジェクトは大変忙しく、朝から終電まで働くのは日常茶飯事。しかも新人であればテストや雑用ばかりやらされるわけですから、そんな中でスキルを身に付けるのは非常に難しいのですが、よほどタフで寝る間も惜しんで勉強したいという人ならこの方法もアリです。

絶対に避けるべき炎上プロジェクト撤退方法

もうおわかりだと思いますが、炎上プロジェクトでいくらつらくても、契約終了を待たずに急にいなくなる、つまりバックレは絶対に避けるべきです。
SESエンジニアがプロジェクトに参画する場合は派遣先企業との契約期間があるので、契約終了までは退場できないのが原則だからです。

炎上プロジェクトに入ってしまったからといって契約終了を待たず、担当営業にも相談せずに撤退してしまうと損害賠償金を請求される可能性もありますので、契約終了を待たずにバックレは絶対に止めましょう。状況によっては心身どころか経済的にも大打撃を受けてしまいます。

最後に～炎上プロジェクトにもメリットがある～

炎上プロジェクトの怖さについては皆さん、十分おわかりいただけたでしょう。
ここで最後に、炎上プロジェクトのメリットをご紹介したいと思います。
「え？メリットなんてあるの？」と驚かれた方、今現在炎上プロジェクトに参画中で悩んでいる方はぜひご一読ください。

達成感が大きい

炎上プロジェクトはとにかくつらいです。残業時間は多くなりますし、余裕なく業務を行うことになります。しかし、だからこそ、炎上プロジェクトを乗り越えたときの達成感は平坦なプロジェクトよりも大きいです。

柔軟に対応できるスキルが身に付く

炎上プロジェクトではテストや雑用に忙殺されるのでスキルが身に付きにくいと説明しましたが、必ずしもそうとは言い切れません。

予期せぬ不具合を短い期間で解析して修正したり、発生した障害に対してデータ修正を行ったり、テスト工程で見つかった致命的な設計ミスに対する代替案を考えたりするなど、実は高いスキルが必要になることもあります。
また、炎上プロジェクトでは追い詰められていますから、人によっては通常時では発揮できない100％本気の状態で臨機応変に対応できるスキルを身に付けることもできるのです。

何事にも打たれ強くなる

もし、炎上プロジェクトを乗り越えることができれば、ストレス耐性ができて打たれ強くなります。多少のつらいプロジェクトにあたっても「あのときの炎上プロジェクトと比べたらこのぐらい余裕！」と考える人が、エンジニア界隈では少なくないのです。

無理をすると大病になってしまうリスクもありますが、我慢できる程度の炎上プロジェクトであれば、一度は経験してみるのもアリなのかもしれません。

話のネタにできる

極端にひどい炎上プロジェクトを乗り越えると、飲み会の席や自己紹介の場で過去の武勇伝ネタとして話すことができます。
エンジニア面談の場でも「そんなにひどい炎上プロジェクトを乗り越えた人だから大丈夫な人だろう」といった感じで評価が上がることも……あるのです！
※ただし、情報セキュリティの観点から炎上プロジェクトの社名やプロジェクト名は伏せて、特定できないように気を付けましょう。