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

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

チームマネジメント変遷

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

お前誰よ @tokoroten

http://twitter.com/tokoroten

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

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

キュリティ



http://emin.co.jp/

http://emin.co.jp/

http://www.zenclerk.com/

http://www.zenclerk.com/

サービス紹介

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

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

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

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

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

性能

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

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

もの

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

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

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

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

ない

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

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

ダメだったら、捨てる

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

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

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

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

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

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

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

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

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

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

とりあえず、要ブレークダウンに貼られたタスクを 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/

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

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

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

Technology