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

今日（2016-02-18）のDevelopers Summit 2016 - Hack the Realでわたしが参加したセッションの中で一番タメになったセッション。

あるあるすぎる。

個人的には他にデータ絡みの組織活動で言うとデータガバナンスなども会社( Executive )からのサポートがないとまったくワークしないということを思っている。

今後、 Executive が会社の中におけるデータ関連の活動に理解がないと会社の継続そのものが難しくなっていくだろうという話にもつながるので、エンジニアよりむしろ経営層にこそ聞いてみて欲しかった内容。

では、メモを公開。本エントリのコンテンツは以下のとおり。

【18-D-3】データ分析グループのチームマネジメント変遷（ロングバージョン） / 中山ところてん氏 [Emotion Intelligence]

資料埋め込み

2015 秋の devsumi 版

devsumi2016 版

紹介されていた書籍

devsumi2016 でわたしがとってきた他セッションのメモ

以降よりがメモ。

【18-D-3】データ分析グループのチームマネジメント変遷（ロングバージョン） / 中山ところてん氏 [Emotion Intelligence]

タイトル改まってた→失敗から学ぶデータ分析グループのチームマネジメント変遷
@tokoroten
- 高機能雑用
  - EC データ分析、新規開発、営業
- ZenClerk というサービスを提供
  - リアルタイムでウェブ店舗に来店した顧客にクーポンを発行する
    - 機械学習でクーポンの最適配布をする
    - どのユーザにクーポンを渡すと売上が改善するかをリアルタイムに予測
      - クーポンを出されると買うユーザは誰なのか？
        
        人によってはクーポンを渡されると買うのをやめちゃう
2015秋のデブサミで LT で 15 分で話した内容の拡張版。
データ分析グループの仕事の範囲
- データ分析の流れ
  - 研究＞開発＞システム開発＞アプリ運用＞営業活動
  - データ分析グループ、アプリの運用でまれたログデータを解析改善活動を行っていくことでビジネスに活かす
  - 必然的にカバー範囲は研究からアプリ運用
データ分析グループの組成失敗例
- ex.1 データがないのにデータ分析しろ
  - 大企業はプロセスごとにプロセスがきれている
  - 会社の壁を超えてログデータを手に入れることが困難
  - しかし会社からはデータ分析しろという命令が
- ex.2 研究のための研究になってしまって、お金が儲からない
  難しい問題を難しく解くのは最終段階。
  - データサイエンティスト＝高学歴、研究者で採用
  - 雇ったら研究的な仕事しかしたがらない
  - 難しい問題を難しく解きたがる
  - 売上につながらない
- ex.3 組織の空中分解問題
  - 現場を改善するためにアナリストを雇う
  - 研究系とアナリスト系でデータ分析グループが空中分解する
  - 双方があいつら仕事してないといいあって対立
- ex.4 目の前の仕事におわれて本質的な仕事ができない
  - データ分析グループはスキルセット的に広範囲をカバー
  - エンジニアと営業の間に落ちた問題を拾う
  - SQL 叩いて Excel で集計するだけの簡単なお仕事
  - 同僚から感謝されるからやるが、本質的な仕事ができない
- ex.5 価値を生むコードとシステム安定稼働を生むコードの対立
  - データ分析グループが本来の領分で仕事をしようとすると、エンジニアの領分と重複
  - 言語や品質の面でエンジニアと対立
  - いくら分析をしても本番に導入することができない
- ex.6 データレイク不在問題
  - データ分析インフラに対する投資をしないで人を雇う
  - データ分析以外のところに多大な工数がかかる状態
  - データレイク（データ蓄積基盤＋データ処理基盤）の不在
- 何が問題なのか？
  - データ分析グループは新しく出来た組織形態
    - その運用方法を知ってる人が少ない
  - データ分析グループとはなにか？
    - 研究からアプリ運用まで一気通貫で PDCA
    - 他の職種の領域と重複する（これ重要）
      - これをわかってないとないと組織内で衝突が起こる
    - 膨大なデータを取り扱うためのシステム投資が必要
データ分析グループを正しく運用するには
- Exective のサポートが必要
  - カバー範囲の明確化
    - 会社としてデータ分析グループ範囲を明確にして周知する
    - データ分析グループにもこの範囲を意識させる
      - 難しい問題を難しく解くことが仕事ではない
