山本一郎氏が語る、プロジェクト炎上のメカニズムと鎮火法：［録音禁止］「今日から僕は神になります」と言われても……

Unity主催の公式カンファレンス「Unite 2013」が、4月15日に東京で開催された。その中から、山本一郎氏の「プロジェクト炎上のメカニズムと早期発見、行うべき処理の概論」をレポートする。

[太田智美，＠IT]

山本一郎氏

　4月15日、Unity主催の公式カンファレンス「Unite 2013」が東京で開催された。ゲーム開発エンジン「Unity」は、インタラクティブな3Dコンテンツを作成するための直感的なツールとして近年急激な盛り上がりをみせており、カナダ・バンクーバーのほかアジア各国でもイベントが開催されている。今回は、東京で開催された「Unite 2013」から、山本一郎氏の「プロジェクト炎上のメカニズムと早期発見、行うべき処理の概論」をレポートする。

「炎上」とは何か？

　山本氏は、炎上を「現状のままでは時間、人員、予算を突っ込んでも求めるべき完成度が上がらないという状態」と定義する。つまり、デスマーチどころかそれ以前の状態を指す。デスマーチは皆で頑張れば何とか納品には漕ぎ着けられるが、炎上はモノが完成しない。やればやるほどチームはダメになっていき、やればやっただけ進捗がマイナスになる状態――それが、炎上である。例えば、次のような状態をいう。

• 仕切り直しをしたくても、予算が底をついた
• 後付けで開発者を投入しても、完成度が上がらない
• メインプログラマが逃げた

　炎上が収まると、デスマーチがやってくる。デスマーチは、「（品質は低くても）一応完成する状態」を指す。例えば、次のような状態をいう。

• 必要な実装を洗い出さずに作業に着手している
• 何を制作するか分かっていないのに、期間だけが決まっている
• 制作すべきものが洗い出せても、期間・予算・人員が不足している

　チームメンバーは終わりなき徹夜をし、納品を目指す。山本氏は、「炎上したならば、せめて適切なデスマーチに戻さなければならない」と言う。

「プロジェクトの進行度」と「複雑性」

　山本氏は、「プロジェクトの進行度」と「複雑性」の関係をグラフを示している。

「プロジェクトの進行度」と「複雑性」の関係

　失敗プロジェクトの傾向として、時間が経てば経つほど複雑性が増加していくことがグラフから見てとれる。この複雑さを、どう解決するかがポイントとなる。これは、ある程度決まった方法しかない。クリティカルな順番にその解決法を挙げる。

1. 責任者同士でハードランディングする
2. 責任者が責任を取った上で、仕切り直す
3. 現場（部下や下請け）が命を削って解決する

　1は、プロジェクトを取りやめるということ。もしくは、大幅な追加予算を投入し、仕切り直すという選択肢もある。これは、責任者がまともだった場合に用いられる方法だという。

　続いて、「責任者が責任を取った上で、仕切り直し」というパターンがある。1度プロジェクトを止めるということは、責任を追及されることを意味する。つまり、担当者が飛ばされて、仕切り直すのがこの方法だ。

　3番目は、悲しいが1番現実的だ。部下や下請けが命を削って解決する。残り少ない予算と時間の中で、最低限のものを作るケースである。炎上状態から立ち直らせるためには、複雑性を減らさなければならない。大幅な追加予算が取れず、かといって担当者が飛ばされないことを考えると、この解決法が取られることが1番多い。

　「問題を解決しようとするとき、『人さえいれば……』と人的リソースを求めがちだが、それは間違いである。人が増えれば、大抵の場合複雑性が増す。より良いプロジェクトの進め方を考えるならば『何を作るためにどれが足りないのか』を再確認する必要がある」と、山本氏は言う。

トレースチャートの有用性

　山本氏は、プロジェクトマネジメントにおいて、「トレースチャート」の活用を提案する。プロジェクトマネージャは、機能・概念別のトレース用チャートを作成し、進ちょくや環境を評価することで、問題の早期発見が見込めるという。

トレースチャート

　山本氏が考える「プロジェクトマネジメントの標準的モデル」は以下のとおり。

プロジェクトマネジメントの標準的モデル

　このように、全体像を確認しながら炎上ポイントを探ることが、プロジェクトをうまく進めるための秘訣だという。樹形図のどの辺りにストレスがかかっているのかを判定することから始め、できるだけそのストレスを回避する。そして、可能な限り複雑さを削っていくことがポイントだ。

全体図を確認しながら炎上ポイントを探る

それでも、突発事態は発生する

　ここまでで述べてきたように、きちんとプロジェクトマネジメントを行っているのにもかかわらず、誤算や遅延は発生する。ここで、山本氏が実際に見てきた「こんな突発事態は嫌だ」シリーズをお届けする。

• 発注担当者の女性にマネージャが恋に落ちて不要な連絡をたくさん入れる
• プログラマが「今日から僕は神になります」と言って突然来なくなる
• 心を病んだマネージャがおかあさん同伴で出社
• 制作作業で追い詰められ過ぎて、デザイナが他社製品の素材をパクる
• 制作指示のメモの字が汚すぎて読めない
• 「デバッグ期間なんて要りませんよ」と豪語するクライアント
• 制作している途中で制作会社が他社に買われる

　このような事態を避けるため、機能分析を行い、工期の前半に粗仕上げまで持っていってしまうことが重要だ。炎上を見据えて、複数の締め切りを用意しておく。

　炎上の教訓として言えることは4つ。

1. Unityに頼れる部分と、運用でカバーする部分をしっかりと分ける
2. 要求条件と優先順位を最初にしっかりと把握しておく
3. 炎上しているコンポーネントを早期発見し、報告する
4. 伝言ゲームを減らし、指揮系統を1本化する

プロジェクトの立て直しは上長の能力次第

　「プロジェクトの立て直しは、原則として上長の能力次第である」と山本氏は言う。「炎上当初は、どうしても放置して、その間に鎮火することを求めてしまうが、放置して鎮火することなどないと思った方がいい。炎上の程度報告、遅延状況、制作進ちょく度といった条件をまずはしっかりと客観的に見ること。その上で、撤退か追加リソースを確保するかを決定する。また、部下は上長に『様子を見る』という選択肢を与えてはならない。炎上案件の多くは、上長の判断が遅くて取り返しがつかなくなることが多いのだ。上長を説得するときは、『AかBかしかありません』という提案をすることをお勧めする。または、松竹梅を提示する。松竹梅の場合、一番最初の選択肢に『やめる』を入れること。大抵の場合、上長もやめたくはないため、その下に書いてある内容をちゃんと読んでもらうことができる」（同氏）。

　以上をまとめると、炎上からの回復プロセスは5つあることが分かる。

1. 追加リソースの確保
2. コンポーネント別制作進ちょくの確認（各分野で足りないものを洗い出す）
3. 炎上したルート（火元）の確認・対処（火元は、特定の個人にある場合が多い）
4. 仕様のスマート化（削れる仕様はすべて落とす）
5. 重要個所へのリソースの投入（重要作業に従事できない人は物量方面へ充当）

　炎上対策の要は、複雑性を減らすことにある。全体を見渡し、分からないことをなくす。当たり前のことばかりかもしれないが、この「当たり前」ができない場合が多いのだ。