ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法

ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ ということで、CEDEC 2012ではドラゴンクエストXの世界観を支えるサーバシステムはどのように構成されているのか、ということが講演されましたが、さらにドラゴンクエストという人気作品を制作する上でどのようなマネージメントが行われたのか、ということについても、スクウェア・エニックス開発部所属の荒木竜馬さんが大規模開発ならではの問題やそれを解決するための工夫について語ってくれています。

タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference
http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html

荒木竜馬：
今日はドラゴンクエストの話ということで、朝早くからたくさんの人にお集まりいただき誠に光栄です。何かしら持って帰っていただけるような話ができればな、と思いますので、よろしくお願いします。で、今日なんですけれども、ドラクエの話ということで、堀井雄二さんとどういった方法で仕事をやっているのかな、とか、いろいろドラクエの裏話みたいなことを期待していらっしゃる方も多いんじゃないかと思うんですけれども、意外と真面目にこつこつマネージメントをやっていますよ、という話がメインになります。

大事なことを言うのを忘れていました。一応、「今日は撮影の方はご遠慮ください」という資料があるんですけれども、後々資料を公開しますので、カメラにバッテンがついているマークを右端の上の方に載せているページがあるのですが、それ以外に関しては、写真を自由に撮っていただいても構わないかな、というふうに思っています。レポートを書いてこい、とか言われている人も多いとは思いますので。いちいちメモ取ってるよりは写真でパシャリと撮ってもらった方が楽チンだったりしますので、このカメラのバツマークがついているページ以外は自由に撮っていただいても結構です。あとはTwitterとかfacebookでつぶやきたい人も、どんどんつぶやいていってくれればな、と思います。

まず自己紹介の方からさせていただきます。株式会社スクウェア・エニックス開発部所属の荒木竜馬と言います。他社の方を経まして、2003年に入社して、代表作の方は「FINAL FANTASY XII」で、現在は「ドラゴンクエストX 目覚めし五つの種族 オンライン」 のデザインセクションマネージャーをやっております。「ドラゴンクエストX」についてなんですが、今日はムービーを見てもらって、ゲームがどんな感じか見てもらおうかな、と思ったんですけれども、社内リハで80分もしゃべってしまって。ちょっと時間がなさそうなので、そちらのムービーの方はカットしたいと思います。シリーズ初のオンライン対応ということで、8月2日に発売済みで、絶賛稼働中でございます。まだご購入いただいていない方は、ぜひともお手にとっていただければ、と思っています。詳しいことはWEBの方に掲載しておりますので、そちらを見に行っていただければ。

さっそく話を始めていきたいと思うんですが、本日のアジェンダなんですけれども、ご覧いただいているような感じで話をしていきたいと思います。今回はマネージメントの話ということで、アジャイルの話からワークフローなどもろもろ、開発でのマネージメントの話あれこれをいろいろお話していく予定です。メソッド、開発手法についてもいくつかお話をしようと思っているんですけれども、個別に手法を掘り下げるというよりは、アジャイル開発……「こういう感じの捉え方をしてやっていますよ」というような実例をお話できればな、と思います。

まず、大規模開発の利点と欠点というところからお話を進めていきたいと思います。ドラゴンクエストとか、あとFINAL FANTASYなんかもそうなんですけど、「トリプルAタイトル」と言わせていただきますが、様々な職種の人間が制作に関わるプロフェッショナルの結晶でございます。トリプルAタイトルは、他社にない世界感や遊びをお客様へ提供するため、どうしても制作についてはボリュームが大きくなってしまいがちです。また、昨今のテクノロジーの進化、あとは専門分野の広がりですね、それを実現するために実装制作するリソースも、どうしても大規模なものになってしまいがちです。で、開発組織が大規模になりますと、なかなか人数通りのパフォーマンスが出せなくなります。イメージ的には大体やはり50人を超えてくると、1人で把握して取り回せる人数ではなくなってくるかな、という印象です。そうすると組織としての枠組みやルーリングですね、こういったものが必要になってきます。100人を超えてくると、制作の意思疎通やコンセンサスの部分でも困難になってきて、プロジェクト規模的にもスタッフがプロジェクトの全体を把握しながら仕事を進めるということが困難になってくるように思います。

そうした時に発生してくる問題として、プロジェクトのスケジュールやゴールを共有できないことによる齟齬や認識違い、その齟齬や認識の違いから発生する遅延とか、プロジェクトの内情やゴールが見えないことによるスタッフの不満などが積もってきたりと、様々な問題が生じてきます。そういった大規模化で起こりうるリスクに対してのリスクヘッジ、リスクの回避ですね、それをするための工夫が非常に不可欠になってきます。メソッドの導入やチーム運営の工夫を行うことで、そういった問題が起こることを事前に防いだり、あるいは起こらないようにするのがマネージャーの仕事です。本日は「メソッドについては大規模開発における軽量的開発、柔軟に開発していきましょう」というものを実現するため、いくつかの手法を組み合わせた運用事例、あとは本作を通して取り組んできたマネージメント全般に対する工夫はもちろん、苦労した点も含めて、考察もあわせてお送りしたいと思います。ということで、ドラゴンクエストXのプロジェクト・マネージメントということで進めていきます。

開発体制と組織について最初にザックリと紹介します。