- システム面のサポート
  - データへの自由なアクセス
  - ログ収集インフラ、データ分析インフラの構築
  - データ分析者のつくったコードがサービスに影響を与えないようにアーキテクチャを設計、エンジニアとの対立を解消
- 会社としての十分なお膳立てがなければワークしない
  - 個人でどうにかできるものではない
  - データ分析グループは空軍のようなもの、陸軍と協力しなければワークしない
Emotion Intelligence 社で起こった事例
- マネジメントの変遷
  - マネージメントなし
  - ペイオフマトリクス
  - ....
- 第一の失敗
  - マネジメント無し
    - データ分析者が会社全体の雑用になってしまった
      - エンジニアと営業の間に落ちた問題をひろってるだけになってしまった
    - ペイオフマトリクス
      e.g. 【経営トレンドワード】ペイオフマトリックス | 経営全般 | 経営プロ
      - あるタスクをコストとインパクトで分析
        
        タスクやアイデアをポスト・イットに書き出してマトリクス状に配置
        
        右上から機械的に作業していく
      - 元ネタ：日産脅威の会議
- 第二の失敗
  - データ分析グループとペイオフマトリクスは相性悪かった
    - 研究、開発、運用をひとつのチームでまわす
    - イノベーションのジレンマ
      - たとえ3人の組織であっても合理的に意思決定することでイノベーションのジレンマに陥ってしまった
        
        ゆえに新しいことができなくなった
  - 日産で上手く言っていたのは、管理職の意思決定がボトルネックだったから
    - 人的資源は豊富でタスクをこなせば前進した
    - ベンチャーは逆
      - 手数の少なさがボトルネック
      - ビジネスを成功させるにはアイデアが必要
  - グラフで分かるイノベーションのジレンマ（面白い、スライドみたい
- 第三の失敗
  - どうやって合理性を無視したらいいのか？＞三段ペイオフマトリクスの導入
    - 研究、開発、運用でペイオフマトリクスをつくって、右上にあるものから順番に処理
  - 最初は機能したが、研究にはられたものの、どうやって検証していいかわからないものは脇によけていった。
    - 要ブレークダウンのチケットが増えていった
      - よくよくみたらそれが会社のコアだった
  - イシューからはじめよ
    - 本質的な問題をときにいかなければならなかった
- 第四の失敗
  - Github Issue で本質的な問題を解決しようとしたら、みんながいろんなことをそこに書き込もうとしてしまった。
    - 自転車置き場の議論に陥った
  - 問題を解くには十分な思考時間と決断が必要、 Github Issue のフォーマットは向いてなかった
    - あれは Github BBS だった
  - メンタルモデルの違いからエンジニアとデータ分析者の対立
    - データ分析者
      - 打率をベースにビジネスを考える
    - エンジニア
      - 曖昧耐性が低い
        
        Ref. ゲーム開発素人集団がゲーム作り始めていつのまにか40倍の組織になっていた話 by DMM Tokyo-des on Prezi
  - 何が問題だったか？
    - Issue を考える人がいなかった
    - ボールを全員でおっかける小学生サッカーのようなことを会社としてやってしまった
    - 職種間の利害対立を調整する人の不在
      - フラット組織とデータ分析組織の相性が悪い
        
        フラットだと個人の対立になってしまう
  - どうしたのか？
    - 会社組織をフラットから普通のハイラキー組織に
    - フラット組織を反省する
      - ピザ二枚の理論のまま会社を大きくしてしまった
      - マネージメントしないことをフラット組織と呼んでしまった
    - データ分析内で人と役割を分けた
      - 新規系
      - 運用系
      - アプリケーション運用系
    - データレイクの構築
      - Redshift にサービスのDBをコピー、 Redshift で分析可能に
まとめ
- データ分析グループは研究、開発、運用を一気通貫で回してサービスを改善
  - 会社としてのサポートが必要
- イノベーションのジレンマはどこでもおきる
  - チーム内でもチーム間でもおきる
  - フラット組織はイノベーションのジレンマに容易に陥る
- 普通の会社になることは悪いことじゃない
  - イノベーションのジレンマの回避には十分な思考と決断が必要
  - データ分析グループの運用には適切な強権が必要