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

Emotion Intelligence株式会社

お前誰よ• @tokoroten

• http://twitter.com/tokoroten

• Emotion Intelligence株式会社• http://emin.co.jp/• http://www.zenclerk.com/

•高機能雑用• 現職： ECデータ分析、新規開発、営業• 昔：半導体計測器屋、ゲームディレクター、セキュリティ

注意・このスライドについて• Emotion Intelligence社の試行錯誤の過程を公開する資料です• Emotion Intelligence社はフラット組織ですが、職能別のマネジメントを同時に行っています•多少盛ってます•オチや答えはありません•みなさんの考える材料の一つになれば幸いです

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

第一の失敗• チームマネジメント無し

• データ分析は 3人• データ分析者が会社全体の雑用になってしまった

• データ分析者は、コードが書ける、データが読める、データが出力できる• 営業とエンジニアの間に落ちた問題を拾っているだけの雑用的存在になってしまった

• 目の前の「見えている」アラートやトラブルに工数が割かれ、製品開発を行うことができなかった

ペイオフマトリクスの導入

コスト（低）

インパクト

コスト（高）

• タスクをコストとインパクトの二軸で評価• タスクやアイディアをポストイットに書き出して、マトリクス上に配置• 右上ほど価値が高いので優先的に対応、左下ほど価値が低いので先送り

優先度：高優先度：中

優先度：低

第二の失敗•ペイオフマトリクスにより順調にタスクを消化• アイディアを思いついたらポストイットに書き、ホワイトボードに張る• 右上に貼ってあるやつから優先的に処理していく• 週一でタスクの棚卸をして、内容確認と進捗確認

•左下に研究系、開発系のタスクが大量に残った• 統計的アラートなどは充実したが、製品の進歩に結びつくような仕事はできなかった

※ペイオフマトリクスにポストイットを貼るときは、同時に github issueに投げて、そのチケット番号をポストイットに書いておくと、詳細管理が楽

何がマズかったのか？•データ分析グループとの相性が悪い• 研究・開発・運用を一つのチームで回す• 研究開発タスクは不確定性が大きい

• どれくらいのコストをかければ実現できるのかわからない• 実現できた際にどれくらいの効果があるかわからない• 研究開発タスクは高コスト、低インパクトに割り引いて評価せざるを得ない

• 研究開発タスクの優先度が下がり、運用系タスクのみが優先的に処理された•あれ？これ、どこかで見たような……

イノベーションのジレンマの発生•イノベーションのジレンマは「大企業だからイノベーションを産めなくて負ける」という話ではない•「合理的に意思決定をすることで、イノベーションが産めなくなって負ける」話•たとえ 3人の組織であっても、合理的に意思決定することで、イノベーションのジレンマに陥る

• 研究開発は運用よりも価値が低いと、合理的に意思決定した結果、製品開発が止まってしまった• 合理性を多少無視するマネージメントが必要

三段ペイオフマトリクスの導入•ペイオフマトリクスを「研究」「開発」「運用」の三つに分割• 研究：アイディアレベル、価値検証が必要なもの• 開発：本番環境での実験が必要なもの• 運用：本番投入のためにブラッシュアップが必要なもの

•それぞれのペイオフマトリクス間でタスクの優先度の比較は行わない• 合理性を意図的に無視することで、イノベーションのジレンマを回避

運用イメージ• それぞれのペイオフマトリクスから右上にあるやつを優先処理• アイディアは「研究」のマトリクスからスタート

• よい結果が出れば、「開発」や「運用」のマトリクスに貼り直し• ダメだったら、捨てる

• アイディアの検証などが正しく回るようになった

第三の失敗• 最初は正しく機能した

• 製品につながる様々な機能が実装された• 「研究」に張られたものの、どうやって検証したらいいかわからないタスクは、管理の邪魔になるので脇によけた

• 「要ブレークダウン」で脇によけておく• ペイオフマトリクスに優先度が高いタスクはほぼ無いのに、要ブレークダウンのチケットが肥大化

