<1,000万MAU突破!>世界中のユーザー動向を数字から読み取るHiNativeの要。postings<1,000万MAU突破!>世界中のユーザー動向を数字から読み取るHiNativeの要。viewsこんにちは!マーケティングインターンの関です。Lang-8には、社内で大事にしている価値観の1つに「数字が共通言語」という考え方があります。神戸大学5年生の重神です。今年の8月からデータ分析のインターンとしてフルタイムで働いてます。今年の前半は起業してWebサービスを開発したり、海外ノマド生活に憧れて3ヶ月ほど放浪してました。立命館大学3年生の林です。9月からデータ分析のインターンとして、フルタイムで働いています。小説から、専門書、ビジネス書まで幅広く好きです。基本的にミーティングを軸に動いてます。ミーティングには二種類あって、ディレクター・データ分析チーム・社長のやんやんさん(喜)が参加するデータ分析MTGと開発メンバーが参加するPDCA共有会です。データ分析MTGは毎週月曜日と木曜日の2回あります。内容としては3つあって、重要な数値の変化の原因調査・次のリリースのKPI設計・新機能の速報値の確認です。重要な数値の変化の原因調査だと、リテンションレートが想定する領域を超えたときとかに、こういう原因でしたというのを共有しています。PDCA共有会というのは毎週火曜日にあって、リリース後の数値を開発メンバーに共有するための場があります。!タスクは大きく二種類に分けることができて、”リリースに対する評価”と”調査系”があります。“リリースに対する評価”は、新機能やA/Bテストの結果の数値を出すものです。”調査系”は二つあって、事前調査と原因調査に分かれます。事前調査はアイデアを施策に落とし込むための調査です。原因調査は意図せずに数値が変わってしまった場合など、すでに起こってしまったことの調査です。それぞれのタスクについて詳しく聞かせてください。アプリ内のボタンのデザインを変えようとしたときにA/Bテストをして、どちらのボタンがいいのかを調査をしたりします。A/Bテストだけでなく、バージョンごとに比較することもあります。新しい機能がついたときやデザインが変わったときに、意図しない数値が落ちていないかを確認します。ちなみにどのタイミングでA/Bテストをやるのかに関しては、ディレクターがスプリント(※短期間の開発スケジュールのこと)を設計するときに決めます。ディレクターが仮説を元に「今スプリントではこういうデザインを実装します」と判断したリリースのKPIを、データ分析MTGで最終確認します。前提として、「PDCA共有会」は、データ分析チームとディレクターはマストで参加をします。エンジニアやデザイナーは自由参加です。気になる機能や自分が実装したものがある人は出るし、その週のリリースがWebだけだったらAndroidエンジニアの人は出ない、みたいな場合もあります。だいたいのメンバーは毎週出ているイメージですね。自由参加なのにみんな出ているので、みんなデータに興味を持っているんだなと思います。PDCA共有会の内容はリリースの数値を開発メンバーで確認して、その後どういうアクションをするかをその場で判断します。最終決定はやんやんさんかディレクターですね。A/BテストでBの数値のほうが良いことがわかったら、「じゃあBを採用してリリースしよう」という決定することもありますが、「まだ母数が少ないからう少し時間を置いてみよう」という決定や、「別の数値も見てみよう」という決定もあります。質問を作成するボタンを変更したとき、もともとのKPIは「タップ数が増える」「質問数が増える」とかですが、質問数が増えたことがわかったときに、「適当に質問作る人が増えちゃったんじゃない?」っていう仮説が出ることがあるんです。いうときは、じゃあ回答率は下がってないかな、という感じで別の数値を見てみることもあります。エンジニアからのフィードバックで自分たちの気づかないことを指摘・提案していただけるのは嬉しいです。発表を聞いているだけではなく、議論もするし、数値に対して本当に正しいのかって考えてくれているなと思います。あとは、エンジニアだったら、「この実装の結果が良かったから別のページでも同じ改善をしてみようか」という話になったとき、エンジニアが「それだったらすぐできますよ」って言ってくれたらじゃあすぐに実装しましょうってなるし、「それはちょっと重いです」ってなったら「近いうちに実装したいから(GitHubの)Issueを立てて保留にしておきましょう」ってなります。実装にどのくらい時間がかかるかをその場で見積もりできるのはいいなと思います。デザイナーに関しても一緒ですね。デザイナー・エンジニアがPDCA確認会に参加することで、そこのコミュニケーションコストが低くなるのがいいなと思います。デザイナーだったらその場でパッとデザイン案が出てきて話が進む、みたいなこともありますよね。DAUなどの重要な数値が急に落ちたり上がったりしたときです。数値が急に下がったり上がったりしたときは必ずやんやんさんがSlackでつぶやくので、データ分析チームがそれを拾って原因を調査します。メインで見る数値は、毎日12時にSlackのbotでグラフが来るようになっています。そこに何か変化があったら、僕らももちろん見ているので、その場で軽く調べたり、すぐに原因がわからなかったらIssueを作ってがっつり調べたりします。2つ目は、ある数値を見ていて別の発見をしてしまったときに調査が始まります。回答率を調査しているときに、調査している時期とは別の時期にも急に下がっていることに気付いた時などがきっかけで調査をします。事前調査には主にディレクターが大きく関わってきます。HiNativeの開発では基本的に2週間で開発を回していて、ディレクターはその2週間で円滑に開発を行えるかを見ながら、次の2週間で何をするのかを考えます。Ease)を使っています。ICEの中のImpact、どのくらいのユーザーに影響を与えるのというのを出すために僕らがデータを出します。ディレクターから「次こんな施策を考えてるんだけど」という話を聞いて、じゃあどんな数値を出せばいいのかを一緒に考えます。仮に「この数値は今データがないです」となったときは2つあって、エンジニアに頼んでログを入れてもらうか、近い数値を出すかのどっちかです。フェルミ推定みたいな感じで、そういう数値の出し方もできますよっていう提案をします。ちなみに今まではデータ分析2人に対してエンジニアがたくさんいたので、アイデアがいっぱいあるけど事前調査が追いついていなかったんです。2人だけだったときはリリース後の数値を見るので精一杯だったみたいだけど、僕ら2人が入ってからようやくしっかり事前調査ができるようになりました。施策を考えるときに、「この施策のほうがよさそう」ってデータから判断できるようになったんです。前までは緊急度の高いものに追われていたみたいだけど、重要度の高い数値を出せるようになったのは大きいですよね。!データ分析のお仕事についてよくわかりました。全体として、なんかこっちのほうがいいから。俺の経験的にこうなんだ!みたいに感情ベースで話す人があまりいないです。根拠もなくただ「良さそう」と言う感覚で施策が採用されるわけではなくて、実際にA/Bテストしてみて、ユーザーがより好ましい行動をした方が採用されるという社風が影響していそうです。上司の感覚で決定されることにフラストレーションが溜まっている人がいたら、Lang-8のデータ・ドリブンの環境は良いと思います。いえ、アイデアは誰でも出せるし、誰のアイデアでも採用される可能性がありますね。デザイナーだろうがアルバイトだろうが数値の良い方が採用されるので。数値を根拠にして議論することができるから、どんな立場でもアイデアを採用してもらえる可能性があります。グロースシートという施策を書き貯めておくシートがあって、そこにはインターンであっても誰でも記入できるんですよ。シャワー浴びてる時や帰り道にふと思いついたらシートに書いておく、みたいな感じです。やんやんさんやディレクターが次スプリントの施策を考えるときにグロースシートを参考に考えるんです。そのときには、誰が書いたかは関係なくICEスコアで決まるので僕らのアイデアが実装されることも全然あります。データ分析のポジションとして入社してくる人に関しては、アイデアを持っていて、データをもとに考えられる人にとっては、すごく居心地がいいと思います。自分のアイデアのImpactを測るために自分で根拠となるデータを出せるので、考案するところから検証まで一人で行うことができます。石橋さん(データ分析兼ディレクター)のように、データ分析を経てディレクターになる人が活躍するのかなと思いますね。同じように、ディレクターの人もSQLのスキルを求められているはずです。あと、データ分析は色々なポジションの人とコミュニケーションをとることが多いので、コミュニケーションスキルは必須だと思います。SEO周りだったら、SEOを担当しているメンバーに「こういうデータが欲しい」って言われたり、ディレクターから依頼されて事前調査をしたり、エンジニアからチュートリアル突破率などの重要な数値を聞かれたり、社長から直接タスクを依頼されたり。全員と関わっていると思います。