データ分析のマネジメント論１：データ分析組織とは何か
この記事について
以前、個人のデータキャリアを振り返る記事を投稿しました。この記事ではN=1のエピソードを書くことでアナリストキャリアの解像度を多少でも上げることを目的としていましたが、その後マネジメントを続けていく中で、また社外のアナリストの方々と話す中で、データアナリストの評価や育成について考える時間が増えました。
そもそも、データアナリストの評価基準はまだ様々な議論があり定まっていないような気がします。データ分析は「データを使って意思決定をサポートすること」という方向性は納得されていても、何を持ってその状態が達成できているかが言語化されていないために、組織としてあるべき姿やメンバーの動き方が定義されていない、という背景があるかもしれません。
加えて、意思決定の価値を定量化することは難しいです。チームの分析活動をROIで表現しづらかったり、それとなく成果を出していて周りからの信頼も厚ければシニアと認識される、といった標準化されていない評価がメンバーの成長を妨げたり、と様々な粒度で悩みを抱えているマネージャーの方は多いと思います。
この記事では、組織の成長フェーズとともにデータアナリストをどのように評価・育成していくのか、私個人の考えを整理したいと思います。当然、すべての分析組織に当てはめられるものではないですし、あくまでも私論ではありますが、少しでも組織マネジメントについての議論のタネになればと願っています。
Disclaimer
● 所属組織における評価や採用基準についての言及ではありません。
● toCのモバイルサービス（ゲーム、タクシー配車、オンラインデーティング）での著者の経験をもとにまとめています。なるべく一般化できることを意識したつもりですが、当てはまらないドメインや組織もあると思います。
● ある程度成熟した分析組織の話になります。データ基盤が運用されていて、KPIのモニタリングやアドホック分析が周っているフェーズの組織を念頭に置いています。
● データサイエンティストや機械学習エンジニアについての言及ではありません。「社内の意思決定のためにデータを使うアナリスト」にスコープを限定し、DSやMLについてはまた別の機会にまとめられたらと思います。
● 同様にデータマネジメントについても言及は少ないです。
● どちらかというとマネージャー向けの内容になります。
このテーマは2本構成になっています。1本目の本記事では、データ分析組織のフェーズと活動範囲について整理し、続く2本目の記事では、アナリストの成長を「ジュニア」「ミドル」「シニア」の3フェーズに区切って、それぞれの境界線がどこにあるのか、マネジメント方針をどのようにするべきかについて探っていきます。かなり長い記事になってしまったので、必要に応じて飛ばして読んでください。
本記事で想定しているデータ分析
一言にデータ分析といってもとても、その生態系には様々な要素があります。本記事では事業会社における以下のような分析機能を想定します。
ステークホルダー
事業活動をする上で「意思決定に必要な数字を知りたい」というニーズはたくさんあります。本記事では（主に）経営陣やプロダクト開発チームの分析ニーズを念頭に話を進めますが、実際の活動範囲はマーケティング、カスタマーケア、財務など多岐に渡ります。何をカバーするかは、分析組織の規模やフェーズ、ケイパビリティによって変わります。
データ
主に、サービス内行動ログなどのデジタルデータを想定しています。これらのログはバックエンド・フロントエンドエンジニアによって実装され、データエンジニアによって管理・運用されているかもしれません。アナリストは分析システム側のステークホルダーとも連携する必要があります。
また、アンケートのデータ、ユーザーインタビューの発言録といった、定性調査の成果物を扱うこともあります。本来的には定性調査活動はその分野の専門性が求められるため、リサーチチームのような独立した組織に切り出されるべきですが、アナリストが分析技術の1つとして身につけて対応する、ということもあるかと思います。
主な活動
指標のモニタリングや様々な分析ニーズへの対応が主な活動です。これらはすべて適切な意思決定のために行われ、場合によってはアナリスト自身が施策を提案する動きも念頭においています。
分析手法
SQLを用いたクロス集計を基本としています。機械学習を使うこともありますが、あくまでも意思決定のための活動にフォーカスし、AI機能開発は含みません。先に述べた定性分析の技術含め、クロス集計に閉じない様々な手法の引き出しを広げていくことも想定しています。
ここで強調したいのは、分析組織の役割は限定しづらいということです。特にチームの立ち上がり期では、アナリストがデータエンジニアを兼務している場合もあるでしょうし、「アナリストは分析依頼に答える存在」という役割を超えて主体的に施策を提案していく場合もあるでしょう。組織やドメインの数だけアナリスト像は異なっているのが現状です。「データアナリストが何をする人なのか」に関しては様々な議論があり、多くの「べき論」は、アナリストの境界をどこに置くか、という議論と重なっていると感じます。
本記事は「アナリストの境界について何が正解か」を述べるものではありません。私自身、プレイヤーとしてはどんどん役割を越境してなんでもできるジェネラリストになってみたいと思う一方で、マネージャーとしてはどのように役割に線を引くか（やらないことを決めて、個に依存しすぎない仕組みを作るか）をずっと考えており、両者の立場はそれぞれ理解できます。この問題はどこまで行ってもグラデーションでしか語れませんが、本記事ではせめて、いくつかの観点を提示することで、境界を考えたり言語化したりする助けになればと願っています。
データ分析組織の活動範囲
そもそも、分析組織は何を目的に活動しているのでしょうか？詳細は後ほど書きますが「分析組織は事業にまつわるあらゆる不確実性を下げるために活動している」というのが本記事の立場になります。データ分析組織が立ち上がったとして、その後どのような課題に直面するのか、課題に対してどのように向き合っていくのか、を大きく3つのフェーズに分けて概観してみます。
立ち上がり：事業のヘルスチェック、FP&Aができる
会社が事業を行っている以上、データ分析で最も重要なのは事業状況を正しく理解する活動 です。
● マネタイズやユーザーベースといった見るべき指標が定義されていてモニタリングできていること
● 数理モデルによって将来の事業状況を予測できるようになること
● 指標を因数分解して注力課題を見極められていること
といった、基礎的な分析活動が求められるフェーズです。事業の羅針盤となるKPI（Key Performance Indicator）やNSM（North Star Metric）が作られて管理・運用されていたり、LTV/CAC のようなフレームが運用されていたりするでしょう。アナリストは恐らく1人組織化か、そのような役割が明確化されていない状態で、データ基盤もほぼない状態かもしれません。
このフェーズでは、意思決定のスピードが何よりもクリティカルなので、（場合によっては多少の非効率も許容しながら）とにかく数字を出して、整理解釈して、経営陣の投資判断をサポートする動きが求められるはずです。立ち上がり期に意識すべきは主に以下の3点になるでしょう。データ組織の評価もこれらに連動するはずです。
1. Financial Planning and Analysis（FP&A）を機能させること
FP&Aはデータ活用の基本項目です。事業の予測ができないことには何も始まらないので、サービスのヘルスチェックやレポーティングの仕組みをまずは機能させましょう。
2. 事業のフォーカスを決めること
分析チームが立ち上がった初期から闇雲に分析しても仕方がありません。解像度を上げ過ぎるのではなく、サービスの大局観を捉える分析をしましょう。様々なフレームがありますが、以下の記事はとても分かりやすく、初手の分析として取り入れ易いと思います。
3. データ基盤に投資を始めること
このフェーズでは、効率を犠牲にしてでも数字を出す動きが求められるかもしれません。もちろん初期はそれでいいかもしれませんが、並行して次のフェーズを見据えたデータ基盤への投資はすべきです。事業が成長すると分析要求は加速的に増えますし、データ基盤の負債によるデータ不整合に悩まされながら、肥大化していく分析ニーズとガバナンス要求に応えていこうとするとすぐに破綻します。
経営陣がデータ投資の重要性を理解していれば、なるべく早いタイミングで基盤整備のための工数をアサインしてもらいましょう。仮に理解されていなかったとしたら、数字を出しながら経営陣との信頼関係を作って、要求を通しやすくする、などのアプローチが必要かもしれません。
立ち上がり期では、このような泥臭い活動のもと、3項目を達成することを目標ラインに置きましょう。
指標の設計について
そもそも初期にどのような指標を設計しフレームを運用するべきか、というのはとてもこの記事でカバーできる内容ではないので深堀りしませんが、例えば指標設計に興味ある方は以下のa16zの記事が実例も豊富で面白いです。また、KPIの設計方針やOKRといったフレームについても様々な書籍があるので参考にしてみてください。
効率化: 分析依頼に効率的に応えられるようになる
立ち上がり期を超えた次に待ち構えているのは、分析のスループットをどのように拡大するかという課題です。このフェーズでは、KPIのような大きな粒度の指標だけでなく、プロダクトをより解像度高く理解することが求められてくるはずです。例えば、
● 様々なディメンション（切り口）によるKPIの分解
● ユーザーのペインを理解するためのファネル分析
● 課金に至る導線のボリュームの分析
● ヘビーユーザーのN=1分析
など、サービス改善の方向性を定めるための様々な定量分析が走るでしょう。
定量分析だけでなく、ユーザーアンケートやエクストリームユーザー分析といった定性分析にも関与しているかもしれません。さらに、ユーザー行動に関わるものだけでなく、パフォーマンスマーケティングのためのパイプライン整備、カスタマーサポートの運用支援なども分析ニーズとして立ち上がってくるでしょう。ここまでくると、もはやアナリストの努力でカバーするなんて悠長なことは言ってられません。肥大化する分析ニーズに早く正確に答えを出していくために、分析プロセスの効率化と標準化に全てを投入すべきです。
分析依頼をチケット制にしてチームのパフォーマンスを測定可能（Measurable）にしたり、メンバーにドキュメンテーションを促して属人化を排除したり、データマネジメントの観点からも、ログ仕様の標準化やデータカタログ運用、データ基盤のSLA運用などなど、やることは大量にあるはずです。
分析チームのマネージャーは、とにかく仕組み化・標準化の鬼になって、数少ないデータアナリストで最大のスループットが出せるようにしましょう。メンバーのパフォーマンスは「対応した分析案件の難易度・量」と「業務効率への寄与度」の2つの側面で評価されていくでしょう。
このフェーズはかなり息の長い活動になると思います。単にデータ出しをするだけではなく、プロセスを見直して仕組み化して評価する、という反復を何度も繰り返す必要があり、データエンジニアや他チームともコミュニケーションを取りながら仕組みを定着させていきます。どこに効率化する余地があるのか定期的に整理して、優先度を決め、測定可能な指標や理想状態（例えばチケット完了率、対応時間、など）で振り返りをしましょう。ここを疎かにすると「チームがずっと頑張り続けてるにも関わらず作業量だけが増えていく」という状態になりマネジメントのハードルが上がっていきます。例えばエウレカでは、データ基盤文脈ではありますが以下のような仕組み化の努力を継続して行っていました。
高度化：主体性を持って不確実性を最小化する
ここまでくると、データ分析組織としてはかなり形になっていると思います。基本的な指標のモニタリングだけではなく、細かい粒度の分析依頼にも応えられるようになっており、社内でもその活動は十分認知されていることでしょう。ここで改めて「分析組織はなんのために存在しているのか？」という問いに立ち戻ってみます。人によって様々な答え方があると思いますが、「事業にまつわる不確実性を下げるため」というのが私個人の回答です。
例えば、ある新機能の利用が特定のユーザー属性に偏ってしまっているのではないか、という仮説をPdMが持ったとして、これを実際にログから検証すれば、これまで分かっていなかった不確実なことが確実な情報に変換されます。同様に、
● MAUを様々な切り口で分解して、どのようなユーザーが定着しているのか知りたい
● 離脱してしまうユーザーがどのように機能接触しているのか知りたい
といったプロダクトの使われ方やユーザー特徴に関する不確実な仮説を、定量的に評価して、確度の高い情報に変換していきます。
これらの仮説は、実際にプロダクトを作り込んでいるPdMや企画職の方から出てくるものなので、これまであえて「分析依頼に応える」という書き方をしていましたが、場合によってはアナリストが数字と向き合う過程で、主体的に仮説を持つこともあるでしょう。
では、分析組織が向き合うべき不確実性にはどのようなものがあるのでしょうか。名著『エンジニアリング組織論への招待』では、不確実性についてとても分かりやすい整理があります。
まず、環境不確実性というものがあります。これはざっくり、市場に対する不確実性（どのような人がプロダクトを利用するのか）や、プロダクトの利用に関する不確実性（ユーザーはどのように、どんな感情で機能を使っているのか）、といったプロダクトにまつわるあらゆる不確実なものを指します。
環境不確実性を下げる活動とは、プロダクトとしてどこを向いていくべきか、何を作っていくべきか、の解像度を高めるあらゆる活動を意味します。分析文脈だと、
経験主義
● 多くの数字を見ることで情報を増やす、機械学習など引き出しを増やしてクロス集計では対応できなかった分析に向き合う
● 外部資料やリサーチによって市場について知る
● 現場に入ってみたり、ユーザーになりきってみることで理解を深める
● 分析資産を管理して情報を統合する
仮説思考
● 質のいい仮説のタネになる情報を提供する
● 数字の番人として、指標の見方や解釈を統一する
● A/Bテストを含む、仮説の検証プロセスを整備する
といった対処法があり、いずれも分析組織が貢献できることは大きいはずです。
もはや単に「依頼にそのまま応える」のではなく、抽象度の高い仮説を検証するための手法を開発して対応可能な依頼を広げたり、アナリスト自身が仮説を見出していったり、と意思決定の貢献領域を拡大していくフェーズです。
続いて、プロダクト開発には通信不確実性という、組織内のコミュニケーションに起因するやっかいな問題もあります。
● 知っている人と知っていない人で分断が起こることで共通認識に基づいた議論ができない
● 立場によって関心事や解釈が変わるので意図したメッセージが伝わらない
など、様々な場面（主に部門や役割のインターフェース間）で発生します。同じ組織内でも「サービス登録者数に興味がある人」「売上に興味がある人」「LTVに興味がある人」「利益率に興味がある人」など人や立場によって観点が変わることによるメッセージのズレやコンフリクトも発生するでしょう。これは限定合理性と呼ばれる状態の一種で、全体最適な議論を阻害します。
分析組織としての貢献の仕方としては、
情報の非対称性を解消していく
● 誰が読んでも誤解の余地のないドキュメントの整備を行う
● 地道な啓蒙活動によって社内の数値解釈を統一する
● データ分析の民主化によるリテラシーの引き上げ
限定合理性を解消していく
● 立場による数字の解釈の違いに自覚的になる
● 分析メンバーが部門間の意図を取り持つコミュニケーションハブになる
などがあります。
第３のフェーズでは、分析手法の高度化やプロセスへの介入によって、プロダクト開発の意思決定に付随する様々な問題（不確実性）に対処していくことになります。やることの方向性は様々ですし、HOWも無限にあります。自分たちがどの領域で事業の不確実性を下げることができるのか考え、（あくまで分析組織ができる範囲で）サポートしていきましょう。
分析手法や役割が高度化されたら、それを標準化して、さらに高難易度の課題に向き合う、といったように「効率化」と「高度化」は両輪の関係になっていきます。
分析組織の役割はどこまで拡大するべきか
データ分析と聞くと、あくまでもデータを処理する手法や技術の話が多くなりがちですが、実際に事業会社でデータを活用しようとすると、深いプロダクト理解や、組織内のコミュニケーション課題を解決する役割が求められることも多くなります。分析組織としては、どこまでデータ処理の外側に越境していくべきなのでしょうか？
これは「アナリストはどこまでビジネス力やドメイン知識が必要なのか」というテーマでよく議論になることで、正解は組織によって異なります。著者が以前いた会社では、データアナリストは分析依頼に応えるだけでなく、自発的にR&D的な動きを推進したり、ドメイン理解を深める仕組みを作ったり、他チームの議論に介入して全体最適なコミュニケーションを誘導したり、と様々な取り組みがありました。モバイルゲームの分析担当だった時には、分析者としてだけではなくゲームデザイナーとしての素養も求められていました。タクシーの配車サービスを担当していたときは、タクシー通勤をして運転手さんへのインタビューを続けていたメンバーもいます。
どこまで越境するかはさておき、個人的にはデータアナリストがドメイン知識を身に着けてプロダクト開発の様々なコミュニケーションに介入していくのは組織にとってプラスに働くと考えています。というのも、データアナリストは数字という客観的な事実を武器に議論をアラインすることができるからです。数字を正しく解釈するためには専門的な訓練が必要で、数字を出した後の伝わり方は人に任せるではなく、下流の意思決定まで並走した方がいい、という観点もあります。
一方で、過度な介入は副作用を生むのも事実です。プロダクトを深く理解したアナリストが議論をリードするようになると、そのアナリストに対する依存度が高まって、将来的に問題を引き起こす場合もあります。アナリストの成長負荷も高まるでしょう。また、職種の役割が厳格に定義され、部門が縦割りになっている組織では越境的な動きが評価されづらい課題もあります。どこまで役割を拡大するか（できるか、すべきか）は、組織ごとに議論する内容になります。
これまでの流れから、分析組織の貢献価値というのは、減らした不確実性によってどれだけ意思決定を手助けできたか、という点につきます。大事なのは、直接的な売上評価だけではなく、減らした不確実性の度合いや、どれだけ意思決定の仕組み化・効率化を進められたかも評価すべき、ということです。こうした長期的に複利で効いてくる活動を意識していないと、中長期でのチームの到達度には大きな差がでてきてしまいます。
ここまでの前半パートでは、データ分析組織の成長フェーズを俯瞰して見てきました。続く後半では、この内容を念頭に、アナリストメンバーの評価・育成について考たいと思います。
この記事が気に入ったらサポートをしてみませんか？