炎上案件Hack！ 今北産業。戦場（獄炎）を爆速で駆け抜けろ！ 3行説明、他（PMO編）
結論（どうすればよいか）
- 5W2h
- タスクボード
- エスカレ
これらができてくると約2W~4Wほどで案件は鎮火に向かいます。
もうちょっと詳しく
1. 炎上案件は、とにかく 報連相 が終わってる。とりあえず 現状把握 しろ！
いつ、だれが、なにを、どうした、どこまで、余力があればなぜ
→なぜ：気がついたら締め切り当日だったなんてのがあるので。
（mgmt（管理側）からしたら意味がわかりませんね、こまめに 中間報告 させましょう。）
2. だれも管理（まともな）なんかしていない！常に（毎日、なんなら毎時） タスク管理 を徹底しろ！
Redmine とかその辺てきとうに参考してください
→なぜ：炎上案件は確認依頼(仕様確認)が多発（工数比20~40%超え※観測範囲）。
仕様なんてない（まとまっていない）ので、過去案件の情報を溜め込むこと。
Ctrl+Fと1分で回答できたほうが幸せ。
3. 考えるな！聞け！迷ったら即相談！ ボールを持つ な！
案件に一番詳しい（ハズ）のは案件の依頼者というか責任者
顧客からの質問は豪速球で投げ返してください。
→なぜ：「顧客が本当に必要だったもの」
そんなに長くないが一応、以下解説
この内容の対象者
- PM 炎上中、炎上しそうなプロジェクトマネージャー
- PdM 炎上中、炎上しそうなプロダクトマネージャー
- PL 炎上中、炎上しそうなプロジェクトリーダー
- PMO 炎上中、炎上しそうなプロジェクトマネージャーオフィス
この内容の対象者外
- 無事に炎上案件を消火できたPM/PL/PdM/PMO等
- まともなPJ管理ができるPM/PL/PdM/PMO等
- Techリードなチームで働いている優秀なエンジニア（転職ドラフトでゴッド級）
- 炎上していない案件のホワイト環境なエンジニア
- PJ参加人数が関係者全員含めて極端に少ない1名~5名とかのチーム
ケース（状況）
- SES案件が炎上中（消火してほしい）
- マネジメントできる人がチームにいない（あなた）
- 顧客の要求レベルが高い（丸投げ）
- チームの開発レベルが低い（ベテランがいない）
その他やるべきこと
- 上記３行でまとめたので参照。
- 契約が請負か準委任かなど契約形態を確認しておく
また上司側に調整し、予め、炎上しまくって完全に崩壊しお手上げ状態になったら撤退してもよい建付けは事前に握っておく（逃げ道は常に作るべし） - 余った工数は自動化して残業地獄から常時定時内へ。枯れた大地に種をまき水やりを行っていく。
- 自分の後任を育てるか、マニュアルを残して、いつでも脱出できるようにしておく。（また火消し案件に呼ばれる頃には、立派な消防員（戦闘員）の仲間入ですね。）
- 品質レベル、コンプラ向上のためメトリックの導入等分析→ダッシュボード
- 技術力、アジリティ向上のため各種生産性向上の取り組み、ツール、ライブラリ、自動化、CI/CD、DevOps、リファクタリング、技術的負債の解消、勉強会、ドキュメント整理
その他Tips
-
コツとしては、プレイングマネージャーにならないこと。
（ただし、スーパーマン、締切は月曜の8時59分の必殺技、ウルトラCをよく使う人は除く）
リーダーが業務をしてしまうとメンバーからの情報が上がって来づらくなり、それがボトルネックとなり、あっという間に悪循環がはじまるので、常に業務はメンバーだけで回してください。 -
チームにアサインした直後にリーダー的な人がいるかも知れません（入れ替わりの場合もあります）
その場合は、リーダー的な人がもらっている情報、メンション（連絡先）、MTGで話す機会など、全件をすべて段階的にでもいいので、あなたにすべての情報が集まるようにしてください。全体に目が行き届かなくなってしまう形で、中途半端にリーダー二人となった場合、メンバーからは誰に報告してよいかわからず、情報が錯綜し、基本的に無駄です。※意図的にリーダー育成している場合は除く
この全件集中を条件にアサインしない場合、本来の目的消火という活動が達成されない可能性があるリスクは上長などに予め行っておくべきでしょう。
逆に、これらをまともにある程度やるだけで、炎上とは無縁です。 -
1週間いなくてもチームが回るようにするのが理想です。
浮いた時間で次にリーダーとなる人物を育成していき、マニュアルを整備し、ハンズオンで練習（代理で作業をさせ）、会議でも徐々にあなたが発言していたところを変わりに発言させる機会を増やす。などフェードアウトの準備をしていってください。これらは引き継ぎ作業を更に少ない日数で終えるための方法です。ブラウザのブックマークやツールの使っている設定など、ローカルの資料など共有できるものはすべて託して次の日さようならができるようにしておいてください。
見積
開発において、工数見積は何かとつきものですね。
見積についての確認依頼が発生した場合のQ&A的なものを作りました。
FYI（ご参考に）
回答Lv.1
デッドラインを超える可能性のある見積を絶対に顧客に出さないでください。
2W～3W（週間）で開発側から見積回答をすると、必ず下限の2Wで予定を切られます。
絶対に顧客（責任者、担当者）を信用しないでください。
また、開発要員の見積は1.5～2倍で顧客に回答してください。
ベテランの場合は1.25倍~1.75倍
中堅の場合1.5倍~2倍
新人の場合2倍~4倍
回答Lv.2
なお、顧客側から期日の前倒し要望をされて渋られた場合、
「いわゆる超概算見積となりますが～〇〇Wほど（〇〇営業日ほど）を見込んでおります。」と回答してください。
回答Lv.3
残念ながら、更に渋られた場合は「現状、不確定要素が多く正確なお見積もりをお出しすることは困難となりますので、開発側からの仕様確認につきましては、即日回答が前提となりますが、多少の工期短縮は可能かと思います。また、開発速度優先となる場合は、不具合発生時などの手戻りリスク、及びバッファ不足によるリスケ調整の追加工数も発生する場合がございます。それと、試験工程を省略する必要もありますので、いわゆる通し試験、ユーザーテストレベルの保証につきましては、お客様にて受入試験をご検討のほどお願いいたします。」とでも返してください。
回答Lv.4
それでも、渋られた場合は、「ご契約内容から御見積超過となってしまいますので、大変申し訳ございませんが、ご対応いたしかねます。つきましては、ご契約内容の変更または、見直しを御検討いただけますと幸いです。弊社担当営業の連絡先が必要な場合は、わたくしに一報いただければ。何卒！」と返しましょう。
回答Lv.5
それらが渋られた場合は、「何卒！」と返しましょう。
※人工増やすか、単価上げるか、できない場合もありますが、大抵予算次第だと思うので、予算無理ならこちらも無理ですのスタンスで暖かく見守りましょう。
QCDのQ可変、C無理、D無理となった場合、基本、全く動かない不具合だらけのシステムの出来上がりです。
回答Lv.Ex（オプションが有る人）
ちなみに、業界もピンキリですが、すべて一括で発注している場合もあると思いますが、QAの問い合わせ1件Openするごとに100万円、特急料金（3営業日前、定時後当日対応など）が発生するスタイルの現場など、この手のは運用案件が多いですかね。もあります。一度札束でわからせないといけないので、営業力がある人は是非、契約の際は特別条項を乗っけておくように。
見積の注意事項、他
- 見積もりの展開は常に首根っこ掴まれることになるということを肝に銘じておいてください。
これは、あなたとチームメンバー達の帰る時間が、その分遅くなることを意味しています。
残業代で稼ぐより、勉強して転職したほうがコスパいいですからね。 - また、現場によっては見積というヌルい言葉ではなく、締切やデッドライン、必達（事項）、必守、希望日など様々な呼び名がありますが意味はほぼ一緒です。
- 契約が請負か準委任かその他色々ありますが、これは必ず上長などに確認したほうがいいです。準委任ならいいですが、請負だと最悪持ち出しで赤字です（イメージ的には給料無しです。そんなことにはならないと思いますが、フリーランスなら給料なしですね。）。この言葉も言葉には意味が宿るので個人的には見積がしっくり来ているので使っています。請負だと締切ですかね（がんばってください）。
- 基本的に顧客という生き物は平気で期限を前倒ししてきます。
顧客が（まともな）システム開発のイロハを知っている人であればよいですが、ほとんどのユーザーは開発のことなんてわからない事が多いと思うので、基本的に工数は盛れるだけ盛れ。遅れると印象は悪くなれど、前倒しは褒められるので、実際はそこまで差分がないのに変な世界ですね。
あとがき余談
-
戦場の傭兵は成果と報酬によって動くものです。我々も報酬に見合うミッションを遂行してください。また炎上したときはこれを見直してください。
-
スライドシェアかなんかで公開予定
（記事の原稿自体は作り終えているのであとは整えて出すだけ）
TBD：URLはこちら -
タイトル不謹慎でしたね。
ダッシュボード 参考：
イメージ的にはこういうのを作ってね。
https://docs.microsoft.com/ja-jp/previous-versions/azure/devops/report/excel/excel-reports?view=tfs-2017