【GDC2012】Biowareのプロデューサーが説く、大規模ゲームプロジェクト運営の秘訣 | GameBusiness.jp

【GDC2012】Biowareのプロデューサーが説く、大規模ゲームプロジェクト運営の秘訣

その他 その他

ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
  • ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジー
ゲーム開発の大規模化とともにプロジェクトを如何にマネジメントするかがこれまで以上に重要になってきました。昨年のCEDECにおいても株式会社ディンプスが同社のプロジェクト運営において、SCRUMを導入した事例が紹介されたり、スクウェアエニックスによりテクノロジーカンファレンスでもゲーム業界におけるプロジェクトマネジメントについて発表がなされ大いに話題となりました。GDC2011でもプロジェクトマネジメントはホットな話題のひとつになっています。

そのような中、GDC2日目のプロデューサブートキャンプ(強化合宿)において、大型RPG開発には定評があるBiowareのオースティン開発スタジオのプロダクトディレクターであるダラス・ディクソン氏がプロジェクトマネジメントにおける人材管理についてかなり深いところまで言及していました。今回はその模様をリポートします。

■大規模開発の中で肝となるトリアージの概念

Biowareオースティンスタジオのプロダクションディレクター、ダラス・ディキンソン(Dallas Dickinson、以下、Dickinson氏)氏は、6日、サンフランシスコで開催中のゲームデベロッパーカンファランス2012(GDC 2012)において、「Triage or Darth Malgus will do it for you (トリアージをやらないと、ダース・マルガスがあなたの代わりにプロジェクトを運営しちゃうよ!?)」と題した講演をおこないました。「ダース・マルガス」とはBiowareオースティンスタジオで開発されたMMO『Star Wars: The Old Republic』に登場するシスの暗黒卿。ディクソン氏自身がプロデューサとして関わった最新作でもあります。

その前に同氏は、ソニーオンラインエンターテイメントでMMORPG『Star Wars Galaxies』やMMOFPS『Planetside』を開発。今回の発表はこれらを含め大中小と様々な規模のゲーム開発プロジェクトに携わってきた同氏の知見を元にした発表となっています。

まず冒頭で、プロデューサとしての共通認識として、プロジェクト運営にはトリアージ(Triage)が重要とDickinson氏。トリアージとは、災害や軍事攻撃等で生じた大量の負傷者に対応する際、限られた医療チームのリソースを振り分けるために各負傷者の状況を確認し優先順位をつけるという概念ですが、プロジェクトマネジメントにおいても頻繁に用いられている概念。これについては、「たとえ用語を知らなかったとしても、自身の経験からタスクに優先順位をつけることがプロジェクトを成功に導く上で重要だということは知っているはず」と付け加えたうえで、今回の講演では、「『時間、費用、品質』を軸に全プロジェクト関係者のタスク、活動時間に優先順位をつけること」としました。

ただ、この使い方を誤るとプロデューサはプロジェクトにとって毒にも薬にもなりうるとし、自身が薬になるためには、「如何なる意図をもって」プロジェクトメンバーに指示を与えているかが重要としました。つまり、キャリアアップなど自己中心的な理由ではなく、作品そのものに対する愛が重要であるとのことです。指示を受ける側はリーダーの微妙な意識のブレを敏感に感じ取るとのこと。

ここで、Dickinson氏は、プロデューサが陥りやすい誤りとして、市場やユーザーターゲットを意識せず、作品開発のみに注視してしまう点を指摘。自分自身もオンラインゲームの研究段階で、中世の時代を舞台とした貿易重視のゲームを開発したところ、「誰のために開発しているのか」といった上層部の質問に明確な答えを出すことが出来ず、翌日プロジェクトがキャンセルされたという手厳しい仕打ちを受けたことを明かしつつ、プロデューサとして重要なのは「商品としてのゲームを期限どおり受け渡す(DELIVER)こと」であると強調しました。

■トリアージを進める上で必要な要素とは

トリアージはそれを実現するうえで重要なわけですが、最も重要なのは、概念の裏にある哲学的部分であるとDickinson氏。これについて、米国航空軍で活躍した、John Boyd氏が同氏の書籍において、空中戦で生き残るうえで重要なのは「如何に正しい判断が出来たか」では無く、「如何にすばやく判断出来たか」であったと指摘していた事を引用し、この意識はゲーム開発プロジェクトでも該当しうるとしました。この意識を共有したうえで、様々なタスクの優先順位を明確にするうえで重要となる原則について解説しました。

