概要

「データ分析」だけれども「分析以外」の話を考える会

「データ分析」というと手法や技術に焦点があたりがちですが、「分析以外」にも着目して実務能力の向上を目指すことを目標としています。
今回は「データ分析者は〇〇とどうやってコミュニケーションを取るか」をテーマに、社内外の様々な人々とどうやってコミュニケーションをとるべきかを考えます。

発表内容

各発表の主張をおおよそまとめています。
(齟齬がありましたらすみません)

※資料は公開が確認出来次第、リンクを更新する

対Bizdev データ分析ドリブンなビジネス開発

湯通堂圭祐さん (@keisuke_yutsudo)（株式会社 FiNC Technologies）

• Bizdevの考えること

  • データを使って事業商品を考えがち
  • 既存サービスへの活用に至らないことが多い

• 意識すること

  • 既存サービスの変数を理解した上で、データを活用した売上向上の方法を考える
  • 自社サービスの内容、仕組み、変数を理解する
  • データビジネスの活用事例を蓄積する
  • Bizdevの達成したい目的を理解する
  • 受け身ではなく自ら提案する

対エンジニア 個人的な経験と偏見に基づくエンジニアによくみられる傾向とうまく付き合うための対策の考察

しんゆうさん（@data_analyst_）(フリーランス)

※ここでいうエンジニアは、分析業務をメインにしていないデータエンジニアやインフラエンジニア、アプリエンジニアなどという認識

• イントロ

  • 非エンジニアのもつエンジニアに対するイメージが先行しがち
  • 「エンジニアだから」ではなく、立場や意見の異なる他者としてコミュニケーションをとるべき

• 対エンジニアに起こりうるケースと向き合い方

  • 「最初からしっかりと作りたがる」
    • コストなど総合的な判断のためにヒアリングの上で対応する
    • エンジニアが対応する部分ではなく、依頼側の対応で解決する場合も
  • 「細かいところまでいちいち聞いてくる」
    • プログラムとして実装する際に決める必要があり、依頼側はそれを伝える必要がある
    • 逆に伝えてないことは実装できないので、仕様漏れは依頼側の責任
    • 細かいところまで指摘をしてくるのはありがたいと感じるべき
  • 「使うことより作ることに興味を持つ」
    • 作ることについては一任する方がよい
    • 実装後は変更が難しいので、予め設計時点で関わっていく
  • 「システム的に問題ないかしか気にしない」
    • 新規テーブルや既存カラムの変更などが周知されないようなケース
    • 利用者側で監視する仕組み作りも必要
    • 影響が大きい場合は、責任者に依頼をする
  • 「技術者の論理を最優先にする」
    • エンジニアの立場としては技術的な正しさが重要
    • 一方ビジネス側では、どのように使うかが重要
    • エンジニアへ期待することを伝え、その上で動いてもらう

対現場の担当 データ分析者は現場の担当とどうやってコミュニケーションを取るか

鈴木 MAX さん （オイシックス・ラ・大地株式会社）

実案件のフローの中での観点を紹介

1. ビジネス課題の設定

   • 現場のキーパーソンを聞く
     • 権限がある/共通の課題意識がある/課題解決にリソースを割けるような人
     • 主にコミュニケーションをとるべき相手を確認する

2. 問題の構造化・見えるか

   • データやアルゴリズムをいったんおいてコミュニケーションをとる
     • アナリストはデータを使うところに先行しがち
     • 問題解決に必要な項目を整理する
   • セカンドオピニオンの意見も聞く
     • キーパーソンの意見だけでなく、他の現場の視点を確認する
   • キーパーソンと仲良くなる
     • 円滑なコミュニケーションのため

3. データ分析

   • 実用に耐えるラインを決める
     • モデルの精度やシステムの障害頻度やリカバリ時間など
     • 実運用で現場の人が困らないようなシステムの要件を決定する

