遊撃エンジニアの @anoworl です。普段はバックエンドやインフラの開発を中心に、ライブ動画配信の仕組みをAWS MediaLiveで構築したり年末年初のCM放映に伴う負荷対策をしたり…今は採用や2B向けのSaaSも開発しています。CMに出演したローラさんがオフィスに来たのは良い思い出です。
だんだんと社員が増えて会社っぽくなってきた弊社では採用活動に力を入れているのですが、その中でお話するとウケが良かった話をここでは紹介したいと思います。
それは弊社のミッションである「ユーザが熱狂するプロダクトを再現性をもって創造する」に直結する、チームの文化です。
そこでこの記事では「使われないアプリを作らない」ために私達が愚直にやっている方法を記します。
アプリを作ると一口に言っても「新規に作る場合」「既存のものを改善していく場合」がありますが、ここでは後者「既存のアプリを改善する場合」に焦点を当てて話します。
2つのやっていること
私達が「使われないアプリを作らない」ためにやっていることは大きく2つあります。
どちらも当たり前のことではあるのですが、実際に開発フローへ組み込もうとすると一筋縄ではいかなかったりします。
例えば…
現状の分析が行われないまま機能が開発され、結局その機能は使われなかったり…
改善後の分析をしなかったため良くない改善（改悪？）がいつまでもアプリに残ったり…
ここでは私達の方法を共有していきます。よろしければみなさんの方法も教えてください！
なお以下では新機能の開発や既存機能の改修含めて、アプリの 改善 と記します。
改善例
以下はこれから説明する方法にしたがって実際に改善した「人気投稿が表示される画面」の改善例です。
この時は人気投稿のレコメンドロジックを改善することで「この画面からクチコミへの遷移率アップ」や「全体の滞在時間アップ」を達成し、ちゃんと使われる機能を作ることができました。
次の項からはこちらの例を使って、実際にやっていることを説明していきます。
「ちゃんと使われるか」予め分析すること
私達のチームでは改善の起案者が以下のテンプレートを利用してGithubのIssueを作成します（流し見で大丈夫です）。
`*` は作成者or優先度変更者が必ず埋めてください ### ユーザーの抱える問題 - 簡潔に説明* - スクショ - Redashリンク ### インパクト想定 - 対象: ヘビーユーザー / 全ユーザー / 他特定ユーザー（ex: 投稿ユーザー）* - 対象画面のDAUU: * - 使用頻度: daily / weekly / monthly * - 改善する数値（Epic）: * - 数値の伸び幅（10倍改善？数%改善？）: ◯倍 もしくは ◯% ### 問題の解決策はなにか - 簡潔に説明* - モック - スクショ ### 検証内容 - AB必要か* : yes / no - 取りたいイベント --- ### 実装 - 各RepositoryのIssue/PRで本Issueを参照すること - コメントにてRedashの検証用URLを貼る
ここで取り上げたいのは「インパクト想定」の部分です。
私達のチームでは「使われないアプリを作らない」ために、改善の起案時に必ずインパクト想定を行います。
ここで例として「人気タブのレコメンドロジック改善」のIssueを見てみましょう。
### インパクト想定 - 対象: 全ユーザー - 対象画面のDAUU: ○○ DAUU - 使用頻度: daily - 改善する数値（Epic）: 24h以内平均閲覧数, 閲覧ユーザRR, おすすめタブ滞在時間 - 数値の伸び幅（10倍改善？数%改善？）: 5〜10%
インパクトの大きさを不確実ではありますが見積もり、その上で開発工数優先順位付けをし開発を行っています。
ユーザの行動ログを分析してインパクトを見積もる
上記の項目を埋めるためには、ユーザの行動ログから任意の軸でデータを取り出す必要があります。
私達はRedshiftにユーザの行動ログを格納しており、それをRedash*1経由でSQLを使い数値を取り出すことで、上記項目を埋めています。
そのため全ての開発者やデザイナーはもちろん、マーケチームやセールスチームもSQLを書きRedash経由でデータを取り出せる環境を作っています。
なお、データを貯めていくアーキテクチャについては以下の記事に詳しくあるので、ご興味のある方はご覧ください。
定量的な認識を揃え、効果の高い所から手を付ける
私達は全員が数字を自分の手で出せるようにすることで、それをベースとして議論を行い、優先順位付けを行っています*2。
情報格差をチームメンバー間で作らないことで、定量的なデータを無視して開発が進んでしまうことを防いでいます。
私達はこれらの方法でインパクトを 想定 し、なおかつそれを 活かす 環境を作ることで「使われない」機能を作ってしまうリスクを軽減しています*3。
「ちゃんと使われたか」確認すること
私達のチームでは機能をリリースした際に「ちゃんと使われているか」「良い結果を生んでいるか」必ず確認し、もしそうなっていなければ機能の追加を取りやめます。
これによりアプリが改悪されることを防いでいます。ここではその方法について記します。
機能追加時には必ずABテストを行う
私達は機能追加・改善をおこなった際には必ずABテストを行っています。
ユーザをランダムに「新規機能を使える群」「新規機能を使えない群」に分け、それぞれのデータを前述のRedashで分析します。以下が分析例です。
このグラフは人気タブのCTRの時系列グラフで、1が機能を使える群だったので、この時の新機能は有効でした。このグラフを作成することに加え仮説検定を行い判断をしています。
もちろん悪くなることもあり、その場合は機能を戻したりします。一番多いのは差が見られないときで、その際は定性的な情報などを考慮し、最終的に判断します。
他の人間が検証できるようにする
上記の分析はIssueにRedashのURLを貼ることで、他の人間が追試験できるようにしています。
定量で測ると一口に言っても、計測の方法やデータの解釈は多様で、一人の人間だけで判断するのには限界があります。そこで私達は他のメンバーが「おや？」と思った際には、違う軸で再試験できるようにテスト結果やその過程を共有しています。
これにより一人のメンバーの中で検証や判断が閉じてしまい、見落としや勘違いが起こるリスクを下げています*4。
ABテストが終わったことを確認してからIssueをクローズする
人間の心は弱いので上記のことを志しても、なあなあになって結局できないことがあります。
人間の弱さは仕組みでカバーすべきなので、弊社は簡単な解決策ですが、カンバンに「検証中」という列を設けています。
Issueは必ず「検証中」で検証しなければClosedに移せないというルールにしています。なおかつ週次の定例で検証結果を共有するようにしており、否が応でも検証という過程は飛ばせないようにしています（そもそもメンバーは重要性を認識しているので、こっそり飛ばそうという人もいないのですが…）。
こうして人間の弱さをカバーすることで、「使われる」アプリを作ろうと努力しています。
おわりに
こうやって私達は改善前後の検証を定量的に行うことで「使われないアプリを作らない」ように心がけています。
エンジニア的に言うなら「 推測するな、計測せよ 」です。私達はアプリを改善するときも、それを実践しています*5。
「使われるアプリ」作っていきましょう！
We are Hiring
AppBrewでは定量・定性に真摯に向き合ってプロダクトを開発したいメンバーを募集しています！
ご興味がある方は転職ドラフトやWantedlyよりぜひご応募ください！
*1:SQLを書くことでDBから数値を取り出し、それをビジュアライズできるダッシュボードツールです。ウェブブラウザで利用できます。Redash公式サイト
*2:もちろん定性も重要視し、ユーザインタビューやアプリレビュー、アプリ内やSNS上のユーザの反応などは誰でもすぐに見られるよう社内QiitaやSlackにまとまっています。
*3:よくあるQ&Aとして「細かな改善だけに終止し部分最適することだけに陥ってしまうのでは？」というものがあります。確かに開発工数が少なく効果が高そうなものを選んでいこうとすると、そのような傾向になりがちです。ただ私達もそれは認識した上で、たとえ時間がかかりそうであっても大きなインパクトが見込めるものは意識的に開発するようにしています。例えばですが最近は「ライブ配信機能」の開発に一ヶ月をかけました。
*4:余談ですが、全社員には人員採用計画や売上計画、全社員の給与・SO、調達の状況なども公開されており、他のメンバーが「おや？」と思った際には確認できる環境が整っています。
*5:とはいえ、まだまだ改善したい点はいくつもあり、RedashはSQLの再利用がコピペになりがちなのでLookerを検討したり、仮説検定の作業に一部手作業が含まれるのでFirebase A/B テストを検討したり、よりよいKPI・KGI・OKRの設定を議論したり…。