こちらは大体こんな感じの組織で制作をしていますよ、という感じなんですが、おそらく他の会社さんとそう変わらないのかなという感じです。画面の赤枠で囲っている部分が、僕がマネージメントを直接管理をしている部分です。組織としては、プログラマー、アーティスト、ゲームデザイナーとあって、その他プロデューサー、ディレクターと、その他もろもろの多種多様な職種の人たちがやっているという感じで……。ちょっと分かりにくいところを説明しますと、「VW」と書いてあるのは社内のCGムービー専門集団ヴィジュアルワークスさんですね、オープニングムービーを作っていただいています。僕が管理しているところのプログラマーで「GFX」とあるんですけど、これは描画プログラムです。「キャラクター」は、キャラクターを作っているんですけれども、「モーション」に関しては、NPCとかモンスターとか、あとフェイシャルのモーションとかもここに含んでいて、あとテクニカルアーティストみたいなのも便宜上モーションに所属していたりします。「カットシーン」については、リアルタイムのイベント操作ですね。絵コンテからカメラワーク、モーションまでを生かした制作になります。「3DBG」については3Dの背景……今回はMMOということでかなり広大なマップを作ってもらっています。そのあたりで起きてきた問題みたいなものも、のちのち話をしたいというふうに思っています。「エフェクト」と「BGアート」についてはそのままで、あと「メニュー」についてはUIアーティストですね。大体このような組織で作っています。この中でプロジェクトの進行を管理し、状況の整理等の判断をやっている、という感じです。分業化された仕事においてスムーズに制作が進むように、ワークロードの構築、整備、あるいはこういったパート間のあいだで起きた問題解決や調整などを僕が行なっています。また客観的な立場から製品のバランスを見て、制作進行の上で実装化するものの取捨選択をする、ということも行います。

というような前提を知ってもらった上で、開発手法、メソッドについてのお話に移っていきたいと思います。アジャイル開発についての話がメインになってくるんですけれども、アジャイル手法は本来、小規模開発に適した手法なんですが、近年のハイエンドグラフィックスやMMOのゲーム開発プロジェクトは大規模になってしまうことが往々にしてあるので、今作ではいくつかのメソッドを利用した工夫を行なっています。ということで、まずそもそもアジャイルというものの個人的なとらえ方を知ってもらった上でそういった話に移っていきたいと思います。

アジャイルについてなんですけれども、僕は広義的な捉え方をしておりまして、作りながら仕様を決めたり、途中で変更することを前提とした手法、というとらえ方をしています。

要するに不確実なものに対する開発手法で、特にゲームは実装してみて調整を繰り返して品質を向上させていくものなので、基本的に親和性は高いと思っています。つまりアジャイルというと狭義的にはいくつかの手法そのものを指したりとかするんですけど、今日ここでは広義的な「不確実なものをリスクを最小限に抑えながら、いかにいい感じに開発していくか」というような捉え方でアジャイルと呼ばせていただきます。特に大規模開発になればなるほど、不確実性というものが高くなります。不確実性は始めは最大で、時間が進むごとに比例して徐々に小さくしていくことができるものなんですけれども、このリスクをどう最小限に留めるかがマネージメントの焦点になってきます。

ということで、ハイブリッドなマネージメントということについて話をしていきます。今回、マネージメントを行うにあたって、大きく4つのポイントで捉えているので、それをご紹介していきます。はじめに「毎日15分ミーティングで進捗管理」、要するにスクラムを参考にしますよ、というお話です。

既にいろいろ理解していただいているところではあると思うんですけれども、開発の上でよくある問題として、例えば日々生まれるバグや要望、日常的に生まれる新しい要望で元々のタスクが圧迫されてしまうとか、スタッフ自身が着手しやすいタスクから手をつけてしまって、重要なものが後回しになってしまう、あとは声が大きいところから先に手をつけてしまう、などなどの問題があると思います。こういった状況に手を立てないでおくと、いつの間にか大変なことになっていたりとか、「あれは認識違いで進んでいたいたかな」、とか、そういったことが起こってきます。

開発の日々刻々と変わる状況に臨機応変に対応、コントロールするためには、それを察知できるタイミングや綿密なコンセンサスが必要です。状況は日々刻々と変わります。毎日15分程度の会議で状況の把握とコントロール、管理を行うことで、状況の変化に柔軟に対応していきましょう、という意味ですね。ポイントとしては、毎日こうした手間を惜しまないことが重要ですよ、ということと、あとはイタレーションごとというか、マイルストーンと思っていただいていいんですけれども、その中でしっかりと目標を決めて、日々の管理を行なっていく、というところもポイントかなと思います。

「朝会」と言っているんですけれども、毎朝15分から20分くらい人を集めて、セクションごとにパブリックミーティング、まあスクラムミーティングをやる、という感じです。座ってやることもあれば、スタンディングでやることもあるんですけれども、もしまだ導入されていない方はスタンディングでやった方がいいかな、と思います。なぜかというと、スタンディングでやると必要最小限の話だけ、という感じになると思うんですけど、座ってやるといろんな話に発展して、結構じっくり話をしはじめちゃうんです。なので、もしやる場合はスタンディングでやった方がいいかな、と。上の写真では座っちゃってるんですけど、なんでかって言うと、画面に写っていないところでプロジェクターに進捗のガントチャートを映しながら話したりしているためです。そういった場合は座りながらやったりもしています。スクラムの話はそのくらいで。

次に「優先度に則ったタスク管理」、これは狩野モデルという思想を参考にしております。

実装要望を「なくては困る」「ないと不満」「あるとより良い」といったカテゴリにランク分けをして優先付けを行っていきます。そうするとマストなものと、そうでないものの違いが見えてくるわけです。この判断基準に関してはディレクターにあるので、ディレクターの実現したいことをそもそも理解して、それによる判断を行う、ということが重要になります。ある程度はマネージメントする人間が取り回しをやるんですけれども、プロジェクトの大きなディレクションに関するものは、ディレクターやアートディレクターに直接判断を仰ぐこともあります。これについてのポイントとしては、ラストまでの行程を明らかにし、無理なものは大量生産に入る前の時点で切るなりの調整を行う、ということで、これによって本当に必要なものに力を注力できます。そしてその後に出てくるアイデアや追加要望みたいなものも、既存のタスクにおいてプライオリティが明らかになっていれば、そういったものとの取捨選択がしやすい。これについては弊社ではデータベースにおけるタスクの管理を行なっておりまして、インハウスで作られたバグ管理システムがあるんですけれども、そちらを利用してタスクの管理を行なっています。この中でタスクのタイトルだったりとか進退度を書いて、あとは優先度という項目があるので、その優先度をつけて発注する、というような形をとっています。WEBベースで見られるようになっていまして、一覧で見て優先度を見たりだとか、イタレーションごとに絞って閲覧して確認をしたり、といったことができるようになっています。