• ちょっとまて、ここに貼ってあるのが、会社のコアじゃないか！！

イシューからはじめよ•タスクをこなすことが仕事ではない•問題を解くことが仕事である•タスクマネジメントは、本質的問題を解くことを放棄してしまった• どのようにしたら、本質的な問題を解きに行けるのか？

•とりあえず、要ブレークダウンを Github issueで管理してみる

Github issueで管理

第四の失敗• Github issueに乗せただけでは進まなかった

• Github issueでむしろ遅滞• Github issueはだれでもツッコミが入れられる• 本質的な問題は抽象度が高く、だれでも一言言いたくなる• 一瞬でバイク小屋の議論 (bikeshed discussion)に陥る• ツッコミ内容を検証しないと前に進めなくなる

• Github issueは名前が悪い• タスクを書くだけで issueを解いてる気になってしまう

•データ分析とエンジニアの連携の失敗• Github Issueを通じて、エンジニアとの連携が加速• メンタルモデルの違いから、対立が発生

エンジニアとの対立• 組織間でイノベーションのジレンマが再発

• 「ほかに依頼されている案件と比較してエンジニア内で優先度決定をするため、ゴールとなる KPIを出してくれ」• 「実験的案件はどうしても割り引いて評価せざるを得ないが、

～～％くらいは上がると思っている。しかし、イノベーションのジレンマの回避のためには KPIを設定してはいけない。だから KPIは出せない」• 「 KPIを出さないなら、そのタスクの優先度は下げます」

• Dev-Data問題！• システムの安定性 VS ビジネス

• エンジニア「 100% 動くものじゃないと使いたくない」• データ分析「 90%の精度でもビジネスにとって有用。トラブルはビジネス的に許容できるレベルのものだ」

• メンタルモデルの差、持っている KPIの差、曖昧耐性

何が問題だったのか？• Issueを解く人の不在

• Issueは管理しただけでは解かれない• 皆、目の前のタスクに忙殺されて、誰も Issueを深く考える時間が取れなかった

• 職種間の利害対立を解決する人が不在• 単一の職種だけでは組織間にまたがる問題を解決することは難しい• たった 20人の会社でも組織の利害対立はイノベーションのジレンマとして表れる• 複数の職種をまたがる人や、越権的な存在が必要

• ようするに組織構造が問題

eminにおけるフラット組織の問題認識• 実験的タスクの実行が困難

• 人（職種）によって見ているタイムスケールが異なる• エンジニアは往々にしてショートスパン• エンジニアを動かさないとプロダクトが成長しない

• 問題が複雑な場合、トレードオフが発生• 人（職種）によって考えている KPIの重みが異なる

• というか、自分が触っている個所が最重要だと思いがち• トレードオフの解決のためのコミュニケーションが増大

• 会議だらけで時間がとられ、しかし答えは出ない状況に

フラット組織からの脱却• フラット組織が上手く機能するのはどういうときか？

• 問題が明確であり手を動かせば前に進む状態• 人員に余裕があり、直近の課題に全リソースを投入しなくても会社が回る状態

• Issueを解く人、研究開発をする人を明確に決める• データ分析、エンジニア、デザイナの一部を研究開発として分離• KPI管理から外して、イノベーションのジレンマから解放する

• コンフリクトの解決に、経営層が関与する• 現場で物事を決めると、どうしても近視眼的になりがち• トレードオフの解決には、ビジネスモデルの変更など、より上位的なアプローチが必要なケースがある。そこまで変更できる権限と視野を持った人が上位に必要

まとめ• データ分析という組織は、少人数で研究・開発・運用を回すため、既存のマネージメントが適用しにくい

• どのようなマネージメントが必要かは手探り• 構造が特殊なので既存の組織との軋轢を生む• イノベーションのジレンマは 3人の組織であっても発生した

• フラット組織は必ずしも素晴らしいものではない• リソースの余裕、人員の成熟が必要• プロダクトの複雑性が高い場合、利害対立の解決が困難• 20人の会社でもイノベーションのジレンマは発生した