グループ作成の手順をわかりやすくする
高口太朗氏（以下、高口）：ここからは具体的な改善のためのプロジェクトサイクルを一緒に追体験していきたいと思います。
まず、ユーザーリサーチの結果から浮かび上がったのは、グループ作成の手順がそもそもわかりにくいのではないかという仮説でした。当時の手順と言うのは、まずグループのアイコンと名前を設定して、それから次にグループのメンバーを招待する順番になっていました。
しかし、実際にグループを作ることを想像すると、まず誰を招待するかが頭に浮かんでいそうです。そうすると、いきなりアイコンやグループを決めなさいと言われても、すぐには思いつかなくて、ユーザーが離脱してしまうことが起こるかもしれないと考えました。
そこで考えられたプランは、手順の順番を入れ替えることでした。つまり、まずグループに招待するメンバーを選び、それが決まったらその次でアイコンとグループ名を決めると。そういう順番です。これなら急にグループ名を決めると言われて戸惑うユーザーを救えるかもしれないと考えました。
こちらについて実際にオンラインでA/Bテストを行いました。しかし、そのテストの結果は我々にとっては意外なものでした。
どの地域においてもグループ作成の成功率にはほとんど変化が見られませんでした。つまり、グループ作成の手順を入れ替えてもユーザーのニーズは受け止めることができていませんでした。
グループ作成成功率が変わらなかったのはなぜ？
ここから、データに基づいて、なぜ作成成功率に変化が見られなかったのか、その要因を探っていきます。
ここで背景に表示しているのは、実際のテスト期間中のダッシュボードの一部です。これらのような多くの指標の中から、我々のLINEアプリに関する知見ですとか、あるいは統計分析の手法を組み合わせて、注目すべき要因を導き出していきます。
データ分析をするにあたって、いくつかの切り口をあらかじめ設定する必要があります。
今回の場合で言えば、まずグループの作成に成功したユーザーに注目するのか、あるいは成功しなかったユーザーに注目するのか。あるいは、同じような結果に見えても地域ごとに固有の要因があるんじゃないかと。または、時間的な依存性があるのではないか。つまり、テストの初期と終盤とでユーザーの反応が変わっていて、結果としてそれが変化がないように見えたのではないかと考えられます。
これらの切り口を一つひとつ念頭に置いてデータを探索していきます。
網羅的にデータ分析を行った結果としてわかってきたのは、変更後、今回テストした手順でグループ作成の完了をできなかったユーザーは、2つ目のアイコンとグループ名を決める画面まで進んでいなかったことがわかりました。つまり、真にユーザーが困っていたポイントは招待するメンバーをスムーズに選べないことだったことが、この分析の結果としてわかりました。
テストの結果は、成功か失敗かだけではなくて、今後の機能改善によってどれだけの効果を見込めるかについても知見を与えてくれます。
この図は、ユーザーが新しい画面に慣れたであろうテストの最終日にグループの作成を完了しなかったユーザーについて、2段階に分解しています。
まず1段階目の分岐では、作成完了しなかったユーザーのうち65パーセントは、テスト期間中にグループ作成画面を見るのがこの日で初めてでした。ということは、この65パーセントの中には、試しにグループ作成のボタンを触ってみたであるとか、あるいは間違って触れてしまったような人が相当数含まれていると考えられます。
次に2段階目で、残りのユーザーのうち7パーセントはテスト期間中にすでにグループ作成を完了したことがあるユーザーでした。なので、これらのユーザーについてはグループの作成方法自体は理解しているので、あまり心配する必要がないといえます。
最後に残った一番右の28パーセントですね。これらのユーザーはテスト期間中に複数回グループ作成を完了できなかったユーザーです。この層が我々が機能改善によって救うべきターゲットになります。
このように、グループ作成を完了できなかったうち3割程度のユーザーが複数回グループ作成を完了できていないという事実が明らかになり、その結果として、継続してグループ作成手順の改善を行っていくという意思決定がなされました。
最小限のリスクで最適な組み合わせを導くテスト設計
そして、次のプランを立てました。それは、先ほどありましたとおり、メンバーを選ぶところにユーザーのペインポイントがあるわけですね。なので、グループに招待するメンバーを選択する画面の上部に、最近1対1でトークした友だちを優先的に表示するプランを考えました。
ここで想定しているシチュエーションは、最近1対1でトークしてそこから会話が広がってグループを作ろうとなったときに、最近トークした友だちのリストがあれば便利にユーザーが使えるだろう、という考え方です。
実はこのセクションは今回のために新たに開発したものではなくて、もともとWebブラウザからLINEの友だちに情報をシェアする際には提供されている画面でした。先ほどのテストの結果を受けて、データサイエンティストとアプリの開発チームとが直接話すことによって「この画面を利用できるんじゃないか？」となりまして、最小限のコストによって次の改善を実装することができました。
そして、別の提案として、こちらのプランも同時にテストを行うことになりました。
このプランでは、今まで当初は2画面だったグループのアイコンとグループ名とメンバーの選択を1画面で行うアイデアです。「手順が1画面にまとまることによって、ユーザーの離脱率が減るのではないか？」という仮説に基づいています。
全体として、テストすべき画面のパターンは4通りになりました。
つまり、招待するユーザーの友だちのリストの並び順、これが2通り。そして手順の画面の数が2通り。これらをかけ合わせて4通りですね。これらの4通りで6ペアの比較を行えば、この4つの選択肢のうちでどれが最もよいかの優劣を決定することができます。
ただし、この方式にはデメリットもあります。それは、1つのテストの中で6つの比較を行うことになりますので、いわゆる多重比較の問題になって、これをナイーブに実行しますと、たまたま偶然で差が生まれたことを有意差とみなしてしまう偽陽性の確率が上がってしまいます。
一方、偽陽性を抑えるために有意性の水準を厳しくしますと、今度は大きなサンプルサイズが必要となって、仮にどれかがネガティブな結果だった場合に、ユーザーに与えるリスクが大きくなってしまいます。
そこで、我々は統計分析に基づいて比較する画面のパターンを3通りに絞って、2ペアの比較だけにすることにしました。
まず、この横に表れています黄緑色で表しているペアで、友だちリストの表示順の効果の検証をします。次に、2つ目の縦の青い矢印のペアで、手順の画面の数の効果を検証します。
つまり、4つの画面パターンで完全に序列を決めることを諦める代わりに、採用すべき組み合わせを最小限のリスクで見出すということです。このようなナイーブでないテスト設計を提案することは、統計の専門知識とアプリについての知識を持ったデータサイエンティストがいなければならない貢献になっています。
グループ作成にかかった時間を評価する
では、実際のテストの結果を見てみましょう。
今回もグループの作成の完了率自体にはいずれも有意な変化は見られませんでした。では、現状のままの画面を維持するという決定でよいのでしょうか？
別の観点から今テストした3パターンの評価を検討するなかで、この企画の当時の担当者から「グループ作成の完了にかかる時間が短縮されていたら、それは完了率が同じでもユーザーにとって使いやすい機能になったのではないか」というアイデアが出されました。
この点について実際に我々は分析を行いました。当時のもともとの手順と、2つのステップの画面でかつ最近トークした友だちが優先表示される画面で、グループ作成完了に要する典型的な時間を計測しました。
その結果、日本、台湾、タイにおいて、この時間が有意に短縮されていました。これは「最近トークした友だちを起点にグループを作る」という我々の考えたシナリオが一定のユーザーニーズを捉えている結果だと考えています。
では、もう1つの、1つの画面にすべて要素を入れるプランはどうだったでしょうか？
結論から言うと、ユーザーの反応はネガティブでした。
まず、1画面のプランの場合には、メンバーが1人だけのグループが作成される数が増加していました。これはおそらく、画面が大きく変わったので試しにグループを作ってみるであるとか、あるいはメンバーを招待する前に誤って手順を完了してしまったという影響と推測しています。この影響を受けて、メンバーが2人以上のグループに絞ると、グループの作成成功率は既存のものに比べて低下していました。
また、グループ作成ボタンを押してから画面を戻ってトークの作成へ切り替えるユーザーも増加していました。これは、グループ作成画面が新しくなったのでユーザーがどうすればいいかわからなくなって、諦めてグループではなくてトークの作成に切り替える行動が反映されていると考えています。
もう1つの要素として、グループの作成完了のボタンを2回押されるケースも増加していることがわかりました。これはおそらく、いったん作成完了と思って完了のボタンを押したものの、必要な事項が入力されておらずもう1回やり直したケースが増えていると考えられます。
以上のテストの結果を受けて、現在のアプリのバージョンでは、画面が2つのステップで、そして最近トークした友だちが優先的に表示される組み合わせが100パーセント適用されています。
グループ作成ボタンはどこにある？
ここまで見てきたのはグループ作成の手順の内側でした。それ以外にまた別な観点で、ユーザーリサーチの結果からユーザーが困難を感じる別のポイントが見えてきました。それは、そもそもグループ作成のボタンがLINEアプリ内のどこにあるのか知らないユーザーが少なからず存在していることです。
ここで会場のみなさんにもご質問してみたいと思うんですけど、グループ作成のボタンはLINEアプリのどちらにあるでしょうか？
ぜひ手元のスマホを開かずにお答えいただきたいんですけれども。1つ目は「ホームタブ」。一番左のタブですね。次に「友だちを追加する画面」。そして3番目が「トークを作成するメニュー」。そして最後は、あまり選んでいただきたくないですけれども、「いや、よくわからない」という選択肢です。
みなさんいかがでしょう？ ホームタブにあると思われる方？
（会場挙手）
ありがとうございます。「友だち追加のメニューにあるよ」って方？
（会場挙手）
おっ、これが多いですね。ありがとうございます。トークを作成するメニューにあると思われる方？
（会場挙手）
同じぐらいですかね。ありがとうございます。最後の「よくわかりません」という方はいらっしゃいますか？
（会場挙手）
ありがとうございます。まだ改善の余地がありますね。
実は答えは、この3つすべてにあります。
今のお答えいただいたことからわかりますとおり、我々が決めるべきことは、どこか1つの場所にグループ作成のボタンを置くのではなくて、ユーザーのみなさんがグループを作成しようと思ったときに直感的に選ぶ場所にグループ作成のボタンを置く必要があるということです。
そして、この3番目のトーク作成のメニューですね、ここにグループ作成の導線が追加されたのは、今からお話しするA/Bテストの結果に基づいています。
このテストのプランはこちらです。
トークタブのトーク作成のボタンを押すと、グループ作成とトーク作成の2つの選択肢が提示されるというプランを考えました。もともとはこの選択肢はなくて、トークを作成するだけでした。グループ作成するときはもちろん大きなモチベーションとして友だちの誰かとトークを始めたいということがあるので、トーク作成の中でグループ作成が選択肢に入っているのが合理的だと考えました。
こちらのテストを行いました。このテストをした結果、日本とインドネシアにおいて、とくにグループ作成を完了するユーザー数が大きく上昇するという、ある意味想定どおりの結果が得られました。
1つの指標が大きく伸びる裏には、他の指標を犠牲になっている可能性も
では、この結果だけを受けて変更後のバージョンを100パーセントリリースするかといいますと、我々の判断はノーです。これはなぜかといいますと、何かの指標が先ほどのように大きく著しく上昇した場合には、ほかの指標を犠牲にしている可能性があるからです。
今回の場合でいくと、トークを作成しようとトーク作成ボタンを押したユーザー、彼らには、グループ作成とトーク作成、2つの選択肢が提示されます。そうすると、グループ作成を選ぶユーザーが増えたとしてもトークを作成するユーザーが減っていたとしたら、結果的にトークがグループにすげ変わっただけですので、数字の見た目ほどユーザーの使いやすさに対する貢献はないといえます。
そこで、グループを作るユーザーが増えたかどうかだけではなくて、トークルームを作るユーザー、そしてグループまたはトークルームを作るユーザー、それらの変化についても検証しました。
先ほどお話ししたとおり、グループ作成を完了するユーザーは確かに増えています。その一方で、トークを作成するユーザーはやはり減っていたことがわかりました。しかし、トータルで見ますと、グループまたはトークどちらかでも作成したユーザーはプラスに転じています。
こちらの伸び幅は小さく見えるんですけれども、グループ作成もしくはトークどちらかを作るユーザーはそもそも人数が多いですので、この変化はユーザー数の絶対数で言えばインパクトの大きい変化になっています。
改善によるネガティブな影響を見極める
では、これで安心してリリースできるのではなくて、まだ検証すべきことがあります。それは何かというと、トークタブにグループ作成の導線を追加したということは、今までグループ作成をするためにホームタブや友だち追加のメニューを訪れていたユーザーたちのトラフィックを分散させている可能性があるということです。
その結果として、ホームタブで行うべき友だち追加ですとか、あるいはLINE公式アカウントの友だち追加が減少していたら、メッセンジャーとしてはマイナスの効果になります。
データ分析の結果、この点についてはとくにネガティブな効果は見られないことを確認しました。ホームタブの閲覧数はほぼ変わらず、また、友だちあるいはLINE公式アカウントの追加の数も変化していませんでした。さらに、トーク作成のボタンは表示が変わったのですが、グループ作成の導線が変わったことによってそのクリックが減るであるとか、ユーザーのネガティブな反応も見られませんでした。
以上を検証した上ではじめて、現在ではトークタブのトーク作成のボタンを押すとグループ作成が選択肢として現れるUIになっています。このように、1つのボタンを変えるだけの小さな改善に見えますが、それであってもユーザーにとって使いにくいネガティブな影響が現れていないかを慎重にデータを通じて見極めた上で、最終的なリリースを判断しています。
ここまでの改善プロジェクトによってお話ししてきたのは、グループ作成の手順の中身を便利になるように修正したり、あるいはグループ作成に入る導線を増やしてグループを作成するユーザー数そのものが増える、そしてグループ数が増えるというような改善を続けてきました。
そして我々の次のフェーズでは、そうしてユーザーのみなさんが作成いただいたグループをアクティブに使い続けてもらうことをターゲットに見据えています。なので、これまでと同じように、まずユーザーさんのみなさんはどのようにグループを利用しているか、そのユーザーリサーチから、今度は「アクティブなグループを増やす」というターゲットに向けてプロジェクトのサイクルが続いていくことになります。
分析を支えた社内ツールたち
さて、ここまでお話ししてきたデータサイエンティストが貢献するLINEアプリの改善プロジェクトについて膨大なデータ量のデータを分析する上で効率的な分析業務を実現できた背景には、社内で最適化された分析の環境とツールの存在が大きくあります。ここからは、実際のA/Bテストの分析手順に沿って、いくつかの内製のツールについてご紹介していきたいと思います。
A/Bテストの実施、そして分析の手順においてデータサイエンティストがプロジェクトの関係者に提供するものは、大まかに4段階に分かれています。
まず、テストに必要な統計的に必要なサンプルサイズ。そして、テスト対象となる具体的なユーザーの指定。それから、テスト進行中のモニタリングのためのダッシュボード。そして最後に、テスト結果のレポーティングです。これらのフェーズそれぞれで異なる社内の内製ツールが活躍しています。
まず、最初の2つのステップ、サンプルサイズの計算と実際のユーザーの選定、こちらに関わるツールを見ていきましょう。
まず1つ目にご紹介するツールは、全社共通のWebアプリケーション「OASIS」です。
OASISでは、Spark SQL、SparkR、PySpark、あるいはMarkdownやPrestoなど、それらのすべてを1つのノートブックで実行することができます。
これによって、テストのサンプルサイズの設計のために必要なデータの集計、そして統計的に必要なサンプルサイズを決めるための統計的な関数、最後にMarkdownによってノートをまとめる、以上を1つに集約することができます。
そして、我々にとってなによりもうれしいことは、これらのノートブックは我々だけが見るわけではなくて、エンジニアではないメンバー、企画やデザイナーのメンバーも含めて全社からアクセスが可能なので、誰に共有するにしてもこのノートブックを1つ作ればいいと。作業と共有までが1つで完了することがすばらしい点になっています。
そして、これらのOASISの上ではデータサイエンティストが使いたい機能を拡張的な機能として登録することができます。それによって冗長的な作業や反復を削減することができます。そのようなデータサイエンティスト自身による開発については、今日夕方のショートトークでも発表があると思いますので、ぜひそちらも聞いていただければと思います。
A/Bテストの自動振り分けやモニタリングツールも
2つ目のツール、こちらは実際にどのユーザーをテスト対象にするかを決定するためのツールです。こちらは「LIBRA」という、Data LabsのMachine Learning チームが開発運用している、A/Bテストの振り分けを自動化するツールです。
LIBRAはユーザー全体をランダムに振り分けたスロットと呼ばれる単位で管理しています。そして、スロットを今回のテストで必要な数だけ指定することによって、A/Bテストの対象ユーザーを指定することができます。そちらをデータサイエンティストがLIBRAのCMSにインプットすると、それが実際のサービスのテスト設定配信サーバに反映されて、ユーザーの下にUIが出し分けられるという仕組みになります。
そして、LIBRAはAPIを提供していますので、テスト対象のユーザーIDのリストを個別に管理しておいてそのテーブルをデータサイエンティストが分析のために逐次参照する必要はなくて、手動のオペレーションは完全に不要になっています。
次に、A/Bテストの進行をモニタリングするダッシュボードについてお話しします。こちらの目的のためには「LIBRA REPORT」というツールが活用されています。
データサイエンティストが、テストの集計のために必要なクエリをGitHubを通じて登録します。そうするとLIBRA REPORTは、LIBRAに登録してあるテストの設定情報と組み合わせることによって、Apache Airflowの実行ワークフローを自動生成してくれます。
Airflowを通じて集計された結果はブラウザベースのダッシュボードに表示されて、全社から関係者が閲覧できる状態になる。それだけではなくて、分析基盤にも中間テーブルが保存されます。
つまり、データサイエンティストがテストの事後分析をするときには、処理済みのデータがすでに生成されている状態ですので、逐一複雑なクエリを何度もデータサイエンティストが実行する必要はなくなっています。これによって事後分析を網羅的に行うことが非常に簡便になっています。
ボタン1つで図表をwikiに共有
もう1つのツールをお話しします。こちらはLIBRA REPORTと別のモニタリングのダッシュボードツールです。
テストによっては、LIBRA REPORTが提供するような汎用的なダッシュボードよりは、より高頻度でデータをチェックするなど、別のニーズがある場合があります。
その場合には、我々のチームでは主にRのShinyダッシュボードを通じてカスタマイズできる可視化を実現しています。Shinyのダッシュボードの技術的な詳細についてはポスターセッションのほうで我々のチームの大木が発表していますので、そちらもぜひ聞いていただけたらと思います。
最後に、テスト結果のレポーティングツールについてご説明します。レポーティングに関してご紹介したいのはconflrというRのパッケージです。
conflrはR Markdownで書いた分析のスクリプトを直接Confluenceのwikiページへと出力してくれるAdd-inとして働いています。
このパッケージのおかげで、データサイエンティストは分析結果の表や図をコピー＆ペーストする必要がなくなりました。ボタンを1つ押すだけで、企画者やデザイナーが見えるかたちにwikiとして共有することができます。
なお、このconflrは我々のチームメンバーが開発して、LINE発のオープンソースのソースウェアとして提供されていますので、ぜひお試しいただければと思います。
最後にまとめです。
このセッションでは、みなさんにお伝えしたい4つのキーワード、LINEのデータに基づくアプリ改善のキーワードを具体的なプロジェクトの実例に基づいてご説明してきました。みなさんがふだんお使いいただいているLINEアプリの機能は裏側ではこうしたデータに基づく改善を日々積み重ねて成り立っています。今後もデータドリブンで進むLINEアプリのさらなる進化にご期待いただければと思います。
ご清聴ありがとうございました。
（会場拍手）
