本記事は、サムザップ Advent Calendar 2022 の12/14の記事です。

はじめに

昨今、アプリ市場の規模拡大に伴い、参入企業も増えており、たくさんのアプリで市場が溢れています。
また、新規Appがリリースされる頻度も増え、サービス終了に至ってしまうケースも最近は増えているのではないかと思います。
会社ブランドの維持だったり、返金対応の法的側面でしっかりとサービス終了対応されている所が多いかと思いますが、その対応に関する情報が探してもあまり無かったりと、手探りながら進めて苦労したという方が多いのではないでしょうか。

そこで、弊社サムザップでの"おくりびと"として、下記いろんな方針に応じた対応を経て得た情報をTipsとして公開出来る範囲で書きました。

『戦国炎舞 -KIZNA -』はKindle版のみサービス終了し、Android/iOS版は継続運用しているケースになります。
『D_CIDE TRAUMEREI』はiOS/Android全てのプラットフォームでのサービス終了をしたケースになります。
『ロンドン迷宮譚』はiOS/Android全てのプラットフォームでのサービス終了し、オフライン版での配信継続をしたケースになります。

※本記事は"おくりびと"としてのTipsをまとめ、法的な情報は専門外なので参考程度として、各サービス側での責任で最終判断お願いします。あらかじめご了承ください。

"おくりびと"の極意 - ゲームApp編 -

一番に想像が付きやすいゲームApp側の対応についてまとめます。

スケジュール確認で3つのチェックポイントを抑える

スケジュール確認で重要なのは、下記の日時設定になります。これらがスケジュールに落とし込まれているか確認して下さい。

課金停止
サービス終了
返金申請の受付期間

各サービスの方針に応じて、柔軟なスケジュール設定が求められると思いますので、ここでは基本方針として参考程度に思っていただければと思います。

スケジュール確認で抑えるポイントその１「課金停止」

まず最初に確認するのは「課金停止」になります。ここでいう課金停止は、ゲーム内通貨の変動が起きない状態の事を示します。
なので、課金が出来ない状態にするだけでは不十分で、ゲーム内通貨の"消費"も塞いでいる日程もスケジュールとして落とし込んでおく事をお勧めします。

ただ、課金停止の日時とゲーム内通貨の変動が起こらない状態にする日時は、必ずしも一緒にしなくても良いので、各サービスでご判断ください。

スケジュール確認で抑えるポイントその２「サービス終了」

ここでいう「サービス終了」はゲームプレイが出来ない状態のことを示し、タイトル画面やお問い合わせくらいは確認出来る状態になります。
このタイミングがゲーム内通貨の変動が起こらない状態として設定する感じでも良いかと思います。

スケジュール確認で抑えるポイントその３「返金申請の受付期間」

基本的には、ゲーム内通貨の変動が起こらない状態になってから、返金申請が開始するスケジュール感が良いと思います。
ユーザは返金申請した時のゲーム内通貨を確認して、おおよその返金額を予想されると想像されます。返金申請後もゲーム内通貨の変動が起きる状態であると、どのタイミングでの返金額計上なのかフワフワしてしまうからです。お知らせにも、どのタイミングでの有償通貨計上による返金額決定なのかを明記すると、より良いかと思います。

また、ここで必要になってくるのは返金申請の受付期間の確保になります。
返金申請の受付開始から終了まで、60日以上必要だったかと思うので、確保されているか確認します。

「はじめに」でもふれましたが、法的な情報は専門外で、この「60日」と言う数字は参考程度にして各サービスを運営する会社の法務部に確認いただくのが良いかと思います。

ユーザ目線で思考する

先に述べた「スケジュール確認で抑えるポイント」をベースに話を進めます。
スケジュール確認で重要な3つの日程から逆算して、ゲーム内やTwitterなどのSNSにてお知らせを行うのは最低限とし、説明を省きます。

返金申請で必要な情報の確認

後述するフロー確認の前に、返金申請で必要な情報を整理します。
個人情報は持たないように返金対応自体は外部に委託するケースを想定して話します。
なので、個人情報系の項目は省き、ここで必要なのは返金申請者が所有していたアカウントなのかを特定する情報であるとします。
最低限必要な項目としては、下記が想定されます。

アカウントID(アカウント所有者しか知り得ないユニークなID)
所持していた有償通貨

これに加え、入力ミスなどで特定が難しい場合のフォロー用に「ユーザ名」「所持している無償通貨」などで、特定出来るようにしておくのも予め想定しておきます。

しかし、ここで注意しないといけないのが、この「アカウントID」がフレンド機能などで他者へオープンな情報になっている場合です。
他者へオープンな情報は別の方が不正に申請する事が出来てしまうので、この場合は「アカウントID」をそのまま使用するのではなく、返金用のクローズドなユニークIDとして発行し、アカウント所有者にしか見えない状態にする必要があります。
これに対する対応期間も追加で必要となるので、事前に確認しておくとスムーズかと思います。

ユーザが返金申請するに至るまでのフロー確認

基本的にサービス終了してから返金申請期間になるケースが多いかと思うので、そのケースでの話を書きます。

当たり前ですが、返金申請が必要な方はゲームを利用していた課金ユーザが対象になります。
なので、不正な返金申請を抑えるために申請フォームへの導線はゲーム内からのみが良いかと思いますが、各サービスの方針に応じて、柔軟に思考してください。

返金申請期間中はゲームプレイが出来ない状態である為、タイトルからの塞いだゲームプレイへの遷移を返金申請フローに活用します。
このまま、返金申請フォームへ飛ばしても良いのですが、ワンクッションおいた方がユーザ目線で考えると良いかなと思います。

タイトル > [中間ページ] > 返金申請フォーム

このワンクッション挟んだ中間ページで、「サービス終了に関して/返金申請に関して」の情報やユーザの返金申請に必要な情報まとめ、入力ミス軽減の為のIDコピー機能があると、より親切かと思います。
こういった対応もあると考えると、課金停止前に対応しないといけない項目を事前情報として知っておくことの重要性がご理解いただけるかと思います。

最後に

ひとくちに"サービス終了"といっても進める上で必要な事前対応項目やそれを踏まえたスケジュール感が見えている状態になっていると、よりスムーズな"おくりびと"対応が出来るかと思います。

"おくりびと"としてのゲームApp側の極意を記事にまとめましたが、公式サイトやそれ以外の部分・今回省いたゲームApp側のより深掘りした内容（AWS/GCP/配信プラットフォームのストア周り）も書けそうな気がしているので、どこかのタイミングでまとめられたら良いなと思いました。

本記事で、少しでも"おくりびと"としての対応がスムーズに進められるように活用いただければと思います。