山本一郎氏が語る「プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論」。ゲーム開発はなぜ炎上するのか

プロジェクト炎上のメカニズムと早期発見，
行うべき処理の概論

山本一郎氏

　2013年4月15日，Unity開発者のためのイベント「Unite Japan」が都内で開催され，「プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論」と題する講演が行われた。登壇したのは，炎上といえばこの人，ブロガーの“やまもといちろう”こと山本一郎氏だ。
　「炎上」と聞くと，我々は「うっかり発言で，ネット大炎上」などといったフレーズを思い浮かべるが，ここで語られる「炎上」というのは，ゲームの開発がにっちもさっちもいかなくなってしまう状況のことで，山本氏は，そういった案件に対する火消しのプロなのである。

　Unityに限らず，ゲームエンジンの普及によってゲーム開発は飛躍的に効率化しているが，その一方で，相変わらず炎上する開発案件も後を絶たない。今回の講演では，なぜ開発は炎上するのか，どうすればそれを鎮火できるかという問題について，プロジェクトをマネジメントする観点からの解説が行われたのだ。

　なお講演に先立って「本講演では，多数の実例に基づいた愚痴や中傷が含まれておりますので，写真撮影やTwitter，Facebook，Google＋などへの転載は別に構いません」という前置きがあったが，構わないと言われてもちょっとコレはいろいろ無理的なスライドも多数あったため，一部を省略してお伝えせざるを得ないことをあらかじめお詫びしたい。

「Unite Japan」公式サイト

そもそも炎上とは何か

　山本氏はまず，炎上の定義を解説した。炎上とは「現状のままでは完成しないし，品質もあがらず，仕切り直しをすることもできず，作業をすればするほど進捗が悪化していく状況」であるという。しばしば言われる「デスマーチ」は無理に無理を重ねて仕事をやっつけるという状況であり，少なくともそれによって作品は完成する。だが炎上は，デスマーチ以前の状況であると語った。
　しかし「作業をすればするほど，進捗が悪化する」とはどういうことだろうか？　普通に考えて，とにかく何かをすれば前進するのではないだろうか？

　山本氏はこの疑問を，プロジェクトマネジメントにおける「複雑性」という概念で解説した。
　成功するプロジェクトは，開発期間が経過すればするほど，複雑性が低減していく。だが失敗するプロジェクトは，期間をかければかけるほど複雑性が増大してしまうのだ。結果，プロジェクトに関わる人員が全体を把握できないまま苦労を重ねることになり，かくしてキャラクターのモーションだけが増えたり，素材ばかりが増えたりといった状況が発生する。

複雑性を下げる

　では，このように増大し続けるモードに入ってしまった複雑性を，どのようにして減少方向に持っていくのか。山本氏によると，炎上案件の複雑性を下げる方法は，ある程度限られているという。
　まずプロジェクトの偉い人（責任者）がまともだった場合，プロジェクトの中止や大幅な追加予算の導入による仕切り直しが行われる。またこの際，担当者の交代（いわゆる「責任を取る」状態）が同時発生することも多い。
　だが現実は厳しく，結局は現場が命を削って解決するケースもままあるようだ。これはもちろん望ましいことではないが，残念ながら起こるときには起こってしまうという。

　いずれにしても，複雑性を下げていくためには，なにがしか予算を追加していかざるを得ないと山本氏は指摘する。また炎上案件の現場ではときに「もっと人員がいれば」という声があがるが，人員を増やすと複雑性が上がる傾向にあるため，まずは現状のプロジェクトがどのような状況にあるのかをきちんと把握，確認することが重要であると語った。

プロジェクトのトレーサビリティ

　いずれにしても，プロジェクトが炎上したら大変なことになるのは事実であり，どうしたら炎上を防げるのかが大きな課題となる。この課題について，山本氏はまずプロジェクトマネジメントのあり方から解説を始めた。

　まず山本氏は，プロジェクトマネジメントの仕事とは，制作物が実現したいコンセプトに対して，完成したパーツをはめ込んで全体のバランスを保つ作業であると語った。その仕事の6割はコミュニケーションが占めているという（裏を返せば，Unityには，残り4割の効率を大幅に向上させる効果があるというわけだ）。
　実際に大きなプロジェクトを進めていくにあたっては，機能別，概念別のトレース用チャートを作って進捗を管理していく必要がある。これによって全体の進捗が明らかになるほか，問題が発生しているのであれば「どこで」「どんな」問題が起こっているのかを把握できる。炎上しかかっている場合，火元がどこかが判断できるようになるのだ。

　このように，プロジェクトのボトルネックになっているところを発見，把握することなしには，ある程度以上の大きなプロジェクトの効率は上がらない。またボトルネックを診断，理解するにあたっては，チーム内部での評価だけでなく，「誰が，どういう指揮命令をうけ，どうアウトプットしたかを確認する」ことが重要になると氏は語った。


