※本タイトルは【こうなってます】炎上現場(前編)の続編となっております。まだ見ていない方はリンクを見てね！
前回は基本的な炎上フローである
①：製品の完成が納期に間に合わない！
②：稼働時間を上げないと追いつかない！
③：残業！ 休日出勤！ 満身創痍！
これらの実態について説明しました。
それでは、こんな炎上案件に巻き込まれたらどうすればいいのか？ それを解説していきましょう。
炎上が佳境になると…自分の身を守らなければならない場面は必ず来ます。
家だって橋だって、設計書を元に作るのです。
設計書を元に現場で施工が進んでいる以上、仕様の変更などできるワケが無いのです。
ですが、何故かシステムはその変更が容易にできる、という謎の認識がまかり通っています。IT業界の悪しき風習です。
現場からしてみれば「何故 『動かない/想定通りの動きをしない』 設計書が承認されて現場に降りてきてんだ！！」となります。
炎上案件に限らず、設計書と外れた修正を求められた場合、設計書通りである旨は必ずリーダー/PMに言いましょう。
動かないコードも悪いですが、それ以上に、動かないコードを組ませる設計書に問題があります。
…、ですが、前回に書いた通り、平常時にこれを盾にする事を繰り返していると、現場からは落第の印を押されてしまいます。
多用は自分の首を絞めることになるので、ご注意を。
ただでさえ炎上してるのに、この期に及んで仕様変更/設計誤りだとぅ…？（怒
設計書が間違っており、これを直さないとシステムの整合性を保てない、という場合です。
そんな場合は、額に青筋を立てつつも必ず以下の4つの工数を算出します。
１．影響範囲調査工数
２．開発/修正工数
３．テスト工数
４．仕様書反映工数
仕様変更は、「１．改修による影響範囲を調べる工数」「２．実際にコードを書く工数」「３．挙動を確認する工数」「４．仕様書へ改修した仕様を反映する工数」の4つの段階工数を持ちます。
※４は１に来ることも多いです。４で行った場合はコードから仕様書を起こす『リバースエンジニアリング』になります。
絶対に工数を適当に申告してはいけません。他の作業が忙しいからと言って「○○日くらいで~」と言ってしまうと首が締まるケースが多いです。
それを概算した上で、バッファ（余剰工数）を多めに盛ります。馬鹿正直に想定工数を伝えてはいけません。首が締まります。
もちろん、その工数になる理由は必要です。影響範囲調査の際に、リスクとなり得る事象は必ず控えておきましょう。
必ず1人日 = 8h で算出し、それを伝えることも大切です。
残業込みで工数を出せなどという悪徳PMも世には存在します。1人日は12時間じゃないですよ（怒）
個人的な考えですが、休日出勤が開発の全体進捗を上げることは無いと思っています。
なぜなら、大多数の人はその出勤を帳消しするように、体調不良で休むからです。
普段も残業しているのに休日出勤を求められる道理はありません。
「用事がある」と言って逃げる事が大事です。
それに、本当に炎上している案件は、稼働日が1日2日増えた所でどうにもなりません。
結局PMや経営陣が揉めて、納期がずれる事も少なくありません。
それを期待して、英気を養うのも仕事です。
準委任契約であれば成果物に責任はありません。危険な案件はさっさと逃げるのが一番です。
現場、雇用主、エージェントに対して申し訳なさを感じている場合ではありません。『もたない』と思ったら、辞める旨は、とにかく早く伝えましょう。自分の身は自分で守らないと、本当に精神が崩壊します（経験談
ですが、完遂すれば「炎上案件を収めた」という貴重な実績ができる為、IT業界の歴が浅い方にとっては、残る選択肢もアリと言えばアリです。工数と体力との相談です…やるなら若い内です。
私も過去に炎上案件を3つ捌き切った経験があります。その経験は思い出したくないモノも多いですが、自身の血肉となったモノも多いです。
今回は『炎上案件の立ち回り』について書いてみました。
しかし…そもそも『炎上しない/させない為』にはどうすればよいのか？ 炎上しなければ誰も不幸にならないのに…。
個人的な経験を踏まえ、それを後編で書いてみようと思います。
入会申込
ログイン
