「アル」というマンガサービスをやっているのですが・・・。

基本的に「無料のマンガとか新刊を便利に探せる」というところの機能が多いんですね。で、ここに「マンガをもっと楽しむためのものがないか・・・」というので、クイズ機能を試していたりします。

で、僕とかは20年くらいインターネットサービスを作っているので、まあこういってはなんですが、知見がめちゃくちゃあるんですね。「こうすれば数字よくなるわ」みたいなのがあるわけです。また、人間心理などについてたくさんの本を読んでいるので、データを見なくても全然精度高くできるんやで・・・、、、

と言いたいところなんですが、実際は、もう死ぬほど外します。びっくりします。人間、そんなに単純なものではないので、「僕は人間を知り尽くしている」みたいな感じで、アイデアを出しても数字が悪いことなんてざらです。

なので、こういう新機能を試す時には、ひたすらに数字を見ながら改善をする必要があります。雰囲気や思い込みはマジで当てにならない。

ただ「数字を見ながら改善する」というのはみんなよく聞くと思うんですが、そのやり方の超各論はあまり公開されないですよね。なので、「アル開発室」では、そのやり方と、実際の結果を紹介していきたいと思います。

基本編 : 毎日0時にリリースする

まず、基本方針として「毎日0時に必ずリリースをする」というのは必須です。

このあたりは、回した改善の「量 * 質 * 集めたユーザ数」が勝負となるので、1日1回の更新と、2日に1度の更新とでは、2倍近い差がついてしまうのです。なので、毎日やる。

さらに、土日祝日にもリリースできるよう、金曜日までに土日分の施策branchを仕込んでおくのがよかったです。

ちなみに、0時にやる理由としては、日中デプロイにすると、計測するツール側のTimezone、Database側のTimezone、実行しているサーバ側のTimezone･･･などが混在してくると、Aデータは+9時間して、Bの方は-15時間して、、などが発生して無駄なところで頭が混乱してしまうので、0時が一番ラクかなーと思っています。計測結果の管理も「2020/02/20の結果」としてわかりやすいですしね。

基本編：追う数字の明確化

で、何の数字を見るか・・・？も大事なんですが、クイズの場合、「Viral係数」を見まくりました。

ざっくりいうと、バイラル係数が1だと、「1人やったら1人連れてきてくれる」ということになるので、ユーザー数が増え続けるのですね。そこまでいけると最高なので、まず1以上を目指します。

で、クイズの場合は因数分解すると以下のようになります。

この中でも、「クイズを開始する率」「クイズを完了する率」「そのクイズをシェアする率」の3つあたりが最重要になってくるので、そこを中心に追っています。

で、これはバーーンとリリースを打つ前に、広告を打って500-1000人くらいに試してもらって、その結果をみて、また変える・・・というのをやる感じです。

基本編：リリースノート管理

そして、数字が変動したときなどに、具体的になにを変更したのかを辿れるようにするために、わかりやすく残しておくのがいいです。

Google Slidesで、さくっとキャプチャを残すなどがわかりやすかったです。

最低限、以下を満たすとよいかなーと。

- リリースのバージョニング(ver20200205など日付などでも)
- リリース後のUIスナップショット画像
- 具体的に変更したリリース内容

基本編：やらないこと

やらないことも大事です。

「1つの施策に時間を掛けすぎてしまうこと」はやりがちなんですが、アンチパターンです。

1つ1つの施策に期待を込めて作り込みすぎたり、まだ出す前の1施策についてより良くするために議論を繰り返したり･･･というのは時間の無駄です。特に、議論は対して前に進まないことが多いです。

機能の妥当性を議論するよりも、超おふざけで、遊びのような感じでアイデアを出して、速攻で実装して1日後に結果を観たほうがリソースは節約できます。

企画・議論段階で「これは絶対いける！」と思ったものもことごとく外すことが多いので、必要最低水準のクオリティを満たしたのであればリリースして計測するのがいいかなーと。

効果がなさそうなことが分かれば即捨てるし、その施策の方針が良さそうなことが分かれば、後で作り直すなり改善を繰り返していくことができます。

また、「同一指標に影響しそうな施策を、同日に2つ以上リリースはしない」というのも大事です。

例えば、クイズでいうと、開始画面でボタンの色と、開始ページのバナーを同時に変えた結果に開始率が向上したとします。（これ自体は多変量テストという手法）。

その時、開始ページのボタンの色が要因なのかバナーを変えたことが要因で上がったのか、という切り分けができなくなると、次につなげづらいのですね。

結果的に開始率が向上しているので良いじゃないか、、と思う人もいるかもしれませんが、具体的には、「ボタンの色を変えることによって数字が上がった」ことが分かったのであれば、赤色ではどうか？薄紅色では？みたいな感じで深堀りした上で施策を繰り返すことができなくなっちゃうのです。

毎日リリースサイクルを回せている状態であれば、焦らなくてもどうせ1日待てば次の施策がリリースできるので、日を分けてリリースするほうがいいなと思っています。

結果編：よかった施策

というわけで、実際に、クイズ機能で試してよかったもの、悪かったものを共有します。

--- 😎 告知はじまり 😎 ---

ここから先は有料になります。単発だと300円ですが、「アル開発室(note版)」に入っていただくと、こんな感じの投稿や、週に1〜2本、コラム的なものが届きます。

どちらを選んでいただいても大丈夫です！

アル開発室をなんでやっているかというと「開発の裏側を共有することで、サービスに愛着を持ってもらう」「まだ稼げないサービスでもお金をいただける場を作ることで、継続的に続けられるようにする」という目的でやっています。読者のみなさんには「一つのサービスの開発の裏側を物語としてリアルタイムで見ることで、物語を読むこと自体の楽しみや、いろいろな気付きや得れる」というのを提供したいなと思っています！

--- 😎 告知おわり 😎 ---

クイズの結果画面で、紙吹雪を出す

本当に膨大な数のテストをしているのですが、効果が一番高かったのが「クイズの完了画面で、紙吹雪をアニメで出す」です。

かなり悪ふざけでやった施策なので、数字がよかったのがびっくりしたのですが・・・。