#分析リーダーズトークに参加してきました！

f:id:takazoom:20181017231919j:plain

本日はこちらのイベントに参加してきました。今回は２回めの開催でしたが、１回めよりも現場視点のお話が多かった気がします。

自分はDataAnalystではないのですが、データ分析への強い欲求があるので、１回めに続いて参加させていただき、今回も大変貴重なお話を聞くことができました。

DataAnalystの方にとっては当たり前の話かもしれませんが、Re:dash・Tableauの使い分けや、分析結果や分析の重要性を社内に伝播させるコツなどは、イメージしやすくて参考になりました。また、教育の工夫や、チームの社内外のブランディングの話は、DataAnalystでなくても参考になるお話でした。

それでは、印象に残った話しを抜粋してお届けします。 ※発言内容の誤りなどを見つた方がいらっしゃいましたら、ご連絡いただけると大変ありがたいです。

第一部　パネルトーク

自己紹介
- メルカリ　樫田さん
  - メルカリに入って２年半。BIチームのマネージャー。
  - バックグラウンドは、外戦コンサル→NEET→分析コンサル
  - Twitter　樫田光 | Hikaru Kashida (@hik0107) | Twitter
- エウレカ　鉄本さん
  - 2011年、インターンでエウレカ入社してエンジニア修行
  - 2017年からBIチームの責任者
- LINE　牟田さん
  - マネージャー＠Data Labs
  - Data Labsは、LINE社内のデータを横串で取り扱う組織。
- サイバーエージェント　備前さん
  - モデレーターつとめます
  - 2006年　新卒入社
  - 2017年　メディアマーケティング本部　本部長
  - 営業部門、アドテク本部など、広く経験。
パネラーの皆さんが日々向き合ってること
- 会社から求められていること
  - 樫田さん
    - 物事の整理
    - 「議論がとっちかっているので、枠組みを定義してほしい」といった感じで依頼がくる
    - 「自分で調べてよ〜」と思うような簡単な依頼に対してのいなし方
      - １．データ分析を民主化させる。かんたんなクエリーは、プロデューサーに叩いてもらう
      - ２．ツールを使う。Looker。慣れれば簡単に操作できるツール。
        
        プロダクトのリリース前から新ダッシュボード「Looker」の導入に踏み切ったわけ - Mercari Engineering Blog
      - ３．簡単な分析は受け付けない。ブランディングにつながる。
        
        ただし距離感が遠くならないように配慮している。
  - 鉄本さん
    - ミッション：データを意思決定につなげる
      - なので、データ集計〜可視化〜深耕（単なる集計では見えないもの）まで幅広く行っている
    - ファイナンスチーム、マーケチーム、人事などのビジネスサイドのチームとの架け橋になる。
      - 人事と連携して、データ視点から採用のサポートも。
      - 簡単な分析はプロダクトマネージャー、エンジニアでできるように整備済。
    - ツール
      - Re:dash
        
        アドホックでみるデータ
        
        無料で、さっと見られるので、ツール導入のファーストステップとしてはオススメ
      - Tableau
        
        定常でみるデータ
- データリテラシーが低い人があやまった解釈をする可能性がある。その対策は？
  - 樫田さん
    - 難しい問題。
    - ゆるふわな階層構造をつくる
      - BI＞準BI（データ分析の欲求がありセンスが有る人）＞リテラシーがない人
      - 全社員のリテラシーをあげるのは難しいので、準BIのオゾン層を作る。
    - 組織
      - Democratization班：BIチームの強化が役割
      - Reicforce班：BIチームの外に伝播させるのが役割
