サービス

サービス開発はクローズからリリースに向かっても一度考えるべき

サービスを開始する前から、クローズする事を考えるなんてなんて奴だと、
思われる方もいるかと思いますが、
一度クローズ⇒リリースに向かってをシミュレーションする事で対応抜け漏れが少なくなります。

クローズ

  • 告知(サービス内、sns等)
  • 返金
  • 決済処理を含めた、処理の制限など
  • プラットフォームのアイテム停止

いくつか上げてみましたが、クローズ時だけ必要な機能でしょうか?
(他にも色々やる事があると思いますが)
告知、処理の制限などはサービス中でも必要な事があるかもしれません。
この時開発メンバーだけでなく、どんな人が関わる必要があるか考えられます。
管理部や経理部といった開発には直接関係の無い部署の人と開発開始時に話せると良いですね。
規約部分とか後手になりがちなので、最初に解決しておいた方が良いです。
(返金額の小数点以下の切り捨て、切り上げ等)

環境縮小

  • サーバのスケールイン、スケールダウン
  • 人員の削減、担当者の変更

人員の削減、担当者の変更などはよくある事ですよね。
担当が誰に変わってもコンフル等に初期構築手順等まとめられていれば、すぐに業務が始められると思います。

IT監査

  • ガチャの確率提出
  • 管理画面のアクセスユーザ制御(追加・変更・削除)
  • 管理者からの仮想通貨の付与、減算
  • ログ提出(確立を誰がどう変えた?誰が付与した?減算した?)

サービス時に不要でしょうか?
ガチャの確率が想定通りになっているかプランナーさんは当然知りたいですよね。
必要か?と言わないと必要と言わない人が多いですが。
サービスが忙しくなっているときに、なかなか準備が面倒なものですので、
後回しにせずしっかりと用意したほうが良いですね。

サービスが盛り上がってきて大きな広告投下時

  • サーバのスケールアウト、スケールアップ
  • サービスのメンテナンスIn、Out
  • メンテナンス時の突破ユーザー管理
  • 社内IPからの突破の有無

サービス開始時に不要でしょうか?そんな事ないですよね。全て必要です。
ただ、サービスの主なコンテンツ、ゲームならゲーム自体の構築が最も大切な為忘れがちになるだけですよね。

サービスリリース

ここはいつも考えている通り必要なコンテンツを頑張って用意します。

この様にクローズ→リリースの流れで一度考えてみると、
完璧に準備してきたと思っても意外と対応漏れが見つかるものです。