失敗から学ぶデータ分析グループのチームマネジメント変遷...

失敗から学ぶデータ分析グループの

チームマネジメント変遷

中山ところてんEmotion Intelligence 株式会社

お前誰よ @tokoroten

http://twitter.com/tokoroten

Emotion Intelligence 株式会社http://emin.co.jp/http://www.zenclerk.com/

高機能雑用現職： EC データ分析、新規開発、営業昔：半導体計測器屋、ゲームディレクター、セ

キュリティ

サービス紹介

会社紹介 ウェブサイト上のユーザの行動をリアルタイムに分析

ZenClerk ：機械学習でクーポンの最適配布をするサービス どのユーザにクーポンを渡すと売上が改善するかをリアルタイムに予測

目次 データ分析グループの仕事の範囲 データ分析グループの組成失敗例 データ分析グループを正しく運用するには

Emotion Intelligence 社で起こった実例 どのようにして解決したか？ まとめ

目次 データ分析グループの仕事の範囲 データ分析グループの組成失敗例 データ分析グループを正しく運用するには

Emotion Intelligence 社で起こった実例 どのようにして解決したか？ まとめ

データ分析の流れ

データ分析グループは、アプリ運用で生まれたログデータを解析、改善活動を行っていくことでビジネスに生かす

必然的にカバー範囲は、研究からアプリ運用

研究 開発システ

ム運用

アプリ運用 営業活動

ログデータ

データ分析グループ

データ分析グループの組成失敗例①

大企業はプロセスごとに会社が切れている 会社の壁を超えてログデータを手に入れることが困難 しかし、会社からは「データ分析しろ」という命令が

…

研究 開発システ

ム運用

アプリ運用 営業活動

研究所 事業会社 孫会社 孫会社 代理店

ログデータ

データが無いのに分析しろって言われても…

データ分析グループの組成失敗例②

データサイエンティスト＝高学歴、研究者 で採用 雇ったら、研究的な仕事しかしたがらない 難しい問題を、難しく解きたがる 研究における価値と、ビジネスにおける価値の混同 売り上げに繋がらない

研究 開発システ

ム運用

アプリ運用 営業活動

ログデータ

データ分析グループ

やったー面白いデータだ！！

あいつら、現場に何も還元しないで、好きなことばっかり

やりやがって……

データ分析グループの組成失敗例③

現場を改善するためにアナリストを雇う 研究系とアナリスト系で、データ分析グループが空中分解

グループが二つに割れる 双方が「あいつらは仕事をしていない」と言い合って対立 現場の改善と、研究でサービスのコアに入っていかないので、

サービスが進歩しない

研究 開発システ

ム運用

アプリ運用 営業活動

データ分析①グループ

データ分析②グループ

好きなことばっかり

……やりやがって好きなことばっか

り……やりやがって

データ分析グループの組成失敗例④

データ分析グループは、スキルセット的に広範囲をカバー エンジニアと営業の間に落ちた問題を拾う SQL 叩いて Excel で集計するだけの簡単なお仕事 同僚から感謝されるため、ついやってしまうが、

本質的な価値を生む仕事ができない

研究 開発システ

ム運用

アプリ運用 営業活動

エンジニア、 DevOps データ分析グループ

営業グループ

バグ見つけてくれて助かるわー お客さんからの依頼で、

データ出力してくれ

データ分析グループの組成失敗例⑤

データ分析グループが本来の領分で仕事をしようとすると、エンジニアの領分と重複

言語や品質の面でエンジニアと対立 いくら分析をしても、本番に導入することができない

研究 開発システ

ム運用

アプリ運用 営業活動

データ分析グループ

エンジニア、 DevOps

Python や R はメンテできないから無理

データ分析のコードは品質が悪い

データ分析グループの組成失敗例⑥

データ分析インフラに対する投資をしないで、人だけ雇う

データ分析以外のところに多大な工数がかかる状態 データレイク（データ蓄積基盤＋データ処理基盤）の不在

研究 開発システ

ム運用

アプリ運用 営業活動

データ分析グループ

ログデータ

え、本番サーバにログインして、ログファイル拾ってくるんですか

…うわ、手元の PC だと、処理に 50 ……時間かかる

