はじめに

チームの紹介というのも兼ねて、まずは自己紹介をさせていただきます。
yuchidaです。略歴を言うとちょっとドン引きされるような経歴を持っています。おっさんと自分で言うのは慣れたけど、他人に呼ばれるとちょっとモヤつくしがないアラフォーです。今は株式会社オトバンク、オーディオブック事業部にてBIチームの一員として働いています。

オトバンクって何ぞ

さて、いきなり出てきて急に会社の名前出されてもと思う方。ごもっともです。まずはオトバンクという会社についてざっくりご説明します。
簡単に言うと、オーディオブックという「本を音声化したもの」を売る「audiobook.jp」というサービスを提供している会社です。最近結構TVをはじめメディアで取り上げられることも増えてきて、きいたことある！という方もいらっしゃるかもしれません。（ここに辿り着いている時点で知ってる方は多いと思いますが）

そんなオトバンクについて少しでも皆さんに知っていただくべく、今回noteで「私たちのチームがどんなことしてるか」という形でご紹介していこうかと思っています。お時間ある方は是非時々覗いてみてくださいね。

BIチームって何ぞ

BIとは「Business Intelligence」の略です。詳しい定義は検索等で見ていただくとして、物凄くざっくり言うと、

「事業の重要な決定の判断材料となるデータを分析し、意思決定をリードする部署」

になります。
それまでは担当している方々の直感をベースに、マーケやエンジニアの方がちょこっとデータを見る、という形で意思決定をしていました。
が、これをきちんと「データに基づいて意思決定をしていこう」ということで、2019年ごろにBIチームが結成されました。2022年8月現在、私ともう1人の小さなチームですが、日夜データとにらめっこしています。

今のオトバンクにおけるBIチームのお仕事は大きく分けて3つです。

①改善施策の分析設計＆分析
オトバンクのメイン事業であるaudiobook.jpでは、「ユーザーの皆さんが気持ちよくサービスを使い続られるためには、どういうことが必要か」「そのためにはどんな機能が必要か」という形で仮説を立てて日々様々な改善策を試しています。
ただ、あくまで仮説のため、本当に改善になっているかはわかりません。単純に変えてハイ終わり、というわけにはいきません。ちゃんと皆さんが機能を使ってくれているか、皆さんがサービスを使い続けてくださることにその機能がどの程度役立っているのかということをきちんと数値で見ていく必要があります。（数値が悪いものについては、泣く泣くお蔵入りになったり、別の手法で試してみたり等もよくある話です）そのために「利用具合をどう数値化すればいいか」等を考え、エンジニアに実装してもらったり、ちょっと施策案に修正を加えたりするのも、BIチームの重要なお仕事です。
あとは、データが集まってからの統計を用いた実際の分析作業です。統計をかじっている方は「有意差」という言葉に聞き覚えがあるかもしれませんが、機能を使ったユーザーと使っていないユーザーのデータに「偶然では説明できない程度の差があるか」というのを見て、施策の効果があったかどうかを判定していきます。

②他部署の方々が自力でほしいデータを取り出せるようにするための手助け
私が最近メインでやっているのはコレです。
集積したデータを取り出すために、SQLというプログラミング言語に近いものでデータベースを操作する必要があります。これを扱うのはそれなりに知識も必要なので、他部署の人がいきなり出せと言われてもなかなか大変。
そういう普段データを扱っていない方々でも「ここを弄れば〇日から〇日までのデータがまとまって出るよ」みたいなテンプレートを作ったり、よく見るデータについてまとめたDashboardを作ったり、Botでチャットツールにまとめたデータを出力したりという作業を行います。

また、「データでの意思決定文化を社内に作る」という役割も担っています。先程オトバンクでの実例も挙げましたが、データに基づいた決定というのは前提として「データで決めよう」という社内の文化が必要です。そうでない場合は、担当者の予測、言い方を悪くすれば勘や気分で物事を決めるということになりがちです。
ただ、データに触れていない人にいきなりデータで決めろというのも無理な話。なので具体的な直近の目標としては「BIチーム以外の人でもデータを頻繁に見られる仕組みを作る＆簡単なSQLなら自力で書けるようにする」となります。このために、毎週講習会のような形でBIチームが他チームにSQLについて書き方の相談、実際書いたものの添削等を行っています。

