失敗から学ぶデータ分析グループのチームマネジメント変遷より
マネジメントの変遷
- マネジメント無し
- ペイオフマトリクス
- 三段ペイオフマトリクス
- Gitub issueに移行
- フラット組織からの脱却
第一の失敗
- データ分析者が雑用マンになってしまった
- データ分析者は、コードの読み書きとデータ出力ができるので、ついつい雑用が集中した
対策:ペイオフマトリクス導入
- スライドp6参照.
- タスクをコストとインパクトの二軸で評価
- タスクやアイディアを付箋に書き出してマトリクス上に配置
- 右上ほど高価値→優先的に対応
- 左下ほど低価値→先送り
第二の失敗
- 左下（低価値のため見送ったタスク）に研究系、開発系のタスクが大量に残った
- 製品の進歩（新機能など）に結びつくような仕事はできなかった
問題
- 研究開発タスクは不確定性が大きい
- どれくらいのコストで実現するかわからない
- 実現できた時にどれほど効果を生むかも未知数
- したがって、研究開発タスクは高コスト・低インパクトと見積もらざるを得ない
- そのため、研究開発タスクの優先度が下がり、運用系タスクが優先的に処理された(イノベーションのジレンマ発生)
対策:三段ペイオフマトリクスの導入
- ペイオフマトリクスを研究・開発・運用の3つに分割
- それぞれのペイオフマトリクス間でタスクの優先度の比較は行わないルールにした
- 合理性を意図的に無視することでイノベーションのジレンマを回避
第三の失敗
- 最初は正しく機能していた
- 「研究」に入れられたがどう検証すればわからないタスクは管理の邪魔になる
- そのようなタスクは「要ブレークダウン」枠を設けて、そちらに移動
- 膨れ上がる「要ブレークダウン」タスク
- 検証が困難な研究タスクこそ会社の競争力の要になるコアなのに放置してしまった
対策:「要ブレークダウン」をGithub Issueで管理
- とりあえずの措置としてGithub Issueに登録してみた
第四の失敗
- Github Issueに登録しただけでは進まなかった
- むしろ停滞すらした
- 本質的な問題は概して抽象度が高いので、誰でも一言言いたくなる
- 自転車置き場の議論発生（瑣末な事柄に議論のリソースが割かれる）
- Github Issueを使うことでデータ分析者とエンジニアの連携が加速したものの、メンタルモデルの違いから対立が発生
エンジニアとの対立
- エンジニアはエンジニアでタスクの優先度を知りたい
- したがって、要求に対してKPIの提示を求められた
- 実験的開発ではKPIを設定したくない（イノベーションのジレンマ回避のため）
- エンジニアから見ると価値を提示できないので優先度を下げざるを得ない
何が問題だったか
- 日々の業務に忙殺されて、本質的な課題について考える時間が取れなかった
- 組織構造として、職種間の利害対立を調停する人がいなかった
フラットな組織における問題点の認識
- 実験的タスクの実行が困難
- 人（職種）によって見ているタイムスケールは異なる。エンジニアは往々にしてショートスパン。
- 問題が複雑な場合、トレードオフが発生するが、人（職種）によってKPIの重みが異なる
- トレードオフの解決のためのMTGが増え、時間を取られる
対策:フラット組織からの脱却
- Issueを解く人、研究開発をする人を明確に定める
- データ分析者、エンジニア、デザイナの一部を研究開発グループとして分離し、イノベーションのジレンマを抑制
- コンフリクトの解決に経営層が関与する
- 現場で物事を考えるとどうしても近視眼的になりがちなので、より高いレベルで意思決定できる人間を配置
(2016/02/15)