・OODAサイクル
トリアージを行う上で役立つのが、OODAサイクルだとDickinson氏。OODAとはObserve(観察)、Orient(体勢調整)、Decide(決断)、Act(実行)を永続的に続けていくというもの。これらは、品質管理で言われている、PDCAサイクルに近いですね。ただ、OODAでは、Orientがついているとこに違いがあります。如何なる状況においてもプロジェクト運営中は「体勢と整える」必要があるからでしょう。Dickinson氏もプロジェクト運営の阻害要因のひとつとして「分析に固執して行動しないこと」をあげています。また、プロデューサはサメのようであると述べた上でその根拠として立ち止まった途端、死んでしまうからとしました。

・過去の経験を生かす
過去の開発から学ぶ事も重要とのこと。ただしこちらも状況分析と同様に固執してしまうのは良くないとDickinson氏。従って、過去の事例について議論する際は、プロジェクト運営に関わる原則などの重要項目を中心におこない、だらだらと話し続けるのは効果的でないとのこと。

・最高のゲームを作るという共通認識を忘れずに
諸活動を続けていくと、自然と横道に逸れてしまう事はよくありますが、そのうちの75%が自らそう選択しているのだとDickinson氏。これを回避できればプロジェクト運営がより効果的になるとのこと。そのために常に開発当初からの目的である「最高のゲームを作る」という共通意識を忘れずに堅持する必要があるとのこと。

・人的資源のトリアージ
トリアージは、プロジェクト全体に関わる、予算、時間、品質における優先順位を決めていく行為であることから、それに関わる人たちの時間管理を徹底し、且つそれぞれが気持ちよく業務に携わる事が出来るような状態をつくりあげるのがプロデューサの仕事だと断言するDickinson氏。全ての人が目標を忘れずに且つ必要な情報を常に共有しながらプロジェクトに従事するには、プロデューサが大人の振る舞い維持する必要があるとのこと。従って、会議をするうえでも、議題、所要時間の明確化並びに会議後のアクションアイテムを明示出来ないことはあってはならないとDickinson氏。メールのやりとりも、ある課題に対し、3人以上の人たちが5−6回連続してスレッドを上げはじめたところでストップし、会議へと持ち込む必要があるとのことです。メールだけで意思疎通を図ろうとすると最終的にこじれてしまう事が多いことがその理由です。

・プロジェクトメンバーを分類化し「適材適所」を実現
前述のようにプロジェクト運営においてコミュニケーションをきめ細かく管理するのもプロデューサの仕事ですが、やはりプロジェクトに関わる全スタッフがその力を最大限に発揮するようにケアをするのが最大の仕事。「コイツは使えない」で済ますのでは無く、その強みを理解するということで、「適材適所」で全スタッフの能力を最大限に活用できるとDickinson氏。そのためにDickinson氏は開発者を様々な形で類型化し、プログラマー、デザイナー、マーケティング、そしてエクゼクティブプロデューサにありがちな行動パターンや心理状況を分類について解説しました。

・プロジェクトメンバーにありがちに行動パターンや心理状況:プログラマー編
悪のジニー
マネージャから言われた機能を他への悪影響などを明確に伝える事なく実行し、問題が起きたときに「あなたの指示に従っただけです」と言い切るタイプ。プロデューサとしてはこのようなタイプのプログラマーはかなり細かくケア(マネジメント)する必要があるとのこと。提案に対して課題などを示す事がなくどうしようも無くなったところで厳しく上司(つまりプロデューサ)を非難をする傾向があるので、その行動パターンを注意深く見ていく必要があるとのこと。

・プロフェッサー
チーム内で最も「頭の良い」プログラマーにありがちなのがこのタイプ。事実優秀でゼロから何かを生み出すことが得意なものの、それを商品レベルまで落としこむのは苦手であるとのこと。「僕はチームにとって付加価値が高すぎてデバッグなんて出来ないよ!」と(悪気無く)言い切ってしまうタイプ。このような人材はプロトタイプや、新機能の開発の初期段階を担ってもらい、有る程度開発が進んだところで、別のチームメンバーにまわすのが得策であるとのことです。

・キャプテンC#*$ブロック
彼らは大概会議の際は、最後部に座りながら会議の様子を伺いつつ決定事項をごとごとく覆していくタイプとDickinson氏。「彼らが会議で発言するのは自分自身が如何に他のメンバーと比較して優秀なのかを示すため。」とDickinson氏。従って自身の発言に対する代替案も用意していないとのこと。ただし、彼らの批判は確かに鋭く、懸案事項になりうるとDickinson氏。従って、このようなタイプのメンバーを有効活用するには、彼らが全ての提案事項に対し課題を示したところで会議を一旦小休止し、そこで感謝とともに会議から退出してもらってから、残りのメンバーで提案事項と課題を分析。最も問題が少なそうな提案を実行するべく話し合うことが肝心であるとのこと。