何が問題なのか？ データ分析グループは近年できた新しい組織形態

その運用方法を知っている人が少ないデータ分析者当人も知らない

だから、研究者とアナリストで空中分解気付くと、 SQL 叩いて Excel で集計する仕事になってしま

う

データ分析グループとは何か？研究からアプリ運用までを一気通貫で PDCA他の職種の領域と重複する膨大なデータを取り扱うためのシステム投資が必要

データ分析グループを正しく運用するには エグゼクティブのサポートが必要

カバー範囲の明確化 会社として、データ分析グループのカバー範囲を明確にし、周知する データ分析者自身にも、この範囲を意識させる チームとして、カバー範囲を満たせるように人材を集める

システム面のサポート データへの自由なアクセス ログ収集インフラ、データ分析インフラの構築 データ分析者の書いたコードが、サービスに影響を与えないようにアー

キテクチャを設計、エンジニアとの対立を解消

会社として十分なお膳立てがなければ、ワークしない データ分析は空軍みたいなモノ。パイロットだけでは機能しな

い

目次 データ分析グループの仕事の範囲 データ分析グループの組成失敗例 データ分析グループを正しく運用するには

Emotion Intelligence 社で起こった実例 どのようにして解決したか？ まとめ

マネジメントの変遷 マネージメント無し ペイオフマトリクス 三段ペイオフマトリクス Github issue に移行 フラット組織からの脱却

第１の失敗 マネージメント無し

データ分析は 3人

データ分析者が会社全体の雑用になってしまった データ分析者は、コードが書ける、データが読める、データを

出力できる 営業とエンジニアの間に落ちた問題を拾っているだけの存在に

なってしまった

目の前の「見えている」アラートやトラブルに工数が割かれ、製品開発を行うことができなかった

第１の失敗

マネージメントをしなかったことで、全員が目の前の問題を拾ってしまった

本来の業務である、データ分析をビジネスにすることができなかった

研究 開発システ

ム運用

アプリ運用 営業活動

エンジニア、 DevOps データ分析グループ

営業グループ

バグ見つけてくれて助かるわー お客さんからの依頼で、

データ出力してくれ

ペイオフマトリクスの導入 コストとインパクトの二

軸でタスクを評価 タスクやアイディアをポ

ストイットに書きだして、マトリクス上に配置

右上ほど価値が高いので優先的に対応、左下ほど価値が低いので先送り

製品の改善につながる施策を正しく選択して実行する

コスト（低）

インパクト

コスト（高）

優先度：高

優先度：中

優先度：低

元ネタ 日産 驚異の会議

第 2 の失敗 ペイオフマトリクスにより、順調にタスクを消化

アイディアを思いついたら、ポストイットに書き、ホワイトボードに張る

右上にあるタスクから優先的に拾って処理する週一でタスクの棚卸をして、内容確認と進捗確認

左下に研究系、開発系のタスクが大量に残った統計的アラートなどは充実したが、製品の進歩に結び

つくような仕事はできなかった

※ペイオフマトリクスにポストイットを貼るときは、同時に github issue に投げて、そのチケット番号をポストイットに書いておくと、詳細管理が楽

何を間違えたのか？ データ分析グループとペイオフマトリクスの相性が悪

い データ分析グループは、研究、開発、運用を一つのチームで回

す 研究開発系タスクは、不確定性が大きい

どれくらいのコストをかければ実現できるのか分からない 実現できた際にどれくらいの効果があるか分からない 研究開発タスクは高コスト、低インパクトに割り引いて評価せざる

を得ない 研究開発タスクの優先度が下がり、運用系タスクのみが優先的

に処理された

これってどこかで見たような… …

イノベーションのジレンマの発生 イノベーションのジレンマは「大企業だからイノベー

ションを産めなくて負ける」という話ではない 「大企業が合理的に意思決定することで、イノベー

ションが産めなくなって負ける」話

たとえ 3人の組織であっても合理的に意思決定することで、イノベーションのジレンマに陥った

研究開発は運用よりも価値が低いと、合理的に意思決定した結果、製品開発が止まってしまった

データ分析グループのマネージメントにおいては、合理性を多少無視することが必要

