もう2年ほど前でしょうか。以前いたアプリチームで年末休暇に課題が出されました。それは新しい施策を考えるでした。
ソシャゲは常に新しい施策や機能を追加していく事が多いと思います。このチームも正にそれで、新しい施策、機能が必要となっていました。

自分は施策を考えるのは得意ではなかったのですが、なにがいいかなーと考えてしました。
するとふと思い出した事がありました。それは、ディレクターがやりたがっていた新規ガチャでした。

休みに入る一ヶ月ほど前でしょうか。ディレクターがこうつぶやいてました**「引き直しガチャやってみたいんだよねー」**...

引き直しガチャとは？

基本的にガチャは一度引いて出たアイテムはプレゼントボックスに送られてガチャは終了します。引き直しがガチャは、決まった回数までは引き直す事が出来るので、気に入ったアイテムが出るまでは引き直しが出来ます。

実はこの一ヶ月前は新婚旅行に行く直前で、その話をディレクターから聞いた時に、「うーんソース見て出来るかどうか調べてみますね〜」と軽い返事で終わっていました。しかし、やれるかちゃんと調べておかないと出来る・出来ないは答えられないので、新婚旅行中にDBのテーブル設計とソースを改修するポイントを調べて置きました。
旅行から帰ってきたときははっきりとした答えは出さずにいましたが、なんとなく出来そうくらいは答えたような覚えがあります。

そして、その課題が出された時に「よし！家でがっつり実装したろ！」と決めました。実装出来る自信もありましたし、なによりディレクターがやってみたかった事をすぐにでもやれる状態を作ってビックリさせたかったという気持ちもありました。
実装は2日ほどで出来ましたが、休みが終わる2日前という土壇場ぶり（笑）

課題を発表する当日は、確か会議室を借りて、考えてきた人がリードディレクター、リードエンジニア、プロデューサーの前で発表するというスタイルでした。他のメンバーは新規イベントを考えてきたりしており、そのほとんどがKeynoteなどのスライド系でした。
自分はディレクターから聞いていた仕様を箇条書きで書いた簡単なスライドを作り、発表をしました。

その中の一枚に、実装してテスト環境にデプロイ済みですの一言を書きました。結果即採用で、テストしたらリリースしようという話になりました。（実際はテストしてもらったときに引き直せないという致命的なバグが出ましたが、すぐに修正しました（笑）

そして、リリースまではいままで時間が無いことを理由にして出来なかったコードレビューをエンジニアで行いました。実装がほぼ終わっており時間的に余裕があったので、エンジニアに声を掛けて、コードレビューをしました。その中で、行ロック漏れが発覚したりと致命的な問題に気づく事が出来ました。コードレビュー大事！

そしてリリース

新規テーブルがあったので、DBのマイグレートを行い、そしてデプロイ！するとデプロイ直後にバグを発見...メンテナンス中の出来事だったので、メンテ開ける前に修正する事が出来ました。ガチャの期間としては確か一週間ほどでしたが、その間はほとんどバグも出ずに無事乗り切る事が出来ました。
ただ、残念ながら引き直しガチャは大ヒットまではいかず、それ以降再び施策に入る事はありませんでした。

この話は残念な話ではない

「なんだ売れなかったのか」「残念だったね」という話ではありません。むしろ大きく得たものがありました。それは、**「このゲームのユーザは引き直しガチャに大きなメリットを感じていない可能性が高い」**それを工数を掛けず（営業日的に）分かった事は大きい。もちろんガチャで排出されるアイテムやキャラクターの引きが弱かったという可能性もありますけどね。

これで得た経験は**「フィードバックを素早く得ること」**です。はっきり言ってしまえば、施策がユーザに喜んでもらえるかなんて、リリースしてみないとわかりません。仮説を立てる事はとても大事ですが、それが本当にそうなのか？は実際にリリースしてみないと分からないという事です。

最近読んでいる本に「継続的デリバリー」があります。この本はフィードバックを素早く得る事が大事で、それを得る為にデプロイやテスト、環境構築を「簡単に」「素早く」やってしまおうという話です。（間違った解釈をしているかもしれませんので、ツッコミお願いします）
この考えはとても共感出来るもので、自分は引き直しガチャ実装で似たような経験が出来たと思っています。そして、一部分のみ自動化するのではなく、全体を自動化するように意識して、チームをデザインしなければならないと気づきました。それは今後の課題ですが。

いままではサーバ自動化うぇーいと考えていましたが、ふと昔の経験を思い出してみると「誰かからの結果を素早く知る事が大事」という事を思い出しました。いま頭にあるのは、サーバ自動化うぇーいではなく、アプリチームが素早くフィードバックを得るためになにをしなければならないのか？を考えるようになりました。

サーバ構築が楽になっても、デプロイするアプリチームが大変では、フィードバックまで時間が掛かってしまいまし、デプロイが複雑である為にデプロイ時にミスが発生したりなどがあるのはとても問題です。
継続的デリバリー、CIが回る環境を作るには、インフラ、アプリで作業領域を分けるのではなく、お互いが1つのチームとして動いていく必要があると考えています。

本番リリースで心臓が痛くなったり、サーバ構築が複雑で時間が掛かったりなんてことはさっさと自動化させて楽して終わらせてしまい、ユーザからのフィードバックを得ましょうよ！それがきっとやりがいに繋がると思います。

この記事は自分のブログを転載しています。