サービスを開始する前から、クローズする事を考えるなんてなんて奴だと、
思われる方もいるかと思いますが、
一度クローズ⇒リリースに向かってをシミュレーションする事で対応抜け漏れが少なくなります。
クローズ事前
- ユーザへの告知
- 関係者への連絡
- 決済処理の停止
- プラットフォームのアイテム販売停止
- プロジェクトに関わるメンバーフォロー
- sorryページの用意と、リダイレクトさせる期間方針の決定
- 返金方針の決定
クローズ当日
- 対象サービスへのアクセス制限、sorryページへのリダイレクト
- ユーザへの終了完了連絡
- 関係者への連絡
クローズ後
- 関連サービスの停止
- データの移行、削除
- 返金
いくつか上げてみましたが、クローズ時だけ必要な機能でしょうか？
（他にも色々やる事があると思いますが）
決まってからやるべき事と決まる前からもできる項目があるかと思いますが、
告知、処理の制限などはサービス中でも必要な事があるかもしれません。
この時開発メンバーだけでなく、どんな人が関わる必要があるか考えられます。
管理部や経理部といった開発には直接関係の無い部署の人と開発開始時に話せると良いですね。
規約部分とか後手になりがちなので、最初に解決しておいた方が良いです。
（返金額の小数点以下の切り捨て、切り上げ等）
環境縮小
- サーバのスケール変更（イン、ダウン）
- 人員の削減、担当者の変更
- 一部機能の制限
人員の削減、担当者の変更などはよくある事ですよね。
担当が誰に変わってもコンフル等に初期構築手順等まとめられていれば、すぐに業務が始められると思います。
一部機能の制限は、全体のメンテナンス以外でも、各項目ごとにメンテナンスができるようになっている事で
サービス中でも問題発生した際に使用する事ができます。
決済で障害が発生したのであれば、購入メニューをメンテナンスにするなど。
IT監査
- ガチャの確率提出
- 管理画面のアクセスユーザ制御（追加・変更・削除）
- 管理者からの仮想通貨の付与、減算
- ログ提出（確立を誰がどう変えた？誰が付与した？減算した？）
- リリースフロー
- 権限管理
サービス時に不要でしょうか？
ガチャの確率が想定通りになっているかプランナーさんは当然知りたいですよね。
必要か？と言わないと必要と言わない人が多いですが。
サービスが忙しくなっているときに、なかなか準備が面倒なものですので、
後回しにせずしっかりと用意したほうが良いですね。
リリースフロー、権限管理などは、決済が絡むサービスでないと監査からは求められませんが
しっかりと準備しておくと安心です。
サービスが盛り上がってきて大きな広告投下時
- サーバのスケール変更（アウト、アップ）
- サービスのメンテナンスIn、Out
- メンテナンス時の突破ユーザー管理
- 社内IPからの突破の有無
サービス開始時に不要でしょうか？そんな事ないですよね。全て必要です。
ただ、サービスの主なコンテンツ、ゲームならゲーム自体の構築が最も大切な為忘れがちになるだけですよね。
サービスリリース
ここはいつも考えている通り必要なコンテンツを頑張って用意します。
この様にクローズ→リリースの流れで一度考えてみると、
完璧に準備してきたと思っても意外と対応漏れが見つかるものです。