エンジニアとして、いくつかの現場を経験すると必ず遭遇するのが、「炎上案件」だ。
いわゆる、納期やプロジェクトの開発スコープ（範囲）が収集つかなくなり、大量にエンジニアを投入しないと解決できない案件をさす。

今回は、フリーランスエンジニアや駆け出しエンジニアが、できるだけ炎上案件に巻き込まれないための３つの注意すべきポイントについて解説する。

事の発端

今回、なぜ炎上案件に関する記事を書こうかと思ったか？というと、以下のTwitterだった。

この体験談と似たようなことを、EC系案件でいくつか修羅場経験したので、俺もあとでまとめて記事にするわ。

最近、この手の炎上少なくなったと思ったんだがなぁ。。。

数億円規模の案件をたった二人で開発させられた話 | Plus one @plus_one_masaki https://t.co/0qc5WAd4tT

— 外出する事以外はかすり傷、イカレたエンジニア兼CEO Hisashi (@freelife_man007) February 13, 2020

なぜ？数億円規模の案件を２人で回してんの？という疑問がわいたので、この記事を読んでいったら面白いほど典型的な「炎上案件」だった。

では、実際どのような案件が炎上するのだろうか？

炎上する案件の特徴

個人的な経験をもとにすると、以下のいずれかの様な案件の場合、大抵炎上することが多い。

実は、炎上しがちなのは、７ではなく１のケースだ。

受注金額が１００万円超える規模になってくると、1人もしくは2人で開発するケースが増えてくる。

ましてや、受注金額が億を超える場合、最低でも、

といったメンバーが最低１人以上必要になってくる。納期によってはSEやPGは2人以上必要だ。

だが、メンバーの要素よりもっと重要なのは、要求定義と要件定義なのだ。

炎上する火種のほとんどはスコープクリープ

要求定義と要件定義、同じように見えて定義することが異なるので、いったん整理してみよう。

要求定義や要件定義が満足にできていないと、初期フェーズで開発すべきタスクが大きく膨らんでしまい、スコープクリープ（要件が多すぎて、納期内でできる量を大幅に超えてしまうこと）を起こす可能性が高くなる。私自身も、PMやPLとして何度かスコープクリープを起こし、痛い目にあったことがある。

なぜなら、顧客は大規模案件になればなるほど、途中で仕様変更や修正を数多く要求してくるからだ。
（作る機能が多岐に渡れば、顧客から修正要望が多くなるのは自然なことである）

その際に、対応できることと対応できないことをふるい分けし、PMやPLは顧客に説明して納得してもらう必要がある。

では、どのようにふるい分けするのが良いのか？

スコープクリープを防ぐために工夫したこと

私自身、優秀なPMとは思っていないが、少なくとも中規模案件（受注金額が300万～）以上の場合、以下の点に気を付けるようにしている。

逆に、これらに当てはまらない場合は、顧客に説明して次フェーズや保守フェーズで対応するように調整している。

炎上案件をどう回避するべきか？

PMが上記の様な努力を怠った場合、どうなるか？は、皆さん想像つくだろう。

炎上案件にフリーランスエンジニアが参画してしまうと最悪で、次の案件にアサイン出来なくなったり、体調を崩したりと著しい不利益を被ることになる。

では、どうすれば炎上案件を回避できるのだろうか？

それには、以下の３つの注意点に気を付けるとよいだろう。

もし、上記３つのいずれかに不安を覚えた場合、できるだけその案件に参画しないほうが良いだろう。