こんにちは。ゲームデザイン部のディレクターの江中です。
昨年に中途入社しましたが、それまでは自社開発の経験ばかりで、アピリッツで初めてゲームの受託開発を経験しました。
この記事では、ゲームディレクターの私が受託開発を進めていくにあたって、企画書を活用して後工程における問題発生防止のために工夫した点を紹介させていただきます。
ゲームの受託開発の流れ
企画書の話をする前に、前提としてゲームの受託開発の流れをご説明いたします。ゲームとはいってもソフトウェアであるため、基本は通常のソフトウェア開発の流れとなります。ソフトウェア開発には様々な手法があると思いますが、規模が大きいゲームの受託開発においては契約を分かりやすくするために、期間（いつまでに）と成果物（何をつくるのか）を明確に定めやすいインクリメンタル開発をすることが多いように思います。インクリメンタル開発とは、プリプロダクション版フェーズやα版フェーズといった形で期間と実装内容を定めて、そのフェーズごとに徐々に機能を追加していく形で実装していく方式です。大雑把なイメージとしては、次のような図となります。
インクリメンタル開発では機能ごとに開発していくため、全てが完成したときのUXを確認できるのが最後になり、大きなリスクがあります。また仕様変更があった場合に、細部まで作り込んでいるとその分多くの工数が無駄になってしまうことがあります。
インクリメンタル開発をより深く理解するために、よく比較されるイテレーティブ開発をご紹介いたします。上記のインクリメンタル開発の弱点を克服しようとしたのがイテレーティブ開発です。イテレーティブ開発では最初は最低限の機能しか実装しませんが、徐々に機能を増強したり操作性を高めたりして洗練させていきます。個人的にはゲーム開発においては、全体のUXを把握しながら開発できるこちらの方法がより向いているように思います。大雑把なイメージを示しますと次のような図になります。
インクリメンタル開発の各工程
インクリメンタル開発ではどのように機能開発していくのかを確認してきましたが、続いて工程がどのように進むのかを見ていきましょう。ちょうど五月雨式にウォーターフォール開発を繰り返すイメージで、次の図のような方式となります。
上記の図では、テストは1つの工程として表されています。しかし、実務においては企画から実装までの幅広い工程の結果をテストしていく必要があるため、実際にはテスト工程はいくつかの工程に分かれます。上流の各開発工程に対応させてテスト工程を分割したものをV字モデルといいます。V字モデルを図にすると、次のようになります。
V字の左側が開発工程で、右側がテスト工程となります。各工程では、次のようなことを実施します。
- 企画工程（要求定義）では、「なぜそれをやるのか」という目的（ゴール）を定義し、その要素（機能や施策）によって何を達成したいのかを決めます。
- 設計工程では、企画で決めた要素をどのように作成するのかを決めます。
- 実装工程では、決めた通りにつくります。
- 試験工程では、設計で決めた通りの仕様になっているのかを確認します。
- 検証工程では、企画で決めた目的を達成しているのかを確認します。
今回は特に、この企画工程の成果物である企画書の使い方について取り上げています。
企画工程で目的・ゴールを整理・共有していないと失敗しやすくなる
入社前に私が経験した自社開発プロジェクトにおいては、各機能や施策の目的はディレクターやプランナーの頭の中にあるので、詳細な企画資料がない状態で設計工程から進行していくということがありました。しかし、設計工程で共有されるのが具体的な機能仕様や施策内容だけだった際には、UXを作り込むデザイナーやエンジニアに目的が伝わらずに、ディレクターや担当プランナーが意図したものにならないこともありました。またプランナー間連携においても、例えば企画工程担当と設計工程担当のプランナーが異なるケースでは、企画工程で定めた目的に合わない内容の仕様書が、設計工程で作成されてしまうことがありました。
例えばキャラクターに「超必殺技」という要素を追加するといった場合に、ARPPU向上を目的にキャラを重ねてもらう施策として導入するのか、継続率向上を目的にキャラクターにパラメーター的な個性を付与してデッキ編成に創意工夫の幅を持たせる施策として導入するのかでは作るべき仕様が大きく異なります。しかし、企画工程で目的を定めていなかったり、設計工程担当プランナーがディレクターへの確認を怠ったりすると、キーワードだけで仕様作成が進んでしまって、目的と合わない仕様が作成されてしまうことがあったのです。
顧客と目的・ゴールを握り、後工程で確認できるように資料化する
自社開発にもある程度当てはまると思いますが、特に受託開発で何か要素を新規開発する際には、目的・ゴールを企画工程で企画書にまとめ、顧客と話し合い共通認識を持ってから設計工程以降を進めると社内外での調整がスムーズに行くように思います。企画書にどのKPI向上を目指すのか、あるいはどのような体験をつくろうとしているのかといったことを書いておき、いつでも参照できるようにしておくのです。
社内においては、まず設計工程担当プランナーは企画書を踏まえて仕様書を作成することができるようになります。また仕様書の完成後に、企画工程担当プランナーを含むレビュアーが、その仕様が実装されることで目的・ゴールが達成されるのかという視点で確認できるようになります。このときUXに詳しいデザイナーや、内部設計に通じたエンジニアが含まれていると、目的をより良く実現できる設計を提案してくれるかもしれません。そして仕様書レビューに参加できなかった実装担当のデザイナーやエンジニアも、企画書を読むことで目的を知ることができるため、実装上の内部的な作り込みも、より良くできるかもしれません。
社外、すなわち顧客においては、握った目的・ゴールの内容を、その後の設計工程の成果物であるソフトウェア仕様書や、検証工程で「企画で決めた目的を達成しているのか」を確認していただく際に基準として活用することができます。誰でも数ヵ月前の記憶は曖昧になりがちなので、どういった目的のために何をつくるのかということを定めた企画書を作成して残しておくと、認識違いが起こりにくくなります。
私が参加したプロジェクトでは、該当フェーズで新規実装した要素が多かったので、ゴール設定資料といった形で①新規実装要素、②その目的、③目的を達成したか否か、の３点を一覧にまとめてご確認いただくことで、比較的スムーズに検収していただくことができたと思います。具体的には次のようなイメージの表を用意し、顧客と該当フェーズで新規開発した要素について認識合わせをさせていただいた形です。
最後に
トヨタ式の鉄則として「前工程は神様、後工程はお客様」というものがあります。特にゲーム受託開発では契約の分かりやすさから、インクリメンタルなウォーターフォール開発に近い方式を採用することが多そうなゆえに、この鉄則が当てはまりやすいように思います。よってディレクターや企画工程を担当するプランナーは、後工程に大きく影響することを理解し、企画（要求定義、要件定義）の品質を高めていくことが求められるように思っています。
またゲーム開発においては実際にプレイしてみないとUXが分からない部分も少なくなく、顧客からインクリメンタル開発的な契約でありながらイテレーティブ開発のようなご要望をいただくこともあります。そういった個所を先回りして検知し、AdobeXDによるモックで念入りに確認したり、あらかじめブラッシュアップ期間に修正していくと方針を決めておいたりする先見性も必要になると思います。
私自身、過去の成功体験が異なるチームメンバーや顧客とどのように認識を合わせながら進めていくべきかを模索しながら進めた方法論となりますが、この記事が読んでいただいた方の一助になれば幸いです。
