国内月間アクティブユーザ数8,400万人（2020年6月時点）を超えるLINE。

メッセンジャーだけではなく，スタンプ，ニュース，マンガといったコンテンツに加え，決済や証券といった金融系サービスまで，さまざまなサービスを展開しています。

サービス上で提供される情報やコンテンツのデータサイズ，ユーザからのアクションなど，LINEのエンジニアたちが開発・運用の中で扱う必要のあるデータは膨大で，多種多様です。

日々データが大量に蓄積・更新される環境であるLINEには，全社・全事業のデータを集約させ，機械学習・データ活用を担うData Science and Engineeringセンター（以下，DSEセンター）という組織があります。

LINE社内における機械学習を活用した企画やプロジェクト・プロダクトの重要性は年々高まっているため，今年2020年3月には，円滑な機械学習ノウハウ共有や，データ関連組織の連携強化によるサービス価値の向上を目的に組織再編も行われました。

そのDSEセンター傘下にある，LINEの機械学習を活用したサービス開発を担うMachine Learning1チーム（以下，ML1チーム）マネージャー菊地悠氏に，LINEが取り組む機械学習サービス開発について，オンラインインタビューを行いました。

後編では，Data Scienceチーム（以下，DSチーム）など周辺のメンバーとの関わり方や使用されるツール，LINEの機械学習エンジニアだからこそのやりがいについて，お届けします。

Machine Learning1チームの周辺組織との関わり

社内ツール「LIBRA」を活用したA/Bテストでのチーム間連携

――LINE DEVELOPER DAY 2019で，DSチーム高口太朗氏のセッション「コミュニケーションアプリ「LINE」の機能改善を支えるデータサイエンス」では，「LIBRA」や「Shiny」といったツールを使用した，MLチームとDSチームの業務上のコミュニケーションの一端が解説されていました。
MLチームの方は，これらのツールを使用して，周辺のメンバーの方々とどのようなコミュニケーションを取りながら業務に取り組んでいるのでしょうか？

図1　LIBRA

「LIBRA」は，A/Bテストを行うための設定情報を管理・定義する，かなり簡素なシステムです。社内のサービスに推薦システムの導入が進んできて，新たなエンジンへの改善ニーズが高まってきたこと，DSチームのデータサイエンティストが個別にA/Bテストの設計を行っており，共通化のメリットが高そうなことから，2017年末くらいから，検討・導入を進め，最近では社内の標準的な環境になりつつあります。

たとえば，より使いやすいUIを決めるにあたり，実験計画と実際のA/Bテストの実施・検証をDSチームだけで行う場合もありますし，機械学習が関わるSmart Channelのようなプロジェクトにおいて，エンジンの変更や機能追加・設定変更などに関して，A/Bテスト実施のサポートをお願いするようなこともあります。

A/Bテストの設計というのは，たとえば1%のCTRが見込まれる表示領域の修正を行うにあたって，「⁠どれくらいの変化量を，どれくらいの確からしさで検出したいか」を決めた上で，「⁠どれくらいのユーザに，どれくらいの期間，試してもらうか」を決めることに相当します。

また実験計画という観点では，試したいパターンが複数存在するような場合に，1度にまとめて行うべきか，複数回に分けて実施すべきか，といった検討をすることもあります。LINE DEVELOPER DAY 2019のセッションで，弊社の高口が解説しているように，1回にまとめてA/Bテストを実施しようとすると，多重比較の問題による偽陽性の可能性や，偽陽性を抑えるためにサンプルサイズが大きくなりすぎる問題が生じることもあります。

高口のセッションでの例は，LINEのメッセンジャーにおけるグループ作成手順のわかりにくさを改善させるために，「⁠招待するユーザの友だちリストの並び順」「⁠手順の画面数」を変更させる改善を組み合わせた，4パターンのテストについて，2回に分けて，3パターンのテストにする，という内容でした。

たとえば2つの機能のテストをまとめて行おうとすると，4群のA/Bテストになります。A～Dの4パターンで考えると，有意差に関する検定は，AとBの比較，AとCの比較…，という風に数えることになり，合計で6つのペアを比較しなければなりません。

このような場合は単純に2群（2パターン）でのA/Bテストを2回行う方が，サンプルサイズも小さくて済む上に，結果の解釈もシンプルになります。

UIの検証の例は，ML1チームは関与していませんが，前回紹介したSmart Channelについては，DSチームに協力してもらいながら，A/Bテストを行っています。

当初は単なるテストの設定情報のみを提供していたLIBRAですが，Smart Channelでは，システム的な連携をかなり盛り込んでもらいました。このため，前編で紹介したバンディットアルゴリズムのA/Bテストを行いながら，同時に個別サービスのロジック，たとえばSmart Channel向けのスタンプのレコメンドのA/Bテストも実施する，といったことが可能になっています。

また，A/Bテスト実施の際のログがリアルタイムで出力されることから，LIBRA上でも，リアルタイムのテスト結果が確認できるような機能追加を行いました。

A/Bテスト実施時の分析の実務にあたっては，DSチームに協力を仰ぎながら，A/Bテストの仕組み自体を導入したり，社内の他システムとの連携をしたりなどを含め，開発に関わる部分はML1チームがメインで担当しています。

エンジニアやデータサイエンティストの裁量に委ねられた開発ツール選定

弊社では，さまざまなサービスのデータをきちんと取ったら，それをダッシュボードなどで常に確認できるようにする，という文化が根づいています。個人的におもしろいと思うのは，この際に使われるツールが1つだけではなくて，かなりの部分がデータサイエンティストの裁量に委ねられている点です。

たとえば，Shinyは統計ソフトR上での分析結果をWebアプリとして公開するためのRのパッケージですが，弊社のデータサイエンティストにはRをメインで利用しているメンバーも多く，こうしたメンバーはShinyを使っています。

その他，Tableauを使ったり，内製の「OASIS」というツールを使ったりもしています。OASISは PythonもRも使える上に，SQL（SparkSQLやPrestoなど）も利用できるので，ML1チームでも，他組織に何かを共有する際に，OASISを使うことは多いです（チーム内部の検証ではJupyterを利用しています⁠）⁠。

他にも「conflr」というLINE発のオープンソースソフトウェア（OSS）で，R Markdownで書いた分析内容を直接Confluenceのwikiページへと出力できるツールもあります。DSチームの中にも，エンジニアリング指向の人が混ざっていたりする点は，おもしろいと思います（※⁠）⁠。

※）

conflr: R MarkdownをConfluenceに投稿するRパッケージ（LINE Engineering Blog）