4. ビジネスへの適用

   • キーパーソンを巻き込んで運用する
     • 現場のメンバー発信では利用が進みにくい
     • 運用してもらうように上位の責任者から働きかけてもらう
   • 運用時の対応を決めておく
     • 障害時に誰に連絡するか、どのように対応するかをケース別に決定する

対クライアント プリセールスデータサイエンティスト - クライアントリレーション - のススメ

漆畑充さん（株式会社Crosstab）

• データ分析系案件の営業について

  • データサイエンティストのための営業に触れられることはあまりない
  • プリセールスを担当する営業が、プロジェクトに重要な項目をすべて確認することは難しい
  • データサイエンティストが提案時にいくつかの項目を確認すべき

• プリセールスヒアリングと期待値コントロール

  • 以下の観点について、やりたいこととできることのギャップを解消する
    • 顧客目的
    • 何をするか
    • どのように
    • データ
    • 納期
    • 予算

• 成果物の設定

  • 納品する成果物を予め合意しておく
    • プロジェクト終盤で成果物が増えると炎上に繋がる
  • 要求される成果物の工数に応じて費用をとる

所感

今回、勉強会に参加して、自分の思うところを発信したくなったので所感としてまとめます。
発表者の方々の意見と異なる部分もあるかもしれませんが、違う立場からの意見ととらえて頂ければ幸いです。

書いてる人

やっていることをまとめます。
主観ですが、比較的幅広くやっているのではないかと思います。

• データ分析業務
  • 要件定義からレポーティングや施策提案までの一連の分析工程の実施
  • データマートやダッシュボードの設計、運用
  • ターゲティングやレコメンデーションなど業務用アルゴリズムのPoC、開発、運用
• マネジメント
  • 分析案件プロジェクトのタスク管理、品質管理
  • 分析業務の標準化や効率化
  • チームビルディング
• コンサルティング
  • KPIやカスタマージャーニーマップの設計に基づく戦略決定
  • データリテラシー教育
• 人事周り
  • 採用
  • 教育

やってることや立場上、色々な人とやりとりをすることがありますので、それを踏まえて発信します。

対〇〇の対応について

自分が普段考えていることをまとめました。

• 共通的な問題と対応法について

  • 基本的に、立場の違いからでてくる考えのギャップが原因となっている
  • ギャップを埋めていくコミュニケーションをとったうえで、折り合いをつけることがが重要となる
    • 俗にいう顧客折衝能力
    • 各ケースにおける原因療法的な話は次項で
  • その上で自身の意見を譲らないようなタイプを相手にする際は、状況に応じて対処する
    • 長期的な視野で考えると、心理的安全性の高い関係性を築くことで解消していくのがベストである
    • 上位の権限を持つ人間に判断を委ねるのは強力ではあるが、進め方を誤ると、その後の関係に悪影響を与える

• 対エンジニア

  • エンジニアはそもそも技術や作ること自体にモチベーションがある人も多いので、データ分析側の都合の単発的な依頼はただの作業である
  • ただ依頼するだけでなく、「何がしたいのか」「何故あなたに頼みたいのか」を伝えらられるとよい
  • エンジニア側の作業負担や技術的負債に繋がるのであれば、より上位の階層で解決を図ることが必要な場合もある

• 対現場担当

  • システム同様、機械学習の導入は、トップダウンに行われることも多いので、実際に使う人たちの意見が組みあがらないケースに陥りやすい
  • 使う側の意見を汲み上げることで、よりよいシステムデザインや運用、モデルの精度向上にも繋がる

• 対クライアント・BizDev

  • 基本的にデータ分析に関する知識が薄いことが多く、そのギャップを埋める必要がある
    • 例えば、データがあれば何かできると思っていたり、必要な作業手順を理解していなかったり
    • - 特に対クライアントにおいては、期待値コントロールを適切に行っておかないと、プロジェクト終盤で地獄を見る
  • そもそも手段と目的が逆転していることもあるので、本質的な課題を明確にしておくべき