Unity を検索

ゲーム開発の振り返りにおいて見落とされがちな、しかし決して見落としてはいけないもの

2021年9月3日 カテゴリ: ゲーム | 4 分 で読めます
People collaborating and  working on computers
People collaborating and  working on computers
シェア

問題を抱えている?ソースがその原因かもしれません。1 人だけのチームでも、1000 人を超えるようなチームでも、単一の信頼できる情報源だけを使ってスムーズなコラボレーションを行うなど不可能だと思われるかもしれません。

チームが大きなプロジェクトを終えて、何が良かったのか、何がもっと良くできたかを議論する振り返りを行っているとき、バージョン管理システム(VCS)のことは特に考えていないかもしれません。VCS がチームのためになるかどうか、あるいは VCS がチームにとって邪魔なものになる可能性について考えていないかもしれません。 

多くのチームがコミュニケーションギャップや意見の不一致に悩まされており、それがプロジェクトの大幅な遅延につながることもあります。チームが次の大きな製品のコードを書き始める前に、一歩下がってツールを見直すことで、状況が一変するかもしれません。何が仕事の助けになり、何が仕事の妨げになっているのでしょうか。

非常に早いリリースサイクルと大容量のファイルに対処しつつ、地理的に分散したチームでミッションクリティカルなアプリケーションの開発に取り組むということは、困難であることがあります。これは企業の規模に関わらず、また、非常に高い協調性をもって動ける企業にも当てはまる事情です。優れた VCS は、プログラマーとアーティストが、パフォーマンスや反復作業のスピード、ブランチやマージの機能を犠牲にすることなく、迅速に共同作業ができるように、チームに非常に効率的なワークフローを提供してくれるものです。

振り返りのための質問

不完全なソースコード管理(SCM)ワークフローがパイプラインを遅くする原因になっていないかどうかを診断するために、次回の振り返りでは以下の質問について検討してみてください。

自分たちのワークフローは、最適化されたものだったのか、それとも破壊的なものだったのか。

チーム全員のワークフローが同じというわけではありません。 

ゲーム開発者はブランチやマージを駆使して、分散型バージョン管理の利点を活用しようとしますが、アーティストはよりシンプルで集中的なファイルベースのバージョン管理の方を好みます。しかし、チーム全員で協調して動く必要があります。複数のユースケースを管理するためにどのツールを使うかといった基本的なことに関する選択がビルドに大きな問題を引き起こす原因となり、そこからコミュニケーションの断絶や案件の失注など、さまざまな悪い結果につながっていくこともあります。集中型と分散型の両方に対応できる柔軟性が無いと、バージョン管理を導入したことでパフォーマンスと効率性を大きく落とすことにもなりかねません。 

チームメンバーは、他の人の作業を邪魔することを気にせずに、自分の作業に集中できているでしょうか。締め切りに間に合わなかったり、バグが発生したり、その他の問題が発生したときに、VCS が原因ではないかと正直に話してみてください。 

ゲームを作るのに費やした時間と比べて、VCS ツールの使い方を学ぶのに費やした時間はどのくらいだったでしょうか。

皆さんのチームの信頼できるソースにアクセスするための障壁をできるだけ少なくする必要があります。 

少人数のチームでも大人数のチームでも、メンバーの経験値やワークフローにはばらつきがあります。特に、Git や BitBucket など、さまざまなツールを組み合わせた DIY ソリューションを使用している場合や、ゲーム制作に最適化されていない単一のツールを使用している場合は、気づかないうちにソースコード管理がパイプラインを遅くしている可能性があります。多くのスタジオでは、開発に使いたい貴重な時間を割いて、バージョン管理だけを目的とした独自の社内文書や SLA の作成を行っています。 

これはチームの課題なのでしょうか。現在の VCS に対するアプローチが、どのくらいアクセスしやすく、直感的であるとチームが感じているか評価しましょう。広範囲な技術的ノウハウを持たないチームがこの評価に携わることが重要です。

フィードバックに迅速に対応していたのか、それとも火消しに徹していたのか。

外部からも内部からも、フィードバックはすぐに届きます。 

ゲームを成功させるには、変化に対応するスピードが重要です。迅速な対応ができないとバックログが詰まってしまい、ある日突然すべてが急を要する状態になってしまいます。 

テクノロジーは本来、俊敏さを実現してくれるものであって、俊敏さを妨げるものではありません。変更があった場合、まずソースコードに手を入れることになります。大きなファイルと巨大なリポジトリを持つゲームを構築するには、ダウンロードやアップロードの速度だけでなく、変更箇所を分離できる速度も課題となります。それを数分や数秒で出来るでしょうか。 

フィードバックに対応する実装を行い、スムーズに変更できる能力があれば、ゲームの品質を向上させるだけでなく、頭痛の種を最小限に抑えることができます。ゲーム開発において、スピードがゲームを成功させるための障害になっているかどうかを判断し、もしそうであれば、バイナリファイルと巨大なサイズのリポジトリの扱いを考慮して設計された VCS を検討します。

何かあったときのために、どのような準備をしていたのか。

100% うまくいけばいいのですが、残念ながらそうはいきません。

しかし、チームが問題に対処するためにどのような準備をしていたか、そして同じくらい重要なこととして、チームは問題が発生したときにどのようなサポートが期待できると思っていたか、ということは評価するに値します。VCS について言えば、他のツールやプラットフォーム、ゲームエンジンとの統合に関するさまざまな要因や、セキュリティへの影響に至るまで、あらゆるものが評価の対象となります。 

VCS で遭遇した問題にどのように対処したか、チームでオープンに話し合ってください。フォーラムでのセルフサービス、メールや電話での直接の案内など、ツールのサポートが充実していると感じていたか。問題が発生したときのベンダーの対応はどうだったか。 

こういうことはただその時やらなければならないからやる、というものではありません。今回のゲームで重大な問題が発生しなかったとしても、ソースコードのような重要なものの実装と保守において、チームがどれだけ完全にサポートされていたかを評価できるということは、次のプロジェクトへの大きな財産となるはずです。

ツールを邪魔者にしないために。無料で Plastic SCM を始めよう 

チームが最高の仕事を出来るように、ツールを整えましょう。Plastic SCM Cloud Edition を無料でお試しいただくか、5 ユーザーまでご利用いただける Enterprise Edition の 30 日間無料トライアルにお申し込みください。

* 最初の 3 ユーザーと 5GB の容量は無料です。それ以上ご利用される場合は、アクティブユーザー数やレポジトリの総容量によって価格が変わります。こちらのページで価格と条件をご確認ください。

 

2021年9月3日 カテゴリ: ゲーム | 4 分 で読めます