増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論

 2018年3月30日,大阪府・グランキューブ大阪で「Game Creators Conference '18」(GCC'18)が開催された。
 GCC'18は関西発のゲーム業界向けゲーム開発カンファレンスだ。関西地区のゲーム企業有志による「勉強会」を母体としたイベントだったが,いまや4トラック24セッションという規模という一大イベントに成長している。地元である関西企業によるセッションのほかに,東京などからこのイベントのために多くの企業が参加している。
 ここではそんなうちの一つであるフロムソフトウェアによる講演の模様を紹介してみたい。「複数タイトルの開発を維持しつつ大規模化に適応した中小企業エンジニアの取り組み」というタイトルの講演だが,「複数タイトルの開発を維持」「大規模化」といったあたりはちょっと見ただけでは意味が分からないかもしれない。

 さて,フロムソフトウェアといえば,初代PlayStationとともにゲーム業界に参入した企業だが,ある程度大きくなってからは会社の規模はそのままに開発を続けてきたらしい。フロムソフトウェアの伊藤 淳氏によると,ここ15年くらいはほとんど体制は変わっていないとのこと。
 同社の社員数は280名程度でほとんどが開発者だ。エンジニアは70人程度とされているので,アーティストなどが非常に多いことも分かる。何チームかに分かれて複数のタイトルを並行開発し,毎年何本かのソフトを発売できるようにしつつ,研究開発のR&Dチームも備える……といった感じだ。今回は話に出てこないが,グラフィックス専門のエンジニアチームもあるとのこと。ちなみに,伊藤氏はR&Dチームの長である。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 なお,フロムソフトウェアでは,直接特定のタイトルの開発に従事するチームを「ライン」と呼び,直接タイトルには関わらないR&Dチームと分けている。以下,ラインとR&D双方での社内体制の変化などが語られるので,基本用語としてここでは押さえておきたい。

 同じ規模の会社で同じ規模のチームが同じように開発を続けてきたこと自体に,どんな意味があるのだろうか? ここで考えなければならない要素に,ゲーム機の世代と開発規模の拡大がある。
 伊藤氏は,PS2,PS3,PS4と3つの世代を挙げ(PSシリーズのみの話ではないが,世代の目安として挙げられている),主な画面サイズやゲームの大きさ,開発期間などを比較していった。

画面解像度 メモリ容量 メディア容量 開発期間
PS2世代 480i 32〜64MB 4.7GB 1年
PS3世代 720p 256MB 30〜50GB 2年
PS4世代 1080p 8GB 50〜100GB 3年(DLC+1年)

 作る手間は増えているのが分かるだろう。そもそも1タイトルごとの開発期間が伸びていて,人員はほぼ変わらないのに,どうしてタイトル発売本数が維持できるのだろうか? そのあたりについてのフロムソフトウェアによる開発体制の変化が語られたわけだ。


PS2世代


増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 まずはPS2世代でのゲーム開発だ。この世代のゲーム機としては,PS2,Xbox,GameCubeがある。それぞれCPUはMIPS系,x86系,PowerPC系,GPUはSCE独自のGraphics Synthesizer,GeForce系,ArtX系とバラバラだった。見て分かるように,ゲーム機のアーキテクチャはそれぞれ完全に独自のものであり,性能もまちまちだ。ゆえに,それぞれのゲーム機ごとに最適化したゲームを作るというのがこの時代の最適解であったという。多機種に移植する際は,ほぼ作り直しになる。
 それぞれのゲーム機で開発ラインはそれぞれ独自に開発環境を持っていた。プラットフォームに特化したゲームを作るので,それが当たり前だったのだ。また,開発期間が短いこともあって,システマチックな手法より,プログラマが直接ゲームを実装していくほうが効率的だったとのこと。
 まとめると,PS2時代はタイトルやプラットフォームでバラバラの開発体制が取られていた。ライン間で連携するようなこともなく,それぞれが独自にゲーム開発をしている状態だ。伊藤氏は,「シングルプラットフォーム」の時代だったと述べていた。これは「非マルチプラットフォーム」の意なのだろうが,単体ではちょっと分かりにくいかもしれない。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論


PS3世代