次に「バッファーコントロールでリスクヘッジ」をする、という話です。これはクリティカルチェーン・プロジェクトマネージメント、CCPMと呼ばれるものを参考にしております。起こりうる問題として、スケジュール通りに終わらない、問題が起こる度にそれだけの管理になってしまっている、あるいはスケジュールに無理やり収めたので、結果、そもそも目指す品質が達成できなかった、などの問題があるんですけれども、そもそもそういった原因として、かつかつにスケジュールを引いているのではないのか、というものです。

そういう、実装タスクをかつかつにスケジュールとしてひいてしまう原因として、そもそもバグなどの手戻りを想定していなかったり、期間でできること以上のことを隠してしまっているとか、あとプランニングされたものがすべて実装されたらFIXだと思っているというようなことが考えられます。よくある問題と言えばそうなんですけれども、こういったリスクを回避するため、CCPMというものを採用しております。このメソッドはタスクを2点で見積もり、バッファーを持たせましょう、ということです。

見積もりについては、最短と最長の2点での見積もりを行います。見積もりの見方ですけれども、実装化そのものにかかる日数を最短、手戻りや調整、バグ修正も含めて、「このくらいあればできるだろう」というような日数を最大としています。その最小と最大の差分をバッファーと言っております。プログラマーの方はそういう実装なんですけれども、アーティストの場合は制作して1発目のチェックを受けるまでを最短、「修正をしてこれぐらいであれば、出荷できるまでのクオリティにできるだろう」というものを最大というふうにしています。その差分のバッファーを見ていくわけですけれども、バッファーは1タスクごとで算出していくわけですが、個別でひとつひとつのバッファーを管理するのではなく、イタレーションごとのバッファーの合算で管理をします。そうすることで、その合算されたバッファーがどのくらい減ってきたかという、その減り具合でリスケ(リスケジュール、予算変更)をしないといけないという予告のサインを見ることができます。そうするとリスケを事前に察知し、対策を打つということができますので、問題やイレギュラーが発生した時も落ち着いて安定した進行を行える、というものになります。つまり、リスクマネージメントをバッファー管理でやっているということです。

実際にどういう管理をやっているか、ということですが、青色の線が実際の作業日数です。オレンジ色の線がひとつひとつのバッファーになっていて、そのバッファーの合算が最後にあります。赤色の線は、始めはバッファーと同じ容量を持っているんですけれども、タスクがずれたり遅延してきたりすると、赤のラインがどんどんオレンジのラインと比べて減ってくる、という感じになります。この赤色のラインがどのくらい減ってきたかによって、プロジェクトあるいはそのチームにどのくらいスケジュールについての危機が迫ってきているかというところも判断できます。

この赤色の線がゼロになったところで対策を打っていると遅いので、大体半分とか3分の2くらいに目減りしたところで、次に何か対策を打たないといけないとか、スケジュールを延ばさないといけないのかとか、人員を追加するのか、あるいは実装要望を整理する必要があるのか、というような話を始める、というふうに運用をしています。この管理は、ひとつひとつのタスクをこうやって分解してまとめてバッファーを見るということなんですが、マスターまでのスケジュールすべてについてこれをやってしまうと、非常に大変かと思います。ですので本作の場合は、この管理はイタレーションごとで行なっています。イタレーションというのは、マイルストーンごとですね。イタレーションが終わるごとに実装要望みたいなものも再度洗い直して再評価したりするので、イタレーションの中でこの管理がしっかりとできていればいいかな、という感じで運用をやっています。

実際の描画プログラマーの線表では、タスクがざざざっと書いてありまして、MSプロジェクトがいくつか、分からない感じでいろいろ引いてあるんですけど、最終的には右上にあるバッファー管理線のところに集約をして、そこを見ることによって危機がどれくらい迫っているのかわかるようにしています。このMSプロジェクトの管理なんですけれども、先ほど見ていただいたタスクDBの方からCSVファイルへ吐き出してインポートするというところで、ある程度自動で更新されるようなものです。

そういった感じで3つのメソッドを主に採用してやっているという感じです。あと、メソッドではないんですけれども、もう1つ大きなポイントがあります。ロードマップの運用についてです。

今回、プロジェクトの計画を大まかなロードマップによって全体把握しております。ロードマップとは、月単位で誰が、どういった項目をやっているのか、というものがざっくりと書いてあるというものです。大規模開発において、目標に至るまでのプロセスを常に意識することはとても重要です。今回のロードマップの運用として、一般のものと違うところは、状況に応じて書き換えながら進めていく、というところにあります。大きなリスケや変更が発生した時に、安易に期間や人員の追加、削減をしないための枠組み、という考え方でロードマップを運用しております。この表は人ベースで書かれておりまして、どの人が、どの時期に、どういった仕事をどの期間でやるか、というところが月単位で書いてあるという感じですね。人員の移動時期などもここで確認ができるようにしております。プロジェクトで大きめの変更が入った場合、このロードマップで計画を改めて確認しながらタスクを進めていきます。ポイントとして、ここでもバッファーの管理を行なっております。ここに関しては、この全体のロードマップ上でもバッファーを持たせることによって、プロジェクトのリスクヘッジをするというものです。判断が必要な場合は、どの程度のハザードが発生しそうだ、というのをバッファーの減り具合を見つつ、トップへとエスカレーションもします。とは言え、ある程度バッファーを確保してプロジェクトの進行をしていますので、多少のずれがあっても逐一プロデューサーやディレクターに相談せずとも、マネージャーの手元である程度はプロジェクトの進行がスムーズに行えるというふうなものとなっています。

