会場：Moscone Center

　日本でも高い知名度を持つ英ゲーム開発会社「Rare」。知らない人のために念のため説明しておくと、スーパーファミコンからニンテンドウ64へプラットフォームが移行する時期、任天堂と協力し同社ブランドで多数のゲームをリリース。「ドンキーコング64」、「バンジョーとカズーイの大冒険」などの3Dアクション、「ゴールデンアイ 007」、「パーフェクトダーク」といった一人称視点のアクションシューティングなど多数のヒット作品を排出。2002年にMicrosoftに買収された後、Microsoft Game Studiosの一部となる。

　国内外で絶大なブランド力を持ち、多くのファンを有していたRare。ここでご紹介するプログラムセッション「Shared Technology at Rare（Rareにおける共有技術：利点と欠点）」では、共有技術部門に在籍し7年以上のキャリアを誇るRare/Microsoft Game StudiosのSenior Software Engineer「Tom Grove」氏が、共有技術グループ開発にあたりRareで体験した失敗例を中心にスピーチを行なった。テクニカルライターではない筆者が（同時通訳ありとはいえ）専門用語が飛び交う同セッションの内容をお伝えするのは場違い感が濃厚だが、それでも「Rareが直面し、現在も改善を続けている共有技術開発の問題点について、端的にでもお伝えできればと同セッションを訪れてみた。

Tom Grove氏

■ 技術共有グループ：開発リソースの集約、効率的な運用など、さまざまな利点を期待

　壇上でTom Grove氏は、まず最初にRareの歴史と特徴を解説。創造性を主導とする会社で、アーティスト、デザイナーがタイトルをひっぱっていく企業風土を持つという。複数タイトルを開発しており、ラインは常時2～4タイトル。それらは主にXbox 360タイトルだが、それとは別に、デザイナーとアーティストを含めたプロトタイプを作るチーム、ニンテンドーDS向けのモバイルチーム、サポートチームなどが存在。

　テーマに登場する「共有技術グループ」は、社内のアウトソーシング的な役割を持つグループ。ニンテンドー64やプレイステーションなど3Dタイトルが主流になりつつあった'99年設立。当初は約5～6名の未経験開発者とリーダーひとりで構成されていたが、現在は開発者20名、リーダーふたり、プロデューサーがひとりいるという。グループの生産物は2000年以降すべてのタイトルで使われており、初適用タイトルは「スターフォックス」だという。

　共有技術グループの設立は、開発リソースがニンテンドー64で活用されていないと考えられたのが始まりだという。当時、各チームはタイトルごとにエンジンを開発。すべてのタイトルは効果的に作られており、よく売れてもいたのだが、今後のこと……次世代機（ゲームキューブ）に以降する際に開発コストが上昇することを予測するなら、現時点では致命的ではない無駄が、次世代機で深刻な問題になる可能性が考慮されたという。

　将来的な問題以外にも、優れた慣行を社内に伝達するのに効果的と判断されたこともあるという。優れた技術が1カ所に集約され、ブラッシュアップされ、全体で用いられるための情報源。同じ社内なら知財はまとまっていたほうがいいという考え。次世代機で必要とされるコンテンツ、プレーヤーの期待などを研究するグループも必要であり、物理エンジン、シェーダーなどの開発コストを徹底的に調べてリソースを共有するのがいいだろうという判断。さらにはクリエイティヴ志向の会社として、アートやデザインチームに力を与えたい目的あったようだ。

　当初の計画によれば、共有技術グループでは「インタビューチーム」を設けようと思ったという。全チームに書面で「どうやってゲームを作るのか」アンケートをとり、そのうえで共有エンジン「R-1」制作を計画。だが、これは外部市場向けてゲームを作るのとは対照的に“内部市場”とでもいうべき“ゲームエンジン作りが趣味”のようになってしまい、そこから新しい作り方をする必要がないと思うようになったという。Tom Grove氏は「とてもナイーブなゲーム開発モデルを作り上げてしまった」と述べている。

　設立当初から、技術共有グループでは問題が頻出する。アンケートに書かれた「アート主導が問題」、「一括でわかりやすいパイプラインが欲しい」、「MAYAツールなど、プレビュー環境でワンクリックエクスポートできるものが欲しい」など数多の問題意識。クリエイティヴ主導によるアーティストのサポートから、共有技術グループを通さないツールの直接導入、ジョイント問題、アセットの欠落。

　ランタイム（アプリケーション実行に必要とされる部品）に高い期待と焦点を置くあまり、ミドルウェアを軽視していたことも問題点のひとつ。'99年～2000年にかけて、いくつか存在していたミドルウェア。技術共有グループでは「そんなものは重要ではない。自分たちでもっといいものが作れる」と考えていたという。ニンテンドー64の頃は5,000ポリゴン程度で背景が作れたため、極めて短時間でエクスポートが可能。これで、次世代ごとにどれくらいコンテンツが増えるかを過小評価してしまったという。これが、ゲームキューブでは5万ポリゴンに、ランタイムでは50万、100万……法線にもなれば700万ポリゴンに到達。ランタイムに時間を費やし、パイプライン、コンポーネントに時間をかけなかったことが災いし、制作サポートが難航する。