増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 PS3世代というと,PS3,Xbox 360,Wiiなどのゲーム機が該当する。CPUはどれもPowerPC系となり,GPUはPS3がGeForce系,Xbox 360はRadeon系,WiiはArtX系を採用していた。クセの強いCellプロセッサやアーキテクチャの違いはあっても,PS3とXbox 360は性能的に比較的近しいものとなっており,マルチプラットフォームタイトルが出ていたことを記憶している人も多いだろう。
 そう,マルチプラットフォームという考え方が出てきたのが,この世代の最大の特徴である。開発体制も少し変わり,マルチプラットフォーム化は,あるプラットフォームで作ったゲームを別のプラットフォームに移植するという流れになったという。マルチタイトルは同時リリースではなく,時間を置いてのリリースとなる。

 またゲームデータも大容量化してきたのがこの時代だ。ゲーム制作コストが跳ね上がったり開発期間が長期化して騒がれていたのを覚えている人もいるだろう。データを用意する代わりにプログラムで作り込んでいくといったPS2世代でのやり方が破綻に向かい,このままではヤバいという認識に至ったという。

 そこで出てきたのが,R&Dチームの主導による開発環境の整備だった。マルチプラットフォームに対応したライブラリをR&Dチームが作り上げ,共通のツールを使ってゲーム開発をしようという試みだ。
 各メーカー製のライブラリは,それぞれをラップするような共通ライブラリが作られ,統一的な環境での開発体制作りが目指されたようだが,必ずしもうまくはいかなかったようだ。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論

 この方策は,ライン側が協力的で,これまでの作業と大きく流れが変わらないような場合は非常にうまくいったようだが,ライン側に負担をかける場合にはあまりうまくいかなかったという。
 たとえば,これまで動いていたプラットフォーム独自の仕組みをわざわざ既存のミドルウェアに置き換えるなどの作業は,そのラインにとってはまったく非効率なものであり,同じような開発環境を整えるだけでも労力がかかる。
 非協力的なラインではそういった作業をしてくれないので,R&Dチームが肩代わりして開発することになり,結果としてR&Dチームの負荷が非常に増えることになる。

 それでもまだエンジニアの場合は理解が得られたほうだったらしい。プログラム以外のデータ作成やワークフローに関わる部分でもツールなどの統一化が図られたわけだが,こちらはさらに難航したという。バージョン管理システムなどはトップダウンで導入したそうだが,プログラム関係者はその有用性をよく理解していても,それ以外の部門ではあまり理解が得られなかったようだ。結果として,統一ツールの採用状況はラインごとにバラバラなものとなった。

 そこで「とにかく共通ツールを使わせる」という意思のもとに,とにかく機能的に不足がないように最小公倍数的なツールが作られることになった。各ラインにはそれぞれのやり方があるので,R&Dが考えたツールを押し付けてもうまくいかない。それぞれで使う機能というものをすべて網羅しておき,各ラインで必要なところだけ使うような体制を取り,とにかくすべてのラインで使うツールを統一することには成功したようだ。力技である。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論

 自社製のツールと他社製のミドルウェアを使うことで開発環境の統一を図ったわけだが,R&Dチームは外部ベンダーとの問い合わせ窓口としての機能を持つようになったという。ツールのメンテナンスなども合わせ,R&Dチームは本来の仕事ができなくなるという事態になってしまった。研究開発ができないということは,長期的に見ると大きなマイナスになるだろう。
 一方で,PS2世代から増加している作業量に対しては徹底的な効率化がラインごとに行われ,自動化できる部分は片っ端から手をつけていったという。PS3世代はこうして乗り切っている。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論


PS4世代


