O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

失敗から学ぶ データ分析グループの チームマネジメント変遷 (デブサミ2016) #devsumi

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

  • Entre para ver os comentários

失敗から学ぶ データ分析グループの チームマネジメント変遷 (デブサミ2016) #devsumi

  1. 1. 失敗から学ぶ データ分析グループの チームマネジメント変遷 中山ところてん Emotion Intelligence株式会社
  2. 2. お前誰よ  @tokoroten  http://twitter.com/tokoroten  Emotion Intelligence株式会社  http://emin.co.jp/  http://www.zenclerk.com/  高機能雑用  現職:ECデータ分析、新規開発、営業  昔:半導体計測器屋、ゲームディレクター、セキュ リティ
  3. 3. サービス紹介
  4. 4. 会社紹介  ウェブサイト上のユーザの行動をリアルタイムに分析  ZenClerk:機械学習でクーポンの最適配布をするサービス  どのユーザにクーポンを渡すと売上が改善するかをリアルタイムに予測
  5. 5. 目次  データ分析グループの仕事の範囲  データ分析グループの組成失敗例  データ分析グループを正しく運用するには  Emotion Intelligence社で起こった実例  どのようにして解決したか?  まとめ
  6. 6. 目次  データ分析グループの仕事の範囲  データ分析グループの組成失敗例  データ分析グループを正しく運用するには  Emotion Intelligence社で起こった実例  どのようにして解決したか?  まとめ
  7. 7. データ分析の流れ  データ分析グループは、アプリ運用で生まれたログ データを解析、改善活動を行っていくことでビジネス に生かす  必然的にカバー範囲は、研究からアプリ運用 研究 開発 システム 運用 アプリ 運用 営業活動 ログ データ データ分析グループ
  8. 8. データ分析グループの組成失敗例①  大企業はプロセスごとに会社が切れている  会社の壁を超えてログデータを手に入れることが困難  しかし、会社からは「データ分析しろ」という命令が … 研究 開発 システム 運用 アプリ 運用 営業活動 研究所 事業会社 孫会社 孫会社 代理店 ログ データ データが無いのに 分析しろって言われても…
  9. 9. データ分析グループの組成失敗例②  データサイエンティスト=高学歴、研究者 で採用  雇ったら、研究的な仕事しかしたがらない  難しい問題を、難しく解きたがる  研究における価値と、ビジネスにおける価値の混同  売り上げに繋がらない 研究 開発 システム 運用 アプリ 運用 営業活動 ログ データ データ分析 グループ やったー 面白いデータだ!! あいつら、現場に何も還元し ないで、好きなことばっかり やりやがって……
  10. 10. データ分析グループの組成失敗例③  現場を改善するためにアナリストを雇う  研究系とアナリスト系で、データ分析グループが空中分解 グループが二つに割れる  双方が「あいつらは仕事をしていない」と言い合って対立  現場の改善と、研究でサービスのコアに入っていかないので、 サービスが進歩しない 研究 開発 システム 運用 アプリ 運用 営業活動 データ分析 グループ① データ分析 グループ② 好きなことばっかり やりやがって…… 好きなことばっかり やりやがって……
  11. 11. データ分析グループの組成失敗例④  データ分析グループは、スキルセット的に広範囲をカバー  エンジニアと営業の間に落ちた問題を拾う  SQL叩いてExcelで集計するだけの簡単なお仕事  同僚から感謝されるため、ついやってしまうが、 本質的な価値を生む仕事ができない 研究 開発 システム 運用 アプリ 運用 営業活動 エンジニア、DevOps データ分析 グループ 営業 グループ バグ見つけてくれて 助かるわー お客さんからの依頼で、 データ出力してくれ
  12. 12. データ分析グループの組成失敗例⑤  データ分析グループが本来の領分で仕事をしようとす ると、エンジニアの領分と重複  言語や品質の面でエンジニアと対立  いくら分析をしても、本番に導入することができない 研究 開発 システム 運用 アプリ 運用 営業活動 データ分析グループ エンジニア、DevOps PythonやRはメンテできないから無理 データ分析のコードは品質が悪い
  13. 13. データ分析グループの組成失敗例⑥  データ分析インフラに対する投資をしないで、人だけ 雇う  データ分析以外のところに多大な工数がかかる状態  データレイク(データ蓄積基盤+データ処理基盤)の 不在 研究 開発 システム 運用 アプリ 運用 営業活動 データ分析グループ ログ データ え、本番サーバにログインして、 ログファイル拾ってくるんですか… うわ、手元のPCだと、 処理に50時間かかる……
  14. 14. 何が問題なのか?  データ分析グループは近年できた新しい組織形 態  その運用方法を知っている人が少ない  データ分析者当人も知らない  だから、研究者とアナリストで空中分解  気付くと、SQL叩いてExcelで集計する仕事になってしまう  データ分析グループとは何か?  研究からアプリ運用までを一気通貫でPDCA  他の職種の領域と重複する  膨大なデータを取り扱うためのシステム投資が必要
  15. 15. データ分析グループを正しく運用するには  エグゼクティブのサポートが必要  カバー範囲の明確化  会社として、データ分析グループのカバー範囲を明確にし、周知する  データ分析者自身にも、この範囲を意識させる  チームとして、カバー範囲を満たせるように人材を集める  システム面のサポート  データへの自由なアクセス  ログ収集インフラ、データ分析インフラの構築  データ分析者の書いたコードが、サービスに影響を与えないようにアー キテクチャを設計、エンジニアとの対立を解消  会社として十分なお膳立てがなければ、ワークしない  データ分析は空軍みたいなモノ。パイロットだけでは機能しない
  16. 16. 目次  データ分析グループの仕事の範囲  データ分析グループの組成失敗例  データ分析グループを正しく運用するには  Emotion Intelligence社で起こった実例  どのようにして解決したか?  まとめ
  17. 17. マネジメントの変遷  マネージメント無し  ペイオフマトリクス  三段ペイオフマトリクス  Github issueに移行  フラット組織からの脱却
  18. 18. 第1の失敗  マネージメント無し  データ分析は3人  データ分析者が会社全体の雑用になってしまった  データ分析者は、コードが書ける、データが読める、データを出 力できる  営業とエンジニアの間に落ちた問題を拾っているだけの存在に なってしまった  目の前の「見えている」アラートやトラブルに工数が 割かれ、製品開発を行うことができなかった
  19. 19. 第1の失敗  マネージメントをしなかったことで、全員が目の前の 問題を拾ってしまった  本来の業務である、データ分析をビジネスにすること ができなかった 研究 開発 システム 運用 アプリ 運用 営業活動 エンジニア、DevOps データ分析 グループ 営業 グループ バグ見つけてくれて 助かるわー お客さんからの依頼で、 データ出力してくれ
  20. 20. ペイオフマトリクスの導入  コストとインパクトの二軸 でタスクを評価  タスクやアイディアをポス トイットに書きだして、マ トリクス上に配置  右上ほど価値が高いので優 先的に対応、左下ほど価値 が低いので先送り  製品の改善につながる施策 を正しく選択して実行する コスト(低) インパクト コスト(高) 優先度:高 優先度:中 優先度:低
  21. 21. 元ネタ  日産 驚異の会議
  22. 22. 第2の失敗  ペイオフマトリクスにより、順調にタスクを消 化  アイディアを思いついたら、ポストイットに書き、ホ ワイトボードに張る  右上にあるタスクから優先的に拾って処理する  週一でタスクの棚卸をして、内容確認と進捗確認  左下に研究系、開発系のタスクが大量に残った  統計的アラートなどは充実したが、製品の進歩に結び つくような仕事はできなかった ※ペイオフマトリクスにポストイットを貼るときは、同時にgithub issueに投げて、そのチケット番 号をポストイットに書いておくと、詳細管理が楽
  23. 23. 何を間違えたのか?  データ分析グループとペイオフマトリクスの相性が悪 い  データ分析グループは、研究、開発、運用を一つのチームで回す  研究開発系タスクは、不確定性が大きい  どれくらいのコストをかければ実現できるのか分からない  実現できた際にどれくらいの効果があるか分からない  研究開発タスクは高コスト、低インパクトに割り引いて評価せざるを 得ない  研究開発タスクの優先度が下がり、運用系タスクのみが優先的に 処理された  これってどこかで見たような… …
  24. 24. イノベーションのジレンマの発生  イノベーションのジレンマは「大企業だからイノベー ションを産めなくて負ける」という話ではない  「大企業が合理的に意思決定することで、イノベー ションが産めなくなって負ける」話  たとえ3人の組織であっても合理的に意思決定すること で、イノベーションのジレンマに陥った  研究開発は運用よりも価値が低いと、合理的に意思決定した結果、 製品開発が止まってしまった  データ分析グループのマネージメントにおいては、 合理性を多少無視することが必要
  25. 25. 考察:日産ではなぜうまくいったのか?  日産の状況  管理職の意思決定がボトルネック  「俺は聞いてないぞ!」「事前に根回しをしろ!」という管 理職を、 業務フローのレベルで、機械的に排除する仕組み  人的資源が豊富でタスクをこなせば前進する状態  経営が安定しており、多少のミスは許容できる  ベンチャーの状況  手数の少なさがボトルネック  ビジネスを成功させるには、アイディアが必要  赤字をVCからの調達で補填、多少のミスは致命傷
  26. 26. 補足:グラフでわかるイノベーションのジレンマ 性能 投資 技術A 大企業が、技術Aに投資
  27. 27. 補足:グラフでわかるイノベーションのジレンマ 投資 技術A 大企業が、技術Aに投資 性能
  28. 28. 補足:グラフでわかるイノベーションのジレンマ 投資 技術A 技術B 技術Bが登場、大企業は投資効率が 悪いので投資しない +カニバリズムを回避 投資効率=傾き 性能
  29. 29. 補足:グラフでわかるイノベーションのジレ ンマ 投資 技術A 技術B 戦場の霧 この時の大企業から見た世界 技術Aに対する投資は合理的 性能
  30. 30. 補足:グラフでわかるイノベーションのジレンマ 投資 技術A 技術B 新興企業は大企業が技術Aを採用し ているので、技術Bを採用 性能
  31. 31. 補足:グラフでわかるイノベーションのジレンマ 投資 技術A 技術B 新興企業は大企業が技術Aを採用し ているので、技術Bを採用 性能
  32. 32. 補足:グラフでわかるイノベーションのジレンマ 投資 技術A 技術B 大企業は合理的な意思決定の結果 新興企業に負ける 性能
  33. 33. 三段ペイオフマトリクスの導入  ペイオフマトリクスを「研究」「開発」「運 用」の三つに分割  研究:アイディアレベル、価値検証が必要なもの  開発:本番環境での実験が必要なもの  運用:本番投入のためにブラッシュアップが必要なも の  それぞれのペイオフマトリクス間でタスクの優 先度の比較は行わない  合理性を意図的に無視することで、イノベーションの ジレンマを回避
  34. 34. 運用イメージ  それぞれのペイオフマトリクスか ら右上にあるやつを優先処理  マトリクスの間で優先度比較は行わ ない  アイディアは「研究」のマトリク スからスタート  よい結果が出れば、「開発」や「運 用」のマトリクスに貼り直し  ダメだったら、捨てる  アイディアの検証などが正しく回 るようになった
  35. 35. 第三の失敗  最初は正しく機能した  製品に繋がる様々な機能が実装された  「研究」に貼られたものの、どうやって検証 していいかわからないタスクは、管理の邪魔 になるので脇によけた  「要ブレークダウン系」で脇によけて おく  ペイオフマトリクスに優先度の高いタスクが 無いのに、要ブレークダウンのポストイット が増大  ちょっとまて、ここに貼ってあるのが、 ビジネスのコアじゃないか!!
  36. 36. イシューから始めよ  タスクをこなすことが仕事ではない  問題を解くことが仕事である  ペイオフマトリクスによる「タスクマ ネージメント」は、本質的な問題を解く ことを放棄してしまった  どのようにしたら本質的問題を解きにい けるのだろうか?  とりあえず、要ブレークダウンに貼られ たタスクをGitHub issueで管理してみる ことに
  37. 37. GitHub Issueでの管理
  38. 38. 第四の失敗  GitHub issueに乗せたら、むしろ進まなくなった  GitHub issueは誰でツッコミが入れられる  本質的で抽象度の高い問題は、誰でも一言言いたくなる  一瞬で自転車置き場の議論(bikeshed discussion)に陥る  議論したからと言って良いものが生まれるわけではない  問題を解くには、十分な思考時間と決断が必要、 GitHub issueのフォーマットでは、issueを解くことが難しい  GitHubに乗せたら、エンジニアとの連携が加速  メンタルモデルの違いから、エンジニアとの対立が顕在化 GitHub issueは名前がクソ過ぎる。名前のせいでそのうえで活動するとissueを解いた気になってしまう。
  39. 39. メンタルモデルの違い  データ分析者のメンタルモデル  確率、実験、やってみないと分からない  打率をベースにビジネスを考える  数値で計測することが仕事だが、 仕事自体を数値で計測できることが少ない  エンジニアのメンタルモデル  抜け漏れなく、バグがなく、QCD  完璧をベースにビジネスを考える、合理的な判断をする傾向  仕事自体を数値で計測できることが多い  バグの量、納期、品質、ダウンタイム、サーバコスト、etc…  一般にエンジニアは曖昧耐性が低い
  40. 40. 曖昧耐性 DMM.comラボ ゲーム開発素人集団がゲーム作り始めて いつのまにか40倍の組織になっていた話 https://prezi.com/bwixfnzutgbv/40/
  41. 41. 曖昧耐性 DMM.comラボ ゲーム開発素人集団がゲーム作り始めて いつのまにか40倍の組織になっていた話 https://prezi.com/bwixfnzutgbv/40/
  42. 42. エンジニアとの対立 ~~~という実装を本番環境に入れてほしい その案件は、どれくらいKPIが上がるの? ~~%くらい上がるとは思うけど、 実験だからやってみないと分からないし、 KPIを仮に出したら、他の案件に劣後するから 出せないよ KPIを出さないなら、やらないよ (イノベーションのジレンマだ……)
  43. 43. エンジニアとの対立 データ分析のためのインフラを構築したい 本番のDBを叩くのはもうツライよ その案件は、どれくらいKPIが上がるの? 分析速度は上がると思うけど、 定性的なものだから、KPIは出せないよ KPIを出さないなら、やらないよ ……
  44. 44. 何が問題だったのか?  Issueを解く人の不在  Issueは管理しただけでは解かれない  皆、目の前のタスクに忙殺されて、誰もissueを深く考える時間 が取れなかった  ボールを全員で追いかける小学生のサッカーでは、ゴールを決め ることはできない  職種間の利害対立を調整する人の不在  データ分析とエンジニアはカバー範囲が重複するので、コンフリ クトを必然的に引き起こす  フラット組織と、データ分析グループの相性が悪い  フラット組織では職能による利害対立が、個人の対立になってしまう  データ分析グループを正しく運用するには、会社のサポートが必要
  45. 45. 結局どうしたのか?  会社組織をフラットから「普通の会社」にする  各部署にマネージャーを置き、利害対立をマネージャーが解決  十分な権限を持ったマネージャーが対立を解消することで、 コンフリクトの解決のために、ビジネスモデルの変更まで考慮すること ができる  Issueを解く人を明確に定める  時間をかけて少人数でディスカッションして決める(少人数≒2人)  フラット組織を反省する  「2枚のピザ理論」のまま会社を大きくしてしまった  マネージメントをしないことを「フラット組織」と呼んでし まっていた  会社としての、マネージメントの失敗であると認識した かつて、プロジェクトマネージメントしないことを「アジャイル」と呼んでいたように……
  46. 46. 結局どうしたのか?  データ分析内で人と役割を分ける  イノベーションのジレンマの回避、目先の仕事からの解放  新規系、研究開発  システム・運用系  アプリケーション運用系  データレイクの構築  サービスのDBをredshiftにコピー、redshiftで分析可能に  現実的な時間でアドホック分析ができるようになり、コミット量 が激減
  47. 47. まとめ  データ分析という組織は、研究、開発、運用を一気通貫で 回してサービスを改善する組織である  既存のマネージメント手法が適用しにくい  他の組織とのコンフリクトを引き起こす  会社としてのサポートがあって、初めて機能する  イノベーションのジレンマはどこでも起きる  チーム内でも起きる、チーム間でも起きる  フラット組織はイノベーションのジレンマに容易に陥る  普通の会社になることは悪いことじゃない  イノベーションのジレンマの回避には、十分な思考と決断が必要  データ分析グループの運用には、適切な強権が必要
  48. 48. 補足:フラット組織が成立する条件  フラット組織の成立には次のような条件が必要  個人の仕事の独立性が高く、調整の必要性が少ない  職能の種類が少ない(コンサル、Google、GitHub社)  プロジェクトの規模が小さい  「2枚のピザ理論」 プロジェクトの人数は4~8人程度に抑えるべき  個人の仕事が会社の成果に直結する状態  ビジネスのKPIが明確で、これを満たすことで売上に繋がる状態  B2Cは、成果が分かりやすい  多少の失敗には動じない黒字体質である  上記を欠いた状態で「フラット組織」を行おうとする と破綻する
  49. 49. 採用情報  Emotion Intelligence株式会社  東京都渋谷区恵比寿南2-19-7 VORT恵比寿Duals101  データ分析、エンジニアを募集中  データ分析  Python、Scikit-learn、redshift、Jupyter、mongodb  エンジニア  Coffee Script、node、mongodb、websocket、JavaScript  フラット組織から、普通の会社になりました

×