ゲーム開発者のためのプロジェクト管理：なぜあなたのゲームは締め切りを守れないのか

ゲーム開発者に前回のプロジェクトが頓挫した理由を聞いても、「コードが難しすぎた」という答えはほとんど出てきません。ほぼ必ずスコープクリープ、燃え尽き、モチベーションの低下、または次に何をすべきかの見失いといった形で終わります。ゲーム開発の技術的な側面はすべての注目を集めますが、ゲームが実際にリリースされるかどうかを決めるのは組織的な側面です。 これはスペアタイムにパッションプロジェクトに取り組んでいるソロ開発者に固有の問題ではありません。本当の予算と本当のチームを持つスタジオでも、管理の側面が崩壊したためにリリースが遅れたり、機能を削減したり、プロジェクト全体をキャンセルしたりします。永遠に完成度40%のまま眠り続けるゲームとリリースされるゲームの違いは、ほぼ常に技術的なものではなく構造的なものです。 ゲーム開発は、同時に多くの分野にまたがるため、特に管理が難しいです。単にソフトウェアを書いているのではありません。アート、デザイン、音声、ナラティブ、プログラミング、QA、そして時にはマーケティングをすべて同じプロジェクト内で調整しています。それぞれに独自のワークフロー、依存関係、「完了」の定義があります。それらをまとめるシステムがなければ、物事は崩壊します。

典型的なソフトウェアプロジェクトは比較的予測可能な構造を持っています。要件を収集し、機能を構築し、テストし、デプロイします。ゲーム開発はそのようには機能しません。独自のスケジュールでアセットを制作するアートパイプラインがあります。プレイテストするまで何かが楽しいかどうかわからないため、本質的に反復的なゲームデザインがあります。完成したビジュアルに依存するオーディオがあります。そしてそれらすべてをつなぎ合わせるコードがあります。 ゲーム開発の依存関係のチェーンは過酷です。プログラマーはデザイナーが戦闘システムを確定するまで敵のAI動作を実装できません。アニメーターはキャラクターモデルが完成するまで攻撃アニメーションを作れません。サウンドデザイナーはアニメーションのタイミングが決まるまでインパクトエフェクトを作れません。一つのボトルネックがプロジェクト全体に波及します。 これが、一般的なプロジェクト管理のアドバイスがゲーム開発者には不十分な理由です。複雑な相互依存関係を持つ5つの分野にわたる200のタスクがある場合、「To-doリストを使えばいい」では通用しません。ビジュアル、技術、組織をすべて同時に扱えるものが必要です。

ゲームプロジェクトでできる最も重要なことは、マイルストーンに分解することです。「ゲームを完成させる」のような漠然としたマイルストーンではありません。明確な成果物と日程を持つ、本物の具体的なマイルストーンです。 典型的なインディーゲームのマイルストーンは次のようになります：プロトタイプ（コアメカニクスが機能し、仮のアート）、バーティカルスライス（最終品質のアートとオーディオを備えた完全なレベル1つ）、アルファ（すべての機能が実装され、コンテンツがほぼ完成）、ベータ（コンテンツが完成し、バグ修正中）、そしてゴールド（リリース）。各マイルストーンは小さなゴールラインのように感じられるべきで、無限のバックログを眺めるのではなく勢いをつけられるようにします。 各マイルストーン内では、分野ごとにタスクを分解します。アートのタスク、プログラミングのタスク、デザインのタスク、オーディオのタスク。チームで作業しているなら、それぞれに優先度と担当者を割り当てます。完了率を追跡して、プログラミングが遅れているのにアートが予定より進んでいるかどうかを一目でわかるようにします。このような可視性が、プロジェクトを終わらせる「もうすぐ完成だと思っていた」という驚きを防ぎます。

