デブサミ2016 #devsumi で話させていただいた資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1007/

1. 失敗から学ぶ
データ分析グループの
チームマネジメント変遷
中山ところてん
Emotion Intelligence株式会社

2. お前誰よ
 @tokoroten
 http://twitter.com/tokoroten
 Emotion Intelligence株式会社
 http://emin.co.jp/
 http://www.zenclerk.com/
 高機能雑用
 現職：ECデータ分析、新規開発、営業
 昔：半導体計測器屋、ゲームディレクター、セキュ
リティ

3. サービス紹介

4. 会社紹介
 ウェブサイト上のユーザの行動をリアルタイムに分析
 ZenClerk：機械学習でクーポンの最適配布をするサービス
 どのユーザにクーポンを渡すと売上が改善するかをリアルタイムに予測

5. 目次
 データ分析グループの仕事の範囲
 データ分析グループの組成失敗例
 データ分析グループを正しく運用するには
 Emotion Intelligence社で起こった実例
 どのようにして解決したか？
 まとめ

6. 目次
 データ分析グループの仕事の範囲
 データ分析グループの組成失敗例
 データ分析グループを正しく運用するには
 Emotion Intelligence社で起こった実例
 どのようにして解決したか？
 まとめ

7. データ分析の流れ
 データ分析グループは、アプリ運用で生まれたログ
データを解析、改善活動を行っていくことでビジネス
に生かす
 必然的にカバー範囲は、研究からアプリ運用
研究 開発
システム
運用
アプリ
運用
営業活動
ログ
データ
データ分析グループ

8. データ分析グループの組成失敗例①
 大企業はプロセスごとに会社が切れている
 会社の壁を超えてログデータを手に入れることが困難
 しかし、会社からは「データ分析しろ」という命令が
…
研究 開発
システム
運用
アプリ
運用
営業活動
研究所 事業会社 孫会社 孫会社 代理店
ログ
データ
データが無いのに
分析しろって言われても…

9. データ分析グループの組成失敗例②
 データサイエンティスト＝高学歴、研究者 で採用
 雇ったら、研究的な仕事しかしたがらない
 難しい問題を、難しく解きたがる
 研究における価値と、ビジネスにおける価値の混同
 売り上げに繋がらない
研究 開発
システム
運用
アプリ
運用
営業活動
ログ
データ
データ分析
グループ
やったー
面白いデータだ！！
あいつら、現場に何も還元し
ないで、好きなことばっかり
やりやがって……

10. データ分析グループの組成失敗例③
 現場を改善するためにアナリストを雇う
 研究系とアナリスト系で、データ分析グループが空中分解
グループが二つに割れる
 双方が「あいつらは仕事をしていない」と言い合って対立
 現場の改善と、研究でサービスのコアに入っていかないので、
サービスが進歩しない
研究 開発
システム
運用
アプリ
運用
営業活動
データ分析
グループ①
データ分析
グループ②
好きなことばっかり
やりやがって……
好きなことばっかり
やりやがって……

11. データ分析グループの組成失敗例④
 データ分析グループは、スキルセット的に広範囲をカバー
 エンジニアと営業の間に落ちた問題を拾う
 SQL叩いてExcelで集計するだけの簡単なお仕事
 同僚から感謝されるため、ついやってしまうが、
本質的な価値を生む仕事ができない
研究 開発
システム
運用
アプリ
運用
営業活動
エンジニア、DevOps
データ分析
グループ
営業
グループ
バグ見つけてくれて
助かるわー お客さんからの依頼で、
データ出力してくれ

12. データ分析グループの組成失敗例⑤
 データ分析グループが本来の領分で仕事をしようとす
ると、エンジニアの領分と重複
 言語や品質の面でエンジニアと対立
 いくら分析をしても、本番に導入することができない
研究 開発
システム
運用
アプリ
運用
営業活動
データ分析グループ
エンジニア、DevOps
PythonやRはメンテできないから無理
データ分析のコードは品質が悪い

13. データ分析グループの組成失敗例⑥
 データ分析インフラに対する投資をしないで、人だけ
雇う
 データ分析以外のところに多大な工数がかかる状態
 データレイク（データ蓄積基盤＋データ処理基盤）の
不在
研究 開発
システム
運用
アプリ
運用
営業活動
データ分析グループ
ログ
データ
え、本番サーバにログインして、
ログファイル拾ってくるんですか…
うわ、手元のPCだと、
処理に50時間かかる……