考察：日産ではなぜうまくいったのか？

日産の状況管理職の意思決定がボトルネック

「俺は聞いてないぞ！」「事前に根回しをしろ！」という管理職を、業務フローのレベルで、機械的に排除する仕組み

人的資源が豊富でタスクをこなせば前進する状態経営が安定しており、多少のミスは許容できる

ベンチャーの状況手数の少なさがボトルネックビジネスを成功させるには、アイディアが必要赤字を VC からの調達で補填、多少のミスは致命傷

補足：グラフでわかるイノベーションのジレンマ

性能

投資

技術 A

大企業が、技術 A に投資

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A

大企業が、技術 A に投資

性能

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A技術 B

技術 B が登場、大企業は投資効率が悪いので投資しない＋カニバリズムを回避

投資効率＝傾き

性能

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A

技術 B

戦場の霧

この時の大企業から見た世界技術 A に対する投資は合理的

性能

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A技術 B

新興企業は大企業が技術 A を採用しているので、技術 B を採用

性能

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A技術 B

新興企業は大企業が技術 A を採用しているので、技術 B を採用

性能

補足：グラフでわかるイノベーションのジレンマ

投資

技術 A技術 B

大企業は合理的な意思決定の結果新興企業に負ける

性能

三段ペイオフマトリクスの導入 ペイオフマトリクスを「研究」「開発」「運

用」の三つに分割研究：アイディアレベル、価値検証が必要なもの開発：本番環境での実験が必要なもの運用：本番投入のためにブラッシュアップが必要な

もの

それぞれのペイオフマトリクス間でタスクの優先度の比較は行わない

合理性を意図的に無視することで、イノベーションのジレンマを回避

運用イメージ それぞれのペイオフマトリクス

から右上にあるやつを優先処理 マトリクスの間で優先度比較は行わ

ない

アイディアは「研究」のマトリクスからスタート

よい結果が出れば、「開発」や「運用」のマトリクスに貼り直し

ダメだったら、捨てる

アイディアの検証などが正しく回るようになった

第三の失敗 最初は正しく機能した

製品に繋がる様々な機能が実装された 「研究」に貼られたものの、どうやって検証していいかわからないタスクは、管理の邪魔になるので脇によけた

「要ブレークダウン系」で脇によけておく

ペイオフマトリクスに優先度の高いタスクが無いのに、要ブレークダウンのポストイットが増大

ちょっとまて、ここに貼ってあるのが、

ビジネスのコアじゃないか！！

イシューから始めよ タスクをこなすことが仕事ではない 問題を解くことが仕事である

ペイオフマトリクスによる「タスクマネージメント」は、本質的な問題を解くことを放棄してしまった

どのようにしたら本質的問題を解きにいけるのだろうか？

とりあえず、要ブレークダウンに貼られたタスクを GitHub issue で管理してみることに

GitHub Issue での管理

第四の失敗 GitHub issue に乗せたら、むしろ進まなくなった

GitHub issue は誰でツッコミが入れられる 本質的で抽象度の高い問題は、誰でも一言言いたくなる

一瞬で自転車置き場の議論（ bikeshed discussion）に陥る議論したからと言って良いものが生まれるわけではない 問題を解くには、十分な思考時間と決断が必要、

GitHub issue のフォーマットでは、 issue を解くことが難しい

GitHub に乗せたら、エンジニアとの連携が加速 メンタルモデルの違いから、エンジニアとの対立が顕在化

GitHub issue は名前がクソ過ぎる。名前のせいでそのうえで活動すると issue を解いた気になってしまう。

メンタルモデルの違い データ分析者のメンタルモデル

確率、実験、やってみないと分からない打率をベースにビジネスを考える数値で計測することが仕事だが、

仕事自体を数値で計測できることが少ない

エンジニアのメンタルモデル抜け漏れなく、バグがなく、 QCD完璧をベースにビジネスを考える、合理的な判断をする傾向 仕事自体を数値で計測できることが多い

バグの量、納期、品質、ダウンタイム、サーバコスト、 etc…一般にエンジニアは曖昧耐性が低い

曖昧耐性

