はじめに
アライアンス事業本部でニュースパス、auサービスTodayといったKDDI社と協業しているプロダクトのプロダクトオーナーをしている大曽根です。Chief Data Officerとしてデータ周りのあれこれも担当しています。プロダクトの詳細については、以下の記事を参考にしていただけると幸いです。
こちらの記事は Gunosy Advent Calendar 2021 の12日目の記事です。 昨日の記事はazihsoynさんの「CUEを小さく使って環境別のYAMLファイルをtemplate化する」でした。
今回は A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは の第8章、「インスティチューショナルメモリとメタアナリシス」で紹介されているインスティチューショナルメモリについて当社の取り組みを紹介します。
インスティチューショナルメモリとは
組織が過去に学んだことをどれだけ記憶しているかを示すものです。例えば、A/Bテストを実施した場合に、
- どういう目的で
- どういう仕様で
- オーナーは誰で
- どれくらいの期間を実施し
- どんな結果が得られたか（どのようなメトリクスにどのような影響を与えたか）
を記録するものです。
なぜ、インスティチューショナルメモリが必要か
それなりの人数でソフトウェアを開発する場合には、組織の変化がついて回ります。一人で開発する上では、例えば「こういう機能を実装したがユーザーにあまり使ってもらえなかった」などの実験や失敗の経験を自身の知識として蓄えればよいですが、チームで開発する場合には共有し、学び次の施策に生かす必要があります。さらに、チームに新しい人を迎えることもあれば、リーダーが変わる、ときにはメンバーが異動/退職などでいなくなる場合も想定されます。その場合に、知識が個人に閉じていると知識が失われてしまうリスクがあります。新しく入ったメンバーが、以前実施し、失敗した施策などを提案する可能性もあります。
よくあるパターンとして、新しいメンバーが入った際、「なぜ競合プロダクトに導入されているこの機能/UIが導入されていないか」という問いが発生します。そこで、どのような仮説で施策を実施し、どのような決定がされたかという知識を蓄積することにより、「この施策をそのまま実装しても使われないので、別の方法で試す」など組織として効率的な開発を行うことができます。特に、コロナ禍においてリモートワークを導入する企業が増える中で、新入社員のオンボーディングにも貢献すると考えられます。また、データドリブンに仮説を組み立てる場合には、「どの変数がどの変数に関連している」ことが知識として残ることも重要です。下記はニュース記事の品質と広告効果の関係を論文化した例になります。
当記事では、プロダクトチームおよび開発組織が実施した施策（A/Bテスト）のインスティチューショナルメモリについて書いていきます。
Gunosy社におけるインスティチューショナルメモリ
主に分析チーム（当社ではBIチームと呼んでいます）の目線での知識共有は図1に示す通り、
- 実験の設定（仮説含む）
- 実験
- ログの格納
- 分析の実施
- 結果の共有
の流れで行われます。
になります。当社ではA/Bテストの基盤が存在し、実験の実施期間、対象のユーザーの割合を決定、設定することができます。A/Bテストの設定のスナップショットも当社のデータ基盤Baikalに格納されます。決定された条件を元にユーザーの割り当てが決まり、ユーザーの行動ログも同様にBaikalに格納されます。
A/Bテストの設定も格納しているため、例えば示唆深い実験結果を論文にする場合に、足りないデータがあるので別の切り口で分析を行うことができます。さらに、新たなデータを加えての分析を実施することで、実験結果を反証することも可能です。
共有に使っているツール
図に示す通り、当社では実験の共有にSlack、Confluenceを用いています（上述の通り論文としても投稿することもあります）。また、週1回で自身の行った実験や開発を共有する会を実施しています。 使い分けと流れは以下のようになります。
- A/Bテスト実施前にオーナー、目的、仮説、期待効果をConfluenceに記載する（テンプレートあり）
- A/Bテスト開始前にPOの承認をもらう
- A/Bテストが設定され、実施されるとSlackに開始される旨が投稿される
- 集計結果が自動でSlackに通知される
- データがある程度集まってタイミングで集計し、結果をConfluenceに記載する
- 拡大判断をSlackで行う (1%、10%のユーザに拡大など)
- 100% (もしくは撤退) になったタイミングでConfluenceに記載
- 施策の結果を成功失敗に関わらず、共有会で資料とともに共有
そのほか、中長期的に重要な結果であれば、結果を論文で共有することもあります。
A/Bテストのテンプレートに記載する内容
A/Bテストのテンプレートに各項目は下記の通りです。
- 施策のオーナー
- 社内ステークホルダー （コンテンツチーム、営業チームなどに営業がおよぶ場合に記載）
- 施策背景、目的
- 施策の目的が達成された場合の各ステークホルダーへの影響
- A/Bテスト対象メトリクス
- 悪影響を与えていないか確認すべき指標 （いわゆるガードレールメトリクス*1）
- 拡大/撤退条件
- スケジュール
A/Bテスト対象メトリクスがやたら描かれてしまうのが最近の悩みです。（リーンアナリティクスのLean Analytics*2の One Metrics That Mattersにそってできれば一つのメトリクスを追いたい）
今後やりたいこと
A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは の第8章、「インスティチューショナルメモリとメタアナリシス」に書いてある、「チームの実験の数をモニタリングする、実験のうち公開された機能の割合」などはまだあまりできていないので今後トライしていきたいと思います（分析について分析するのでメタアナリシスと呼ぶ）。実験の数だけを追うとユーザーのペインに関する仮説を考えず実装ばかりするビルドトラップにハマりそうなので、実験のうちの100%公開された機能割合や与えた影響などと合わせて出すことで、よりユーザー理解が深まっているかなどをモニタリングできるかもしれません。（もちろん小粒な実験を多く繰り返すことで、局所最適なプロダクトになってしまう可能性もあるので注意は必要です）
おわりに
ソフトウェア開発において、知識を蓄積し、組織（チーム）が学習することは非常に重要だと考えています。インスティチューショナルメモリの活用によりユーザー理解が進み、よりユーザーに価値のあるプロダクトを提供できるようにしていきたいです。
