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

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

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. Github issueで管理

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人の会社でもイノベーションのジレンマは発生した