DMM.com 　 　ラボ ゲーム開発素人集団がゲーム作り始めて いつのまにか 40倍の組織になっていた話https://prezi.com/bwixfnzutgbv/40/

曖昧耐性

DMM.com 　 　ラボ ゲーム開発素人集団がゲーム作り始めて いつのまにか 40倍の組織になっていた話https://prezi.com/bwixfnzutgbv/40/

エンジニアとの対立

～～～という実装を本番環境に入れてほしい

その案件は、どれくらい KPI が上がるの？

～～% くらい上がるとは思うけど、実験だからやってみないと分からないし、

KPI を仮に出したら、他の案件に劣後するから出せないよ

KPI を出さないなら、やらないよ

( ……イノベーションのジレンマだ )

エンジニアとの対立データ分析のためのインフラを構築したい

本番の DB を叩くのはもうツライよ

その案件は、どれくらい KPI が上がるの？

分析速度は上がると思うけど、定性的なものだから、 KPI は出せないよ

KPI を出さないなら、やらないよ

……

何が問題だったのか？ Issue を解く人の不在

Issue は管理しただけでは解かれない皆、目の前のタスクに忙殺されて、誰も issue を深く考える時

間が取れなかったボールを全員で追いかける小学生のサッカーでは、ゴールを決

めることはできない

職種間の利害対立を調整する人の不在 データ分析とエンジニアはカバー範囲が重複するので、コンフ

リクトを必然的に引き起こす フラット組織と、データ分析グループの相性が悪い

フラット組織では職能による利害対立が、個人の対立になってしまう

データ分析グループを正しく運用するには、会社のサポートが必要

結局どうしたのか？ 会社組織をフラットから「普通の会社」にする

各部署にマネージャーを置き、利害対立をマネージャーが解決 十分な権限を持ったマネージャーが対立を解消することで、

コンフリクトの解決のために、ビジネスモデルの変更まで考慮することができる

Issue を解く人を明確に定める 時間をかけて少人数でディスカッションして決める（少人数≒ 2人）

フラット組織を反省する 「 2枚のピザ理論」のまま会社を大きくしてしまった マネージメントをしないことを「フラット組織」と呼んでし

まっていた 会社としての、マネージメントの失敗であると認識した

かつて、プロジェクトマネージメントしないことを「アジャイル」と呼んでいたように……

結局どうしたのか？ データ分析内で人と役割を分ける

イノベーションのジレンマの回避、目先の仕事からの解放 新規系、研究開発 システム・運用系 アプリケーション運用系

データレイクの構築 サービスの DB を redshift にコピー、 redshift で分析可能に 現実的な時間でアドホック分析ができるようになり、コミット量が激減

まとめ データ分析という組織は、研究、開発、運用を一気通貫で回

してサービスを改善する組織である 既存のマネージメント手法が適用しにくい 他の組織とのコンフリクトを引き起こす 会社としてのサポートがあって、初めて機能する

イノベーションのジレンマはどこでも起きる チーム内でも起きる、チーム間でも起きる フラット組織はイノベーションのジレンマに容易に陥る

普通の会社になることは悪いことじゃない イノベーションのジレンマの回避には、十分な思考と決断が必要 データ分析グループの運用には、適切な強権が必要

補足：フラット組織が成立する条件

フラット組織の成立には次のような条件が必要個人の仕事の独立性が高く、調整の必要性が少ない

職能の種類が少ない（コンサル、 Google 、 GitHub 社） プロジェクトの規模が小さい

「 2枚のピザ理論」　プロジェクトの人数は 4～ 8人程度に抑えるべき

個人の仕事が会社の成果に直結する状態 ビジネスの KPI が明確で、これを満たすことで売上に繋がる状態 B2C は、成果が分かりやすい

多少の失敗には動じない黒字体質である

上記を欠いた状態で「フラット組織」を行おうとすると破綻する

採用情報 Emotion Intelligence 株式会社

東京都渋谷区恵比寿南 2-19-7VORT恵比寿 Duals101

データ分析、エンジニアを募集中 データ分析

Python 、 Scikit-learn 、 redshift 、 Jupyter 、 mongodb エンジニア

Coffee Script 、 node 、 mongodb 、 websocket 、 JavaScript

フラット組織から、普通の会社になりました