　このほかにも、大きな問題点として「私たちは良い開発モデルを持っていなかった」とTom Grove氏はいう。共有技術を作るやりかたを、ゲームと同じアプローチで実施。当初「こういったエンジンが必要」と推測で作るも、問題を指摘してもらうことが開発チームに依存する結果となる。こういったケースでのバグ報告は、声が大きい人、偉い人の意見が優先されがち。その裏で、実は多くの人がひそかに不満を抱いているかもしれないし、さらには「そもそも何も変わらないんじゃないか」など、技術共有グループに対して悪感情さえもたれかねない。しかも、ブラッシュアップ、最適化といった一番クレームが出にくいところは、後回しにされてしまいかねない。すべてが対処慮法になりがちで、共有技術を開発するうえで良いやり方ではなかったという。

　また、共有技術を作るのに、小数の未経験エンジニア、人材を集めたこともいけなかった。未経験ゆえに生成コードの品質も悪く、そもそもゲームが作りたくて入ってきた人たちだから、開発するために「自分が一番面白い」と思うような機能しか作らなくなってしまいかねないし、実際「バンプマップ、法線マップ、レイヤーテクスチャなんてかまわない。既存のパイプラインでもっともっとパワーを追加したい。そう、私たちは、面白いものを作りたがっていた」とTom Grove氏は独白する。

■ 改善に向けてのさまざまな努力と“7年間”という道のり

　その後、共有技術グループでは、さまざまな改善策が行なわれていったという。スクラムにも似たAgile開発システム、長期的な計画と反応的な開発バランス、プロセスの可視化と透明化。4週間単位で作業し、スプリントが終わったらプレビューを実施。

　社内部署としては最後発になるが、プロデューサーを設置したのも大きな改善のひとつ。Tom Grove氏は当初「内部技術を作る共有技術グループに“プロデューサー”なんて変じゃないか?」と思ったというが、実際にはグループおよびチームの規模が一定レベル、20人を超えてくると、やはりチームの生産物に責任を持つ人物、外部利用者の観点からも“窓口”が必要になってくるというわけだ。この共有技術グループ・プロデューサーを、Microsoftでは“PN”と呼んでいるという。部下を管理し、技術的な作業がきちんと実践されているかを管理。もしプロデューサーがいなければ、現場にいる人たちが総務的な仕事を兼務しなければならなくなる。

　また、同僚にコードをレビューしてもらう（ピア・コード・レビュー）、共有グループ内の全エンジニアにコードをみせ、一元管理される前にみんなでチェックする仕組みも導入された。ソースコントロールのなかに追加されるものは、最低でもひとりが確認する。

　共有エンジンを作るという当初の計画も、コンポーネントベースのプロセス開発に変更。重要なのは、レンダラー開発、技術の実装など、実際に開発を行なうこと。「プログラムはプログラム。社員にやる気があれば、技術を作るのはそれほど難しくない。ちゃんとしたものを、ちゃんとした期間内に作るほうがもっと難しい」とTom Grove氏はいう。

　コンポーネントベースであるということは、エンジンを作るということではない。共有テクノロジグループを作ったときには、このグループがなにをしなければならないか考えたとき、そのときはエンジンを作るべきだというのが一般的だったという。しかし、これはそもそもおかしなこと。社内にはすでに5つのゲームエンジンがあり、開発グループはそのエンジンの出来に満足しており、技術的にも問題はなかった、クライアントチームはみな円滑に動作するゲームエンジンを持ち、効果的に開発していた。

　しかし、問題はこういった“仕組みそのものが無駄である”ということで、すでに性能が証明されたエンジンから新しいエンジンにいこうすることは、クライアントとの関係を損なうことにもつながる。問題がないのに新エンジンに移行するのは「強制的に新しいものをやれ、というふうに言われていると感じてしまう」といい、実際、そういった行為はクライアントが感じている問題を解決するものではなかったという。

　技術共有がプロセス志向になることによって、ミドルウェアを導入する可能性も出てくる。ひとつの巨大なエンジンに、ミドルウェアをタイトルに入れたり、会社全体で導入するのは難しいが、色々なコンポーネントがあれば、ミドルウェアがでてきたときに、そのコンポーネントのかわりに“ミドルウェアを組み込むことができるという「形式を持つことが重要」”だとTom Grove氏は説く。

