より良いチームワークを作り上げる、KO_OP のバージョン管理活用法

正直なところ、才能のあるアーティストやエンジニアが集まったスタジオで、一つの制作プロセスに合わせるのは大変なことです。うっかり行われたファイルの複製や上書きを追跡するためにチームが奔走するという事態は、アセットの管理ミスや部門間のサイロ化の結果、引き起こされたものであることが多いです。

カナダのスタジオ KO_OP も、まさにそのようなフラストレーションを抱えていました。最初は Git がプログラマーにとって適切なバージョン管理プラットフォームだと考えていましたが、誰もが Git を快適に使えるわけではなかったのです。その結果、制作スピードが大幅に低下してしまいました。KO_OP の次の大作となる『Goodbye Volcano High』のリリースに向けた作業をしている中で、このフラストレーションを緩和するための対策を早急にとる必要がありました。

KO_OP でスタジオ全体で使えるソリューションを探していたところ、新しいバージョン管理システム（VCS）として、Plastic SCM Cloud Edition を採用することになりました。どうしてその選択に至ったのか、そしてこの選択によって何が変わったのかを見てみましょう。

非常に高速なリリースサイクル、大容量のファイル、分散したチームという要素が揃ってしまうと、どんなに協調性のある企業でもバランスをとるのが難しくなります。ワークフローもぐちゃぐちゃになり、誰がプロジェクトのどの部分を担当しているのか、いつどのような変更が行われているのかなど、疑問や混乱が常にある状態になります。

そのため、アーティストとエンジニアがお互いに知らないうちに同じファイルに手を入れてしまい、マージの際に回避不能な衝突を起こしてしまうことがあるのです。クリエイティブチームとテクニカルチームは独立して仕事をすることが多いのですが、その境界線は一見してわかる以上にさまざまな場所で交差しています。クリエイティブとテクニカル、この二つの要素は、ゲームの構想から制作、発売、修正、継続的なアップデートに至るまでのすべての段階で必要となります。KO_OP のモントリオールにあるスタジオも同様で、フルタイムのチームメンバー全員が対等な会社のオーナーであり、ゲームのデザインや開発など、あらゆる面で重要な決定権を共有しています。

スタジオディレクターの Saleem Dabbous 氏とプログラマーの Bronson Zgeb 氏によって 2012 年に設立された KO_OP は、インタラクティブなプロジェクトにおいて、より民主的で実験的なアプローチを大切にしてきました。『Lara Croft GO』のエクスパンション、『The Mirror of Spirits』や、Apple Arcade 向けゲーム『Winding Worlds』など、同スタジオの代表作の制作には真剣なチームワークが要求され、またそれ故に、同じくらい充実したサポートも要求されます。最近の Vice のプロフィールで Dabbous 氏が説明しているように、「このスタジオは、その一員である人々をサポートするために存在しているのであって、その逆ではない」のです。

しかし、当時のチームは、自分たちの使命にどこか息苦しさを感じていました。KO_OP では、バージョン管理に Git を使用していましたが、より効率的なコラボレーションを実現するうえで要求される、全体を俯瞰した見方ができないことがわかりました。プログラマーはそれまでの仕事でソースコードの管理に Git を活用していましたが、技術的な専門知識の乏しいクリエイターは、一見不思議なシステムのように見える Git を直感的に理解することができませんでした。パンデミックの影響で全員が分散してリモートで仕事することを余儀なくされると、コミュニケーションは悪化し、エラーが多発したため、KO_OP のチームは変化が必要だと考えました。

『Goodbye Volcano High』の仕事を進める中で、とうとう KO_OP は Plastic SCM と出会いました。Unity を使うスタジオとして、それは当然のことのように思えました。Plastic SCM は、パフォーマンスやブランチ・マージ機能について妥協することなくワークフローを洗練させ、スムーズなコラボレーションを可能にする役割を果たすバージョン管理システムです。最も重要なことは、チームが単一の真実の情報源に頼ることができるということです。

Git からの移行は、驚くほどシンプルで分かりやすいものでした。KO_OP のチームは、効率化のためのベストプラクティスなどが記載された Plastic の詳細なドキュメントを高く評価しました。「Plastic は、私たちがこれまで使っていたものよりもはるかに細かく、効果的なレベルでブランチモデルを設定する方法を教えてくれました」と Dabbous 氏は言います。親しみやすく、リッチなビジュアルを持つツールは、アーティストにもエンジニアにも魅力的でした。

KO_OP のアーティストは、プロジェクトにアセットを安全に取り込むために、プログラマーに頼っていました。今では、ユーザーフレンドリーな GUI とワークフローである Gluon のおかげで、ブランチやマージに関する深い知識がなくても、誰もが大きな見過ごしをすることもなくファイルを手に取り、大きなバイナリを扱うことができるようになりました。開発者の Jacob Blommestein 氏は、これを「（.psd ファイルを追加することができた）アーティストにとって、驚きの出来事」と表現しています。また氏によれば、「バージョニングは透明でした」。

同時に、ナラティブチームのライターはプロジェクトの状況を把握できるようになり、開発者は Plastic のブランチのビジュアライゼーションに魅了されました。「Plastic は解析が簡単で、Git よりもはるかに操作しやすいです」と Dabbous 氏は語ります。「みんなが破壊的でない方法で、プロジェクトの中を飛び回ることができます」。

Plastic を他の重要なコミュニケーションツール（Slack や Jira など）とよりよく統合するために、KO_OP のプログラマーは一連の DevOps ツールの開発にも着手しました。Dabbous 氏はこう言います。「次のステップとして、全体的なコラボレーションを向上させるべきだと考えました」。この意欲と、コードを素早く再利用して改良し、KO_OP の他の相互依存しているシステムを追跡する新たな能力とが相まって、チームにとっての転機が訪れました。

Plastic のユニークなバージョン管理のアプローチは、結果的に KO_OP の制作ラインを再起動させ、プロジェクト計画をはるかに超えた形で再定義する絶好の機会をもたらしたのです。Plastic のアプローチは、市場に素早く製品を投入するためのオープンなコミュニケーションと迅速なイテレーションのための能力を与えてくれます。チームが統一されたワークフローに沿って作業を進めるようになった結果、『Goodbye Volcano High』の待望のリリースに向けた作業が順調に進むようになりました。今では誰もが、他の人が何をしているのか、自分の作業が KO_OP で共有しているビジョンにどのように合致するのかを意識するようになり、スタジオはバラバラに仕事をする人たちの集まりではなく、志を同じくする人たちのつながりのあるグループのように運営されています。

チームが最高の仕事を出来るように、ツールを整えましょう。Plastic SCM を無料でお試しください。