で、何か問題があったら大きなところで調整をしていくというのはもちろんなんですけれども、直近のスケジュールをひいてスタッフに見せていくとですね、先ほど言ったようにイタレーションごとに管理をしているので、そこだけを日々スタッフに見てもらうと、今の頑張りがここまで終われば終了なのか、それとも永遠に続くスケジュールなのか、というふうなところで不安になってくることがあります。

そういったところはスタッフに先々の予定を知ってもらうという意味でも、ロードマップを用意していることは非常に重要だと感じています。実際のところ、ロードマップを実際に何度も見つつ進めるというのはあまりないんですけれども、ロードマップがあって全体の行程が明らかになっていると、安心感みたいなものの役割を果たしてくれたりもします。ただ今回、プロジェクトをやっていく上での反省点として、セクションによってロードマップをスタッフに公開したところと、そうでないセクションがありまして、進行の違いには大きな差があったかな、というふうに感じています。ロードマップを公開しつつ日々タスクを進められたセクションに関しては、比較的問題もなく穏やかに進んだんですけれども、やはり目標とするところがどこか、ということが分かりにくいセクションに関しては、不満があがったり質問があがったりといった点で大きな差が出ました。ロードマップに関してスタッフになぜ公開しなかったかというと、結構、人員の異動についてのことが言及されていたりとかもするので、そういったところで見せなかったセクションもあったようです。そのへんは反省して、今後はロードマップに関してはすべからく全員に公開しつつ、意識を共有して進めていきたい、というふうに反省しています。

というところで、今回2種類のリスクヘッジのためのバッファー管理をやっています。ひとつはイタレーション毎のバッファー管理。これはスタッフの作業のリスクヘッジを行うためのバッファーの管理ですね。あとはロードマップ上でもバッファーを管理しています。これはプロジェクト全体のリスクヘッジをするためのもの、という位置づけで2種類のバッファー管理を使い分けています。ただしこのバッファーなんですけれども、余分にならないように見積もりと予測をしっかりとやることが重要です。スタッフ作業上のバッファーに関しては、見積もりの精度はある程度高いというところはあるんですけれども、プロジェクトのリスク管理をどの程度とっておくかというのは今回、ほぼ経験則から見積もりをやっております。例えば品質向上のための期間をバッファーとしてある程度確保しておき、その期間でバランスを取ったりというようなことをやりました。ただ、今回、バッファーが余ってしまい手が空いてしまうということはなかったんですけれども、意外とバッファーを取っておいたんだけれども足らなくなったね、ということはありましたので、プロジェクトのバッファーの管理についてより精度の高い見積もりをするための進歩というものをどうしていけばいいか、というのは、今後の課題だと捉えております。

というところで一旦メソッドについてはそんな感じでまとめをしていきたいと思います。優先度に沿ったタスク管理、マージンコントロール、バッファーコントロールでリスクヘッジ、あと毎日15分ミーティングで進捗管理というところです。スクラムで日々管理、CCPMでイタレーション管理をベースに狩野モデル思想というのも、優先度管理というものを行なっています。聞いて頂いて、勉強していただいている方は結構あれ？って思うところもあるかもしれないんですけれども、それぞれのメソッドをフル活用しているわけではございません。そのメソッドをフル活用する、盗み適用する、というものではなくて、それぞれ必要な部分を組み合わせた管理を行なっている、というところが今回のポイントです。日々のタスクやマイルストーン、イタレーションをこれらのメソッドのハイブリッドで管理して、それをやりつつも全体的な大まかな進行をロードマップで確認しながら進める、というのがコンセプトのマネージメントという構図になっています。それによりできることは、組織におけるゴールの共有、目の前のタスクの意味を理解して作業に取り組んでもらえる、あとは大規模なタスクでの品質管理、大規模開発における品質のばらつきを防ぐこと、などがあります。また、リスクマネージメント、計画を破綻させるハザードへの対策というふうに、これらのメソッドを工夫して組み合わせてやることによって、精度が高まるというふうに感じています。

というところで、メソッドの話に関しては以上です。ここからはその他のマネージメントワークへと話を進めていきたいと思います。まずはチーム運用についてのお話をしていきます。

イタレーションについて、何度も言いますけれども、マイルストーンという言い方とほぼ同義にとらえているんですけれども、これについて掘り下げをしていきます。今回は特に量産期に差し掛かってからなんですけれども、2ヶ月という期間で実装・評価を行なっているということになります。

特に評価のところでは、定期的に全員でのプレイ会を半日から1日かけて実施することにより、意見や感想、評価を集めて改善点を検討し、ディレクターがそれの精査されたものを次のイタレーションで実装、さらに新規実装されるものを含めて再検討し、優先度をつけて次のイタレーションの計画を行う、というようなサイクルで行なっています。つまり計画、実装、評価、そして計画というサイクルをこういった内容で2ヶ月単位で行なっているということです。

この規模のゲームの実装・評価は、2ヶ月が最適だったと感じています。これは始めから「2ヶ月でやりましょう」となっていた話ではなくて、プロジェクトで試行錯誤の末に最終的にこの期間に落ち着いたかな、という感じですね。この2ヶ月という期間のイタレーションを繰り返して品質を向上させ、マスターへと近づけていかせるわけです。一般のソフトウェア開発であると、大体1週間から4週間あたりが最適だと言われていますが、ゲーム開発においては特に「実装して評価」のプロセスを厚くする必要がある。なので、期間は一般的なソフトウェア開発よりもやや長めになってしまうんじゃないか、と思っています。とはいえ、このへんのイタレーションの長さについては、プロジェクトの規模や内容によっても全然違ってくると思いますので、そのプロジェクトの状況や内容を見つつ、ということですね。今後も新しいプロジェクトをやる時に2ヶ月かどうかというのはその時次第だというふうに思います。