- DataAnalystが会社から評価されるには？
  - 牟田さん
    - 会社からAnalystに対する評価基準は整備されていない。
    - 自分はメンバーに対して「人をどれだけ動かしたか」を基準に評価している。
  - 樫田さん
    - 難しいが３段階くらいありそう
      - １，言われた分析ができる
      - ２．（言われてないのに）先回りして分析できる
      - ３．Analystっぽくないことをしている。
        
        ２までできると、会社から言われるのは、
        
        人と人をつなげてほしい。
        
        他の人に教えてほしい。
        
        成果を意識してほしい。
    - 基準はあるが、最終的には社内の評判で決める。
      - TOP10%、下位10%は確実にわかるが、その間はわからない。

第二部　会場の皆さんが気になっていそうな事

データの大事さを伝えるコツ
- 牟田さん
  - 統計的な分析よりもABテストのほうが成果が上がることを示した。
  - 結果として、社内にABテストの文化が根付いた
- 樫田さん
  - １．１人の人にしつこく何回も諦めずに説明する。話しが通じるポイントをみつける。
  - ２．人間関係を築けない場合は、人を変える。
  - ３．DataAnalystという肩書を捨て、まず仲良くなってから、分析ネタをぶつける
教育の工夫
- 牟田さん
  - 特別な工夫はしていない
  - 自走できる人を採用するのが前提になるが、
  - OJTで、現場で苦労して覚えてもらっている
- 鉄本さん
  - OJTに加えて
    - SQLの整備
    - 自動化
    - ドキュメンテーションの整備
  - などをやってもらって、キャッチアップしてもらう。
- 樫田さん
  - １．自走力のある人を採用する。
  - ２．アサイン。熱量持って取り組める案件や、データ分析に理解のあるプロデューサーの案件にアサインする。
  - ３．よくつかうクエリー、データ定義書の整備をやってもらう。
未経験者の採用
- 備前さん
  - 新卒：「素直で、イイヤツ」をとる
    - 社員がみんな「素直で、イイヤツ」--サイバーエージェントが成長し続ける理由 (1/2)
    - 「素直でいい人」で離職減サイバーの意外な採用基準｜出世ナビ｜NIKKEI STYLE
  - 手先の器用さはあとで学べるが、「素直・イイヤツ」は後天的に身に着けられない。
クエリの管理方法が知りたい。むかしにつくったクエリの管理方法
- 鉄本さん
  - 重要なもの、何回も使うものはGitで管理
  - 簡単なものはアドホックでRe:dash
  - SQL書かなくてもデータが手に入る状態を目指している。
- 樫田さん
  - よく使うものはGit管理
  - アドホックなものは
    - スプレッドシート
    - アウトプットのWiki
    - SlackBotを使って、クエリーの再活用を促す
    - 「クエリーレシピ」というネーミング。愛されやすさを考慮して名付けた
- 牟田さん
  - アウトプットのWikiに、クエリーを紐つける
    - そうすると、レポートの再現性が保たれる。
  - シンプルなルールで運用
    - 課題は、同じようなクエリーが散在すること
BIツール導入後、ダッシュボードの管理をどうやっているか気になる。あれこれ作っていると、本来見たいダッシュボードを見つけづらくなってしまう。
- 牟田さん
  - 管理できないということは目的を見失っている、ということ。絶対に避ける
  - Wikiを用意する
- 備前さん
  - 中央集権的に管理する
  - 作ったものが勝手に出回らないようにする
- 鉄本さん
  - ダッシュボードはない
  - レポートに組み込んでしまう
- 樫田さん
  - 以前は氾濫してしまっていた
    - 1,000−2,000の中、見られているのは2,3個だけ
  - なので、Lookerに乗り換えるときに気をつけた
    - Lookerは中央集権にむいている
      - もとデータを作るのはBIチームだけ
      - そして、もとデータを加工できる人を絞る
  - ダッシュボードをたくさん作ってもしょうがない
    - 丹精こめて愛をこめて作る
    - 色、かたち、場所をこだわって作る
    - プロダクトを作るのと一緒
    - 中身（数字）が良くても見映え（UIUX）がだめだと、見てもらえない
最後に一言
- 鉄本さん
  - データの話ばかりしたが、定性的な観点も大切