ラセングルが今進めているのは「Unity複数プロジェクトのパッケージ管理」。各プロジェクトで同じことが行われリソースを無駄にしないために
本稿では、「CEDEC2025」でラセングルが登壇したセッションの内容を紹介する。セッションでは、複数プロジェクトの開発におけるパッケージの管理手法などが伝えられている。
一般社団法人コンピュータエンターテインメント協会（CESA）は7月22日から24日、「CEDEC2025」を開催した。本イベントは、ゲーム開発に関する技術や知識を共有し、開発者のスキルアップや業界全体の発展を目的とした国内最大級の技術交流カンファレンスだ。
本稿では、株式会社ラセングルのクライアントエンジニアである張 永儒氏が登壇したセッション「Unityでの複数プロジェクト並行開発におけるパッケージ管理と開発手法」の内容を紹介する。ラセングルは『Fate/Grand Order（FGO）』をはじめ、『Fate』シリーズのゲーム化作品を中心にさまざまなジャンルのゲームを世に送り出してきたデベロッパーだ。
セッションの中では、同社が複数プロジェクトを並行して開発する中で直面した、ゲームの基盤部分に関する問題点と、その解決法として導入した「パッケージベース開発」の内容や導入フロー、そこから得られた知見や課題などが、実務的な観点から共有された。
基盤作りが抱えていた問題と、改善を阻む3つの理由
張氏はまず、課題が生まれた背景を説明。ラセングルでは新作開発のため、常に複数の企画やプロトタイプ開発が同時に進行していた。その際各プロジェクトでは、ゲームプレイ部分だけでなくUI基盤や課金システム、物理エンジンといった「基盤部分のプログラム」も1から制作していたという。本来共通する要素を再利用せずに作り直すことで、膨大な手間と時間がかかってしまうという問題があった。
理想は再利用できる基盤を作り、各チームがゲームプレイ制作に専念できる環境だ。そのため基盤部分を専門に担当するチームを設置し、基盤部分を複数プロジェクト間で管理・共有しようと何度も試みたが、以下の3つの理由で失敗してしまったという。
1.コードの依存関係管理が不十分
依存関係とは、たとえばUI基盤を使ってUIを表示するように、処理をおこなうために特定のコードや基盤システムを必要とする関係性を指す。ゲーム制作では必要な基盤の種類が膨大で管理が難しく、ひとつの基盤が気づかぬうちに別の基盤に依存してしまい、結局どちらも移植が必要になってしまう、といったことが起きていた。また、基盤システムとゲームプレイが相互に依存する「循環依存」により、基盤システムの移植自体が難しくなることもあった。
2.依存関係を十分に把握することが難しい
プロジェクトが大規模になるほどコードの量が増え、気づかないところで依存関係が生まれてしまう。1人コード管理者を置いたとしても、すべての依存関係の把握と管理が不可能な状況になっていた。
3.コードの管理範囲が曖昧
細かなコード管理のため、ゲームプレイを担当するインゲーム、それ以外の部分を担当するアウトゲームのように担当を分けてみても、それぞれの中間にある「遷移処理」などは誰が担当するのかが曖昧で、管理が難しいという問題が発生していた。
これらの課題を解決するため、「基盤コードの一元管理」「コードの依存関係管理」「各コード責任者の管理領域の明確化」「コード共有の簡略化」を目的とした“パッケージベース”の開発環境が考案された。
簡単に使えて、再利用可能。“パッケージベース”の開発がもたらすメリット
「パッケージ」とは、それぞれの基盤システムをパッケージとして個別にブロック分けし、管理・共有しやすくする仕組みのことだ。パッケージは以下の3つの性質を持っている。
特徴1.抽象化・簡略化性質
個々のパッケージでは複雑で具体的な処理をあえてユーザーの目から隠し、必要な操作のみをAPIとして表示することで、誰でも簡単に使うことができる。たとえば発電の仕組みを理解していなくても、コンセントにプラグを挿せば家電が使えるように、中身の詳細を知らなくても気軽に使えるものとして設計されている。
特徴2.再利用性質
各パッケージは他のプロジェクトで再利用できる。そのため大きな課題だった1からの基盤システム制作が不要になり、大幅なコストダウンと効率化を実現できる。張氏は例としてレゴブロックを挙げ、消防車のレゴパーツが他のものの制作に使えるように、自由に流用可能な仕組みであるとした。
特徴3.単一方向の依存関係性質
2つのパッケージ間で相互に依存する循環依存が起こると、エラーが起こるようになっている。これにより移植を困難にする循環依存の早期発見と、軌道修正が容易になる。
すでにWeb業界ではNode Package Manager（NPM）というパッケージ管理ツールが使われており、ラセングルが開発に使用しているUnityにも、NPMのスタイルを取り入れた「Unity Package Manager（UPM）」がある。パッケージ開発・管理にはこれらのツールを多分に活用したそうだ。
効率化を促進し、一見デメリットがないように思えるパッケージベースの開発だが、なぜこれまでラセングルではこの仕組みが活用されてこなかったのだろうか。この点に関して張氏は、パッケージ導入時に弊害（ボトルネック）となっていた3つのポイント、そしてそれらをどのように解決したかを述べた。
チームの説得、エンジニアの育成――パッケージ導入への課題と対策
まず弊害として挙げられたのは、「プロジェクトチームの理解を得ることが難しい」ということだ。既存のプロジェクトでは、パッケージなしで開発する環境が確立されている。そのためパッケージ導入時にはすでにある環境を一度壊すことになり、開発期間が長いプロジェクトほど負担が大きくなってしまう。一方で短期間の開発では効果が見えにくく、当初は社内でパッケージの実用性に疑問の声が上がっていたそうだ。
この対策として、張氏はまずツールに着目。パッケージ管理用に前述のUPMといったすでに社内で使っているツールを使用し、パッケージを保管するサーバーにはVerdaccioなどの無料のツールを用いて、心理的・物理的なコストを削減。パッケージ環境導入時の負担を最小限にした。
そして導入対象は小規模、特にスケジュールに追われていない新規プロジェクトに絞り、はじめはグラフィックス系の基盤に対して検証利用した。開発初期から無理のない範囲で導入することでパッケージのメリットを感じやすくなり、次第にパッケージベースの開発方式がプロジェクト全体に拡大。成功事例ができたことで他プロジェクトでも同じ方式が使われるようになり、最終的に会社全体の開発手法として定着させることができた。
次に問題となったのは、「パッケージ開発に適したプログラム制作に慣れていない」という点。ユーザーにパッケージ内のどこまでの範囲をAPIとして見せるのか、更新時に複数プロジェクト間での互換性をどう確保するのかなど、パッケージ開発は単体のゲーム制作とは毛色が違う。そのためパッケージを最適化するノウハウが社内全体で蓄積されておらず、導入や開発へのハードルが高かった。
この問題に対しては、まず各パッケージの開発チームにコードオーナー（管理者）を設置。パッケージ設計の経験があるエンジニアを管理者として置き、プログラム設計やコード管理、依存関係の調整などをさせることで、チーム内にパッケージ開発の経験を積み重ねていった。そうしてある程度エンジニアが育ったところで、チーム内から新規パッケージの管理者を任命。こうしてパッケージ設計ができる人材を徐々に増やしていった。なお、コード権限や必要なチェックリストの設定には、.githubの設定ファイルを活用したとのこと。
そして互換性の問題に関しては、パッケージ更新時のChange Logに変更点の記入を必須化。更新のたびに利用者が影響のある範囲を確認する必要がなくなり、互換性を維持しやすくなった。
また、実際にパッケージを導入する際に問題となったのは「利用者全員のUPM環境設定の難しさ」だ。UPMを用いてパッケージを導入するには個人の認証トークン（パスワード）が必要で、利用者が自分でUPMを設定しなければならなかった。この設定は特に非エンジニア職にとっては煩雑で、導入を妨げる要因のひとつとなっていた。
これに対しては、まずパッケージ導入の詳細な手順書を社内用Wikiとして作成。また、batファイルやPythonファイルを使用して設定フローの一部を自動化し、ファイルをダブルクリックするだけで簡単に設定できる環境を整えた。
パッケージベース導入後の改善と、見えてきた2つの課題
実際にパッケージベースの開発を導入した結果は以下のとおりだ。まずもっとも大きな成果として、正しいパッケージベースの開発により、再利用可能な基盤システムが徐々に増加した。毎回基盤を作り直す手間が減ったことで、当初の目論見どおり開発効率を大きく向上させることに成功した。
そして自社パッケージ用のサーバーを設置したことで、基盤システムの一元管理が可能に。各プロジェクトでバラバラだったものがまとまり、基盤システムを管理・調整しやすくなった。
また各コードの責任範囲が曖昧だった問題に対しては、パッケージ単位での管理者の任命により責任の所在が明確化。管理者が相談窓口として各プロジェクトをサポートし、開発の停滞を減らすことができた。
パッケージベースの開発により多くの問題を解決することに成功したが、張氏によればまだ2つの課題が存在しているという。
まずひとつは、「パッケージ間でのアセット（素材）参照」問題だ。たとえばパッケージAの中に、パッケージBに含まれる素材を参照して表示するコードが含まれていたとする。パッケージAのみを導入するとき、パッケージAB間で依存関係が正しく設定されていれば、必要なアセットが適宜ダウンロードされ、問題は起こらない。しかし設定漏れやミスがあると、アセットが表示されないままになってしまう。
これらの参照エラーは、プログラミングコードであれば正しく動作しないためすぐに問題を発見できるが、アセットの場合は表示・再生されないというだけで、プログラム自体は動いてしまう。よって手動でチェックする必要があり、問題に気づきにくい状況になっている。
現状の対策として、パッケージを更新した後に、必ず初期状態のプロジェクトでテストして、アセットに問題がないかチェックするようにしているそうだ。ただし時間と手間がかかるため、自動でテストする仕組みを検討中とのこと。
もうひとつの問題は、「各プロジェクトの環境違いが引き起こすトラブル」だ。各プロジェクトはUnityのバージョン、プロジェクト設定、アセットの基準などの環境が異なる。そのため同じパッケージでも、問題なく使えるプロジェクトとバグが発生するプロジェクトが同時に存在してしまっていた。
これに対しては、環境設定の基準を定めたものを「スタンダード環境」と定義し、この環境で基盤を開発するという対策を実施。まだ完全ではないものの、問題が起きた際はスタンダード環境とプロジェクトの環境を比較し、基本的にスタンダード環境に合わせて調整・更新することで、トラブル防止に一定の効果を上げているようだ。
「誰かがやらないと改善は始まらない」。地道な努力がもたらした大きな成果
複数プロジェクトを並行して開発する環境では、同じ基盤を再利用可能な「パッケージベースの開発」が効率化やコスト削減に多大な貢献をもたらした。チームの説得、パッケージ開発の経験不足など導入にはさまざまな問題を解決する必要があり、短期的な効果を感じづらいが、長期的には基盤パッケージの継続的な蓄積や、コードの一元的な管理体制などにより大きな恩恵を受けられる。
基盤作りは地道に積み上げる必要があり、成果が見えづらいものだ。それでもチームのために誰かがやらないと改善は始まらないと張氏は語り、セッションは終了した。
複数のプロジェクトやプロトタイプ開発が並行して動いている状況では、いかに無駄を減らして効率を上げるかが常々の課題だ。この問題にラセングルは「パッケージベースの開発」という方法でひとつの解決策を示した。ゲーム開発の裏側の部分ではあるが、ゲームプレイの制作に専念できる環境というのは、チームのモチベーションやゲームのクオリティに大きく寄与するだろう。同じ問題を抱えている多くのデベロッパーにとって有用なセッションとなった。
