Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
失敗から学ぶ
データ分析グループの
チームマネジメント変遷
中山ところてん
Emotion Intelligence株式会社
お前誰よ
• @tokoroten
• http://twitter.com/tokoroten
• Emotion Intelligence株式会社
• http://emin.co.jp/
• http://www.zenclerk.com...
注意・このスライドについて
• Emotion Intelligence社の試行錯誤の過程を公開
する資料です
• Emotion Intelligence社はフラット組織ですが、
職能別のマネジメントを同時に行っています
• 多少盛ってます
...
マネジメントの変遷
• マネージメント無し
• ペイオフマトリクス
• 三段ペイオフマトリクス
• Github issueに移行
• フラット組織からの脱却
第一の失敗
• チームマネジメント無し
• データ分析は3人
• データ分析者が会社全体の雑用になってしまった
• データ分析者は、コードが書ける、データが読める、データが出力
できる
• 営業とエンジニアの間に落ちた問題を拾っているだけの雑用...
ペイオフマトリクスの導入
コスト(低)
インパクト
コスト(高)
• タスクをコストとインパクトの
二軸で評価
• タスクやアイディアをポスト
イットに書き出して、マトリク
ス上に配置
• 右上ほど価値が高いので優
先的に対応、左下ほど価値
が...
第二の失敗
• ペイオフマトリクスにより順調にタスクを消化
• アイディアを思いついたらポストイットに書き、ホワイト
ボードに張る
• 右上に貼ってあるやつから優先的に処理していく
• 週一でタスクの棚卸をして、内容確認と進捗確認
• 左下に研...
何がマズかったのか?
• データ分析グループとの相性が悪い
• 研究・開発・運用を一つのチームで回す
• 研究開発タスクは不確定性が大きい
• どれくらいのコストをかければ実現できるのかわからない
• 実現できた際にどれくらいの効果があるかわか...
イノベーションのジレンマの発生
• イノベーションのジレンマは「大企業だからイノベー
ションを産めなくて負ける」という話ではない
• 「合理的に意思決定をすることで、イノベーション
が産めなくなって負ける」話
• たとえ3人の組織であっても、合...
三段ペイオフマトリクスの導入
• ペイオフマトリクスを「研究」「開発」「運用」の三つ
に分割
• 研究:アイディアレベル、価値検証が必要なもの
• 開発:本番環境での実験が必要なもの
• 運用:本番投入のためにブラッシュアップが必要なもの
• ...
運用イメージ
• それぞれのペイオフマトリクス
から右上にあるやつを優先処
理
• アイディアは「研究」のマトリク
スからスタート
• よい結果が出れば、「開発」や「運
用」のマトリクスに貼り直し
• ダメだったら、捨てる
• アイディアの検証...
第三の失敗
• 最初は正しく機能した
• 製品につながる様々な機能が実装された
• 「研究」に張られたものの、どうやって検証したら
いいかわからないタスクは、管理の邪魔になるの
で脇によけた
• 「要ブレークダウン」で脇によけておく
• ペイオ...
イシューからはじめよ
• タスクをこなすことが仕事ではない
• 問題を解くことが仕事である
• タスクマネジメントは、本質的問題を解くことを放棄
してしまった
• どのようにしたら、本質的な問題を解きに行けるのか?
• とりあえず、要ブレークダ...
Github issueで管理
第四の失敗
• Github issueに乗せただけでは進まなかった
• Github issueでむしろ遅滞
• Github issueはだれでもツッコミが入れられる
• 本質的な問題は抽象度が高く、だれでも一言言いたくなる
• 一瞬でバイ...
エンジニアとの対立
• 組織間でイノベーションのジレンマが再発
• 「ほかに依頼されている案件と比較してエンジニア内で優先度決
定をするため、ゴールとなるKPIを出してくれ」
• 「実験的案件はどうしても割り引いて評価せざるを得ないが、
~~%...
何が問題だったのか?
• Issueを解く人の不在
• Issueは管理しただけでは解かれない
• 皆、目の前のタスクに忙殺されて、誰もIssueを深く考える時
間が取れなかった
• 職種間の利害対立を解決する人が不在
• 単一の職種だけでは組...
eminにおけるフラット組織の問題認識
• 実験的タスクの実行が困難
• 人(職種)によって見ているタイムスケールが異なる
• エンジニアは往々にしてショートスパン
• エンジニアを動かさないとプロダクトが成長しない
• 問題が複雑な場合、トレ...
フラット組織からの脱却
• フラット組織が上手く機能するのはどういうときか?
• 問題が明確であり手を動かせば前に進む状態
• 人員に余裕があり、直近の課題に全リソースを投入しなくても会社が回る
状態
• Issueを解く人、研究開発をする人を...
まとめ
• データ分析という組織は、少人数で研究・開発・運用を
回すため、既存のマネージメントが適用しにくい
• どのようなマネージメントが必要かは手探り
• 構造が特殊なので既存の組織との軋轢を生む
• イノベーションのジレンマは3人の組織で...
失敗から学ぶデータ分析グループのチームマネジメント変遷
Upcoming SlideShare
Loading in …5
×

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