　開発サポートについても“顧客にサービスを提供するのと同じ”というふうに考えるようになったという。以前は四半期ごとにバージョンアップを行ない、違う仕事サイクルを持つ開発グループとの間で問題が発生するなど、度重なるバージョンアップが重荷になっていた。仕事を共有するチームのなかで、小さなAPIが違ったことで、ある地点からほかの場所に動くのに何千もの動作が関わることがある。チーム間の距離が広がってしまうと、すいった小さなAPIの変更が大問題になることがある。そういった変更があったとき、チーム内の認識が遅れると、ビルトが悪化する可能性もでてくる。そのためにも常に責任の所在が明らかで、最新バージョンを使うための自動化といったソースコントロールツールが重要で、これにより実際の開発も改善されていったという。

　ケースオフィサー（情報収集を行なう人）も、改善に重要な役割を果たしている。ケースオフィサーはゲーム開発チーム、共有技術グループとともに仕事をすることで、双方の関係が円滑化していく。可視化により、責任の所在もより明確になっていく。同じ社内に複数のチームが存在する場合、チームごとに“文化”があるもの。お互い長年つきあっているから旧知の間柄である一方、互いのチーム間にライバル意識が発生する。そこに他チームが挿入されるとき、製品主導型をとってしまうと、ライバル文化のなかではうまくいかない。実際、以前のRareでは各チームにゲームエンジンがあったこともあり、協業が“競争”という意識になっていたという。

　物事の窓口としても、ケースオフィサーは欠かせない存在。ゲームチームの技術担当が常にケースオフィサーのところにいき「これはいつできるのか」、「なぜできていないのか」といった確認ができるようになる。ケースオフィサーが必ずしもその問題を解決できるとは限らないが、少なくとも共有技術グループに対して問題の解決がどうなっているかを確認できるのは大きい。

　アナクロではあるが、直接的な人間関係の構築も重要。共有技術グループは、各チームの長に「なにかリクエストはあるか?」と質問を投げかけ、それ以外にも毎月のスプリント会議も行なう。技術担当、管理職と定期的に顔を合わせ、どういう方向に進んでいくべきなのか確認をする。クッキーを食べながら、毎月インフォーマルな担当者とのミーティングも実施されている。そこでは、シリアスな問題だけではなく、ゲームの話、遊びの話、採用問題などが話題になることもある。非公式な環境で問題定義をするような場を設けることで、その問題を長期間寝かせて深刻化するといった事態を避ける狙いがあるという。

　また、ゲーム開発会社に入ったのに、高い技術を持っているがゆえに共有技術に回されるという不満を解消するため、新入社員は常に共有技術チームからスタートするようになった。ゲーム開発から入るわけではないが、これで共有するコードベースを持つことができる。これは、日本企業で実施されている“新人研修”のイメージに近いかもしれない。

　豊富な技術者から未経験者への技術伝達、グループ内での人材育成。当初は共有技術グループの人間があまりにも経験不足だったという問題があったが現時点ではもっと良い比率でよい優れた開発者がいる。共有技術グループのなかで経験豊富な人が増えている。色々な意識のすりあわせをする仕組みもあり、品質管理の向上に寄与しているという。

■ 3つの重要な教訓

　Tom Grove氏は、講義のまとめとして“3つの重要な教訓”を提示した。

　ひとつは「クライアントとの関係を保持」するということ。言葉にするのは簡単だが、クライアントとの関係、技術に長けた人と疎い人で1対1の会議をするため、電子メールだけで済ませるのではなく、直接ミーティングを持つといったことも重要。ふたつめは「ケースオフィサー」の存在。共有技術グループにいる多くのエンジニアが、ケースオフィサーとコンタクトを取る。3つ目は「リアクティブ（動的）モデル」。ゲーム開発へのリクエストが変わることもあるため、必要に応じて効率よく提供していくことが重要。うまくバランスをとり、長期的な作業、タスクのほうもきちっとやっていかなければならない。

　セッションはTom Grove氏の「総合的には、とても厳しいプロセスでした。ただ話を聞くだけでは、いかにこれが大変だったかわからないと思います。しかし、これはここまでくるのに本当に長い道のりでした。効果的な共有技術チームができあがり、強いチームと連携を結ぶというところにくるまで、本当に長い道のりをたどってきた、ただ、もう一度やるかといわれたら、やりたいとは思わない（笑）」という言葉で幕を閉じた。すべての問題が解決して円滑に進んでいるわけではなく、改善の努力は常に続けていかなければならない。ジョーク風のコメントを残したTom Grove氏だが、中身は“共有技術”の重要性が（それこそ血の出るような思いが）にじみ出た、とても濃いものだったといえる。

□Game Developers Conference(英語)のホームページ
http://www.gdconf.com/
□Game Developers Conference(日本語)のホームページ
http://japan.gdconf.com/
□Rareのホームページ
http://www.rareware.com/
□関連情報
【3月8日】Game Developers Conference 2007 記事リンク集
http://watch.impress.co.jp/docs/20070308/gdclink.htm

(2006年3月11日)

[Reported by 豊臣和孝]