　そのうえで，プロジェクトが複雑になればなるほど，必要とされるコミュニケーションの量も増える傾向にあると指摘。「何を作るのか」という点が首尾一貫していないときに炎上傾向が加速するという。具体的には「例えばアクションゲームを作ろうとするとき，『爽快感を求めよう』の一言で片付けるクリエイターがいたら，そいつはダメ」ということであり，「何をもって爽快とするかをはっきりさせなければ，作る側がどうすべきか判断できない。その結果，作業の優先順位も見えにくくなる」という。
　ここで必要なのは，作業全体でストレスがかかっている部分を具体的に判断し，そこに人員や予算を割くことであり，ただ漫然と「これをやらなくては」「ここが足りなさそう」というフィーリングで動いていると「子供のサッカーのようになる」そうだ。

それでもなお発生するトラブル

　このような予防線を張ってもなおトラブルは発生する。山本氏は以下のようなトラブルの類型を挙げる。

・気分でものを言う担当者によるもの（イメージの共有がなかなかできず，無駄な素材を大量に作ることになったり，ある程度完成した段階で「何か違う」といった，テイストの不一致が発生したりする）
・実際の使いやすさの問題（書類のうえではクールになるはずだったのに，実際に作ってみたらひどく使いにくい）
・機能上の問題（あまり効率的でない実装を行ったため，動作がもっさりとしている）
・拡張性の問題（管理ツールの実装を考慮していない）

　などを指摘し，「どこにどういう力点を置いて開発しているのかを，最初に考えておくべき」であると語った。


　また特殊なトラブルとしては

・発注担当者とマネージャーの色恋沙汰
・プログラマが謎の宣言とともに突然来なくなる
・心を壊したマネージャーが母親同伴で出社
・スケジュールに追い詰められたデザイナーが他社製品を真似る
・メモの字が汚すぎて読めない
・デバッグ期間なんていらないと担当者が豪語する
・制作会社が途中で他社に買収される

　……などが指摘されたが，重要なのはその内容より，「これだけ奇抜なトラブルが，実際に起こっている」ということだ。

　ゆえに，突発事態に対して余裕を作っておかねばならないと山本氏は語る。具体的には，制作期間の前半段階でβ版を作ってしまい，そして「このゲームはこういうところが面白い」という部分を早めに完成させてから，残りの工期でそれをブラッシュアップしていくという方法論だ。

　従来型のゲーム制作では，工程のあとのほうに重要な作業を押し込む傾向にあったが，Unityのようなツールの出現により，この順番を逆転させることが可能となったという。山本氏は自分の経験に則して「工期の前半でβ版を作れずに止まったプロジェクトはいくつもあるが，β版を作ったがゆえにダメになったプロジェクトは一件もない」と語った。

Unityによって起こること

　このような作業工程において，Unityのメリットは大きい。具体的に氏は「コーディング規約を大幅に（4割程度）減らせること」「試作段階で，どういうゲームにするのかの確認が容易であること」をメリットとして指摘した。


　だが，そのように便利であるため「Unityだから安い，早い，試作が簡単」「Unityだからすごいものが作れるに違いない」という，いわば願望めいた思い込みが発注側に生まれやすい側面もあるという。現実は「Unityを使おうが使うまいが，面白いゲームを作るのは大変なこと」だ。


　この発注側と開発側の齟齬は，大変な問題に発展することが多く，よくあるパターンとしては，確かに良い作品はできるのだけれども，納期が当初の予定より大幅に遅れたとか，途中から人員を大増員したため売り上げが伸びても赤字が解消できなかったりとかいった例が挙げられた。

炎上の教訓

　当たり前のことだが，Unityは万能ではない。ゆえに，「Unityに頼れる部分と，運用で吸収する部分を分ける」ことや，小規模なプロジェクトの頃から，プロジェクト全体を見わたして，「何を実現するためにこのプロジェクトを行っているのか，メンバーでしっかりと共有する」ことなどで，プロジェクトをマネジメントしていくノウハウを身につけるべきであるとする。

　また，「要求仕様と優先順位を最初に把握すること」の重要性も語られた。実装を進めていく中で「両方」ではなく「どちらか」しか実現不可能な要素が出てきたとき，そのどちらを取るのかが明確でないと，複数のプログラマーがそれぞれ違う重点で実装を行ってしまうことがある。


　さらに「炎上しているコンポーネントの早期発見と報告」も炎上回避において重要だ。これはただ「それを心がけましょう」という話ではなく，「なるべく炎上を早く発見できるシステムをいくつか作っておく」ということだ。