22,592 views

Published on

デブサミ秋2015の発表資料
http://codezine.jp/article/detail/9026

Published in: Technology
  • Be the first to comment

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

  1. 1. 失敗から学ぶ データ分析グループの チームマネジメント変遷 中山ところてん Emotion Intelligence株式会社
  2. 2. お前誰よ • @tokoroten • http://twitter.com/tokoroten • Emotion Intelligence株式会社 • http://emin.co.jp/ • http://www.zenclerk.com/ • 高機能雑用 • 現職:ECデータ分析、新規開発、営業 • 昔:半導体計測器屋、ゲームディレクター、セキュリティ
  3. 3. 注意・このスライドについて • Emotion Intelligence社の試行錯誤の過程を公開 する資料です • Emotion Intelligence社はフラット組織ですが、 職能別のマネジメントを同時に行っています • 多少盛ってます • オチや答えはありません • みなさんの考える材料の一つになれば幸いです
  4. 4. マネジメントの変遷 • マネージメント無し • ペイオフマトリクス • 三段ペイオフマトリクス • Github issueに移行 • フラット組織からの脱却
  5. 5. 第一の失敗 • チームマネジメント無し • データ分析は3人 • データ分析者が会社全体の雑用になってしまった • データ分析者は、コードが書ける、データが読める、データが出力 できる • 営業とエンジニアの間に落ちた問題を拾っているだけの雑用的存 在になってしまった • 目の前の「見えている」アラートやトラブルに工数が割かれ、 製品開発を行うことができなかった
  6. 6. ペイオフマトリクスの導入 コスト(低) インパクト コスト(高) • タスクをコストとインパクトの 二軸で評価 • タスクやアイディアをポスト イットに書き出して、マトリク ス上に配置 • 右上ほど価値が高いので優 先的に対応、左下ほど価値 が低いので先送り 優先度:高 優先度:中 優先度:低
  7. 7. 第二の失敗 • ペイオフマトリクスにより順調にタスクを消化 • アイディアを思いついたらポストイットに書き、ホワイト ボードに張る • 右上に貼ってあるやつから優先的に処理していく • 週一でタスクの棚卸をして、内容確認と進捗確認 • 左下に研究系、開発系のタスクが大量に残った • 統計的アラートなどは充実したが、製品の進歩に結び つくような仕事はできなかった ※ペイオフマトリクスにポストイットを貼るときは、同時にgithub issueに投 げて、そのチケット番号をポストイットに書いておくと、詳細管理が楽
  8. 8. 何がマズかったのか? • データ分析グループとの相性が悪い • 研究・開発・運用を一つのチームで回す • 研究開発タスクは不確定性が大きい • どれくらいのコストをかければ実現できるのかわからない • 実現できた際にどれくらいの効果があるかわからない • 研究開発タスクは高コスト、低インパクトに割り引いて評価せ ざるを得ない • 研究開発タスクの優先度が下がり、運用系タスクのみ が優先的に処理された • あれ?これ、どこかで見たような……
  9. 9. イノベーションのジレンマの発生 • イノベーションのジレンマは「大企業だからイノベー ションを産めなくて負ける」という話ではない • 「合理的に意思決定をすることで、イノベーション が産めなくなって負ける」話 • たとえ3人の組織であっても、合理的に意思決定 することで、イノベーションのジレンマに陥る • 研究開発は運用よりも価値が低いと、合理的に意思決 定した結果、製品開発が止まってしまった • 合理性を多少無視するマネージメントが必要
  10. 10. 三段ペイオフマトリクスの導入 • ペイオフマトリクスを「研究」「開発」「運用」の三つ に分割 • 研究:アイディアレベル、価値検証が必要なもの • 開発:本番環境での実験が必要なもの • 運用:本番投入のためにブラッシュアップが必要なもの • それぞれのペイオフマトリクス間でタスクの優先度 の比較は行わない • 合理性を意図的に無視することで、イノベーションのジ レンマを回避
  11. 11. 運用イメージ • それぞれのペイオフマトリクス から右上にあるやつを優先処 理 • アイディアは「研究」のマトリク スからスタート • よい結果が出れば、「開発」や「運 用」のマトリクスに貼り直し • ダメだったら、捨てる • アイディアの検証などが正しく 回るようになった
  12. 12. 第三の失敗 • 最初は正しく機能した • 製品につながる様々な機能が実装された • 「研究」に張られたものの、どうやって検証したら いいかわからないタスクは、管理の邪魔になるの で脇によけた • 「要ブレークダウン」で脇によけておく • ペイオフマトリクスに優先度が高いタスクはほぼ 無いのに、要ブレークダウンのチケットが肥大化 • ちょっとまて、ここに貼ってあるのが、会 社のコアじゃないか!!
  13. 13. イシューからはじめよ • タスクをこなすことが仕事ではない • 問題を解くことが仕事である • タスクマネジメントは、本質的問題を解くことを放棄 してしまった • どのようにしたら、本質的な問題を解きに行けるのか? • とりあえず、要ブレークダウンをGithub issueで管 理してみる
  14. 14. Github issueで管理
  15. 15. 第四の失敗 • Github issueに乗せただけでは進まなかった • Github issueでむしろ遅滞 • Github issueはだれでもツッコミが入れられる • 本質的な問題は抽象度が高く、だれでも一言言いたくなる • 一瞬でバイク小屋の議論(bikeshed discussion)に陥る • ツッコミ内容を検証しないと前に進めなくなる • Github issueは名前が悪い • タスクを書くだけでissueを解いてる気になってしまう • データ分析とエンジニアの連携の失敗 • Github Issueを通じて、エンジニアとの連携が加速 • メンタルモデルの違いから、対立が発生
  16. 16. エンジニアとの対立 • 組織間でイノベーションのジレンマが再発 • 「ほかに依頼されている案件と比較してエンジニア内で優先度決 定をするため、ゴールとなるKPIを出してくれ」 • 「実験的案件はどうしても割り引いて評価せざるを得ないが、 ~~%くらいは上がると思っている。しかし、イノベーションのジレ ンマの回避のためにはKPIを設定してはいけない。だからKPIは出 せない」 • 「KPIを出さないなら、そのタスクの優先度は下げます」 • Dev-Data問題! • システムの安定性 VS ビジネス • エンジニア「100%動くものじゃないと使いたくない」 • データ分析「90%の精度でもビジネスにとって有用。トラブルはビジネ ス的に許容できるレベルのものだ」 • メンタルモデルの差、持っているKPIの差、曖昧耐性
  17. 17. 何が問題だったのか? • Issueを解く人の不在 • Issueは管理しただけでは解かれない • 皆、目の前のタスクに忙殺されて、誰もIssueを深く考える時 間が取れなかった • 職種間の利害対立を解決する人が不在 • 単一の職種だけでは組織間にまたがる問題を解決すること は難しい • たった20人の会社でも組織の利害対立はイノベーションのジ レンマとして表れる • 複数の職種をまたがる人や、越権的な存在が必要 • ようするに組織構造が問題
  18. 18. eminにおけるフラット組織の問題認識 • 実験的タスクの実行が困難 • 人(職種)によって見ているタイムスケールが異なる • エンジニアは往々にしてショートスパン • エンジニアを動かさないとプロダクトが成長しない • 問題が複雑な場合、トレードオフが発生 • 人(職種)によって考えているKPIの重みが異なる • というか、自分が触っている個所が最重要だと思いがち • トレードオフの解決のためのコミュニケーションが増大 • 会議だらけで時間がとられ、しかし答えは出ない状況に
  19. 19. フラット組織からの脱却 • フラット組織が上手く機能するのはどういうときか? • 問題が明確であり手を動かせば前に進む状態 • 人員に余裕があり、直近の課題に全リソースを投入しなくても会社が回る 状態 • Issueを解く人、研究開発をする人を明確に決める • データ分析、エンジニア、デザイナの一部を研究開発として分離 • KPI管理から外して、イノベーションのジレンマから解放する • コンフリクトの解決に、経営層が関与する • 現場で物事を決めると、どうしても近視眼的になりがち • トレードオフの解決には、ビジネスモデルの変更など、より上位的なアプ ローチが必要なケースがある。そこまで変更できる権限と視野を持った人 が上位に必要
  20. 20. まとめ • データ分析という組織は、少人数で研究・開発・運用を 回すため、既存のマネージメントが適用しにくい • どのようなマネージメントが必要かは手探り • 構造が特殊なので既存の組織との軋轢を生む • イノベーションのジレンマは3人の組織であっても発生した • フラット組織は必ずしも素晴らしいものではない • リソースの余裕、人員の成熟が必要 • プロダクトの複雑性が高い場合、利害対立の解決が困難 • 20人の会社でもイノベーションのジレンマは発生した

×