データ分析の設計・コミュニケーションの際に意識すること

はじめに

データ分析に関するやりとりは、前提でおさえておくべき観点が多く、どうしても認識齟齬が起こりやすいと感じています。
そこで、経験的に、ここをおさえておけば分析内容がぶれないだろう、という項目をまとめてみました。
なお、ここでは、データ分析に関する観点のことを便宜上設計と呼んでいます。

データ分析の設計について

設計を整理するメリット

「はじめに」で軽く触れましたが、まず、データ分析時の設計観点をまとめることのメリットを整理してみます。

• コミュニケーションの円滑化
  • 分析の依頼側・作業側での認識齟齬やその手戻りの解消
  • 分析手順や内容が見えることで、分析に対する理解が得られ、結果に対する議論の活性化
• 俗人化の解消
  • 分析実施者しか把握してない仕様を減らすことができる
  • 車輪の再発明な分析を防止
  • 一度行った分析の深堀が容易になる
  • (分析結果や使ったプログラムを併せて管理する仕組みがあること前提)
• 品質担保・教育時の方針が明確化
  • 内容を確認・指導するべき項目が洗い出される

元々データサイエンティストが活躍していた企業では、データ分析に関わる業務を一気通貫で行っていたために、これらはあまり重要でない問題ではなかったのだと思います。正直良く知らないですが。

しかし、データ分析に取り組んでいく企業が徐々に増えてきており、その仲でのデータ分析が関わる業務が分業される場合も出てきてました。そんな中で、上記のような問題は避けられず、データ分析に関する設計に関して、一定の基準を定めていくことは重要です。

設計時に決めておくべき項目

データ分析を行う際に、必要な項目を下記にまとめました。
それぞれの詳細については後述します。

• 分析目的
  • 分析を行う背景
  • どのような仮説を検証したいか
  • 結果に基づいて、どのようなアクションを行うか
• データマート設計
  • 対象
    • 取り扱うデータやその断面、抽出条件
  • 必要な変数
    • 参照するデータやその断面、結合方式
    • 各変数の加工方法、欠損の取り扱い
• 分析手順
  • 仮説をどのような手順で検証するか
  • クロス集計
    • 分析軸と集計値
    • 有意差の判定基準について
  • 機械学習
    • クラスタリング、ロジスティック回帰、決定木、etc.
    • 目的変数、説明変数
• アウトプット
  • 表、もしくはグラフで何を出すか
  • 仮説をどのように確認するか

各項目の決め方について

まず、データ分析における目的を明確にしておくことが最重要です。何故なら、目的に応じて、それに必要なデータや手法が変わってくるためです。

その後の分析手順とデータマート設計とアウトプットについては、一概にどれから着手すべきかは難しい問題です。これらの内容は密接に関連するため、必ずしも順序立てて決めていくものではなく、並行して考えていきます。
目的が定まった後、必要なアウトプットが導かれ、それに必要な分析手法、更にデータマートが決まる、というのが理想だとは思います。しかし、手法やデータによる制約から、見直すことも時には必要です。そのため、分析目的を見据えた上で、トータルで分析を組み立てていく必要があります。

「目的」について

目的ですが、まず背景を整理にした上で、分析で明らかにしたい仮説を洗い出し、それに基づいた施策の方向性を明確にする必要があります。これは、オーソドックスな仮説検証型のアプローチです。

背景については、「(Why)のため、(Who)が(How)をしたい。」という形式でほぼ表せると思います。（これはユーザーストーリーのテンプレとほぼ一緒。）必ずしも分析者が背景知識を持っているわけではないので、その共通認識を揃えるという意味でも言語化が必要です。

仮説と施策は、密接に関係するため、双方に意識する必要があります。

分析において求められる仮説は、「データで検証できること」と「施策に繋がること」を意識する必要があります。データ分析を行うことから前者はほぼ自明だと思いますが、後者の意識も重要です。仮説の立て方によっては、具体的な施策に繋がらないパターンもあるためです。また、分析のアプローチとして、仮説を前提に進めていく仮説検証型ではなく、仮説を探していく仮説探索型もありますが、その際もアクションとして何を見据えて、何の分析を行っていくかを意識しておくべきです。

仮説と施策の立て方についてですが、アブダクションによる考え方が基本だと思います。アブダクションは、例えば「ECサイトの売上が落ちた(事象)のは、顧客単価が落ちた(法則)から」といった考え方です。起こった改善したい事象に対し、それを説明する法則をあてはめ、仮説とするということです。ここでの法則を解き明かすのに、データ分析が役立ちます。特に機械学習は、大量のデータの中から法則性を見出す帰納的な考え方と相性が良いです。

余談ではありますが、分析への理解が薄いと、データや機械学習を魔法のように錯覚しているケースがあります。そのため、解き明かしたい仮説が定まっていないことが多いです。これについては、データ分析の仮説検証の手順をしっかりと啓蒙する必要があります。

「データマート設計」について

分析で取り扱うデータマートは、分析で扱う対象と同義です。

対象数を表すものとして、データマートのユニークキー定義があります。そのため、データマートが何のレコード集合なのか、意識することが重要です。これは、SQLによる処理でいうところのFROM句やWHERE句、JOIN方式などで表現できます。SQLによる考え方はエンジニア的なものですが、ベン図によって、抽出元テーブル(FROM)とそこからの抽出条件(WHERE)とその組み合わせ方(JOIN)を説明することもできます。

データマートのユニークキーが定まった後に、各レコードで紐づける変数を定義します。こちらは、SQLでいうところのSELECT句です。ここでは、用意すべき変数自体の選定とその項目について検討します。

用意すべき変数については、アウトプットを作成するために必要なものを揃えることが最低条件です。更に、アウトプットを踏まえた深堀を想定して必要そうな変数を加えておくと、その後の深堀検証のサイクルがスムーズに進みます。

変数定義で意識しておくべきこととして、どのように値を加工するかが必要なのは明白です。更に、欠損値や異常値の処理に対する定義づけも重要です。
欠損値は、欠損のなる条件やその処理方式によって、集計値が変わってくるので意識しておくべき点です。
異常値は、プロフィールやアンケートなどのユーザ入力によるデータやシステム不整合によって正常に保持されないデータなどが存在します。設計時には気づきにくいものですが、その取扱いによって再現性がとれなくなることもあるので、必要な場合は記録として残すべきかと思います。

「分析手順」について

分析手順は、一番記載が薄いところです。
扱う手法の話は最低限書きますが、細かい作業内容はそもそも試行錯誤しながら固まっていくことも多いです。
ディテールについては、コードを参照すればよいため、設計書に必要以上に書く必要はないと思います。

「アウトプット」について

仮説を検証できるような集計結果やグラフを事前に作成しておきます。これは、データ分析の結果で得られるもののイメージを共有する狙いがあります。
また、作成に必要なデータが見えてくるので、分析時の手戻りなどを防ぐことにも繋がります。