③施策を考えるための材料になるデータを共有する
プロダクトマネージャーが施策を考える際、「ここどうなってるんだ…？」というのが気になるものです。自力でデータを出せる方もいらっしゃるのですが、ちょっと複雑だったりする場合は先述のSQLにて取り出す作業をBIチームが担当し、判断の材料としてもらう事があります。上の方で書いた定義にかなり近い役割ですね。今までは一番上の分析作業ばっかりだったのですが、今年度に入ってずいぶんこの「材料」出しが多くできるようになってきた気がします。

と、このようなお仕事をやっているわけですが、なにぶん経験も浅く人数も少ないチーム。元々私は心理学をかじっており、統計ちょっとだけできるということでBIチームとして配属されたのですが、お世辞にも真面目な学生ではなかったので残念ながら本当にちょっとだけレベルの統計しかできず…他会社の偉大なBIのやり方や学習法を見ながら勉強の毎日です。

ABテストの勉強会

「改善施策の分析設計＆分析」がBIチームのお仕事と先ほど述べましたが、ちゃんと良いものをお届けできるか、結果に結びつけられるかはこの分析の精度次第となってきます。しかし私自身そこまで事業の成長についてしっかり勉強したわけでもなく、統計の知識も不十分なことが多いです。そこでチーム員と相談して、事業成長に必要な知識をチームでの輪読形式の勉強会で学んでいこうという事になりました。

その題材となったのがこちら。
「ABテスト実践ガイド　真のデータドリブンへ至る信用できる実験とは」
通称カバ本です。表紙のカバにちなんでいるとのこと。
界隈では大変有名な本で、Google, Amazon, Microsoft, LinkedInという
名だたる企業での実例や教訓がふんだんに盛り込まれている名著です。

実験を通じて事業を成長させるために必要な知識がきちんと記されているため、ここから普段の業務に活かせるものや、チームに足りないものを学んでいこうという目的です。

いきなりABテストという単語が出てきましたが、簡単に説明します。
ABテストとは「ある変更を加えた時に、それが目的に影響を与えたかを、複数の対象から集めたデータで検証する方法」です。

例を挙げると……「ユーザーの購入を増やすために、ある機能Aを追加したい」としましょう。
ABテストの手順としては以下のようになります。

・ユーザーをα・βの2つの群に分ける
・α群には機能Aがあるアプリ、β群には機能Aがないアプリを使ってもらう
・α群とβ群の購入に違いがあるかを調べる
・α群の購入が増えた場合は、機能Aは購入を増やすのに効果があると判断し、機能Aをユーザー全体に出す
・α群の購入が減ったりした場合は逆効果なので、機能Aはお蔵入り

色々な変更は基本的にこのABテストを行ってから実装することで、ユーザーにより良いものをお届けできるようになり事業の成長にもつながります。
ちゃんと効果があるものを積み重ね、効果の無いものを減らしていくことで改善に繋げていくという形ですね。

実験成熟度モデルについて

さて、これ以上の説明はWebの集合知にお任せするとして。
今回特にお話したいと思っているのは、この本の第4章に記されている「実験成熟度モデル」についてです。

曰く、ABテストを通じてすべての変更を行うために、組織が通過する4つのフェーズがあるそうです。

1.クロールフェーズ
2.ウォークフェーズ
3.ランフェーズ
4.フライフェーズ

這う → 歩く → 走る → 飛ぶ という実にわかりやすいネーミングです。
ひとつずつ説明していきましょう。

1.クロールフェーズ
ここは「ABテストによる変更を始めたて」の、一番初期段階になります。そもそもABテストを行うためには、データが無いと何も始まりません。まずエンジニアに頼むなり自力でどうにかするなりで、データを集める仕組みを作る必要があります。
それからデータサイエンス能力。集めたデータを統計的・計算的・人間的視点から見ることができなければ、それはただのデータでしかありません。
集めたデータをきちんと処理し、理解できる形に変換できないと、変更が有効だったかの判断ができないからです。
実験回数の目安は月1回程度（年10回以下）となっています。