・サプライズキング
サプライズキングは、悪のジニーの対の存在にあたるとDickinson氏。どのような状況においても「これだったら、この時間までに出来るよ!」などと楽観的指標を示し、プロデューサがそれにあわせスケジューリングを進めていくと、後だしじゃんけんのように、商品レベルに落としこむにはあと数ヶ月は必要だと言ってくるタイプ。比較的に憎めない性格であることから、このようなプログラマーの提案を聞くときは、キャプテンC#*$ブロックを同席させるか、後で彼にこの提案についてどう思うかを確認すると仕事がしやすくなるとのこと。

・プロジェクトメンバーにありがちに行動パターンや心理状況:デザイナー編
チキンリトル
このタイプのデザイナーの仕事は非常に繊細と、Dickinson氏。従って、商品レベルに落とし込むうえで重要となる仔細の完成度を高める上で重要な役割を果たします。しかし、ひとつで間にか問題があると、それが如何にささいな事であっても長時間を費やしてしまう傾向にあるため注意が必要とのこと。彼らの仕事の様子を見定めつつ、何かで止まっているようであったらすぐに確認し、その課題を別の人に対応してもらうのがベスト。

・マジカルユニコーン
このタイプのデザイナーはプロジェクトに対し完璧なビジョンを脳内に持ち、その壮大なビジョンを変えることが出来ないタイプ。アウトプットもどうしてもその壮大なビジョンに依拠してしまう傾向にあるので、常に彼らの仕事に注意を払い、必要な仕事のみを有る意味無理やりお願いする必要があるとのこと。もちろん彼らのビジョンに同調することも重要。

・車輪の再開発者
彼らはシステム上の1%の瑕疵すら許せないタイプ。その1%の課題を解決するために全てのデザインをやり直そうとしてしまうとのこと。このタイプのデザイナーは管理するのが本当に困難なものの、とにかくそのような無駄な時間を費やさない様に注意を払う必要があるとのことです。

・マッドサイエンティスト
このようなデザイナーは優秀だが、コントロールが難しいとDickinson氏。一見、夢物語のような事を語っていながら、一旦何か作り出すととんでもない効果を発揮するとのこと。ただし、プログラマーというわけではないのでそれをシステム化することは難しいことから有る程度何かを生み出した段階で、それをプログラマーのほうに依頼しシステム化を進める必要があるとのこと。

・プロジェクトメンバーにありがちに行動パターンや心理状況:経営上層部編
プロジェクトを完遂させるという視点では他の部署や上司と言えども、「管理」しなければならないのが「プロデューサ」。従って、Dickinson氏は、マーケティング部門の人たちや、経営上層部の人たちの類型についても解説しました。会場に上司がいることを確認しつつ、それぞれ説明する際に「これはあなたではないですよ!」と言いながら説明している様は会場の笑いを誘っていました。

・マーケティング
マーケティング部門は特に分類する事なく、とにかく「期日どおりこれをやらないと問題になるんだよね」と一言告げれば大丈夫と、Dickinson氏。ここでは多くの観客の笑いを誘っていました。

・キッチンシンク
「このゲームのこの機能とあの機能を加えたらいいゲームになるんじゃないの?」と提案してくるタイプ。まさに台所の流しに、いろいろな物が溜まっていくように、提案が垂れ流されるというイメージでしょうか。彼らが提案する機能は、往々にして、そのゲームがヒットするために多くの開発者が数年間もの時間をかけ洗練させた結果として生まれた機能であるという事実を意識せずに気軽に提案してくるのが問題だとDickinson氏。

・このゲームをやったんだけど大好きなんだよね
キッチンシンクが複数のゲームにおける特定の機能を提示するのに対し、この手の上層部は単に自分の好きなゲームに似たゲームを作るようにと指示する傾向にあるとのこと。それでは自社の独自性を発揮できないのは明らか。

・灼熱の大地
宮本茂氏の「ちゃぶ台返し」は業界内外で既に有名ですが、同じ事が海外でも起こっているようです。ただし、この上層部の場合は、ゲームについてほとんど知識が無いのが前提。特にこの手の上層部が好きジャンルのゲームとまったく違うジャンルのゲームを開発中の場合、本質的な部分を端から改善するように「指導」する傾向にあり、手に負えないとのこと。

■全ては「最高のゲーム」を作るために

これらかなり「好き勝手」な事を経営上層部は言ってくるようですが、これらの的を得ない提案も、プロジェクト遂行の阻害要因にならないように処理するのがプロデューサの仕事とDickinson氏。このように、様々な人が関わり、それぞれがそれぞれの思惑でプロジェクトに関わっているものの、これらをまとめていくことがプロデューサの仕事なのだと改めて示したうえで、結局、様々な管理業務が何をするために行われているのかを再認識する必要があるとのこと。それはすなわち「優れたゲームを生み出すため」。このビジョンをしっかりと堅持しその基準に基づいてトリアージを導入すれば、皆が成功し、それに基づいた実績も築き上げられるとのことでした。
《中村彰憲》

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら