こんにちは！マーケティングインターンの関です。
Lang-8には、社内で大事にしている価値観の1つに「数字が共通言語」という考え方があります。その原動力となっているのが、Lang-8が誇るデータ分析チームです！
今回は、データ分析メンバー2名へのインタビューを通して、「数字が共通言語」をどのように実現しているのかをお伝えするとともに、データ分析の魅力をたっぷりお届けします！

まずは軽く自己紹介からお願いします！

重神 は〜い。神戸大学5年生の重神です。今年の8月からデータ分析のインターンとしてフルタイムで働いてます。今年の前半は起業してWebサービスを開発したり、海外ノマド生活に憧れて3ヶ月ほど放浪してました。

林 立命館大学3年生の林です。同じく、9月からデータ分析のインターンとして、フルタイムで働いています。趣味は読書です。小説から、専門書、ビジネス書まで幅広く好きです。

データ分析チームは社員2人・学生インターン2人の4人で構成されていますが、チーム全体ではどんな動き方をしているんですか？

重神　基本的にミーティングを軸に動いてます。ミーティングには二種類あって、ディレクター・データ分析チーム・社長のやんやんさん（喜）が参加するデータ分析MTGと開発メンバーが参加するPDCA共有会です。
データ分析MTGは毎週月曜日と木曜日の2回あります。
内容としては3つあって、重要な数値の変化の原因調査・次のリリースのKPI設計・新機能の速報値の確認です。
例えば、重要な数値の変化の原因調査だと、リテンションレートが想定する領域を超えたときとかに、こういう原因でしたというのを共有しています。
また、PDCA共有会というのは毎週火曜日にあって、リリース後の数値を開発メンバーに共有するための場があります。

なるほど〜、それらのミーティングで発表する内容を元にタスクを進めているんですね！

林　そうですね！
タスクは大きく二種類に分けることができて、”リリースに対する評価”と”調査系”があります。
“リリースに対する評価”は、新機能やA/Bテストの結果の数値を出すものです。
”調査系”は二つあって、事前調査と原因調査に分かれます。事前調査はアイデアを施策に落とし込むための調査です。原因調査は意図せずに数値が変わってしまった場合など、すでに起こってしまったことの調査です。

では、それぞれのタスクについて詳しく聞かせてください。
まずは”リリースに対する評価”タスクについては、どんなことをやっているんですか？

林　例えばアプリ内のボタンのデザインを変えようとしたときにA/Bテストをして、どちらのボタンがいいのかを調査をしたりします。A/Bテストだけでなく、バージョンごとに比較することもあります。新しい機能がついたときやデザインが変わったときに、意図しない数値が落ちていないかを確認します。
ちなみにどのタイミングでA/Bテストをやるのかに関しては、ディレクターがスプリント（※短期間の開発スケジュールのこと）を設計するときに決めます。そして、ディレクターが仮説を元に「今スプリントではこういうデザインを実装します」と判断したリリースのKPIを、データ分析MTGで最終確認します。

リリースの結果の数値は毎週「PDCA共有会」で社内に発表していますが、どんな感じで進めているんでしょうか？

重神　前提として、「PDCA共有会」は、データ分析チームとディレクターはマストで参加をします。エンジニアやデザイナーは自由参加です。ただ、気になる機能や自分が実装したものがある人は出るし、その週のリリースがWebだけだったらAndroidエンジニアの人は出ない、みたいな場合もあります。でもだいたいのメンバーは毎週出ているイメージですね。自由参加なのにみんな出ているので、みんなデータに興味を持っているんだなと思います。

林　そして、PDCA共有会の内容はリリースの数値を開発メンバーで確認して、その後どういうアクションをするかをその場で判断します。最終決定はやんやんさんかディレクターですね。

重神　そうですね。
例えばA/BテストでBの数値のほうが良いことがわかったら、「じゃあBを採用してリリースしよう」という決定することもありますが、「まだ母数が少ないからう少し時間を置いてみよう」という決定や、「別の数値も見てみよう」という決定もあります。
例えば質問を作成するボタンを変更したとき、もともとのKPIは「タップ数が増える」「質問数が増える」とかですが、質問数が増えたことがわかったときに、「適当に質問作る人が増えちゃったんじゃない？」っていう仮説が出ることがあるんです。そういうときは、じゃあ回答率は下がってないかな、という感じで別の数値を見てみることもあります。

「PDCA共有会」にほとんどの開発メンバーが参加してることに関しては、どんなメリットを感じますか？

林　足立さん(バックエンドエンジニア)とか青木さん（Androidエンジニア) など、エンジニアからのフィードバックで自分たちの気づかないことを指摘・提案していただけるのは嬉しいです。発表を聞いているだけではなく、議論もするし、数値に対して本当に正しいのかって考えてくれているなと思います。

重神　あとは、エンジニアだったら、「この実装の結果が良かったから別のページでも同じ改善をしてみようか」という話になったとき、エンジニアが「それだったらすぐできますよ」って言ってくれたらじゃあすぐに実装しましょうってなるし、「それはちょっと重いです」ってなったら「近いうちに実装したいから(GitHubの)Issueを立てて保留にしておきましょう」ってなります。

林　実装にどのくらい時間がかかるかをその場で見積もりできるのはいいなと思います。

重神　デザイナーに関しても一緒ですね。デザイナー・エンジニアがPDCA確認会に参加することで、そこのコミュニケーションコストが低くなるのがいいなと思います。

林　デザイナーだったらその場でパッとデザイン案が出てきて話が進む、みたいなこともありますよね。

では、続いて”調査系”タスクの話を聞かせてください！まず、原因調査ってどういうときに発生するんですか？

重神　原因調査をするきっかけとしては2つあって、１つは毎日見ている回答率・新規登録数・DAUなどの重要な数値が急に落ちたり上がったりしたときです。数値が急に下がったり上がったりしたときは必ずやんやんさんがSlackでつぶやくので、データ分析チームがそれを拾って原因を調査します。

林　メインで見る数値は、毎日12時にSlackのbotでグラフが来るようになっています。そこに何か変化があったら、僕らももちろん見ているので、その場で軽く調べたり、すぐに原因がわからなかったらIssueを作ってがっつり調べたりします。

重神　2つ目は、ある数値を見ていて別の発見をしてしまったときに調査が始まります。
たとえば回答率を調査しているときに、調査している時期とは別の時期にも急に下がっていることに気付いた時などがきっかけで調査をします。

では、事前調査はどんなときに発生するんですか？

重神　事前調査には主にディレクターが大きく関わってきます。HiNativeの開発では基本的に2週間で開発を回していて、ディレクターはその2週間で円滑に開発を行えるかを見ながら、次の2週間で何をするのかを考えます。
ディレクターの人たちが「次の2週間でどんな施策をしよう」と考えたときに、いくつかあるアイデアの中でどの施策が「良いアイデア」なのかを測るためにICEスコア（※Impact, Confidence, Development or Design Ease）を使っています。ICEの中のImpact、どのくらいのユーザーに影響を与えるのというのを出すために僕らがデータを出します。
ディレクターから「次こんな施策を考えてるんだけど」という話を聞いて、じゃあどんな数値を出せばいいのかを一緒に考えます。仮に「この数値は今データがないです」となったときは2つあって、エンジニアに頼んでログを入れてもらうか、近い数値を出すかのどっちかです。フェルミ推定みたいな感じで、そういう数値の出し方もできますよっていう提案をします。
ちなみに今まではデータ分析2人に対してエンジニアがたくさんいたので、アイデアがいっぱいあるけど事前調査が追いついていなかったんです。2人だけだったときはリリース後の数値を見るので精一杯だったみたいだけど、僕ら2人が入ってからようやくしっかり事前調査ができるようになりました。施策を考えるときに、「この施策のほうがよさそう」ってデータから判断できるようになったんです。

林　ちょっと前までは緊急度の高いものに追われていたみたいだけど、重要度の高い数値を出せるようになったのは大きいですよね。

なるほど！データ分析のお仕事についてよくわかりました。
では、Lang-8のメンバーはどのような人が多いと思いますか？

重神　全体として、なんかこっちのほうがいいから。とか、俺の経験的にこうなんだ！みたいに感情ベースで話す人があまりいないです。根拠もなくただ「良さそう」と言う感覚で施策が採用されるわけではなくて、実際にA/Bテストしてみて、ユーザーがより好ましい行動をした方が採用されるという社風が影響していそうです。

林　とはいえ、アイデアは誰でも出せるし、誰のアイデアでも採用される可能性がありますね。デザイナーだろうがアルバイトだろうが数値の良い方が採用されるので。
数値を根拠にして議論することができるから、どんな立場でもアイデアを採用してもらえる可能性があります。

重神　例えば、グロースシートという施策を書き貯めておくシートがあって、そこにはインターンであっても誰でも記入できるんですよ。シャワー浴びてる時や帰り道にふと思いついたらシートに書いておく、みたいな感じです。そして、やんやんさんやディレクターが次スプリントの施策を考えるときにグロースシートを参考に考えるんです。
そのときには、誰が書いたかは関係なくICEスコアで決まるので僕らのアイデアが実装されることも全然あります。まあ、今の所まだないですけど（笑）

Lang-8にデータ分析として入ってくる人はどんな人が良さそうでしょうか？

林　データ分析のポジションとして入社してくる人に関しては、アイデアを持っていて、データをもとに考えられる人にとっては、すごく居心地がいいと思います。自分のアイデアのImpactを測るために自分で根拠となるデータを出せるので、考案するところから検証まで一人で行うことができます。だから石橋さん（データ分析兼ディレクター）のように、データ分析を経てディレクターになる人が活躍するのかなと思いますね。同じように、ディレクターの人もSQLのスキルを求められているはずです。

重神　あと、データ分析は色々なポジションの人とコミュニケーションをとることが多いので、コミュニケーションスキルは必須だと思います。例えばSEO周りだったら、SEOを担当しているメンバーに「こういうデータが欲しい」って言われたり、ディレクターから依頼されて事前調査をしたり、エンジニアからチュートリアル突破率などの重要な数値を聞かれたり、社長から直接タスクを依頼されたり。わりと全員と関わっていると思います。

林　そうですね。一番全員と関わってます。

それでは最後に、Lang-8のデータ分析としてのやりがいや魅力を教えてください！

林　Lang-8はデータ・ドリブンな会社なので、アイデアよりもデータを基軸にして意思決定を行っています。そのデータ分析を自分が担っているため、そこにやりがいや、責任感を感じますね。 サービスの中核にいる気持ちになります。インターンでも同等な責任を与えられているのはすごくいいと思います。

重神　僕もそういう感覚はありますね。だから意識的に「その数値自体が何を表しているのか」ということを細かく見るようにしています。たとえば「回答率」といっても、「全ユーザーの質問の中で回答がついた割合」も「質問を開いたユーザーの中で回答した割合」も回答率なので、そもそもどういう数値が求められているのかということを正確に把握するよう意識しています。重要な意思決定に関わるので。

林　あとは、全メンバーが数値を知るのはPDCA共有会なので、ほとんどのメンバーはそのときに初めて「A/Bテストの中でBが良かった」というのを知るんですが、自分だけがデータを出した瞬間に結果がわかるんです。500万人いるユーザーの中で自分が一番先に結果を知ることができるというエモさがあります。
学生目線で言うと、最近データが流行っていると感じていて、英語は必須スキルになってきているので、Lang-8だと両方学べるのは良いと思います。データ分析チームの社員の1人は台湾国籍なので英語でコミュニケーションを取れるし、データを学びつつ英語を学べるのは一石二鳥感があります。

重神　海外ユーザーが多いので、要因が複雑すぎて難しいけど楽しいというのもあります。新規登録やチュートリアルの突破率は重要なので常に見ているけど、突破率が落ちたときに、まずは母語別に数値を見ないとわからないんです。特定の母語のユーザーが急にチュートリアルを離脱していることがわかったときに、その母語で表記のバグがあるかもしれない、という切り取り方をします。

林　数値の要因分析をするってなったときに、日本の多くのサービスはユーザーが日本人であることが多いと思います。その場合はある程度要因の予測はできるんですよね。だけどHiNativeは海外のユーザーが97%を占めているので、迷宮入りしそうになったことがあるんですよ。

重神　ありましたね（笑）ある変更によって日本語インターフェースだけが影響を受けなかったのでその影響に気付きにくかった、という複雑なケースでした。
日本人だけを対象にしているサービスだったら体験できないですよね。

お二人ともありがとうございました！

おわりに

Lang-8では、データ分析をはじめとしたさまざまなポジションを募集しております。
「数字が共通言語」なLang-8で一緒にグローバルサービスを作りませんか？ご応募お待ちしております！