そして先ほどお話ししました全体プレイ会についてですけれども、非常に効果が高いものだと考えております。結構、大人数で制作を進めておりますと、自分の作っているパートの仕事に追われて、なかなかそのゲームの全体を把握しながらものを作るということができなくなってきます。そういった意味でも全員での評価をやろうということは、メリットが大きいと感じております。メリットとしては全員で評価を行うことで自分の担当箇所以外の部分も把握できる、それから自分の仕事がどういうふうにゲームに反映するか、というのも改めて実感をすることができます。また、評価に対するジャッジを複数のディレクターが行いますので、プロジェクトとしての優先度や思想というものを全員で共有、把握することができます。また、スタッフ全員がゲームをやりこんでいるというところまでは、なかなかいきませんので、そういったタイミングを持たせてあげることにより、お客様の視点により近い意見をスタッフから得ることができる。なので、ゲームデザイナーとしても有効な意見をそのタイミングで吸い上げることができます。デメリットとしては、半日から1日、全員の時間を拘束するので、実はコスト換算すると、かなりコストをかけているとは思います。とは言え、そのコストを押してでも、こういった評価の段階で全員でプレイ会を行うということは非常におすすめしたい。それくらいの効果があるというふうに感じています。

そういったイタレーションを繰り返すことで、品質向上を行いつつ開発を行なってきています。しかしながら長期開発での落とし穴というものはあります。

長期開発の初期段階ではゴールが見えづらい。大規模開発になると制作するリソースも膨大で、その実装と評価のイタレーションは確実に精度を上げているんですけれども、初期段階での評価はゴール感が非常に見えづらいものとなってしまいます。また、評価におけるディレクションというものはとても重要で、長期スパンで判断がぶれるようだと、プロジェクト全体の迷走にもつながることとなります。実際のところ、今回のドラクエXを作るにあたって、結構な期間をかけているんですけれども、初期段階では全員が完成形のイメージをなかなか持てませんでした。本音を言って「正直完成しないんじゃないかな」と思った時期もありました。そういった時期を経てですね、最後の1年ないしは1年半と、リソースがそろってきて組み上がってきて、全容が見え始めてきたところで、一気に全員として盛り上がりを見せてきたかなという感じです。そういった初期段階で、目指さず・先をぶらさず、進めていくというのはとても難しいことであるとともに、そのあたりに間してはディレクターによる手腕がかなり問われてくるというふうに感じています。今回に関しては藤澤仁さんというディレクターなんですけれども、彼自身が持っていたイメージというものを、なかなか全員で共有できなかったんですけれども、イタレーションを踏んで開発を進めていくことによってイメージ自体を全員で徐々に共有していったかな、と思います。

ここでのまとめについてなんですけれども、大規模開発においても計画、実装、評価の流れはとても重要ということです。あとは全員でのプレイ会をおすすめするので、ぜひそれぞれのタイミングで実施していただけるといいかな、と思っています。

次ですが、タスクの管理についてのお話に移っていきます。先ほどイタレーションでのバッファー管理……具体的なところをやっていますよ、という話をしたんですけれども、今回は失敗しやすいスケジュールの話をいくつかしていきたいと思います。初期段階からいろいろ試してきているので、あまりおすすめしないスケジュールの引き方というのがあります。まず、やってはいけないダメな例1なんですけれども、タスク1つ1つに余裕を持たせて進めていきましょう、ということです。

さっきのバッファー管理と似たようなものなんですけど、1つ1つのタスクに余裕を持たせることで、「このぐらいあれば終わるだろうから頑張ってね」というふうになってしまいます。一見余裕を持っているので、仕事としてはこの期間を取っておけばスムーズに進むだろう、という風に見えたりもするんですけれども、こういう引き方をしてしまうとスタッフ自身の油断を引き起こしやすい。あと人にもよるんですけれども、前倒しでちゃんと終わらせて次に進んでくれる人と、そうでない人との差が激しくなってきます。たいてい人間は余裕を与えると油断をしてしまいますので、スケジュール的に余裕がなく、作業自体に余裕を持たせてしまって、前倒しで実は作業が終わっているんだけど、出荷をまだしていないとか、下手をするとそういうトラブルが起きてしまう。俗にいう学生症候群と呼ばれるものです。なので、この引き方は余裕を持っているようですが、実際のところはうまくいかないのでおすすめしません。

ダメな例2なんですけれども、「この期間をまとめてあげるから、がんばってこのタスクをこなしてね」というものです。

個人でマネージメントしながらがんばってね、という話なので、これでそもそもうまくいくんでしたらマネージャーの仕事なんていらない、商売あがったりなわけです。通常、まずもってうまくいくことはございません。下手すりゃいくつものタスクがもぐりまくった後に〆切を迎えてしまうということも十分あります。ただし、人によってはこのマネージメント、やってはいけないマネージメントも逆の効果を発揮することもあります。特に職人気質な人にはこういったやり方をした方が良かったりすることもあります。品質向上を与えた期間の中で裁量に任せる、ということにしている場合は、ひょっとしたらいいかもしれません。そういったスケジュールをしているところは常にヒアリングや状況確認というのが怠れないんですけれども、個人の裁量に任せることにより、持てる力を最大限に発揮してもらえる、という事例もございます。前倒しでタスクを終わらせて余った時間で品質向上に取り組みましょうと、次の文から段落を分ける。意味上のかたまりである程度分けると読みやすくなる。共通して言えることなんですけれども、これをやる場合は少数精鋭であること、そして職人気質の高いチームであるということを考慮してやっています。今回のプロジェクトに関してなんですけれども、例えばアートディレクターは、元々セルフマネージメントができるであろう人なんです。もちろん描き仕事では質も量も右に出る者はいないな、というほどの実力の持ち主でもあります。なので、このタスクをこの期間で終わらせてください、というようにザックリしておいて、その中で裁量で品質向上も任せてやっていただく、ということをやっています。あと、この作品で言うと、例えばエフェクトチームだったりとか、あとはモンスターのモーションチームというものは、人数を最小限にしぼって、生粋のスペシャリストを揃えてやる、ということをやっていて、そういった職人が集まっている少数のチームに対しては、「この期間内で品質向上も含めて、目指すところをがんばってやってください」、というようなスケジュールの引き方をしています。ただし、このへんの見極めというのは、とっても難しいです。基本的におすすめはしません。とは言え、今回ドラゴンクエストXで特に尖った品質をたたき出しているというところは、こういう運用があったからで、このことも見逃せない。個人的には非常に興味深い事例だと認識をしています。そういう見知った仲で、この人だったらこういう仕事をしてくれるだろう、とかそういう期待がある場合には、こういった管理に賭けてみるのもまあ一興なのではないかと思います。