すべてのゲームプロジェクトには、ゲームが何であるか、どのように機能するか、計画が何であるかを説明する中心的なドキュメントが必要です。ゲームデザインドキュメント、プロジェクトバイブル、何と呼んでも構いません。重要なのは、3ヶ月前に何を考えていたか忘れてしまう将来の自分も含め、プロジェクトの全員が一つの場所を見て何が構築されているかを理解できることです。 このドキュメントは、誰も読まない50ページの仕様書であってはなりません。コアゲームプレイループ、主要なメカニクス、アートディレクション、技術要件、スコープをカバーする、構造化されたセクション付きドキュメントであるべきです。簡潔に保ち、更新し続けてください。6ヶ月前は正確だったが以来手が触れていないデザインドキュメントは、ドキュメントがないよりも悪いです。なぜならそれは積極的に誤解を招くからです。 タスクをこのドキュメントのセクションにリンクさせましょう。「なぜこの機能を構築しているのか？」という質問に対する答えは、関連するセクションへのリンクであるべきです。これにより、高レベルのビジョンから個々のタスクに至るまでの推論の連鎖が作られ、全員の足並みが揃います。 IndieDevBoardのデザインドキュメントでは、カンバンボードとマイルストーンのすぐ隣に存在するセクション付きの構造化されたドキュメントを作成できます。ドキュメントを更新し、タスクを更新すれば、5つの異なるアプリを切り替えることなくすべてがつながったままです。

ゲーム開発は本質的にビジュアルです。人々が見て操作するものを構築しています。プロジェクト管理もそれを反映すべきです。 カンバンボードはタスクの追跡に有効で、何が進行中、何がブロックされ、何が完了しているかを一目で確認できます。しかしゲーム開発では特に、タイムラインビューも必要で、今後の数週間から数ヶ月にわたってマイルストーンがどのように並んでいるかを確認できます。アートパイプラインがプログラミングのスプリントと並行して動いているガントチャートは、何かが衝突するかどうかをすぐに示してくれます。 ムードボードは、ゲーム開発者がプロジェクト管理において活用しきれていないもう一つのツールです。アートスタイル、UIデザイン、環境コンセプト、キャラクターの美学のビジュアルリファレンスを一か所に集めることで、チーム全員が同じビジュアル言語から作業できます。これにより、共有のリファレンスが確立されなかったためにキャラクターアーティストと環境アーティストが全く異なるアートスタイルになってしまうという、よくある問題を防ぎます。

ゲーム開発についての不快な真実があります。あなたの最初のビジョンは大きすぎます。常にそうです。ゲームをリリースする最大のスキルは、プロジェクトの魂を削らずに機能を削ることです。 そのためには、初日から優先度について容赦なくあることが必要です。すべての機能、すべてのメカニクス、すべてのアセットは、必須、あると良い、またはストレッチゴールとしてタグ付けされるべきです。必然的にスケジュールが遅れたとき、そしてそれは起きます、下から上に向かって削ります。まずストレッチゴールがなくなります。次にあると良いものが。必須項目が最小限のゲームです。 これをタスク管理で追跡しましょう。カンバンボードに優先度レベルとラベルを使用して、重要なパスだけをフィルタリングして見られるようにします。目標リリースの3週間前で遅れているとき、必須タスクだけを表示して、リリースまでに何が残っているかを正確に把握できる必要があります。その明確さがゲームを世に送り出します。 経費の追跡も、ほとんどのインディー開発者が思う以上に重要です。アセットを購入したり、コントラクターに支払ったり、何らかの予算を運用したりしているなら、プロジェクトレベルでお金の行き先を把握する必要があります。小さな購入はすぐに積み重なり、支出を見失うことはプロジェクトが静かに死んでいくもう一つの方法です。

世界最高のプロジェクト管理システムも、ゲームを「いつかは完成する」ものとして扱っていれば役に立ちません。日程を設定しましょう。たとえ恣意的でも。たとえ後で変更しても。目標があることで、すべての決断の考え方が変わります。 締め切りがあると、「このかっこいい新機能を追加すべきか？」は「これを追加して期限通りにリリースできるか？」になります。その捉え方の変化は強力です。すべての機能リクエストをウィッシュリストのアイテムではなく、トレードオフの計算に変えます。 実際にゲームをリリースするゲーム開発者は、必ずしも才能があるわけでも、より規律正しいわけでもありません。追跡できる単位に作業を分解し、構造、可視性、説明責任を持ってプロジェクトを扱った人たちです。決定事項を文書化しました。必要なときにスコープを削りました。楽しくなくなっても前進し続けました。 あなたが夢を持つソロ開発者であろうと、Steamのリリースウィンドウを目指す小さなチームであろうと、ゲームが世界に存在するかあなたのハードドライブにだけ存在するかの違いは、作業をどのように管理するかにかかっています。コードやアートと同じくらい真剣にそれに取り組めば、成功の確率は劇的に上がります。