14. 何が問題なのか？
 データ分析グループは近年できた新しい組織形
態
 その運用方法を知っている人が少ない
 データ分析者当人も知らない
 だから、研究者とアナリストで空中分解
 気付くと、SQL叩いてExcelで集計する仕事になってしまう
 データ分析グループとは何か？
 研究からアプリ運用までを一気通貫でPDCA
 他の職種の領域と重複する
 膨大なデータを取り扱うためのシステム投資が必要

15. データ分析グループを正しく運用するには
 エグゼクティブのサポートが必要
 カバー範囲の明確化
 会社として、データ分析グループのカバー範囲を明確にし、周知する
 データ分析者自身にも、この範囲を意識させる
 チームとして、カバー範囲を満たせるように人材を集める
 システム面のサポート
 データへの自由なアクセス
 ログ収集インフラ、データ分析インフラの構築
 データ分析者の書いたコードが、サービスに影響を与えないようにアー
キテクチャを設計、エンジニアとの対立を解消
 会社として十分なお膳立てがなければ、ワークしない
 データ分析は空軍みたいなモノ。パイロットだけでは機能しない

16. 目次
 データ分析グループの仕事の範囲
 データ分析グループの組成失敗例
 データ分析グループを正しく運用するには
 Emotion Intelligence社で起こった実例
 どのようにして解決したか？
 まとめ

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

18. 第１の失敗
 マネージメント無し
 データ分析は3人
 データ分析者が会社全体の雑用になってしまった
 データ分析者は、コードが書ける、データが読める、データを出
力できる
 営業とエンジニアの間に落ちた問題を拾っているだけの存在に
なってしまった
 目の前の「見えている」アラートやトラブルに工数が
割かれ、製品開発を行うことができなかった

19. 第１の失敗
 マネージメントをしなかったことで、全員が目の前の
問題を拾ってしまった
 本来の業務である、データ分析をビジネスにすること
ができなかった
研究 開発
システム
運用
アプリ
運用
営業活動
エンジニア、DevOps
データ分析
グループ
営業
グループ
バグ見つけてくれて
助かるわー お客さんからの依頼で、
データ出力してくれ

20. ペイオフマトリクスの導入
 コストとインパクトの二軸
でタスクを評価
 タスクやアイディアをポス
トイットに書きだして、マ
トリクス上に配置
 右上ほど価値が高いので優
先的に対応、左下ほど価値
が低いので先送り
 製品の改善につながる施策
を正しく選択して実行する
コスト（低）
インパクト
コスト（高）
優先度：高
優先度：中
優先度：低

21. 元ネタ
 日産 驚異の会議

22. 第2の失敗
 ペイオフマトリクスにより、順調にタスクを消
化
 アイディアを思いついたら、ポストイットに書き、ホ
ワイトボードに張る
 右上にあるタスクから優先的に拾って処理する
 週一でタスクの棚卸をして、内容確認と進捗確認
 左下に研究系、開発系のタスクが大量に残った
 統計的アラートなどは充実したが、製品の進歩に結び
つくような仕事はできなかった
※ペイオフマトリクスにポストイットを貼るときは、同時にgithub issueに投げて、そのチケット番
号をポストイットに書いておくと、詳細管理が楽

23. 何を間違えたのか？
 データ分析グループとペイオフマトリクスの相性が悪
い
 データ分析グループは、研究、開発、運用を一つのチームで回す
 研究開発系タスクは、不確定性が大きい
 どれくらいのコストをかければ実現できるのか分からない
 実現できた際にどれくらいの効果があるか分からない
 研究開発タスクは高コスト、低インパクトに割り引いて評価せざるを
得ない
 研究開発タスクの優先度が下がり、運用系タスクのみが優先的に
処理された
 これってどこかで見たような… …

25. イノベーションのジレンマの発生
 イノベーションのジレンマは「大企業だからイノベー
ションを産めなくて負ける」という話ではない
 「大企業が合理的に意思決定することで、イノベー
ションが産めなくなって負ける」話
 たとえ3人の組織であっても合理的に意思決定すること
で、イノベーションのジレンマに陥った
 研究開発は運用よりも価値が低いと、合理的に意思決定した結果、
製品開発が止まってしまった
 データ分析グループのマネージメントにおいては、
合理性を多少無視することが必要