あと、補足して言いますと、もちろん他のセクションについてもスペシャルな人員というのはそろってはいます。ただ人数が多いと、どうしても個人個人の仕事のぶれとか、スキル差というものが生じてきてしまいます。そうした場合はやはり画一的な管理で統制をとらざるをえないというのは、基本です。で、ここでのまとめなんですけれども、時には状況に応じて逆の発想で取り組む柔軟さも、必要なんじゃないかなと思っています。

先ほどから話をしていますように、薄々感づいておられる方もいるかもしれないんですけれども、デザイナー、まあアーティストというものは非常に尖った職人気質というか、プロフェッショナルな人種であります。そんな一筋縄ではいかない人たちを先導していくのは、実はプログラマ－の管理をするという以上に大変です。ここからはデザイナーの管理について少しお話しをしてきます。

セクションによって運用が違ってきますよ、というお話です。デザイナーの見積もりとバッファーについては、セクションによってかなり運用が違ってきます。

タスクを分解しやすいセクションと、そうでないセクションでは運用が異なります。例えばキャラクターに関しては、1キャラクターを大体数日で制作をします。作業内容はモデリング、UV、テクスチャなど。段階的に分解できると、比較的1日単位での管理というのはしやすいものとなっています。モーションに関しては、1モーション数時間から数日での制作というふうになりますので、細かく分解できて精度が高いスケジュールというものが可能なんですけれども、反面、細かすぎてともすれば管理コストが高くなってしまうという危険性があります。ですので、モーションの場合は細かすぎるところはある程度まとめての管理をするなどしています。また、1モーション数時間単位のタスクの管理のバッファーを2ヶ月合算で評価をする、というふうになりますと、その1タスクごとのバッファーについての評価がなかなかしづらいですので、モーションの場合は2ヶ月ごとのイタレーションの中でもさらにまとめて、2週間単位で実装、制作と評価を行うというようにしています。だいたい1日3モーションずつくらいのモーションだと2週間単位で区切った場合というのがちょうどいいかな、と感じでおりました。これが1週間単位とかになりますと、ちょっとスパンが短すぎて、Plan Do Seeにおいて逆に手間がかかってしまうかな、という印象がございます。2週間がタスクの結果を評価する意味でも、モーションにとっては良い期間だったのかな、という感じです。

カットシーンに関しては、要する日数は多いんですけれども作業分解がしやすいので、比較的管理がしやすい、というのがあります。ただし1人が1シーンを担当するというふうにやっておりまして、その制作は、数ヶ月1人でそのシーンを作るというふうになっています。ですので、スタッフ間での作業効率的な部分のブレが大きく、管理についてはやはり日々単位で細かく見てやっていかないといけないかな、と思います。3DBGに関しての管理なんですが、こちらは今回MMOということもありまして、かなり広大なマップを作っております。そのため、期間も長く、制作段階は大雑把に区切るんですけれども、日々管理でのタスク分解で運用をしていくというのは少々難しいです。キャラクターのようなものは数日単位のタスク管理がしやすいんですけれども、BGのようにスパンの長い仕事をどのように分解して調整していくかというのは、今回一生懸命やったんですけれども、なかなか最後までうまくいかなかったところもありました。そのあたりは今後の課題と捉えております。BGにおいては日々のタスク管理をするための別角度でのタスク分解の定義が必要なのではないかな、という感じです。

タスク分解の細分化なんですけれども、どこまで細分化するか、どういった運用をするか、というのはその時々の目標、タスクの量や内容、それをこなすリソース、管理する人員がどれくらいいるのかによっても違ってくると思います。そういった時々で違ってきますよ、というのは当たり前の話で、むしろそれくらい複合的な要素を加味して運用方法を決めていかなければ、「イタレーションを2ヶ月で区切るから2ヶ月ごとにやりましょう」とか、あまり画一的にやってしまうと、運用途中で挫折してしまったりとか、あとは管理しきれなくて最終的にはその管理自体が甘くなってしまう、といったところもありますので、そういったセクションによってのタスクの分解と運用については、ここでいろいろと調整してやっていかないといけないのかな、と感じています。

今後の課題としまして、1タスクが長いスパンというものの管理をどうするかというところなんですけれども、タスクの分解については今後の課題としてとらえていきつつも、今回はワークフローについて整理することで、ある程度このへんの仕事の進み具合というものをスムーズにいかせる等工夫をしております。

そのワークフローについてなんですが、スパンの長い仕事において気をつけていくところと言いますと、ムダな待ちが出ないようにしたりとか、あとは下流のセクションが影響を受けにくいようにする、というところがございます。こういった話は並行作業ができるようなフローを引いて、他セクションの作業を気にせずに、その作業に集中できるようなフローというものを意識しております。例としまして、BGのワークフロー、カットシーン周りのワークフローというものをちょっとご紹介をします。今回ざっくりとこのようなワークフローで進めていったんですけれども、それぞれBGのフェーズに合わせた形で進行させております。先ほど言いましたようにBGは制作スパンが長く、仕上がりを待っていると、いつ上がってくるんだ、という話になります。数ヶ月単位かかっての制作になりますので、上がってくるまで数ヶ月の間待っているというわけにはいきません。そのため、大きく4段階のフェーズに分けたフローでの制作を引いております。それが真ん中に書いてあります「ラフマップ」「テンプレートマップ」「コリジョンFIX」「FIX」というステータスになります。

