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