2025年7月22日～24日に開催されたゲーム開発者向け技術カンファレンス「CEDEC2025」において、ラセングルのクライアントエンジニアである張 永儒氏が登壇。「Unityでの複数プロジェクト並行開発におけるパッケージ管理と開発手法」と題し、同社が直面した開発上の課題と、その解決策として導入した“パッケージベース開発”の具体的なノウハウを共有しました。
複数のプロトタイプ開発が同時に進行する中で、各プロジェクトが独自に共通機能を実装することによるリソースの浪費や、複雑化するコードの依存関係といった問題に直面した同社。本セッションでは、これらの課題を解決するために「パッケージベース開発」を導入した経緯から、導入プロセスで発生した3つの“ボトルネック”とその具体的な解消法、そして導入後の成果と新たな課題まで、実務に即した知見が詳細に語られました。本稿では、その講演内容をレポートします。
なぜ「パッケージ管理」が必要だったのか？ 複数の並行開発が抱える課題
セッションの冒頭、張氏はラセングルが複数のゲームタイトルを企画・開発しており、常に複数のプロトタイプ開発が同時に進行しているという背景を説明しました。当初、各プロジェクトではUI基盤や課金システム、物理エンジンといった共通機能が個別に実装されており、共通部分の再利用ができず、多大な工数と時間が費やされるという問題を抱えていました。
理想としたのは、基盤開発チームが共通機能を一元管理し、各プロジェクトがゲームのコアロジック開発にリソースを集中できる体制です。しかし、張氏は「基盤を作る話はこれまで何度も出たが、なかなかうまくいかなかった」と振り返ります。その失敗の背景には、並行開発特有の根深い課題がありました。
依存関係の複雑化と管理範囲の曖昧さ―並行開発を阻む3つの「壁」
張氏は、基盤開発が頓挫してきた原因として、主に3つの問題点を挙げました。
コードの依存関係管理が不十分
UI基盤が、意図せず課金システムに依存してしまうといった、無駄な依存関係が発生。これにより、一部の機能を移植する際に、予期せぬ他の機能もセットで移植しなければならない状況や、モジュール同士が相互に参照し合う“循環依存”が発生し、機能の分離を困難にしていました。依存関係の把握が困難
プロジェクトが大規模化するにつれてコードの全体像を把握することが難しくなり、開発者が知らないうちに新たな依存関係が生まれてしまうという問題です。担当分野の管理範囲が曖昧
インゲームとアウトゲームのように担当者を分けても、その境界にある「遷移処理」などは誰が責任を持つのかが曖昧になり、管理が手薄になるケースがあったと指摘しました。
これらの課題を解決するため、同社がたどり着いたのが「パッケージベース開発」でした。
解決策としての「パッケージベース開発」とその利点
張氏は、パッケージベース開発を導入することで、前述の課題を解決できると説明しました。その特徴として、以下の3点を挙げています。
簡略化性質: 複雑な処理をパッケージ内部に隠し、必要な機能のみをシンプルなAPIとして提供します。これにより、開発者はパッケージの詳細な実装を理解せずとも、容易に機能を利用できます。張氏はこれを「日常生活で発電の仕組みを知らなくてもコンセントから電気が使えるのと同じ」と例えました。
再利用性質: 各パッケージはレゴブロックのように、他のパッケージやプロジェクトで何度も再利用が可能です。これにより、開発コストの削減と効率化が実現します。
単一方向の依存関係性質: パッケージ同士が相互に依存する“循環依存”が構造的に発生しにくく、エラーとして検知されるため、健全な依存関係を維持しやすくなります。
Unityに標準搭載されているUnity Package Manager (UPM) も、Web業界で広く使われているnpm (Node Package Manager) をベースにしており、こうしたパッケージベースの開発思想に基づいていると張氏は解説しました。
導入を阻む「ボトルネック」と、現場で編み出した解消法
多くの利点がある一方で、パッケージベース開発の導入は一筋縄ではいかなかったと張氏は語ります。同社が直面した3つのボトルネックと、それを乗り越えるために実践した具体的な解消法が紹介されました。
その1：プロジェクトの理解を得ることが難しい
従来の開発フローを変えることへの現場の抵抗感や、短期的な効果が見えにくいことから、導入には慎重な意見もあったといいます。
【解消法】
低コストでのスタート: 運用中のツールや無料ツールのみを活用し、追加コストを最小限に抑えることで、導入へのハードルを下げました。
スモールスタート: スケジュールに比較的余裕のある新規施策チームから導入を開始。まずはグラフィックス系の基盤から着手し、小さな成功実績を積み重ねることで、徐々に他プロジェクトへと展開していきました。
その2：パッケージ開発に適したプログラム設計
アクセス権限の制御やバージョン間の互換性担保など、パッケージ開発特有のノウハウがチームに不足していました。
【解消法】
コードオーナーの設置と管理フローの策定: まず経験豊富なエンジニアを管理者に任命して品質を担保しつつ、徐々に他のエンジニアへ管理権限を委譲することで、チーム全体のスキルアップを図りました。
Change Logの強制: バージョン更新時の変更点を「Change Log」として記録することを必須とし、管理者への情報共有を円滑化。これにより、管理者の影響範囲調査の負担が大幅に軽減されました。
その3：作業者全員のUPM環境設定が難しい
アーティストやプランナーなど、非エンジニア職のスタッフにとって、個別の認証トークン設定などが複雑で、ミスが発生しやすい状況でした。
【解消法】
設定フローのWiki化: まず、誰でも理解しやすいように図解付きの手順書を社内Wikiに整備しました。
設定作業の自動化: さらに、バッチファイルやPythonスクリプトを用いて設定作業を自動化するツールを作成。「ダブルクリックするだけで設定が完了する」という手軽さを実現し、ヒューマンエラーを根本からなくす工夫を行いました。
導入後の成果と、新たに見えた「実運用上の課題」
これらの取り組みの結果、ラセングルでは大きな成果が得られたと張氏は報告します。
開発効率の向上: 再利用可能な基盤が蓄積され、並行開発の効率が大幅に向上しました。
一元管理の実現: 自社パッケージサーバーを設置し、基盤コードの一元管理と保守性の向上を実現しました。
責任範囲の明確化: パッケージ単位で管理者を任命することで責任の所在が明確になり、管理者が各プロジェクトの相談窓口として機能するサポート体制が確立されました。
一方で、実運用フェーズに入り、新たな課題も見えてきたといいます。
パッケージ間でのアセット参照問題: あるパッケージ内のプレハブが、別のパッケージ内のプレハブを参照している場合、依存関係の設定を忘れると参照エラーが発生します。この問題に対し、現状は「パッケージ更新後に必ずクリーンなプロジェクトでダウンロードテストを実施する」というルールで対応しているものの、将来的には自動テストの導入を検討しているとのことです。
プロジェクトごとの環境差異によるトラブル: Unityのバージョンやプロジェクト設定の違いにより、あるプロジェクトでは問題なく動く基盤が、別のプロジェクトではバグを引き起こすケースがありました。これに対しては、基準となる「スタンダード環境」を定義。各プロジェクトはこのスタンダード環境に準拠する方針を採ることで、環境差異によるトラブルを未然に防いでいると説明しました。
まとめ
本セッションでは、複数プロジェクトの並行開発という、多くの開発スタジオが直面するであろう課題に対し、ラセングルが「パッケージベース開発」という手法を用いていかに立ち向かい、開発効率を向上させてきたかが具体的に語られました。
パッケージベース開発は、基盤の継続的な蓄積や効率的なリソース共有、一元的な管理体制の構築といった大きなメリットをもたらします。しかし、その導入は単にツールを導入するだけでは完結せず、現場の理解を得るための丁寧なプロセス設計や、運用を円滑にするためのルール整備、そして発生する新たな課題への継続的な対応が不可欠であることが示されました。
張氏は最後に、「基盤作りは成果が見えづらく、報われないと感じることもあるが、チームのために誰かがやらないと始まらない」と述べ、地道な改善の重要性を強調しました。開発環境の標準化やチーム全体の生産性向上を目指すデベロッパーにとって、非常に示唆に富んだセッションとなりました。
