データサイエンティスト養成読本『ビジネス活用編』の4章を全公開します
Hikaru Kashidaです。
2018.10.30発売の 『データサイエンティスト養成読本』の第4章を執筆させていただきました。せっかくなので、僕が執筆した章についてこちらのnoteで全文を公開しようと思います。
書籍の方を購入したい方は店頭もしくはこちらからどうぞ。
※ 当然ですが、編集了承済みです
※ 一部書籍版とは微妙に編集されている箇所もあり、完全一致はしません
嬉しいコメントいっぱい頂いています〜
以下原文です。
序文
メルカリはいま世界的に急成長をみせるCtoC市場において、グローバルにサービスを展開している会社です。この環境での事業運営においては、データドリブンかつ圧倒的なスピード感を持った意思決定が要求されます。世界で競争するための人材が続々とジョインする中で、データ分析組織とデータ分析者はどのように振る舞うべきでしょうか。本章ではメルカリで取り組まれている意思決定を最速化する体制や、データリテラシーを組織に根付かせるための取り組みを紹介します。
筆者紹介
樫田光（Hikaru Kashida）
https://twitter.com/hik0107
2016年に中途でメルカリ入社。データ分析を通して国内/米国の両事業の企画支援・戦略立案を行う一方、BIチームのマネージャを務める。
メルカリへのジョイン以前は、外資系戦略コンサル、スタートアップ取締役などでのビジネス経験を経たのち、データサイエンスに興味を持ち30歳でプログラミングの勉強をはじめてデータの世界に転身。好きな言語はPython。
Section1.
BIチームとデータアナリスト
ミッションは「意思決定力MAX化」
メルカリと開発組織の全体像
メルカリはフリマアプリ「メルカリ」をはじめとして、各種のCtoCサービスを展開する会社です。国内最大のフリマアプリである“メルカリ”を日本で運営しているほかに、US・UKなどでも同様のコンセプトのCtoCマーケットプレイスMercariを展開しています。
USのサービスに関しては、Palo Altoにあるローカルのオフィスでの開発と同時に、日本オフィスでも開発を行っています。そのため、日本オフィス社内のプロダクト開発チームは、大きく2つに別れています。
国内のメルカリアプリの開発を行うチーム（通称「JPチーム」）
US Mercariの開発を日本国内で行うチーム（通称「US@Tokyoチーム」）
会社の特徴としては、まず上記のとおりグローバル志向であることが挙げられます。社内にも多国籍なメンバーが多く、関わるプロダクトによっては海外とのやりとりも頻繁に発生します。
もう1つの大きな特徴として、会社としてもサービスとしても、非常に成長のスピードが早い点が挙げられます。執筆時点でメルカリは5歳の若い企業ですが、サービスのダウンロード数は1億件、登録MAU（Monthly Active Users）は約1,075万人を超えています。
この成長のスピード感は、メルカリで働く上での1つの醍醐味である一方、データ分析チームを含め社内の組織構造では、スピードへの最適化を必要とされるシーンが多く存在します。
筆者について
筆者はメルカリに2016年初期にデータアナリストとしてジョインしました。
入社してからの1年はUS@Tokyoチームで、Mercari USのための分析をしていました。その後、2017年4月から現在まではJPチームで分析をしています。
データ分析チーム全体を率いるマネージャとしての業務をしていますが、自分の時間の半分は実際の分析に使うプレイングマネージャ・スタイルで働いていて、分析の勘所が鈍らないように腐心しています。
続いて、筆者の所属する、メルカリ内で分析を行う専門チーム“BIチーム”の組織について説明します。
メルカリ内の分析を一手に担う専門部署
「BI（Business Intelligence）チーム」はメルカリでの分析を専門に行う部署で、社内のさまざまな判断・意思決定を定量的な分析から支える役割を担っています。所属するメンバーは基本的に「データアナリスト」と呼ばれています。社内的には「BI」という呼称で浸透しており、チームのロゴシールなども存在します。
現状、BIチームの人数は決して多くなく、少数精鋭のチームです。ただ、これからの展開に鑑みて、積極的に採用を行い、メンバーを増やしているフェーズです。日本国内だけでなく、USオフィス（Palo Alto）とUKオフィス（London）にもそれぞれ現地のBIチームが存在します。
ミッション・プリンシプル
分析を専門とするチームを運営するうえで、チームのミッションをどのようにとらえるかは、非常に重要だと考えています。
なぜかというと、“データ”という言葉からは、できること／できると周囲から期待されることが非常に幅広くとらえられます。そのため、自身のスコープと存在意義を明確に規定しておかなければ、業務内容が薄く広くなってしまい、本当にフォーカスしてやるべきことを見失ってしまうからです。
メルカリのBIチームのミッションは「意思決定力MAX化」という言葉で表されると考えています。社内における
- 経営
- 事業
- プロジェクト
- 施策・UX/UIの変更
といったさまざまなレイヤーの意思決定の確度・スピード・納得感（これらすべてを“MAX化”という言葉で括っています）を、定量的なファクトを使って高めていくことが自分たちの存在価値であるととらえています。
逆にいえば、アウトプットの結果が何らかの意思決定に対してインパクトを与える可能性が低い分析などは、最低限に抑えられるように腐心しています。
メタファーとして考えてみると、すごく心配性の人に「明日、雨降りそうって聞いたけど降水確率って何％？」と聞かれるとします。「90%と10%だったらどう変わるの？」と聞き返したときに「どっちみち傘を持って行く」という回答になるようであれば、その場合は結局、意思決定は変わらないので、分析する必要はないと判断します。
数字やファクトというのは、時に必要をこえて過度に頼られる可能性があるので、分析の必要度合いは見極めるように注意しています。
データアナリストの役割
次にBIチームの業務内容について、最初に簡単に紹介します。
BIチームは、メルカリの組織内ではプロダクト開発部の一部として存在しています。プロダクト開発部は文字通りプロダクト、弊社の代表例でいえばフリマアプリ「メルカリ」などの開発と改善などを行い、サービスの成長を目指す組織です。
部内にはプロダクトマネージャ（以下PM）、エンジニア、デザイナー、データアナリスト、マーケターなどが在籍しており、少人数のプロジェクトを組成して各プロジェクトごとに施策のPDCAを高速で回しています。データアナリストは、主にこのPDCAの“Plan”と“Check+Action”に深く関わっています。
"Plan"に関しては主に次図のようなことをデータ分析を通して支援していきます。
プロジェクトの組成初期では、そのチーム全体のKPIやそのブレークダウンを設計し、大枠の方向性やゴールなどの設定に寄与します。また、PMとディスカッションを行い、施策候補を洗い出したうえで、それらの施策のポテンシャル・解決できる問題の大きさなどを可能な限り定量化し、優先度の判断なども行います。
もちろん、こういったプロセスはBIのデータアナリストが独断的に行うものではなく、PMや事業責任者との強い連携と蜜なディスカッションを通して進められていきます。
“Check&Action”もBIチームの力が発揮される場面といえます。
分析チームの役割として、比較的イメージしやすい施策の効果測定などはもちろん行っていますが、単なる効果分析だけでなくそこからの深掘りや改善提案などをより重視しています。
また、「恒常的なCheck&Action」という意味では、ダッシュボードが1つの大きな要素として挙げられます。ダッシュボードの社内的な役割については、Section3 文化／Cultureで詳しく述べます。
本節の冒頭で述べたとおり、圧倒的な成長速度を体現しているメルカリにとって、プロジェクト内および施策のPDCAサイクルのスピードは事業と組織の生命線の1つともいえる要素です。BIチームはこのサイクルのスピードを加速する、もしくは分析によって1つのサイクルの成功確度を上げるうえで重要な役割を担っているといえます。
Beyond the Product
BIチームの業務スコープは主にプロダクトに関係するものになりますが、社内的にも数字全般に精通してる事情から、プロダクト以外にも数値に関する部署との連携を行うことがあります。例として、最近分析に着手しているCS（Customer Support）向けの分析などが挙げられます。
そのほか、広報やファイナンスなどコーポレート系の部署から、外部に公開する数字の相談などを受けることもしばしばあります。また、新規事業の相談をされることもあり、社内でも活動の幅は非常に広く、かつ全社的、プロジェクト横断的に情報をとらえることのできる立場にいるといえます。
プロジェクトの例
いくつかプロジェクトの例を挙げて、BIチームがどのような動き方をするのか、そのイメージを紹介します。
実際にBIチームが扱う範囲は非常に広いのですが、ここでは具体的なイメージをもってもらうために、2つほど例を挙げます。
例① 機能開発系プロジェクト
- アプリ内のどこに特にユーザのペインポイントがあるかを特定（ファネル分析など）
- 施策案洗い出しのディスカッション
- 施策のインパクトのポテンシャルの定量評価
- 現状のペインの大きさを過去の行動ログから推定
- 改善のKPIへのインパクトを試算
- 新機能実装のためのデータログ設計
- A/Bテストなどの設計と評価
- 新機能の分析。効果や利用度合い、KPIへのインパクトなど
例② グロース系プロジェクト
- ゴール目標とKPIのブレイクダウン
- ユーザのセグメンテーション
- セグメントごとのボリュームや特徴の分析
- 施策案洗い出しのディスカッション、施策インパクトの推定
- KPIモニタリングのためのダッシュボードの設計、実装
- 施策の効果測定
次節では、これらの分析業務によるプロジェクトへの貢献度を最大化するために、BIチームの組織体制について紹介していきます。
コラム①
世界3大発明で考える分析チームのミッション
すでに述べたとおり、BIチームの一義的なミッションは「意思決定のMAX化」にあります。これは今後もチームの核をなす要素であり、これ自体が変わることはないですが、チームの拡大や会社のフェーズによって、自分たちのミッションをもう少し広義にとらえる必要が出てくるかな、という可能性も考えています。
その場合に、筆者が最も適していると考えているフレームワークが「世界三大発明」です。世界三大発明とは、「羅針盤」「活版印刷機」「火薬」の3つを指します。
羅針盤=意思決定の支援
羅針盤は、大航海時代に船旅の精度を高め、航海のリスクを低減し、人類が探索できる領域を拡張するのに大きく寄与しました。
これは分析で言うところの、定量化・データを用いた意思決定の支援であり、メルカリのBIチームが最も重要ととらえるミッションはこの「羅針盤」としての機能といえます。
活版印刷=知識の民主化
活版印刷はさまざまな形で人類の活動レベルを上げたといえますが、顕著な例の1つとして聖書の流通が挙げられます。複写にコストがかかっていた時代、聖書は教会にしか存在せず、それが教会への権力集中の一端を担っていた側面があります。
しかし印刷技術の進歩は、聖書を一般市民にも流通させ「重要な情報の民主化」を実現しました。
これを分析の世界でとらえると、SQLなどの分析技術や簡単にデータを探索可能なBIツールの社内普及に近い概念といえると思います。社内の全メンバーがデータにカジュアルにアクセスできるようになることで、データの民主化を興し、組織としての意思決定力レベルの底上げにつながります。広義でみるとこれらはメルカリのBIチームのミッションといえるでしょう。
また、後述するゆるふわBIといった活動や、ダッシュボード文化の普及などと関連した領域であると考えています。
火薬
火薬は、古代において基本的には国家の戦力 = 兵士の頭数という単純な形で決まっていた国力の概念を覆し、「武力のルールチェンジ」を巻き起こしました。
現代においても、テクノロジーの勃興が従来の労働集約型のビジネスモデルにありがちだった、会社の組織規模=会社の生産力という概念をさまざまな分野で覆しています。特に近年で発達と普及がめざましく、データ分析と関わりが深いのが機械学習です。機械学習は現代のルールチェンジの道具つまり21世紀における火薬であるといえます。
社内のMLチームと共同しながら機械学習を推進することも、将来的にはBIチームの重要なミッションの1つとなるでしょう。
Section2. 組織／Organization
ハイブリッド型組織がどのように機能しているのか
本節では、組織内でのBIチームの位置づけと体制について説明します。
メルカリのプロジェクト運営方針
まず、分析チームとしての組織体制の話をするまえに全体の理解のためにメルカリ全体の経営体制と組織の組成の方法について説明します。
メルカリでは、4半期ごとに経営目標を定め、それにそってプロジェクトチームの編成を行い、各チームごとにそれぞれが細かい方針を決めて活動する、という経営サイクルを採用しています。
プロジェクトは、期ごとにフォーカスするKGIを分解する形でテーマを与えられます。たとえば、次に挙げるような粒度でテーマを分けます。
「キャンペーン施策」
「新機能」
「UX向上」
「ユーザ獲得」
BIチームのデータアナリストも、これらのプロジェクトのテーマにそって必要となる分析を展開していくことになります。
BIチームの位置づけ
メルカリでは、BIチームは組織横断的なチームに位置づけられ、そこに所属する各アナリストが開発プロジェクトを分析面で支えています。
各アナリストは、基本的に1つのプロジェクトチーム（場合によっては複数）を半専属的に担当し、BIチームという横軸組織に属しつつも日常業務では担当するプロジェクトチームの一員として動きます。
BIチームは、座席としてまとまって座っているわけではなく、それぞれ各PJO（プロジェクトオーナー：各プロジェクトのリーダー的な存在）の近くに座って仕事をするようにしています。
そのため、公式の組織図の上では横断組織として存在しながらも、実質的には各プロジェクトチームの一員としての位置づけの方がウェイトとしてははるかに大きくなっている、ハイブリッド型の体制になっています。
BIチームとしての活動
このため、BIチームのアナリストは個別で1人のプロフェッショナルとして動くことが多く、比較的アナリスト同士が一緒に活動する機会は限定されています。
1週間の中でチーム（もしくは複数のアナリストが共同する場）の活動は最低限に留められ、具体的には次に限られます。
・毎週月曜45分のスタンドアップミーティング（通称SM）
・週1回のチーム定例60分
SMは主に、
①各メンバーが今週取り組むタスクの大まかな共有
②先週の分析アウトプット
の共有を行う場です。お互いが取り組んでいる課題を把握しておくとともに、分析の内容に関する議論や知見の共有などもここで取り交わされます。
チーム定例では、BIチーム全体としての活動が必要な案件（ツールのリプレイスや採用関連、社内の分析教育など）についての推進がメインの目的です。
そのほかに時として必要となる管理監督的な業務や、細かいやりとりなどはほとんどをSlack上で行っています。
もちろん、入社して日が浅いメンバーに対してのメンタリングや教育、またアナリスト同士での分析相談などは上記の枠組みとは別に行われており、そういった場面では複数のアナリストが一緒に活動する機会は用意されています。
この組織体制を採用する理由
メリットとデメリット
このハイブリッド体制を敷く意図について少し説明します。
一般的に、データ分析チームを横断組織として存在させることには、メリットもデメリットも、それぞれあると考えられます。横断組織としてのメリットとしては、次の3点が挙げられるでしょう。
①スキル育成・標準化：
同様のスキルセットを持ったメンバー同士で集まることで、相互的なスキルの向上や、ベストプラクティスの交換などが進みやすい
②人事評価：
同職種同士であるゆえに、技術面の評価などが比較的フェアに行える。またキャリアパスなどの議論がしやすい
③アサインメントの柔軟性：
どのチームの範囲にも属さないような仕事、ボールを拾いやすくなる。一定スパンでの担当のシャッフルなどがしやすい
逆に、デメリット面としては次のような項目が該当するのではないでしょうか。
・プロジェクトへの帰属意識が薄れるため、実務上で成果につながる動きをしづらい
・特定のドメイン知識が身につかず、筋の良い仮説が作れない
・チームとしての壁があるため、すべてにおいてスピードが遅くなる
現状のメルカリの事業運営では、ここで挙げた「デメリット」に該当する項目を克服することが非常に重要であり、それがBIチームとして、今のようなハイブリッド体制を敷いている理由にもなります。
ベンチャー企業メルカリで大事なこと
メルカリは前述のとおり、組織・事業の両面で成長速度が非常に速く、また社内にいるメンバーたちのスピード感に対する意識も非常に高い会社です。
そのため、BIチームが一般的な機能型の横軸組織として、「普段はチームとして固まっていて、分析のニーズや依頼に応じてプロジェクトをサポートしに行く」という形式を取っていると、プロジェクトメンバーが期待するPDCAのスピード感に対して、BIの分析アウトプットのスピードやクオリティがまったく合わなくなることが予想されます。
プロジェクトチームの運営では非常に多くの情報が取り交わされており、前提条件やプロジェクト内の環境も目まぐるしく変わっていきます。例として、日々プロジェクトのSlack上でさまざまな情報が流れています。またプロジェクトチームの席でも頻繁に口頭でさまざまなディスカッションや意思判断が行われており、外部からこれらの状況をキャッチアップすることは容易ではありません。
これは一般的な会社でも当てはまると思いますが、事業のスピード感を何よりも重んじるメルカリにおいては、この状況はより切迫したものです。
そういったチーム固有のドメイン知識や前提条件といったものが、プロジェクトにとって意味のある分析には必須の要素であると私達は考えています。
そのため、プロジェクトの最前線にチームの一員として身をおくことは、分析で価値を出すための必要最低条件ととらえ、今のような体制（=担当するプロジェクトへの一意なアサインメント、物理的な距離を含めたプロジェクトチームへのエンベッド）を敷くことにしています。
また、ややエモーショナルな話になりますが、プロジェクトの成功においては、プロジェクトチームとしての一体感が実は非常に大事だと考えています。チームの一員として、分析・提案をするからこそ信頼されることもあるし、実践的な提案ができるという側面があるのは無視できません。また、アナリスト本人のやりがいにもつながる部分だと思います。
ハイブリッド型の問題の克服
しかしこの体制によって、いくつかの運営上のデメリットが生じがちになるのも事実です。それをどのように克服しようとしているかについて説明します。
人事評価
この体制における1つの問題点として、人事評価の難しさが挙げられます。各アナリストが独立して働いているため、マネージャの私から見たときにメンバーの普段の活躍ぶりやパフォーマンスの視認性が低く、一般論として考えると人事評価が困難になる傾向にあります。
この点に関しては、次の3つによって大部分を克服できると考えています。
・マネージャ↔メンバーでの頻繁な1on1
・評価の基準を標準化し、公表する
・プロジェクト側のメンバー（主にプロダクトマネージャ（PM））に協力をしてもらう
特に重要なのは、アナリストがアサインされているプロジェクトメンバーの協力です。BIチームでは四半期ごとの評価の際に、パフォーマンスレビューのためのヒアリングを15件ほど各PMと行っています。
1人のアナリストについて平均3〜5名のPMにレビューを依頼します。このときに大事にしているのは、次の2点です。
・レビューしてもらう項目をこちらで提示し、全PMで揃える
・同じアナリストのレビューでも、PMのシニア度によってヒアリングの場を分ける（シニアなPMとジュニアなPMでは観点が違うため。また、同じ席では概してシニアなPMの発言が多くを占めがちになる）
15件のヒアリングは、セッティングや準備、実施とレビュー内容の総括などを含めて決して少なくない工数がかかりますが、普段ある程度独立して仕事をしてもらっている（=マネジメントコストが低い）分、ここにはコストをかけるべきと考え、毎期必ず実施しています。
毎期末に定期的に行うことで、同じPM↔アナリストの組のレビューでは、アナリストの成長や変化に関して多くの示唆が得られます。
場合によっては、キーとなるPMとは隔週程度で1on1を行い、プロジェクトの状況と担当アナリストのパフォーマンスや課題点をアップデートし、育成の方法を話す体制を敷くこともあります。
メルカリでは、1on1は推奨されているコミュニケーション経路であり、マネージャの私とBIチームの各メンバーも毎週必ず30分の1on1を設定しています。1on1の内容は必ずしも画一的なものではありませんが、自身のプロジェクト内での近況やパフォーマンスについては一定期間ごとに聞くようにしています。このパフォーマンスの自己認識と周囲のPMからのレビューを加味して、人事評価やフィードバックを行っています。
繰り返しになりますが、これらの1on1や幅広いPMへのヒアリングはそれなりに工数を必要としますが、現状のBIチームの体制のうえでは必須であり、そこには時間を割くべきとの確信のもと、決して疎かにしないようにしています。
アサインとローテーション
アサイン、つまりどのアナリストがどのプロジェクトを担当するかは難しい問題の1つです。これについては、次を総合的に判断して決めていくことになります。
・プロジェクトの重要性
・データ分析が貢献できる余地の大きさ
・アナリストの適性／興味
幸い、メルカリでは4半期ごとに経営指標の優先順位が明確に提示され、どのプロジェクトがどの経営指標と関連するかがある程度明示されるので、これをアサインの優先度の参考にできます。
ただし、メルカリでは経営としてどういったプロジェクト領域に優先度を置き、リソースを投下していくかの判断が非常に柔軟かつダイナミックに変わっていくことがあるので、四半期ごとの注力テーマやプロジェクトの内容が前期を単純に踏襲しないということがよく発生します。そのため、アナリストが取り組む分析のテーマも、期ごとに大きく変わる可能性を秘めています。
もちろん、複数の期にまたがって特定のテーマのプロジェクトに一貫して関わってもらうことが基本的には多いのですが、経営レベルでの優先度見直しなどで、重点が置かれるプロジェクトが変わる局面などでは、大胆なアサイン変更を断行します。
たとえば、1年近くUS市場のマーケティングの分析を担当していたアナリストが、次の四半期は日本市場のCS（お客様からのお問い合わせ）の分析に変更ということもあります。
また、明示的にアサインされたプロジェクト以外でもアナリストの得意分野や活躍の幅によっては、周囲の別のチームから声がかかり、アドホックなヘルプや助言を求められるといった機会も頻繁にあります。
そういった、各自の活動範囲の拡張については（もちろん必要な場合は筆者がマネージャとして交通整理や工数管理に入ることはありますが）基本的にアナリストの自主性にまかせています。そのため、場合によっては単一のプロジェクトを超えて、かなり幅広い範囲で活躍することもできます。
このシチュエーションにも対応するため、アナリストの採用では特定のプロジェクトテーマでなくより汎用的な場面でも活躍し得る人材、具体的には分析力だけでなくや論理的思考力、問題整理力などを重視したタレントの獲得に力を入れています。この点については、後述のコラム「採用」で詳しく解説します。
次節では、メルカリ内のデータに関する文化背景や取り組みについて述べます。
Section3. 文化／Culture
全社員のデータ感度／リテラシー向上への取り組み
社内のデータ感度
データアナリストが社内で幅広く活躍するためには、社内の「データリテラシー」のレベルは非常に大事です。これはデータ分析に関わる方、もしくは社内のデータ分析部署の活躍を望んでいる読者のみなさんも痛感していることであり、議論の余地なしではないかと想像します。
これは個人としての感覚値になる部分も大きいですが、メルカリはデータに対する意識やリテラシーが比較的高い会社ではないかと思っています。具体的には、
・取締役や執行役員でも必要な場合にはSQLを書いている
・データを使った客観的な根拠のある施策判断が推奨されている
・多岐にわたる職種がSQLを書いてデータの抽出などに励んでいる
（具体的には、PMはもちろん、経理や広報、財務、CSなど）
このように全社的に数字による状況の判断と意思決定、施策アクションの定量的な振り返りが重んじられており、また個々の分析スキルは職種を問わず重要なものとしてみなされています。
そのため、組織内でBIチームの果たす役割は大きく、社内的に部署としての十分なプレゼンスを発揮できている実感は強くあります。
分析のスピーディな共有
データの分析結果がどのような形で共有・報告されているのかについて紹介します。結論からいうと、社内での分析結果のデリバー（提供）はかなりカジュアルな形で行われます。
分析の報告というと、PowerPointでレポートを作成してミーティングを招集して関係者に分析の目的・使ったデータや手法・そして結果を報告...といった形式を想像するかもしれません。その一般的なイメージに反して、メルカリでの分析結果の共有は、極めて簡潔・スピーディに行われることが大半です。
最も多いのは、分析の結果（インサイト）がすぐにわかるようなグラフやWiki（共有ドキュメント）などを作成して、Slackに投稿しておしまい、というパターンです。場合によってはWikiすら作成せずに、チャートの結果を直接Slackに投稿しています。それからSlack上で議論が発展→近席に座っているPMなどのチームメンバーとディスカッションに発展といったように、分析を受けて考察やアクションが進んでいきます。
分析の結果が『誰からでも見れるようになっている』『結果が出たら即時共有』というのが重要なスタンスです。これによって、Slack上で分析結果を見た人は誰でもオープンに意見ができ、さらにPDCAサイクルの高スピード化にもつながります。分析の結果をわざわざレポートとしてまとめたり、共有のためにミーティングを設定したり、ということを行わないのはこういった背景が大きく作用しています。
このように書くと、非常に単発的な分析ばかりしているようにも思えてしまうかもしれません。補足しておくと、大きな意思決定に関わるデータなどでは、さまざまな角度から多種に渡る分析を行う必要が出てくるため、時間をかけて分析をし、Google Slideなどでまとめてメンバーにプレゼンするようなケースもあります。
これは主に、事業の戦略上で重要かつ社内の幅広いメンバーに関わる分析として、多くの関係者の間でデータや事実に関する理解を共通させることが目的です。良質な分析のスライドは、多くの関係者に繰り返し見られ、企画や戦術を立てる際のスターティング・ポイントとなることもしばしばあります。
データリテラシーを形成するための取り組み
元々の文化としてメルカリのデータリテラシーは高いレベルにありましたが、最近ではBIチームの活動によってデータへの感度をさらに高めるような流れを作っていきたいと考えています。そのために行っている具体的な取り組みについて、いくつか紹介します。
ダッシュボード文化の加速
ダッシュボードは社内のデータに対する意識を高め、数字にもとづいたPDCAを浸透させる上で重要な役割を担っています。また、日々の数字をモニタリングしKPIの変化などを監視するのに役立ち、施策が打たれた際に効果の度合いを簡易的にとらえるためにも使われます。
こういったダッシュボードの設計・実装もデータアナリストの重要な仕事ですが、特に重視しているのは誰もがいつも確認したくなる「愛されダッシュボード」を作れるかどうかです。ダッシュボードは社内の関係者に広く見られてこそ価値があるので、常に確認したくなるものを作ることにこだわっています。
具体的には、グラフの系列の数や色使いなど、細部が見やすいような設計にはこだわるべきだと考えています。そのほかにも、なるべく見る側の気持ちが「燃える」ような工夫も大事な要素です。たとえば売上の目標に対する実績を示す場合、日々の数字がただ表示されているものと、1日1日積み上がって達成に向かっているものでは、後者の方が見た目にも面白く、見る人を燃え上がらせます。
また、ほとんどのKPIは1日1回程度の更新でよいのですが、流通高や出品数など、特にキーとなるデータに関しては、ほぼリアルタイムで数値が見える「Live」というチャートを用意しています。これは数字に敏感な企画者は頻繁に観察していますし、施策を打ったときにすぐに効果を実感できるので、ダッシュボード上でも人気の高いコンテンツです。
地道ですが、こういったしくみを散りばめることで、ダッシュボードのチェックの頻度が上がり、数字に対する意識や感度が高まることにつながっていくと信じています。
なおダッシュボードに関しては現在（執筆時点の2018年7月時点）はChartioというツールを使っていますが、現在進行系で「Looker」という新しいダッシュボードプラットフォームに移行中です。
Lookerは非アナリストがより能動的・主体的に数値分析を行いデータを取れるように最適化されているツールです。社内のさらなるデータ文化形成に一役買ってくれるのではないかと期待しています。
Chartio/Lookerのどちらもアメリカの会社によって運営されているもので、USオフィスで実用が先行したあとに日本でも導入した形になります。USオフィスの存在によってグローバル基準のツールの選定・導入が行われているのはメルカリの特徴の1つです。
SlackへのKPI投稿
多くの社員の意識を数字に向けるために、さらに発展した形として「SlackへのKPI投稿」があります。基本的にプロジェクトの運営に必要となる数字はダッシュボードに集約されています。
しかし、それを見るという行為も言ってしまえば「一手間」がかかる上に、あくまでも「プル」のしくみです。よって「プッシュ」のしくみを用意することが大事だと考え、トップレベルで重要な数字に関しては、プログラムを組んでSlackに毎朝投稿しています。
これによって、毎日全員が数値をしっかり追う癖が付き、データに対する興味と感度が上がります。それに加えてしばしばSlack上で議論が起こることも良い点だと思っています。
「昨日いきなり数字が上がったんだけどこれ何？」のように、誰かが言い出すのです。1人でダッシュボードを見ていては誰とも会話になりませんが、Slackで会話をはじめることで、何が起こっているのか究明しやすくなります。したがって、KPIの状況が設定したビジネス目標と乖離している場合などは、いち早くSlack上で議論が展開され、追加の施策が検討されます。こういった事業運営のPDCAを加速する上でも、シンプルながらこの取組みから得られるものは大きいです。
ゆるふわBI
日々、さまざまな分野で多種多様な分析ニーズが発生するメルカリでは、すべての分析をBIチームだけでこなすのは現実的ではなく、かつ非効率です。最も理想的なのは、簡単なものであれば、BIチームが介在せずに各部署でその分析を実行して問題を解消できることです。
そうした背景から立ち上げたのが「ゆるふわBI」通称「ゆB」と呼ばれているプログラムです。
これは2018年からスタートしたのですが、各部門のデータ分析が好きなメンバーを集めて、わからないことを聞けたり、一緒に勉強できたりする言葉のとおりゆるい組織です。
社内Slack上のゆるふわBIプロジェクトのチャンネルには今は100人以上（職種も経理、広報、財務、CS、エンジニア、マーケターなど多岐に渡る）のメンバーが参加しており、データ分析に関するさまざまな質問と回答が飛び交っています。
やりとりされる内容には、クエリの文法に関する簡単な質問から、過去の分析の知見、テーブル構造やカラムの定義、BigQueryのアップデート情報など、バラエティに富んでいます。
「ゆるふわ」という名前にもあるように、ここではどんな初歩的な質問でも受け付け、絶対に誰かが返信するという雰囲気を作ることで、誰でも質問できるようにしておくことで、社内メンバー全体の能力向上に貢献しています。週に一度行われる定例会では、参加メンバーが最近行った分析を共有したり、分析で困っていることを持ち寄って質問したりしています。
この定例会も有志で参加できる形式のため希望者が非常に多く、最近ではチームを複数に分けて実施するまでのコミュニティに拡大しています。
四半期ごとにゆBメンバーの中から数名の立候補を募って、BIチームのメンバーが1on1で集中的にSQLと分析の指導を行う「SQLブートキャンプ」という取り組みがあります。これは、特にデータ分析力を強化したい有志が3ヵ月にわたって分析のアウトプットを作っていく教育プログラムです。
※下記図はブートキャンプ参加者の分析例。メディア発表に使われた
まず、ブートキャンプの生徒は分析をするテーマを決めます。そして、週に1時間アナリストと1on1の相談時間を確保し、そこで具体的な質疑や本職の分析者の指導を受ける権利が与えられます。この際、自身の業務に関連が深い分析テーマを選んでもらうようにしています。さらに、週一のゆB定例会での発表が決められており、週次で進捗が出るようにコミットすることを求められるとともにモチベーションを保つことで、データリテラシーを上げるしくみです。
Query Recipe
GitHubに過去のクエリを蓄積していく「Query Recipe」という取り組みをはじめています。
書いたクエリにはその人のノウハウが詰まっており、分析業務は意外と属人化しやすいところがあります。分析に使ったクエリをどこかに集めておけばいろいろとメリットがあると考え、GitHub上にメンバーが書いたクエリをアップしています。社内の非アナリストには、クエリの雛形さえあればそれを改変して自分で実行できるくらいのレベルの人が多いです。過去に分析に使われたクエリの集積には大きな意味があるという思想のもと、このしくみを作りました。
実際、BIチームのメンバー同士でも「この分析方法は知らなかった」ということも時としてあるため、クエリの共有は大事だと考えます。また、これからチームを拡大するにあたり、新しいメンバーのラーニングコストを下げることにもつながります。もちろん先述の「ゆB」のメンバーの参考にもなります。
まとめ
本稿ではメルカリ社内の分析に関するさまざまな取り組みと文化を紹介しました。これらの取り組みの背景には、何をおいても「メルカリという組織」全体が持つ性質が深く関わっています。それはすなわち次に挙げるような要素です。
- プロダクトの成長速度と、それを支える組織全体のスピードに対する意識の高さ
- 事業や組織構造の変化・流動に対する適応の必要性
- 経営から執行レベルまでデータを重視するカルチャー
分析チームの組織づくりや社内での取り組みについては、企業の規模やフェーズによって、千差万別のやり方があると思いますが、スピード感を持って事業を推進し結果を出すことにこだわりたい組織や、データリテラシーの素養があり、それを一段と高めていきたい会社などでは、参考にしていただけるような情報になっていれば幸甚です。
また、メルカリの組織の強さと文化は、一にも二にも優秀な社員の採用によって形成・維持されています。弊社のデータ分析文化の雰囲気を感じ取っていただいて、共感できる方はぜひ門戸を叩いてみてください。
コラム②
採用について
本コラムでは、BIチームの採用の考え方と採用基準などについて紹介します。
分析フローにおけるフルスタック
具体的な採用基準について紹介する前に、メルカリのデータアナリストが行う業務のプロセスを可視化すると、下記の図のようになります。細かい違いはあれど、だいたいの会社ではデータアナリストが業務でバリューを出すためのフローはこれに近いと思います。
メルカリでは、基本路線としては、図の①〜④のどこかが突出して優れている（そのトレードオフとして苦手なステップがある）というタイプよりも、全能力がバランスよく高いという人材を採用するようにしています（※2018年7月執筆時）。
これは組織の話でみたように、各アナリストがそれぞれ独立してプロジェクトチームに入り込み、担当したプロジェクトの分析に関する業務を川上から川下まで一手に引き受ける、というスタイルを必要とするからです。
ひとりひとりが独立して課題の発見から分析の要件の設計・分析の実施とデリバーまで行えるフルスタック的な能力を持っているため、一緒に働くプランナーにとって非常に頼りになる存在として認知され、スピーディな業務展開が可能になります。
勇者型アナリスト
筆者はこのようなプロセス完結型のスキルセットを揃えた人材を、「勇者型人材」と呼んでいます。これはゲームの勇者のように、戦えば強く、攻撃魔法・回復魔法などのひととおりのスキルセットを備えているバランスの良い人物のたとえとしての呼称です。
現実世界のデータアナリストは魔法が使えるわけではありませんが、一般的に下記図で示すようなスキルと特徴を持っていると考えています。
これらのスキルをすべてバランスよく備えた人物がメルカリのデータアナリストとして理想的な候補となります。たとえて言うなら、BIチームは勇者のたまり場でそれぞれがいろいろな世界（プロジェクト）を救うため個々で旅に出ていきます。
採用のためのチーム内言語
この基準に当てはまる人物を採用するために、チーム内では採用基準を下記図のように3つの要素に分類して考えています。
これはもともと、ギリシャの古代哲学者のアリストテレスが、自著で述べた「人を説得するのに重要な3要素」を引用して、現代の企業人風に再解釈したものです。
パトスとは英語で言うところの「Passion」で、メルカリで働くにあたっての熱意や動機などがマッチしているか、という観点を表しています。
エトスとは英語で言うところの「Ethic」で、広い意味での人間性ととらえて解釈しています。具体的には、コミュニケーションのとり方やチームでの協働がちゃんとできる、周囲から信頼を得られる人間性なのか、という観点を表しています。
ロゴスは英語と言うところの「Logic」で、自分が主張したいことを論理的で説明可能な形に落とし込むスキルを有しているか、という観点を表しています。ロジカルな思考ができるかどうか、という点や分析の設計から定量化までが適切にできるか、という点が該当します。
データアナリストとしてのハードスキルという意味では一般的にはロゴスに依るところが大きいと考えますが、メルカリ社内では価値を出すためにパトス／エトスのような、ソフトスキルも非常に大事であるととらえているため、この3つの項目は並列に置かれています。
BIチーム内では採用候補者の評価は実際にこの3つの項目で行い、評価シートの記入もこの項目にそって設計されています。面接官から面接官への引き継ぎも、この3項目にそって行われます。
また、候補者のことをより詳細に理解するために、この3項目をさらに「今後身につけることができるタイプの素質かどうか」で分けて考えています（これを便宜的に先天的要素・後天的要素）と呼んでいます。
たとえばパトス（=情熱）については、メルカリという事業に対しての関心や熱意は、面接などを通して理解を深めることで高まっていく可能性はありますが、「データ分析を通して何かを実現したい」などという、仕事そのものへの熱意を醸造することはより難しいと考えられます。
よって前者は後天的要素、後者は先天的要素に分類し、先天的要素の方をより重要視して評価しています。
----原文ココまで
最後に
長文を読んでいただきありがとうございました。
『データサイエンティスト養成読本』は僕以外の方の章が更に面白いので、興味ある方は是非とも書籍の方を手にとって見てください。
ではまた、別の記事でお会いしましょう。
いいなと思ったら応援しよう！
