2013年4月15日、東京都のベルサール汐留でゲームエンジン“Unity”の技術カンファレンス“Unite Japan”が開幕。初日に行われたゲーム開発現場で起こりうる“炎上”をテーマにしたセッションの模様をお伝えする。
切込隊長こと山本一郎氏がUnityの問題をあぶり出す
ゲーム業界に限らず、コンテンツ開発の中長期的プロジェクトにおいて予算や納期といった要因は避けては通れないものだ。このセッションに登壇した山本一郎氏が代表を務めるイレギュラーズアンドパートナーズは、開発が遅れて納期を守れない状態に陥ったプロジェクトを受託して、調整や処理、事態を収拾することを業務のひとつとして行なっている。山本氏はこういった問題を抱えたプロジェクトのうち、現状のままではいくら頑張っても完成しない状態のことを“炎上（燃えた）”と定義している（ちなみに品質は低くても、頑張ればなんとか完成する状態のことは“デスマーチ”）。
炎上したプロジェクトは、プロジェクトマネジメントの観点から「複雑性が上がっている」と分析することもできる。こうなると「やればやるほど進捗がマイナスになっていく」という不思議な負のスパイラルが発生し、一体何をやっていてどこまで進んでいるのかを誰も把握していない状態になるという。こうして上がった複雑性は「プロジェクトを止める」、「追加予算を投入して立て直す」、「誰かが責任を取って仕切り直す」、「現場が命を削って最低限のものを完成させる」といった方法で解決するしかない。ちなみに納期に間に合わせるために人員を追加するといった対処が往々にして見られるが、結果的に複雑性が上がるだけのケースが少なくないようだ。プロジェクトの全体を見渡して、どこに何が足りないのか、何を作るために仕事をしているのかを明確にすることが必要だと指摘している。
プロジェクトが炎上しないようにするためには、事前に炎上の原因となりそうなポイントを探ればいい。プロジェクトのどこにストレスがかかっていて、問題が起きているのか。それがわかれば、対処や改善のしようもある。しかし、どれだけ頑張ってプロジェクトを管理しても、突発的な誤算や遅延は発生する。
また、いささか極端だが以下のような例も紹介された（すべて実話らしい）。
・取引会社の女性に恋をしたプロジェクト管理者が不要な連絡をたくさん入れる。
・プログラマーが突然、会社に来なくなる。
・心を病んだマネージャーが母親を連れて出社。
・追い詰められたデザイナーが他社製品の素材をパクる。
・制作指示書の文字が汚くて読めない。
・クライアントが「デバッグ期間なんて要りません」と豪語する。
→結果的にのちの作業負担が大きくなるだけ。
・開発中に制作会社が他社に買収される。
万が一、このような突発事態が発生しても対処できるようにしておくことが望ましく、そのために作業期間の早い段階でゲームが動く状態に持っていくこと（β版の前倒し）が重要だと語った。これは従来の家庭用ゲーム機の開発手法とは逆であるが、Unityのような新しいツールの登場によって、さらに重要度は増しているという。実際、β版の前倒しを行ったプロジェクトで、うまくいかなかったケースはないとのこと。
ここでプロジェクトマネジメントにおけるUnityの利点が説明された。標準的なプロジェクトの場合、プロジェクト管理者は作業時間の60％をチーム内のコミュニケーションに割かれる。そして、Unityは残りの40％の作業効率を引き上げる効果が期待できるという。具体的には、以下の2点を挙げられた。
・コーディング規約が少なくて済む
→チーム内の統一性を保ち、作業量を抑えることができる。Unityの場合、標準の4割以下。
・試作工程でゲーム性の検証が容易
→ゲームのコンセプトや問題を早期に確認することができる。
しかし、このようにUnityが便利であるがために問題が起きるケースがあるという。それが下のスライドだ。
Unityを使ったからといって、あらゆる面で作業速度が上がるわけではない。作業工程によってはやはり時間が必要な部分があり、この点を発注側が理解できていないと、結果的にプロジェクトが炎上したりゲームが完成しても失敗に終わってしまうようだ。山本氏はこうした事態を避けるために4つのポイントを挙げている。
・Unityに頼れる部分と運用で吸収する部分を分ける
・要求条件（要求仕様）と優先順位を最初に把握する
・炎上しているコンポーネントを早期発見し、報告する
・伝言ゲームを減らして、指揮系統を一本化する
さらに、それでも炎上してしまったときの対策にも触れている。炎上したプロジェクトを放置しておいて、そのまま立ち直る可能性はほとんどなく、絶対に“様子を見る”という選択肢を与える（選ぶ）べきではないという。山本氏の元に持ち込まれる問題を抱えたプロジェクトのうち、上長の判断が遅れたため取り返しがつかなくなったケースが非常に多いようだ。
炎上したプロジェクトに対しては、基本的に“撤退する”か“追加リソースの確保”しかないと強調している。しかし、実際には撤退の判断は責任問題が伴うので難しいようだ。そこで後者の対策による「炎上からの回復プロセス」が紹介された。
1）追加リソース（期間、予算、人員など）の確保
2）コンポーネント別の制作進捗の確認
3）炎上したポイントの確認と対処
→これは特定の人が問題であるケースが多く、プロジェクトから外したり、別の仕事を与えるなどの対処が必要。
4）削れる仕様を落としてスリムに
5）重要な作業を洗い出して、リソースを投入
これらは要するに「複雑性を下げること」に注力していることであり、プロジェクトの全体像を把握して、分からないことをなくすことで“火消し”は可能だという。
そして最後にUnityが直面している問題として、山本氏は「Unityに頼り切る馬鹿」が発生していると語った。Unityは何でもできる万能なツールではなく、プロジェクトが大きくなればなるほどマネジメントやコミュニケーションの重要性が増していく。“Unityしか使えない人”になってしまうと、Unity以外の分野において経験不足を露呈することになり、問題の火種となる可能性があるという。Unityとともにマネジメントに関するスキルを磨く必要があると指摘していた。