26. 考察：日産ではなぜうまくいったのか？
 日産の状況
 管理職の意思決定がボトルネック
 「俺は聞いてないぞ！」「事前に根回しをしろ！」という管
理職を、
業務フローのレベルで、機械的に排除する仕組み
 人的資源が豊富でタスクをこなせば前進する状態
 経営が安定しており、多少のミスは許容できる
 ベンチャーの状況
 手数の少なさがボトルネック
 ビジネスを成功させるには、アイディアが必要
 赤字をVCからの調達で補填、多少のミスは致命傷

27. 補足：グラフでわかるイノベーションのジレンマ
性能
投資
技術A
大企業が、技術Aに投資

28. 補足：グラフでわかるイノベーションのジレンマ
投資
技術A
大企業が、技術Aに投資
性能

29. 補足：グラフでわかるイノベーションのジレンマ
投資
技術A
技術B
技術Bが登場、大企業は投資効率が
悪いので投資しない
＋カニバリズムを回避
投資効率＝傾き
性能

30. 補足：グラフでわかるイノベーションのジレ
ンマ
投資
技術A
技術B
戦場の霧
この時の大企業から見た世界
技術Aに対する投資は合理的
性能

31. 補足：グラフでわかるイノベーションのジレンマ
投資
技術A
技術B
新興企業は大企業が技術Aを採用し
ているので、技術Bを採用
性能

32. 補足：グラフでわかるイノベーションのジレンマ
投資
技術A
技術B
新興企業は大企業が技術Aを採用し
ているので、技術Bを採用
性能

33. 補足：グラフでわかるイノベーションのジレンマ
投資
技術A
技術B
大企業は合理的な意思決定の結果
新興企業に負ける
性能

34. 三段ペイオフマトリクスの導入
 ペイオフマトリクスを「研究」「開発」「運
用」の三つに分割
 研究：アイディアレベル、価値検証が必要なもの
 開発：本番環境での実験が必要なもの
 運用：本番投入のためにブラッシュアップが必要なも
の
 それぞれのペイオフマトリクス間でタスクの優
先度の比較は行わない
 合理性を意図的に無視することで、イノベーションの
ジレンマを回避

35. 運用イメージ
 それぞれのペイオフマトリクスか
ら右上にあるやつを優先処理
 マトリクスの間で優先度比較は行わ
ない
 アイディアは「研究」のマトリク
スからスタート
 よい結果が出れば、「開発」や「運
用」のマトリクスに貼り直し
 ダメだったら、捨てる
 アイディアの検証などが正しく回
るようになった

36. 第三の失敗
 最初は正しく機能した
 製品に繋がる様々な機能が実装された
 「研究」に貼られたものの、どうやって検証
していいかわからないタスクは、管理の邪魔
になるので脇によけた
 「要ブレークダウン系」で脇によけて
おく
 ペイオフマトリクスに優先度の高いタスクが
無いのに、要ブレークダウンのポストイット
が増大
 ちょっとまて、ここに貼ってあるのが、
ビジネスのコアじゃないか！！

37. イシューから始めよ
 タスクをこなすことが仕事ではない
 問題を解くことが仕事である
 ペイオフマトリクスによる「タスクマ
ネージメント」は、本質的な問題を解く
ことを放棄してしまった
 どのようにしたら本質的問題を解きにい
けるのだろうか？
 とりあえず、要ブレークダウンに貼られ
たタスクをGitHub issueで管理してみる
ことに

38. GitHub Issueでの管理

39. 第四の失敗
 GitHub issueに乗せたら、むしろ進まなくなった
 GitHub issueは誰でツッコミが入れられる
 本質的で抽象度の高い問題は、誰でも一言言いたくなる
 一瞬で自転車置き場の議論（bikeshed discussion）に陥る
 議論したからと言って良いものが生まれるわけではない
 問題を解くには、十分な思考時間と決断が必要、
GitHub issueのフォーマットでは、issueを解くことが難しい
 GitHubに乗せたら、エンジニアとの連携が加速
 メンタルモデルの違いから、エンジニアとの対立が顕在化
GitHub issueは名前がクソ過ぎる。名前のせいでそのうえで活動するとissueを解いた気になってしまう。

40. メンタルモデルの違い
 データ分析者のメンタルモデル
 確率、実験、やってみないと分からない
 打率をベースにビジネスを考える
 数値で計測することが仕事だが、