　「伝言ゲームを減らす・指揮系統の一本化」という点については，大規模開発でさまざまな人がプロジェクトに関わると，どうしても「同じ状況を見ているのに，違う報告書が上がってきて，誰の報告を信じていいのか分からなくなる」ことがあると山本氏は指摘する。これに有効なのは「言っていることではなく，起きていることに注目する。客観視できるシステムを作ること」だという。指揮系統にしても，たとえ指揮系統の図表があったとしても，それが実態と異なっていて，誰がどんな指示をだしているのか判然としないことがあるという。


　これらの防止策を施してなお炎上してしまった場合，状況はいわば「危機対応」となり，立て直しが効くかどうかは担当者の能力に大きく依存するという。放置して勝手に炎上が解決したりすることはないので，担当者に「とりあえず様子を見よう」などと言わせてはならない。
　実際，山本氏のもとにたどり着く炎上案件の多くは，炎上しつつある段階で担当者が「様子見」してしまった結果，どうにもならないところまで燃え上がってしまったケースが多いとのこと（質疑応答ではこの点について，「どう報告すればいいか」が語られた。中でも「対応策としてプランAとプランBを用意し，その一つでプロジェクトの中止を提案しておけば，提出した書類を全部読んでもらえる。プロジェクトを中止したい担当者は，めったにいないので」というノウハウは心に迫るものがあった）。

　最後に特殊な（そして遺憾ながらしばしば発生する）炎上パターンとして，隠れ炎上があると山本氏は指摘した。簡単にいえば，ゲームは完成しているのだが，つまらない――いわゆる「クソゲー」ができてしまうということだ。大変につらい話である。

炎上からの回復

　炎上したプロジェクトを立て直すプロセスは限られている。
　まず追加リソースの投入は不可欠だ。炎上によってリソースは薄くなるので，そのままで状況を好転させられる可能はほとんどない（現実的には「まったくない」と考えたほうが良い）。まず，何が・どこまで・どのように足りないのかを洗い出し，把握した状況を全体図に貼り付けていくのだ。

　炎上ルートの把握――つまり火元の確認も重要だ。これについて山本氏は「非常に残念なことだが，例外なく特定の個人がコミュニケーション不全を引き起こし，プロジェクトを炎上させる」という。そして，「何が問題になっているかをあぶり出し，その問題になっている個人を外すなり，追加人員をあてがうなりして，ボトルネックを解消することが大事」と語った。

　ちなみに，質疑応答ではこの点がさらに詳しく語られたが，危険なタイプとして「フィーリングでしゃべる人」「会議の前と後で言うことが違う人」などが挙げられた。ただ，そういう人が一概にダメかといえばそうでもなく，発想豊かで面白いゲームを作る力がある可能性もあるという。加えて，「会議の前後で言っていることが違う」ことに問題はあるが，それを周囲がきちんと指摘しないことにも問題があると山本氏は述べた。

　多くのことを一度にやろうとして複雑性が上がっていることも少なくないので，仕様を可能な限り削ることも欠かせない。「このゲームを成り立たせるために最低限必要なものは何か」がはっきりしていないと，なかなか炎上からは回復しないという。

　最終的に追加リソースを投入する際は，「このゲームは，何を遊ばせたいのか」というところから重点的にリソースの投入を開始すべきだという。これによって一部の人員が手すきになってしまうことがあるが，そうやって浮いた人員は，物量が必要な部門（DLCそのほか）にまわすことができる。

　炎上からの回復の要諦は，複雑性を下げることだと氏は語る。ゲームの根幹となるコンセプトを把握し，プロジェクトの全体像を掴むことはそれほど難しいことではなく，これを通じてプロジェクトの複雑性を下げていくことが可能となるのだ。

「Unityしか使えない人にならないでほしい」

　山本氏は最後に，Unityが非常に便利なツールであるゆえ，プロジェクトマネジメントの意識がなくても少人数でゲームが作れる印象を与えていると指摘した。また「Unityさえ使えれば，大規模プロジェクトに参加しても大丈夫」という意見も散見されるという。


　だがマネジメントコストが増大する大規模プロジェクトにおいては，Unityしか使えない人が適応できる局面はあまり多くない。したがって「Unityしか使えない人にならないでほしい」と山本氏は強調した。

　またプロジェクトマネジメントのスキルという点については，小規模チームをうまく切り回して良い作品を作った人が，大規模チームになるとダメだったということがあると語った。マネジメントスキルは適性もあるし，日々スキルアップのための勉強しなくては，磨かれないものでもあるのだ。

　まとめとして，山本氏は「炎上は属人的なコミュニケーションミスが原因」とする。そして，プロジェクトに参加するにあたっては「木を見るだけでなく，森を見る気持ちで」なるべく全体像を把握しながら仕事を進めるべきであると語るとともに，「万が一，炎上して，私に頼ることになったら，負けだと思ってください」と講演を締めくくった。

「Unite Japan」公式サイト