神保町で働くカスタマーサクセスマネージャーのブログ

2017年秋からカスタマーサクセスに取り組んでます。気づいたことを殴り書き。

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

f:id:takazoom:20181017231919j:plain

connpass.com

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

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

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

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

第一部 パネルトーク

  • 自己紹介
  • パネラーの皆さんが日々向き合ってること
    • 会社から求められていること
      • 樫田さん
      • 鉄本さん
        • ミッション:データを意思決定につなげる
          • なので、データ集計〜可視化〜深耕(単なる集計では見えないもの)まで幅広く行っている
        • ファイナンスチーム、マーケチーム、人事などのビジネスサイドのチームとの架け橋になる。
          • 人事と連携して、データ視点から採用のサポートも。
          • 簡単な分析はプロダクトマネージャー、エンジニアでできるように整備済。
        • ツール
          • Re:dash
            • アドホックでみるデータ
            • 無料で、さっと見られるので、ツール導入のファーストステップとしてはオススメ
          • Tableau
            • 定常でみるデータ
    • データリテラシーが低い人があやまった解釈をする可能性がある。その対策は?
      • 樫田さん
        • 難しい問題。
        • ゆるふわな階層構造をつくる
        • 組織
          • Democratization班:BIチームの強化が役割
          • Reicforce班:BIチームの外に伝播させるのが役割
    • DataAnalystが会社から評価されるには?
      • 牟田さん
        • 会社からAnalystに対する評価基準は整備されていない。
        • 自分はメンバーに対して「人をどれだけ動かしたか」を基準に評価している。
      • 樫田さん
        • 難しいが3段階くらいありそう
          • 1,言われた分析ができる
          • 2.(言われてないのに)先回りして分析できる
          • 3.Analystっぽくないことをしている。
            • 2までできると、会社から言われるのは、
              • 人と人をつなげてほしい。
              • 他の人に教えてほしい。
              • 成果を意識してほしい。
        • 基準はあるが、最終的には社内の評判で決める。
          • TOP10%、下位10%は確実にわかるが、その間はわからない。

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

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

以上となります!

f:id:takazoom:20181017231926j:plain

ちなみに、一回目の様子はこちら↓。

takazoom.hatenablog.com