増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 そしてPS4世代だ。PS4,Xbox One,Wii Uなどが相当する。PS4もXbox OneもPCに似たアーキテクチャを取り,どちらもAMDのSoCを使ったことにより,x86系+Radeon系(GCN)と,これまでにないくらいに近いハードウェアになっていたと言えるだろう。PowerPC系とRadeon系(非GCN)のWii Uは……まあともかくとして。
 一方で,画面解像度は1080pが当たり前となり,求められる品質は格段に上がってきていた。フロムソフトウェアでもそれに対応すべく対応を進めるのだが,ライン内での効率化は前世代でほぼやり尽くされていたため,業務効率を大きく上げることは簡単ではない。
 そこでどうしたのかというと,開発環境のさらなる統一・共通化だ。PS3世代にも行われていた開発環境の統一は,一つのやり方に集約するというより,既存の開発環境をすべて束ねる感じの統一だったので,それぞれで皆やり方は違っている。同じツールを使っているのに,こちらのラインでのやり方というのは別のラインでは通用しない。ツールだけ同じでワークフローは統一されていなかったのだ。
 開発環境を整備しようとするとラインの数だけ担当者が必要になる。これを共通化すれば,サポートの手間も大幅に縮小できる。人員を入れ替えても新しいラインに馴染むまでの期間が省略でき,効率が大きく上がる。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論

 ということで,真の開発環境統一が行われたわけだが,前世代と比べるとかなりすんなりと進んだようだ。その理由には,PS2世代からPS3世代への移行より環境の変化が少なかったことと,すでにかなりの部分で統一が進んでいたことが挙げられている。
 具体的な進め方としては,PS4での新規開発で,これまでの2ラインを合体した新しいラインでの大規模開発が進められた。開発規模の拡大した新世代機へ投入する人員コストとしては妥当なものだろう。さらにほかのラインからもメンバーを引き抜き,各ラインのノウハウを集めた一大開発ラインが構成されることになった。結果として,この合同チームでの成果が持ち帰られて全社で統一環境を作る下地となったようだ。
 とはいえ,放置しておくとまた各ラインで独自進化してしまうので,ライン間の情報共有が密に取られることになった。どうしてそういう実装にするのかについての基本的な考え方が共有されるようになり,Twitterのようなつぶやきを共有するツールで,リアルタイムの進捗が共有されるようになった。変なことをしているとツッコミが入るので,結果としてラインを超えた開発体制が構築されたようだ。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論

 また,どこかのラインで共通ツールに拡張が必要になった場合,そのラインで機能実装を行うようにしたのだという。自分たちに必要な機能なのだから,自分たちで作るのが一番いいというのもあるだろうが,自分たちで共通ツールに取り組むことで自分たちのツールだという意識を持たせるためだろう。以前トップダウンで導入したバージョン管理ツールでの反省を踏まえたものと思われる。
 そして,新機能がそのラインでうまくいったら,全体に共有されるという形だ。もしかしたらR&Dチームで作ったほうがデキがよくなるのかもしれないが,とにかくこのような流れで共通化することが優先されたという。機能自体のリファクタリングはあとでできるという考え方だ。

 また,マルチプラットフォームを進めるうえで,できるだけ多機種の開発ラインを巻き込んでコミュニケーションを図ったという。
 その際に「こういう機能がほしい」ではなく「こういうことで困っている」といった,問題点そのものを挙げるようにして,多くのアイデアを集めるようにしているそうだ。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論 増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論


そして次世代へ


増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 そうこうして,ついに社内全体の開発環境が統一されるに至ったわけだが,新しいツールを使うようにするという意識が強すぎて誤解を招いていた部分もあるという。そのツールの範囲内だけで仕事をして,新しいことはやっちゃいけないと思われがちだったり,社内全体で使うツールなので,新しいことを気軽に試せないといったものだ。前述のように各ラインで試してうまくいったら全体で取り入れるような流れを作り,新しい開発体制への誤解を解いていったようだ。開発環境への不満は絶対に放置してはいけないとのことだ。
 また,共通化にはどういった意味があるのかの啓蒙も重要だという。アイデアを独り占めにせず共有すること,現状維持ではなくみんなで変化を受け入れて改善していくこと。こういったことを意識させることが社内体制として重要になる。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 ただ,ラインを超えた社内の情報共有を図るということ自体が問題を起こすこともあるらしい。たとえば契約上の問題で,ほかのチームとはゲームの情報を共有できなかったり,プラットフォームごとに縛りが違ったりと,面倒なことも多いようだ。そのあたりでは法務担当者の役割と連携の重要性が強調されていた。

 そして次世代では,現在よりもさらに多くのものが要求され,ゲームの規模も大きくなることはほぼ確実と見られているようだ。モバイルなどへの転換というのもアリかもしれないが,コンシューマのメインストリームで見ればおそらくそうなるだろう。現在よりも作業量が増えると,さらなる効率化が必要となっている。とくにアセットの需要はさらに大きくなるだろう。

増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
 まだ気が早い話ではあるが,すでに対策は練られつつある。アセットの自動生成は当然検討されるべきものであり,そういったあたりで「攻め」のプロシージャルやデータ作成の根本的な部分での改善で生産性を上げられないかとフロムソフトウェアでは考えているという。
 次第により多くの労力を要求する最新世代ゲームへの対応を,限られた人員で変わらずにこなしていくため,同社は業務体制を時代に合わせて進化させ続けてきた。それほど規模の大きな会社ではないにも関わらず,各時代でトップクラスの話題をさらう作品を作り続けている。次世代がいつくるのかは知らないが,さらなる効率化でそれも乗り越えるのであろう。新世代への対応がどういったものになるのか楽しみだ。

GCC 2018関連記事