まずラフマップなんですけれども、このマップは、マップの広さ、位置関係、見え方を確認するための非常に荒いマップとなります。一旦こういったポリゴンの状態で実際に実機で歩いてみて、プランニングや絵面の検証などを行います。そうして再考されたマップをお見せしたいと思います。こちらは既に公開されているオーガのグレン城というオプションなんですけれども、実際にプレイしていただいているお客様だとお分かりかもしれないんですが、始めは、これと、今の構造とかなり違っています。なんですけれども、ラフマップで構造を検証することにより、さっきよりちょっと荒いマップになっているんですが、構造的にはこの段階で既にリリースされているものとほぼ変わらないという状況になっています。ラフマップの段階でここまで進めることにより、後々の作業をスムーズに運ぶということをやっております。そしてラフマップをつめた段階で、次はテンプレートマップというステータスになるんですけれども、これは本番モデルに向けた基本構造と同様の配置がFIXしているというものとなります。ここではある程度の形状が確定しておりますので、例えば街になりますとNPCの配置ができるような状態になりますし、フィールドではモンスターを配置したりといったレベルデザインが可能な状態なのでテンプレートマップと呼んでいます。そうしたステータスを経て次にコリジョンFIX、これはまあPCの移動範囲の形状FIXをさせているというステータスで、あとFIXの段階では遠近モデルやテクスチャといってものが終了している、というのも進めていきます。

ここでのポイントなんですけれども、テンプレートマップというステータスが肝になっておりまして、これはここで形状やプランニングなどがほぼ固まっている状況で、この段階でBGから他のセクションへと受け渡せる、という状態が重要です。ここでレベルデザイナーやカットシーンのレイアウト制作に渡すことにより、このテンプレートマップ以降のステータスでは、それぞれのセクションがそれぞれの仕事に集中して進める、というような構造になっております。完成するとこんな感じですね。ラフを作ったあとの、FIXではこんなデザインになると。あとはキャラクターに関しても同様に並行作業でやっていきます。モデリング以降のフローにおいては、テクスチャやモーション、シーケンスの作業が並行して行えるようになっています。

要するにフローについてのポイントなんですけれども、プライオリティの高い決定は先にやって、早期に次へとバトンタッチできるようにしましょう、ということです。

できるだけ並行して作業に集中できるようにするような工夫が必要です。ただし、今回について手放しでこのフローがうまくいったか、というとそうではなくて、このフローを行うにあたって、フローが順調にちゃんと稼働しているかということを、担当が1人ついて「問題がないか」と確認し、あれば是正を行っているといったような、新しい役割を持つような調整が必要だというところの反省はございます。こういう工夫をすると、またそういったところのタスクも発生するので、コスト対効果として新しいフローをやったりとかする時には、そういったところも注意が必要かなと感じています。

というところで、ちょっと時間も少なくなってきたんですが、その他、行ってきた工夫などをささっと話していきたいと思います。スタッフのそれぞれの役割を持ってもらうという。これはチーム運用的なことの話なんですけれども、長い間チームに滞在しておりますと作業がマンネリ化したり、大きなプロジェクトだと、流れている作業をこなすだけになってしまいがちです。そういったことが続くと、スタッフ自身が思考をしなくなってきます。流れ作業をこなしているだけの人になってしまうんですね。そうすると結果、モチベーションが下がってきて効率も悪くなってしまいます。これは結構、大規模な開発だと起こりがちなことで、最終的にはやることをやって会社を去られたりしてしまったりとかもするので、そういったものをなるべく防ぐためにも、スタッフそれぞれに役割を持ってもらうという工夫が必要かと。

そうすることによって、どれだけ自分がチームに関わっているかを実感してもらうことができます。これは非常に大事なことで、まずはどんなパートでもいいので、担当というものをつけることが必要かな、と。担当を持つことにより、その人自身に責任感というものが生まれます。また担当をつけるということによって、他セクションとのやりとりというのが増えてきますので、自分の仕事がどうプロジェクトに生きてくるかを実感し、おのずと能動的に動いてくれるようになります。ただ言われたものを作るだけの人間は思考の停止に陥ってしまいます。物事を常に能動的にとらえて仕事に取り組んでもらうためには、役割と責任を持ってもらうというのが非常に重要だと感じています。そういった、ちょっとした意識改革でもチームの雰囲気や意識というのが変わってきます。今回は実験的に一部のセクションでそういった試みをやってきたんですけれども、効果としては非常に高く、チームの雰囲気としても良かったので、今後はプロジェクト全体として、それぞれ担当を持って責任を持ってやってもらっていきたいな、と考えております。

あとはスクラムについて少しお話をします。

スクラムの効果については改めてお話はしないんですけれども、始めるまでが結構大変だったなあ、という印象があります。開始時の説得が特に難しい。スクラムについては継続して効果が求められるものなので、そこをどう工夫していくかが難しいかな、と思っています。プログラマーだと「効果的ですよ」と客観的に説明をして分かってもらえると積極的に取り入れてくれたりとかもするんですけれども、アーティストの場合はですね、結構周りの仕事を見ないで自分の仕事に集中するという性質があるので、説得するか、ともすれば強引にトップダウンでやってもらうしかない、というようなところがあるかな、と。今回デザイナー全体でそういったスクラムについて導入できたかというと、なかなか最後まで導入できなかったセクションもございました。あるいは、導入できたものの、僕自身が全てのセクションのスクラムを見ることができるわけではないので、気づけばちょっと散漫になってしまったとか、マネージメントする側のスキルとかファシリテーションを行うスキルも必要だな、と。まあ、実力不足ですね。そういったところも実感しております。そういったところは僕がやっぱり組織としてちょっと取り組んでいかないといけないかな、というような実感です。ただ、導入したセクションについては、コミュニケーションが高まり、チームとしての意思疎通というものも取れやすくなってきました。意識疎通が薄いところほど問題も起きやすく、仕事の遅延も起きやすいです。俯瞰で見ていてやはりスクラムの効果は高いので、ぜひとも皆さんにやっていただけたら、と思うんですけれども。準備やそのためのリソース確保などを大規模制作の現場に浸透させるというのは、少々難しいところです。

