長期運用アプリゲームにおいて、仕様作成の際にあらかじめ決めておきたい7項目

本記事はCraft Egg Advent Calendar 2022の12月11日の記事です。

はじめに

株式会社Craft Eggでプランナー業務を担当しております野部です。

ゲーム開発というのはプロジェクト単位で役割分担から職種内のタスクまで、同じ「プランナー」という職種名でもタイトル毎にぜんぜん違うというのが当たり前かと思います。

その中で「プランナー」にとって「比較的共通している業務となると、施策・機能の仕様作成でしょうか。おおまかにはプランナーが施策、または機能の仕様を作成し(施策を実現するために新機能が必要になることももちろんあります)、エンジニアにその仕様に基づいた実装をしてもらうのがアプリゲームの業務フローかと思われます。

弊社で一つのタイトルを5年以上運用していく中で、施策・機能の仕様書を作成し、エンジニアに実装してもらった後、その後の運用で「これはあらかじめ仕様として決めておけば良かった」と思うようなことがしばしばありました。そこで本記事ではそんな「あらかじめ決めておきたい項目」を抜き出し、言語化してみました。ゲーム開発においてはだいたいどんな施策・プロジェクトでも当てはまるのではないかと思っていますので、参考になれば幸いです。

仕様作成の際にあらかじめ決めておきたい7項目

①開催頻度はどれくらいか

施策とそれを実現するための機能をの追加するにあたって、一番最初に気にしたいポイントです。極端な話、「未来永劫同じことをやる予定はないので、一回こっきりの対応でいいです」と「今後も何回か開催する予定があるので、ある程度機能の使い回しができるようにしておいてください」ではエンジニアの考慮することが変わってきますし、「これは年一回の行事に合わせた施策なので、来年の今ごろにまた使うかなと思います」と「来月にはもう使う予定あります」ではまた対応が変わってくる部分も出てきます。

「うるう年の2月29日にこういう機能を実施したいです。次に使うのは4年後です」という話になったならば「4年経ったらアプリの中身も様変わりしているだろうし、次もまた1から作り直すことになる前提で設計しよう」ということも十分ありえます。

②データだけでどこまで変更可能にしておくか

同じ施策で報酬を変えたいです、あるいは夏に「水着キャンペーン」として実施した施策を冬には「クリスマスキャンペーン」としてUIの飾り付け等を変えて実施したいです、こういった依頼は「季節性の行事」「前回開催時のお客さま反響を踏まえた内容アップデート」が基本となるアプリゲームでは頻出するかと思います。

その際に何をどれだけ変更できるようにして欲しいのかをエンジニアにはっきり依頼し、プランナーの側でも「何ができるか」「何ができないか」の前提を把握しておくことで、施策の円滑な立案と実施ができるようになります。

また、何らかの利用回数制限がある施策では、回数のリセットはする予定があるかどうか、リセットする場合はどのようにそれを実現するかをエンジニアに相談しておくことで後々の運用の工数を下げられる場合があります。

③更新方法はどうするか

当たり前ですが何らかの施策をお客さまに提供するためには、単に機能開発をするだけでなく、お客さまがゲームを遊んでいる端末へその内容を反映することが必要です。

たとえばアプリのアップデート直後から利用してほしい施策についてはアップデートにあわせてサーバーへデータを反映することで終わることもありますが、なんらかの特定の日付とともに開始してほしい施策の場合は、データの更新状況とは別に、施策そのものを開始するためのタイマーを設定できるようにする等の対応を依頼します。

アプリをアップデートしてすぐに体験してほしいし、一定時刻までは利用できないようにしたい(お客さまに横並びで一斉に新しい機能を体験してほしい)場合は、アップデートそのものはゲームの全体メンテナンス中に行い、メンテナンスの終了時刻をもってお客さまの利用開始時刻とする、というパターンもあります。

④どう始まり、どう終わるか

「更新方法はどうするか」に絡む部分でもありますが、運用中のゲームで施策を追加する場合、当然ながら「施策を実施していない時」と「施策を実施している時」の境界になるタイミングが発生します。

もともとゲーム内にログインしていたお客さまは施策開始時にログイン状況がどうなるのか、施策の終了時刻をまたぐ形でなにかアクションしたお客さまにどう対応するか、というのは「開催中に何をするか」を作っている時点では漏れがちなので、あらかじめパターン分けをしておくとエンジニアやデバッグ担当の方々が誤解や手戻りなく仕事をすることができます。

⑤同種の施策の重複を許容するか

「A」というキャンペーンを開催中に、「B」という同種の別のキャンペーンを開催できるかどうかという話です。

ログインボーナスとかだとイメージがつかみやすいかと思いますが、例えば新規に画面を実装して期間中その画面をハブに細かい施策にアクセスできるようにしたい場合(期間限定系の施策だとありがちですね)、当該画面が同時に複数利用できてほしい場合はそれをエンジニアにお伝えして、内部的にそれぞれの画面を区別する実装をする、といった相談が必要になります。

⑥他の施策との兼ね合いはどうするか

アプリゲーム、特に数年以上運用されているゲームでは「施策が一つだけ実施されている」という状況はかなり稀で、おおよそ常時何らかの施策が複数実施されている状況かと思います。

同時に実施されうる施策が複数ある場合には、それぞれについてUI上の表示優先順位等を決めておくことで、表示物の優先順位違いによる手もどりを減らせます。

⑦トラブルが起きたときはどう対処するか

いわゆる機能メンテナンスの必要性有無の話になります。

施策をリリースしたはいいが本番で不具合が起きてしまった、という場合には一旦施策を止める等の判断が求められるわけですが、施策一つのために全体メンテナンス＝お客さまが一切ゲームをプレイできなくなるのと機能メンテナンス＝問題のある機能以外は遊べる状態にするのとでは、お客さまへの影響値はもちろんのこと運営上のダメージも変わってきます。

もちろん、不具合が起きたとしてもお客さまに害が少ないと想定される施策または機能の場合は、不具合が出たとしてもゲーム全体としては通常運営を続ける想定で機能単位でのメンテナンス機能を依頼しない場合もあります。（逆に言えば、仕様の見積もりをする段階で「トラブルがあったときにメンテナンスをするべき施策なのかどうか」の位置付けは決まっていたほうが望ましいです。）

まとめ

本記事では、私が日々のプランナー業務でぼんやり考慮していた事項を改めて言語化して書いてみました。
アプリゲームの運用にあたっては、機能というのは基本的に実装して終わりではなく「リリース後の運用での調整」こそがアプリの評価に関わってくる局面が多いです。機能の仕様書作成に当たっては「実装時点でどう動くか」だけでなく「今後どのように内容が追加されていくか」といった「点」ではなく「線」での挙動想定をすることで、より効率的に施策の立案やエンジニアの実装対応を行うことができるかと思われます。

いざ言語化してみるとなんてこと無い考慮項目ばかりですが、この記事が少しでも誰かのお役に立てれば幸いです。