2.ウォークフェーズ
やや実験に慣れ、徐々にABテストを増やしていく時期になります。実験を複数行っていくと、「こういう数値（メトリクス）を見る」というのが定まってきます。1回の実験に留まらず、横断的に見ることが出来るメトリクスを決め、実験回数を増やせるようにしていく段階です。
また、集めたデータの信用性を検証することで、より結果に信頼を置けるようにしていくのもこのフェイズでやるべき事です。
実験回数目安は週1回程度（年50回以下）とのことです。

3.ランフェーズ
ここからは実験規模が一気に増え、毎日のように何らかの変更を加える、という段階です。ウォークフェイズで多くの実験ができるようにしたのはこのために必要なんですね。純粋に回数を増やすだけではなく、メトリクスを包括的・総合的なものにするのも重要です。
また、あるメトリクスが上がると別のメトリクスが下がる、いわゆるトレードオフとなる数値についてもどういうものがトレードオフになるのか、という事も含めて組織全体で共有しておく必要があります。
実験回数目安は毎日（年250回以下）。

4.フライフェーズ
最後のフェーズになると、1日複数回の実験が行われるようになり、全ての変更をABテストで行うのが標準になります。
また、新機能を作るチームがデータサイエンティストの手を借りずとも、自分たちのチーム内で簡単な分析が可能になっています。この量の実験をするとなると、当然手動では大変な手間になってしまうため、実験の仕組みを自動化することが必要になります。
さらに、行った実験についての記録や知識の蓄積をすることで、過去の実験から学びを得るための制度が出来上がっている状態です。あとからこれを見返すことで、どんな事が何に効果的なのかを体系的に理解できるわけです。
実験回数は多いところでは年1000回を超えることもあるそうです。

これらのフェーズが変わると、目標としている数値も変わりますし、技術的な焦点やチームに求められるものも全く違ってきます。それぞれ何が焦点になるかは置いておくとして、今オトバンクがどのフェーズにいるか、という事を考えてみました。

今のオトバンクのフェーズ

幸いデータを集める仕組みはエンジニアが既に用意してくれていたため、私の入社前にその辺りはクリアしています。データサイエンス能力は、（一応）我々BIチームが見られる、ということでこれもクリア。実験回数については詳しくは伏せますが、少なくともクロールフェーズは突破していると思われます。

オトバンクは現状2段階目の「ウォークフェーズ」にあると思っています。
実際現在では、実験で用いる横断的なメトリクスを設定し、それを元にして改善施策を打っているところです。この辺りのメトリクスを決める際にも色々あったのですが、そのあたりはまた別の機会に。
また、以前はデータの信用性についてのチェックはあまり行う余裕がなかったのですが、最近は実験期間やサンプル数等、徐々に信頼性についても徐々にチェックできるようになってきました。会社規模的にそれほど頻繁に変更が行えるわけでもなく、実験規模についても妥当なあたりかなと思います。

ランフェーズに至るためには、BIチームとしてはやはり「メトリクスの再設定」あたりのことが必要になりそうです。今見ているものでは対応しきれなくなる、あるいはもっと別の角度から見る必要が出てくることもあるため、より総合的な面で見られるような数値をウォッチしていかなければなりません。

あとは簡単に結果を出せるようにするために、分析を自動化したり、というところでしょうか。今でもある程度の数値は、分析のテンプレートを作って割と簡単に出せるような仕組みはできていますが、それをさらに適切で楽な分析になるようにしていきたいところです。
そのためにも、色々と勉強会で学んでいきたいですね。

おわりに

というわけで、勉強会を通じて組織自体のフェーズを成長させるために
諸々やっています、というお話でした。
audiobook.jpでは、ユーザーの皆さんにより良いサービスを届けられるよう、ABテストを使って様々な改善を検証しながら試みています。
目新しいものが出てきたら、是非色々と触ってみてくださいね。

また、定期的にチームについて発信していこうと思っているので、今後も公式共々よろしくお願いします。
それでは。BIチーム yuchidaでした。