時間も近いですね。あとは見積もりについてなんですけれども、若干飛ばさせていただきます。見積もりについて、作業担当者自身に出してもらうことが重要ですよ、という話がございます。

これはリーダーと共にタスクを確認しながら、見積もりと作業のバランスの差異を軽減して進めていくものです。そのため、後々分析を行う際も納得感があります。

あとは、こうやってマネージメントを進めていくにあたって、いろいろ考えたところもあるんですけれども、今回特にデザイナーあがりの僕がプログラマーの管理をしたというところについて、ちょっとだけお話をします。良かった点としては、デザイナーのことを僕が全て把握しておりますので、作業プライオリティを握れたということが非常に大きかったです。描画プログラマーのタスクを握ることにより、デザイナーの作業というものが非常に円滑に進むようになりました。反面、良くなかった点としては、僕自身がプログラマー出身ではございませんので、プログラマーのタスクの見積もりの判断力に欠ける、というところがあり、見積もりの際にはプログラマーのチーフに同席していただき、スタッフと話しながらタスクを決めるということをやっていました。そういう面で結局チーフの時間を取ってしまったりとかもするので、そこは一つ反省点かなというふうに感じています。

そうすると、マネージャーに求められるスキルとはなんぞや？という話になるんですけど。

品質を落とさず制作進行を行う判断能力、セクション間で発生した問題の解決、実際のワークフローの構築、そうした現場において進行をコントロールする必要があるので、そもそも現場の経験がないとマネージャーという職は少々難しいのではないか、と感じております。マネージメントというのはコスト、予算と密接に関係するものです。時にはパートリードをしている人間よりも高い判断能力が求められることもあるので、まずは現場の経験を踏み、そしてマネージメントの道へと進む、というのがマネージャーを目指す人間にとってはいいフローなのかな、と今回改めてひしひしと感じております。

というところで、ちょっと時間がオーバーしているんですけど、本日のまとめの話でございます。ソフトウェア開発は不確実であるということ。始めに決めたものがその通りに実装されて終了するということは、まずありえません。バグや予想外の問題も起きています。品質面でも実装していく上で変更を加えつつ理想のクオリティーへと達成させていくものであります。そういった不確実性はプロジェクトが進むに比例して少なくなっていくんですけれども、それを理解してプロジェクト運用をするということが非常に大事になってきます。つまり、スケジュール管理はある意味、組み替えることが前提の運用であるべきなんです。いずれにしても何かしら起こるもの、特に大規模な時は長い開発スパンの中で予期しないことやイレギュラーな事案が発生することが多く、組み替えがしやすい管理というものが望ましいです。この中で、リスケジュールをする、という話になると、当初の予定からずれてしまうというネガティブなイメージがあるんですけれども、スケジュールは組み替えて変更を行う前提で進めていくという認識が重要です。イレギュラーな事態が起こった時に正しく対処してプロジェクト進行への影響を最小限にするためのリスクヘッジを行うために、スケジュール管理というものはあると考えています。

ゆえに、プロジェクトマネージメントはリスクマネージメントなんです。プロジェクトに合ったやり方を組み立てていくことが重要と言えます。そういったリスクヘッジをするためのメソッドなので、どんどんプロジェクトに合ったものを導入していきましょう、というところなんですけれども、しかしながら、メソッドを重視するあまり本来の目的である軽量的な開発、いわゆる柔軟な開発や、あるいはそれが現場の負担になってしまうことでは本末転倒でございます。メソッドを適用することが目的ではなく、限られた予算、期間の枠組みの中でいかにプロジェクトを合理的に進めるかが目的のはずです。メソッドやチーム運営、ワークフローの工夫はプロジェクトに合ったやり方で組み立てていくことが重要だと思っています。メソッドを完璧にこなせなくとも、運用がよければそれでいいんじゃないか、というような考え方で僕は取り組んでいます。運用自体をうまく生かせるためにメソッドを組み替えたり、というような工夫が必要になってくるんですけれども、そういった応用がいかにきくか、というところがマネージメント業です。

いかに合理的な開発を行うか、マネージメントはこの一点に尽きると思います。なぜ合理的な開発を行う必要があるのかと言うと、期間やコストを守るというのも重要なゴールではあるんですけれども、あくまでそれは表面的な目的で、効率をはかって、例えばパワーをクオリティーに当てていくことにより、ブランド力を向上させたり、あとは時間を確保してあげることによりスタッフが心の平安を持ち、結果モチベーションを持って仕事をしてもらう、そういったところが重要なんじゃないかと思っています。大規模になるほど合理的開発の難度というものは上がってきます。そのための施策も状況により千差万別でございます。仕事の流れを円滑にし、組織の能力を最大限に発揮させるための工夫というものを、今後も続けていきたい、というふうに考えています。今後のドラクエXの開発は新規タイトルの開発ではなく、運用の上でお客様に提供させていただくサービスの開発というふうにシフトしていきます。なので、特にそういった観点からの取り組みや工夫を今後も続けていきたいですね。

というところで、今日、僕の言いたかったところは大体言いました。最後にひとつだけ付け加えると、マネージメントを行うということは、人ありきのものでございます。こうしてドラクエXが無事にリリースできたというのはプロフェッショナルなアシストや天才プログラマーたち、そしてゲームデザイナーのセンスがあればこそ、こうして達成できたんだな、と感じています。こうしてプロジェクトに携わり一丸となって協力してくれた、開発のスタッフの皆様に最大の敬意と尊敬をもって今日の講演のシメとさせていただきたいと思います。講演については以上になります。ご静聴ありがとうございました。