炎上からの回復プロセス
しかし、もし炎上してしまったら、あとは「危機対応」であり、「偉い人の能力次第」となる。そして、炎上したら偉い人に様子見をさせないことだと強調した。状況をしっかり報告し、それによって上長が激怒しようが、羽交い絞めにしてでもなんらかの決断を勝ち取ることがマネジメントを燃やさないために一番重要なことだという。
そして、炎上からの回復プロセスを以下のようにまとめた。
- 追加リソース（期間、予算、人員など消火剤）の確保
- コンポーネント別制作進捗の確認
-
炎上したルート（火元）の確認、対処
残念ながら特定の個人が問題を引き起こすことがとても多いので、それに適切に対応することが必要（テクニカルディレクターとアートディレクターの関係でもめることがとても多い） - 削っていい仕様をすべて落とす
- 重要な作業を洗い出して、リリースを投入する。重要な作業に従事できない人は物量方面へ充当
炎上対策の要諦は「複雑性を下げること」。プロジェクト全体を見渡したときに、ひとつひとつを解釈して状況を確認して判断していけばそれほど難しくはない。若葉マークのプロジェクトマネージャーでも、2～3週間がんばってログをトレースしていけば誰でもできることなので、ぜひ複雑性を下げる方向でがんばってほしいと山本氏はエールを贈った。
「Unity馬鹿」にならないように
最後にUnityが広く使われることの一番の問題点として、山本氏は「Unityに頼り切る馬鹿が続出すること」を挙げた。
「最近よく『Unity Slave（Dog）』という言葉を聞く。Unityを使えばプロジェクト全体を見なくても少人数でゲーム制作ができるように見えてしまう。そのために、マネジメントとチームメイト（作業員）の機能的な分離ができなくなってしまう人たちが出てくる。Unityはものすごく便利なツールで多くのプロジェクトで採用されているから、Unityを使えれば大規模プロジェクトに投入しても大丈夫だと言う人が多いが、むしろ逆に大きなプロジェクトでマネジメントコストが増大する局面では、Unityしか使えない人は意外と適応が難しいことが多い。なので、Unityしか使えない人にならないでほしい」（山本氏）
またプロジェクトの規模とマネジメントスキルについても言及。ある外資系デベロッパーが、ある拠点から撤退するときにつくった書類を示した。サンプル数に問題はあるものの、その資料からは、小さい作品（18人月以下）をつくって当たったからといって、大きいプロジェクト（250人月以上）で有能とは限らないということが読み取れるという。規模的な部分に対する適性というのはマネジメントスキルにおいて非常に大きいため、プロジェクトをだれにどう仕切らせればうまくいくのかを考えるときには、この点をぜひ考えてほしいと山本氏は語った。
まとめ
山本氏は最後に、あらためて以下のようにまとめた。
- 最初の要求仕様、優先順位、概念（コンセプト）の確認が炎上を防ぐ
- 炎上の理由の大半は、属人的なコミュニケーションミス
- Unityは便利ゆえに無茶な要求が出やすく、チームの経験値が高まりづらい
- 燃えてしまったら偉い人に判断を促そう
そして、基本的には、木ではなく森を見るような心がけでプロジェクトにたずさわってほしいと述べ、「もし何か起きて、私に頼らなければならなくなったら負けだと思ってください」と語り、場内を笑いに包んで講演を終えた。