仕事自体を数値で計測できることが少ない
 エンジニアのメンタルモデル
 抜け漏れなく、バグがなく、QCD
 完璧をベースにビジネスを考える、合理的な判断をする傾向
 仕事自体を数値で計測できることが多い
 バグの量、納期、品質、ダウンタイム、サーバコスト、etc…
 一般にエンジニアは曖昧耐性が低い

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

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

43. エンジニアとの対立
～～～という実装を本番環境に入れてほしい
その案件は、どれくらいKPIが上がるの？
～～%くらい上がるとは思うけど、
実験だからやってみないと分からないし、
KPIを仮に出したら、他の案件に劣後するから
出せないよ
KPIを出さないなら、やらないよ
(イノベーションのジレンマだ……)

44. エンジニアとの対立
データ分析のためのインフラを構築したい
本番のDBを叩くのはもうツライよ
その案件は、どれくらいKPIが上がるの？
分析速度は上がると思うけど、
定性的なものだから、KPIは出せないよ
KPIを出さないなら、やらないよ
……

45. 何が問題だったのか？
 Issueを解く人の不在
 Issueは管理しただけでは解かれない
 皆、目の前のタスクに忙殺されて、誰もissueを深く考える時間
が取れなかった
 ボールを全員で追いかける小学生のサッカーでは、ゴールを決め
ることはできない
 職種間の利害対立を調整する人の不在
 データ分析とエンジニアはカバー範囲が重複するので、コンフリ
クトを必然的に引き起こす
 フラット組織と、データ分析グループの相性が悪い
 フラット組織では職能による利害対立が、個人の対立になってしまう
 データ分析グループを正しく運用するには、会社のサポートが必要

46. 結局どうしたのか？
 会社組織をフラットから「普通の会社」にする
 各部署にマネージャーを置き、利害対立をマネージャーが解決
 十分な権限を持ったマネージャーが対立を解消することで、
コンフリクトの解決のために、ビジネスモデルの変更まで考慮すること
ができる
 Issueを解く人を明確に定める
 時間をかけて少人数でディスカッションして決める（少人数≒2人）
 フラット組織を反省する
 「2枚のピザ理論」のまま会社を大きくしてしまった
 マネージメントをしないことを「フラット組織」と呼んでし
まっていた
 会社としての、マネージメントの失敗であると認識した
かつて、プロジェクトマネージメントしないことを「アジャイル」と呼んでいたように……

47. 結局どうしたのか？
 データ分析内で人と役割を分ける
 イノベーションのジレンマの回避、目先の仕事からの解放
 新規系、研究開発
 システム・運用系
 アプリケーション運用系
 データレイクの構築
 サービスのDBをredshiftにコピー、redshiftで分析可能に
 現実的な時間でアドホック分析ができるようになり、コミット量
が激減

48. まとめ
 データ分析という組織は、研究、開発、運用を一気通貫で
回してサービスを改善する組織である
 既存のマネージメント手法が適用しにくい
 他の組織とのコンフリクトを引き起こす
 会社としてのサポートがあって、初めて機能する
 イノベーションのジレンマはどこでも起きる
 チーム内でも起きる、チーム間でも起きる
 フラット組織はイノベーションのジレンマに容易に陥る
 普通の会社になることは悪いことじゃない
 イノベーションのジレンマの回避には、十分な思考と決断が必要
 データ分析グループの運用には、適切な強権が必要

49. 補足：フラット組織が成立する条件
 フラット組織の成立には次のような条件が必要
 個人の仕事の独立性が高く、調整の必要性が少ない
 職能の種類が少ない（コンサル、Google、GitHub社）
 プロジェクトの規模が小さい
 「2枚のピザ理論」 プロジェクトの人数は4～8人程度に抑えるべき
 個人の仕事が会社の成果に直結する状態
 ビジネスのKPIが明確で、これを満たすことで売上に繋がる状態
 B2Cは、成果が分かりやすい
 多少の失敗には動じない黒字体質である
 上記を欠いた状態で「フラット組織」を行おうとする
と破綻する

50. 採用情報
 Emotion Intelligence株式会社
 東京都渋谷区恵比寿南2-19-7
VORT恵比寿Duals101
 データ分析、エンジニアを募集中
 データ分析
 Python、Scikit-learn、redshift、Jupyter、mongodb
 エンジニア
 Coffee Script、node、mongodb、websocket、JavaScript
 フラット組織から、普通の会社になりました