ITエンジニアとしてゲーム業界からプロダクト開発のヒントを得る（CEDEC2024）
はじめに
本記事は、ITエンジニアとしてソフトウェア開発スキルを発展させるため、異なる領域から開発という活動を分析した際の発見をまとめたものである。参加レポートのようにセッションの内容を解説するものではなく、あくまで発見を列挙した上でさらに思考を巡らせたものである（そのため怪文書または乱雑で夢想的な内容で構成されている）。この切り口から見た情報が、ソフトウェア業界に対して新たな発展や知見をもたらすことができればと思う。
なぜゲーム業界か
ITエンジニアとしての経験（研究・アカデミック・開発）を積んで１０年程になるが、ここ最近は自分の考えやスキルが狭い領域に収まっていると実感していた。技術領域としてはフルスタックで分野を問わず全般に触れ、チームビルドやプロダクト価値などプロセスやビジネル面から見て、どうすればもっと良い開発ができるのか考えてきた。その際参考にしているものの多くはソフトウェアを主としたコミュニティや書籍や記事、論文である。
同じものを見るとしても、別の立場や視点で見ることでより深い理解できるはずであり、その点において自分の経験は多様性や発展性の側面から停滞や局所化に陥っているのではないかと感じていた。
専門性の高さ（俗にいう一万時間）は重要であるが、研究においても新規性は異なる分野の知見の応用から発生することが多い。つまり、ITエンジニアとしてのより独創的で効果的なスキル発展のためには、ソフトウェア業界以外の知見や文化の応用が有効ではないかという仮説から、ゲーム開発という領域のカンファレンスからヒントを得ようと試みるに至った。加えて、プロダクト価値の最大化においては、状況は煩雑形ではなく複雑系やカオスの領域（Cynefin framework）に置かれることがほとんどであるため、知識の幅こそ解決の糸口になるのではないかという期待からである（RANGEはこの知識の幅を推している）。
ゲーム業界である理由は、近しくも遠からずの領域であり、例えばテストにおいては各々独自の発展（ゲームでは特に自動プレイによるテスト）をしていることを実例として認知していたためである。また、ゲームが持つより複雑なロジックや、顧客との距離が近いという性質についても、よりよいソフトウェア開発へのヒントになるのではないかと期待した。
そこで今回参加したのは国内最大級のゲーム開発者向けのイベントのCEDEC2024である。このイベントで紹介されるセッションは、特に自動テストに関する記事を実務においても参考にしたことがあり、価値を実感していたことから選定した。
ユニークな点
1. 動的なテスト
https://cedec.cesa.or.jp/2024/session/detail/s66040e2aeca6e/
このセッションは目的ドリブンであり、目的はカードゲームの遊び方を画一的にしないバランス調整をすることである。高スコアを突出して出すことができる特定の組み合わせを排除することで、柔軟なデッキ構築のための試行錯誤をユーザーに提供することにある。
内容は、デッキ構築を遺伝的アルゴリズムにより強化し、デッキ評価は深層強化学習モデルによってプレイしたスコアを用いることで、自動でハイスコアを出すデッキパターンを特定することである。これにより、突出したスコアを出す組み合わせの場合や、ハイスコアを出すデッキが同じようなカードの組み合わせの場合にカード効果を修正している。AI部分の担当は研究者の役割であり、スコアの可視化やバランス調整に関しての仕組み（プランナー用アプリ）作りの方は開発者によるもので、部門を跨いで共通認識を構築している点は見習うべき点を多く感じた。
ここでの発見は、バランス調節のための膨大なゲームプレイ試行によって、実装上のバグの発見に役立ったという点である。ロジック部分はUnityに依存せず純粋なC#で記載されているため、その部分では単体テスト等が充実している（はずだ）が、その上で億単位のプレイにより発見があったという点が面白い。これは言うなれば動的なテストである。
ソフトウェア業界ではこのような方針ではなく（諸説あり）、仕様と境界や同値条件による組み合わせに対するテストを静的に記述する。組み合わせは全て網羅することはできない。理由はテストコードの記述やメンテナンス工数による（異論はあるかもしれないが、テストコードは必要以上に多くない方がいい）。ある意味Staticなテストであり、探索的テストを除けば不具合を発見するというベクトルが開発中に（インクリメント以降）発生することは多くない。なぜなら基本的にイテレーション内のユーザーストーリーの受け入れ条件に落とし込むからである（BDDやATDD等）。
学マスの例のように、生成ルール（モデル）を元に動的にテスト（プレイ）が実行される場合は発見性が高まる。このようにして発見されたバグがあれば、必要があればそれを抑えるようなテストケースを追加したり実装を見直すことにつながる。感覚としてはMutation testに近い。CICD上で定期的に探索的にエージェントがテストを生成して実行して不具合を発見するような方向は、リソースに対する費用対効果が見込めれば品質をより作り込むことにつながると期待できそうだ。これはどうにかツールを組み合わせて実現してみたい。
2. 優先度の判断基準
優先度、つまりやることとやらないことを決めること、これについては常にソフトウェア開発を悩ませる一因である。ゲーム業界でもそれは同じだ。しかしNintendoは非常に堅実でロジカルな解法を持っていた。
それはゲームのコアに着目し、なんらかの判断が必要な場合はそのコアをベースとして判断するということである。この場合のコアというのは、ティアーズオブザキングダムにおいて、推理⇨実行⇨結果により面白いことが起こる仕組み作りである。スクラビルド（ゲーム内でリンクがアイテムと武器を結合するシステム）は、任意のアイテムを結合できるが、開発初期では複数結合したい、任意の角度で結合したい、結合結果にそれぞれユニークな命名をつけたい、というようなさまざまなアイデアがあった。それらを全て実装するのか諦めるか優先度を含めて決める必要があった。
彼らのアプローチは、判断に迷う場合はゲームのコアを実現するために必要かどうか、という観点に立ち戻ることであった。例えば任意の角度の結合は、角度の違いによって武器の効果が変わらないため、結果に影響しないという点でコアに合わないとしてやらないことにした。また、ユニークな命名というのは方針を変えて、コアを体現するために結果が予測できるような命名をつけることにした。このように、全てのストーリー（やりたいこと）はコアに合致するかどうかによって判断され整理されていく。
この観点はプロダクト開発においても見習う点が多い。我々が徹底してこれを体現するためには、優先度判断はスプリントゴールやプロダクトゴールの実現に必要か、という観点で考えるべきだろうか。少なくとも、チーム内でこういった方針で判断しよう、という共通認識を確立してチームビルドしていくことが重要ではないかと実感した。
3. ゲームから見たスクラム
https://cedec.cesa.or.jp/2024/session/detail/s6608205d3a6db/
スクウェアエニックスのスクラムマスターがスクラムを語ってくれるセッションからさまざまなユニークな点を見つけた（ゲーム業界ではスクラムは取り入れられているが、会場アンケートからすると多いというわけではないようだ）。
まず一点目は、スプリントの開始前に十分な準備期間を用意している点。スクラムがゲーム業界で難しい点として、関係者が多くタスクにとりかかるReady状態になるタイミングがそれぞれ大きく異なることがあげられていた。スクエニではこれらの対処として、スプリントを開始するまでの期間を用いて制作依頼や実装方針をきちんと計画して全てがReadyの状態を作ったのちに、スプリントを開始するということだった。スプリントも１つではゴールを達成してレビューができないため複数スプリントを経由してレビューを行っている。これらによってスクラムが機能する状況を部分的に作り出しているようだ。一方類似点としては、手戻りを起こしたくないため作らなくても判断できることは事前に行うというペーパープロトのような考え方にも見える。
二点目は、発注や受注という言葉は使わずに制作依頼という言葉に置き換えること。これは、受託関係における上下関係をつくることを避けるため、依頼という概念でやりとりするというものであり、スクラムにおける尊敬を体現しているようだ。ソフトウェア業界においても是非導入されてほしい。尊い。
三点目は、振り返りはチームビルドの場である、と明言していたことだ。これはゲームだからというわけではなく一般にそう考えられているのかもしれないが、僕個人の経験からするとこういった姿勢を見聞きしたことはなかったためユニークだと感じた。振り返りを通してチームメンバーの関係性を築くことを重要視しており、さらにそういった目的をまず最初に話すことということであった。こういうスクラムマスターの下で働くのはとても楽しそうに感じた。
その他参考になる点としては、プランニングはメンバーのボトムアップで行いプロダクトオーナーと合意を取る場であること、自発性の尊重（うまくいかないだろうことが経験的にわかっていたとしても）、制御できない要因（政治や契約的な制約）を吐露すること、感情を表に出して意見すること、Issueは手元にボールが残らないような受け入れ条件（相手に合意をもらうではなく相手に提出するまで）にするなど。
全体としてスクラムというフレームワークに縛られすぎない自由な発想であり、刺激としては心地よいものだった。
類似性
1. スキーマ駆動開発
https://cedec.cesa.or.jp/2024/session/detail/s66062709d99a7/
ポケラボのAPI偽装によるクライアント側の自動テスト効率化のセッション。
まずゲーム開発はクライアント（Unity）とサーバーサイド（API）に分かれるらしい。クライアント側でUI部分のテスト、例えばアイテムを取得した場合にそれが適切に表示されること、などをテストするため、その状況を再現するサーバーサイドのAPIを偽装することで、クライアント単体でテストできるようにしたという内容である。
ソフトウェア業界ではこれらのことをMockやFakeということが多いが、独特な命名（偽装）をしている。彼らの内容を我々の業界で表現すると、フロントエンド単体でテストをするためにMSWを導入してAPIをMockした、ということである。またより設計的観点でいうと、Repositoryを抽象化してFakeと入れ替える（依存性注入）によって実体がなくともテストを行えるようにしたということである。
その際、サーバーサイドのデータ型とクライアントサイドのデータ型の整合性を取る必要があった。Mockすべき境界がちょうとサーバーとクライアントの間と一致しているためである。そのため彼らはデータスキーマをjsonで定義して、それを元にUnity側のC#のデータ型とサーバー側のphpのデータ型を生成するようにしたということだ。この話、思い当たる節があるエンジニアも多いのではないだろうか。
そう、スキーマ駆動開発そのものである。例えば、バックエンドをPython（FastAPI）で記述してAPI定義書を生成し、そのAPI定義書からTypeScriptのデータ型を生成する。MSWによりそれらスキーマを元にAPIのMockを作成する。これをゲーム業界で実行していることと同じ構造である（レヴィ・ストロースのいうような変換が成立する）。
ここから得られる発見は、ゲームとソフトウェア開発の間には、共通して応用可能な構造が存在するということで、未発見の適用の可能性が大いにあるということである（先に述べた動的なテストによる不具合発見なども同じことを示す）。期待としては、ゲーム業界独自でうまくいっているノウハウを抽象化した概念を、ソフトウェア業界に応用することである。このセッションにおいて、具体的な実例を発見できたのはこの仮説を確かなものにするとい
う意味で意義があった。
2. SREというスクラムマスター
https://cedec.cesa.or.jp/2024/session/detail/s6604f029340ec/
このセッションは、ゲーム業界にもSREが必要だよねという内容で、SREとは新たにできた業務ではなくこれまで日々こなしていた内容に適切な名前がついて分離されたものだ、というものだった。発見は、彼らのいうSREはソフトウェアにおけるスクラムマスターを包含するものであり、その定義から発生したものではなくボトムアップで辿り着いたということだ。
セッションによると、SREの役目は自動化という手段で開発の効率化を実現するものである。そして、チームはこのSREの役目をもつメンバーに依存せずこの目標を実現できるようになるように、SREが意識面や知識面でサポートしていく。そのためには、例えばチームの負荷が過剰な場合にはどうにかして改善サイクルを回すための負荷を低減する。
スクラムマスターであればこれを聞いてまさに自分の責務そのものではないかと思うのではないだろうか。面白いのは、彼らがスクラムマスターについて言及することなくこれら内容を実践していることであり、そうであるからこそ本質的な活動であることである。
僕個人がよく思考するのは、スクラムやスクラムマスターという定義や概念がある程度確立している場合、形式や役割に基づいて思考することが少なくとも発生するのではないかという点である。初期は指針として重要な補助輪であると思うが、本質的に限界を定めている可能性を懸念している。スクラムガイド的にはそうならないようにあえて詳細には言及しないで考える余地を多く残す工夫がされているが、しかしある程度そういった型から離れていくこと、フラットな状態でどういう活動が組織において必要なのか考えるということは、とても新鮮であり可能性の萌芽を感じる。
3. イテレーションによる学習
Nintendoの講演は複数あり、取り上げたい内容ベースで記載しているので申し訳ないがどのセッションが区別がつかない。ティアーズオブザキングダムのセッションのどれかである。
いうまでもなくこれはアジャイルマインドそのものである。最低限の実装という言及はクリティカルで、学習（価値発見）のためのMVPである。ソフトウェア用語で言えば、eMVPを繰り返すことで期間内に価値を最大化するということである。Nintendoの主張は、面白さの追求＝このサイクルを多く効果的に回すことであり、回転数を上げるためには手戻りを抑え自動化領域を増やし、効果的にするためにはレビューの質を上げていくのである。発見としては、我々が日々改善していく一方で、根本的な目的をベースに改善を捉え直す必要があるのではないかと考えさせられたことだ。
振り返ると、一つ一つの改善は確かに目的をもって行っているが、主となる目標に常に向いているかというとそうではないことも多い。例えば何回も書くことになるタイプのIssueはテンプレート化しておこうなど。でもそれは工数を削減してスプリント中のインクリメントの質を上げるためであるとか、そういうことと紐づけるところまで考えないこともある。単に効率的だからというレベルで済ませてしまう。この点を徹底的に考え直すきっかけとして良い機会となった。
レビューの質については、より多くの多様な意見をフィードバックに活かすことために、透明性や参加しやすさ、意見の出しやすさを向上させるために掲示板システムを開発しているということであった。この考えはスクラムでいう透明性や尊敬に近い。
発見としては、レビューを効果的にするために自作アプリを作成するまで徹底していることだ。ここから感じ取れるのは、レビューという場に非常に重きを置いていることである。ソフトウェア業界でも同じ考えは持っているが、ここまで徹底はできないないのではないかと正直思う（偏見）。またこの掲示板には、感想ではなく情報を書き、議論はしないこと、というルールがある。自分が感じたことは理由を含めて記述し、意見が違う相手に対してレスするのではなく、反対の意見の場合はまた別の内容として投稿することになっている。こういったルールは情報をフラットに扱えるし、意見を出す障壁を作らない、また関係性に影響を与えないという点でとても効果的であり、ソフトウェア開発にも取り込みたい姿勢の一つである。
4. マイクロサービス
このようにNintendoは開発環境に対する整備が非常に整っており、ゲーム開発インフラという専門領域がある。これは自然と数多くのツールを生み出すこととなる。これらがどのような設計になっているかというと、図のように言及せずともわかるレベルでマイクロサービスアーキテクチャを示唆している。これは用語を使わず概念はきちんと理解している人が作成した図だと確信している（キャリア募集要項にはマイクロサービス設計の経験が記載されている）。
このように独自にカスタマイズされたツールにより、遊びの面白さを追求するサイクルを徹底して効率的に回すことで、常に面白いゲームを展開しているのだろう（これは倒せない）。このテイラードの環境は容易に真似できないという点でマイケル・ポーターのいう戦略に適合して差別化を体現しているようだ。ソフトウェア開発においても開発を効率化するインフラに投資するのは重要であると再認識させられる。
5. 包括的なドキュメントよりも動くソフトウェア
仕様書からデータへ、という内容もソフトウェア開発との類似点である。セッションによると、仕様書は最新の状態を表していないこともあり、参考にすべきマスター情報としては適格ではないということだ。ゲーム制作という環境では、プランナーやデザイナー、サウンドエンジニアやQA、テスターなどあらゆる職種の人が同一の信頼できる情報にアクセスできる必要がある。それは全てが密接に関わり相互に影響しうるものだからである。この相互作用がなければ面白さに限定をしてしまうというのだ。そのため、マスターは仕様書ではなく定義されたデータそのものとすることで、全ての人が最新の情報にアクセスすることを可能にし、それによりシナジーを最大化した。もちろんアクセス可能にするだけでなく、データで扱えることから適切な整形や可視化により柔軟なアクセスを可能にした。これも開発支援ツールである。
これはソフトウェアにおいて、仕様書をマスターとしてそこからテストを作成し管理するということから脱却し、テストコードそのものを可読性高く保つことで動く仕様として管理することと同じである。このテストコードはエンジニアだけでなくプロダクトオーナーやドメインエキスパートにも読めるようにユビキタス言語や平易な（技術的過ぎない）言葉を用いて記述される。これによって受け入れ条件作成の議論により多くの人の参加を促し、シナジーを最大化する。つまりATDD（受け入れ駆動テスト開発）である。SbE（Specification by Example）ともいうか。違いは、ゲーム業界は面白さの追求であり、ソフトウェア業界では顧客に対する価値の実現の追求である点。
スキーマ駆動の構造の一致のように、この観点も同じく構造を持つといえる。さらに面白い点は、プログラムの領域が少なくなっている点である。データの表現力が増すことで、実装するプログラム自体が圧縮されていく。これはコードの保守運用工数を考えると理にかなっていると直感する。まだ抽象的であり適切な変換が特定できないが、ソフトウェア業界においてもこの考えを取り入れてみたい。
セッションの内容はここまでだが、この講演の後、さらに思考を巡らせてについて仕様書に書くべき内容について考えていた。例えば仕様書に、この敵は水に入ることを避ける、という直接的な記載を書くよりは、この敵は〜という理由から水を苦手とする、というような本質的な背景を記載する方が、その後の状況に応じて考慮すべき観点の可能性が高まるのではないか。後者からは自然な理屈で創発的なアイデアにつながる。苦手であれば当然避けるべきだし、かかることも触れることも避けるだろうと考えられる。また苦手な理由が機能しない場合は水に対して何の問題もなくなる可能性も推測される。ソフトウェアにおけるストーリーも同様で、より根源的な内容が記載されていれば、その後の創発的な議論は多くの関係者とのシナジーを用いてよりよい受け入れ条件につながるのではないか、と夢想した。このように想像を働かせることは動機にもつながり、bondingという意味でステークホルダーのソフトウェアに対する関心がより高まるのではないか。こういった人間心理的な側面も含めより創発的な開発につなげたいと思った。
スプリントゴール
1. ゲーム業界における重要な気づき
制作と確認のサイクルを回すことで、どうすればもっと面白くなるか突き詰めること、この発言を聞いた時にもっとも心が躍った。やりがい、内発的動機を感じた。この目的にコミットすること自体、めちゃくちゃ楽しいだろうなと。なぜか。それは感情の動きに着目する目的であるからだ。ゲームにおいては面白いかどうか、という感情面に対する検査が行われるため、エンジニアとしてもレビュー（デモプレイ）に参加することによりその感情を少なからず抱く。また日々どうすれば面白くなるか、と考えることは報酬を期待するという点でドーパミンが分泌される。加えて面白さに対する共感はオキシトシンを分泌し、対象との結合を深める。つまりはストーリーテリングのテクニックと同様のことが発生していることにより、非常に高いレベルのモチベーションを維持できるのではないか。この支配的要因は、Angel's cocktail（ドーパミン、オキシトシン、エンドルフィン）であり、それぞれモチベーション、安心、創造や集中に関連する。
面白い＝自分自身に対する感情である点が、ゲームとソフトウェアのイテレーションのゴールに対するワクワク感の違いを説明できる（少なくとも僕自身の感情に対しては）。この発見をもとにすれば、どうすればソフトウェアにおいてよりモチベーションを高め効果的な開発ができるようになるのかという創発的なアイデアが生まれそうである。
普段の業務では、スプリントゴールに指定する内容はどうしても実利的で現実的で無機質なものになることが多い。例えば、保守運用コストを抑えるためにCICDの重複部分が改修されること、ユーザーの〇〇時の負荷を減らす、など。これはプロダクトゴールを軸に作成するという点で評価、コミットしやすくするために無味乾燥になりがちである。何がいいたいかというと、感情の動きという点をスプリントゴールから無意識的にしても除外している可能性があるということである。
RSGT2024では一年以上の調査結果をもとに、スプリントゴールについての発表を行った。ここではどうすればもっとゴールにコミットできるか、ゴールというものを有効活用できるかという観点で試行錯誤してきた結果をまとめているが、このような人間がもつ感情面の特性については考慮に入れられていなかった。
2. 人間の性質を利用する
CEDECにおけるこの感情面の特性をスプリントゴールに組み込むとすれば、ゴールに対して自身が抱きうる感情を期待するためにできることをスプリント内に取り組むこと、である。
例えば、先ほどあげた例、保守運用コストを抑えるためにCICDの重複部分が改修されること、について。このゴールに対して抱きうる感情としては、今後の変更が楽になるぞ、という安堵である。つまり今後CICDに関する何らかの変更が発生したとして、安堵するためにはどういった点を改修すべきか、どの重複部分から統一すべきか、と考えることである。これを日々考えることにより、このゴールはエンジニアとの精神的な関連性を深め、僕自身がゲームの面白さを追求することに感じた内発的動機によるコミットと同等のやりがいが期待できるのではないかと考えた。何かを期待することはドーパミンの分泌を促進し、達成時には報酬によりさらにそれが加速するため（ガチャも同じ構造）。
こういった感情面の話はあいまいで捉えどころがなく立証が難しく信頼にたるものではないと捉われがちだが、こういった心理学的側面は統計的な研究によるある程度の裏付けもあり、我々も人間であるからこそ、その性質を十分に利用すべきではないだろうか。
さいごに
本題とは関係がないが今回は現地参加をした。オンラインでも情報量としては大差がないかもしれないが（講演後のAskTheSpeakerなど除く）、現地参加のメリットとしては何といっても参加感ではないかと思う。
その場には全員がゲームをよりよく開発するにはどうすればいいのか期待した人たちがいて、講演者は目視できる環境で声を発している。この空気感は集中して内容を理解して思考するためにとても効果的であった（根拠を添えられないため非科学的な域を出ないが）。みたいセッションと時間が被っていたものは後でオンライン視聴したが、そこから何かを得ようとする動機の強さはオフラインに変え難い（気合いの問題かもしれないが）。
ゲーム業界はやはりソフトウェア業界とは領域が近いがしかし少し異なる文化を持っており、ソフトウェア開発における新規性に向けてさまざまなヒントを得ることができた。言うなれば、感情という人間の性質に科学的にフォーカスすること。これら気づきによって得られたアイデアを実行・検証することで、今後のソフトウェア開発のさらなる発展へと貢献したい。