データ分析概論
データ分析とは
データ分析とは、「特定の問題を解決する優れた意思決定を下すため、集めたデータから目的に沿った知見を得ようとする作業である」である。
時代や文化、データ獲得にかけられるコスト、施策実施にかけられる予算などによって、なにが「正しい意思決定」なのかは変わってくる。唯一絶対の「正しい意思決定」を追求するより、様々な制約条件の中で「これが良い」と納得できる「優れた意思決定」につなげることが重要である。
あくまで「優れた意思決定」を下すことが最上位の目的であるため、データ分析などしなくとも「優れた意思決定」を下せるのであれば、そもそもデータ分析は不要である。
なぜ仮説が大切なのか
世界は仮説でできている。現在科学的に「正しい」とされていることは、「今のところ反証されずに残っている仮説」にすぎず、実験によって「正しくない」と証明される可能性(反証可能性)が残されている。
ある時期まで正しいとされていた仮説が否定されることも多い。例として以下のようなものが挙げられる。
長年反証されずに残っている仮説は、「長年反証されてない=毎回仮説通りの結果になる」ため、自然と再現性を満たすことになる。
仮説思考と網羅思考
仮説思考では問いに対して仮説を立て、仮説の検証に必要なデータのみを集める。適切な仮説を立てることさえできれば、その仮説が棄却されるにせよ、採択されるにせよ、必ず意味のある結論が得られる。
仮説思考の図
網羅試行では今あるデータから事実、結論を導き出す。データに偏りがあると間違った結論が導かれてしまい、かといって、データをまんべんなく集めようとすると莫大な時間がかかってしまう。また、時間をかけて分析したが、当たり前の結論しか得られなかったということにもなりかねない。
網羅思考の図
仮説が先?データが先?
セブン&アイ・ホールディングス会長の鈴木敏文さんは「仮説が先、データが後である」と繰り返し言及している。
仮説を立てる前にデータを集めすぎるのは網羅試行の罠にはまりやすく、後知恵バイアスによってデータに過剰に適合した仮説を立ててしまうことにも繋がる。ただし、全く情報がないと筋の良い仮説は立てられないため、実際には仮説構築においても必要最小限の情報を利用する。
データ分析のプロセス
現実のデータ分析では、考え方の指針がなければ変数が多すぎて優れた意思決定につなげるのは難しい。そこで、データ分析を進めるための指針として以下のプロセスを紹介する。
データ分析のプロセス
①構造を理解する
②目的を設定する
③論点を抑える
④仮説を立てる
⑤データ収集&仮説検証
⑥意思決定
①構造を理解する
基本的に、問題として表面化していることは氷山の一角に過ぎないため、問題発生の背後にある構造を理解しなければ、問題の本質が捉えられず的外れな意思決定をしてしまう。「優れた意思決定」を下したければ、問題の裏にある背景や構造を整理して、解像度高く理解しておく必要がある。
構造を整理し、理解するためには、因果ループ図が役に立つ。因果ループ図に論理の飛躍や因果関係の矛盾を見つけたら、対象への知識や情報が足りておらず、まだ気づいていない要素があることが原因であることが多い。その場合は、関連情報を収集する、ステークホルダーにインタビューする、実際に現場に足を運ぶなど、徹底的に調査することで知識を深める必要がある。
例)学校教育の因果ループ図
構造の解像度を高めることは、後続の問題設定プロセス(目的の設定・論点を抑える・仮説を立てる)の土台となる極めて重要な項目ではあるが、あくまでも問題設定のための手段にすぎない。解像度を高めるために必要以上に過度な時間や労力をかけるべきではない。ただし、問題設定でつまずいたら、そもそも解像度が低いことが原因であることが多い。その場合は「①構造を理解する」に立ち返り、解像度を高めることに時間を費やす必要がある。
なお、経営者など旗振り役をする人は、意思決定すると同時に、意思決定の背景を高い解像度ですべてのステークホルダーに共有して、ステークホルダーを巻き込んでいくことが求められる。背景を高い解像度で共有しておかないと、現場で手段が目的化したり、理解不足による不毛な争いが起こって意志の統率が難しくなる。
構造の解像度を高める際に役立つ考え方には以下のようなものがある。
解像度を高めるためのさまざまな考え方
考え方 | 説明 |
ゼロベースで考える | 既存の枠組みにとらわれず、頭をまっさらな状態にして、ゼロから考える思考法 |
逆から考える | あえて逆の条件や結論を正として考える逆張りの思考法 |
両極端に振って考える | 攻撃に全振りしたり、防御に全振りしたらどうなるのかを考える思考法 |
アナロジーで考える | 自然界や他の業界などに似たような現象や構造がないか考える思考法 |
鳥の目、虫の目で考える | 時間的あるいは空間的に、マクロ、ミクロの視点で考える思考法 |
現場視点で考える | 実際に現場に行き、現場の視点から考える思考法 |
顧客視点で考える | 一人の顧客の視点から考える思考法 |
競合相手の視点で考える | 競争相手の役員や社員の視点で自社がどう見えるか考える思考法 |
別の時間軸で考える | 将来問題が発生する場合何が原因かや何もしなければどうなるかなど別の時間軸を起点に考える思考法 |
2つ上のポジションの視点で考える | 自分の立場を離れ、2つ上の視点から自分の抱えている課題がどう見えるか考える思考法 |
②目的を設定する
「優れた意思決定」を下すためには、「何をするか?」「どうやってするか?」の前に「どんな状態を望んでいるのか?」を徹底的に深堀りする必要がある。ここで間違って、手段の目的化をしてしまうと、目的を達成しても望みの状態にはたどり着かない。まずは、「今、目的と思っているもの」はなんのために達成したいのかをとことん深掘りし、「真の目的」を達成するための「小目的」として適切かどうかを見極める必要がある。その後、目的と現状とのギャップから解くべき問いを明確にする。
適切な目的の設定できているかの条件として、しばしばSMACという概念が用いられる。
適切な目的の条件
適切でない目的の例
上位の目的と下位の目的との間に飛躍がある、あるいは一貫性がない、そもそも目的の深掘りができないなどに該当する場合は、解像度が低いため「①構造を理解する」に立ち返る。
③論点を抑える
適切な目的を設定できたら、現在抱えている問題に対する論点、つまり「何をして、何をしないか?」を洗い出し、適切な論点に絞り込む。
問題解決のための適切な論点は、仮説がすぐに思いつくぐらい十分に掘り下げられていて、実際に解くことができ、解決したときの目的に対するインパクトが大きい。
適切な論点の条件
適切でない論点の例
論点が一つしか出せない、うまく深掘りができないなどに該当する場合は、解像度が低いため「①構造を理解する」に立ち返る。
④仮説を立てる
問題に対する適切な論点を絞り込めたら、その解決策の仮説(仮の答え)、つまり「どうやってするか?」を洗い出し、良い仮説に絞り込む。
問題解決のための良い仮説は、検証でき(反証可能)、論点に対して明確で明瞭な仮説になっていて、次のアクションに結びつく。また、仮説は実際に実行されないと意味がないため、面白そうと思える、ワクワクする仮説は評価が高くなる。
良い仮説の条件
悪い仮説の例
良い仮説が思いつかない場合は「③問を抑える」に戻ってさらに論点を掘り下げるか、解像度が低いため「①構造を理解する」に立ち返る。
⑤データ収集&仮説検証
仮説を立てたら、その仮説を検証するため、小規模な実験、数理モデルに基づくシミュレーション、過去の類似事例のリサーチなどによってデータを集める。仮説を裏付けるデータばかりを集めてしまうのを防ぐため、仮説を立てる段階で、仮説の検証に必要なデータと検証方法を考えておき、データが出た時点で仮説の成否がわかるという状態が理想的である。
データは現実の一側面を切り取ったものに過ぎず、全ての情報を完全に表現することはできない。適切にデータ取得の対象を選択できていたとしても、データ取得の背景によってデータの見え方が変わってくる。
当然だが、ピントのズレたデータや誤情報だらけのデータから有益な結論は得られない。
そのため、データを集める際には、「データが利用ニーズに対して適合しているか」「データが現実を正確に反映しているか」などに注意を払う必要がある。データ品質を測定する主な評価軸には次のようなものがある。
データ品質の代表的な評価軸
さらに、データ分析では、途中で多種多様なさまざまなバイアスが入り込み、意思決定を左右することが知られているが、データ分析の段階ごとに4つのバイアスに大別するとわかりやすい。
データ分析の段階別4つのバイアス
データを取得したら、予め定めておいた検証方法に従って仮説を検証する。統計学や数理モデル、機械学習なども仮説を検証するための1つの手段に過ぎず、仮説を検証できるなら単なる四則演算でも良い。
⑥意思決定
どれほど時間をかけてデータ分析しても、どれほど正確な結果が得られても、実行されなければなんの意味もない。そして、納得してもらえなければ決して実行されることはない。データ分析を「優れた意思決定」につなげるためには、ステークホルダー一人ひとりが「その意思決定がどんな価値を生み出すのか」を自分事として具体的にイメージできるように、コミュニケーションとる必要がある。日頃からビジョンを語り、組織全体で共有しておくことには大きな効果がある。
成果の質
前述のように、データ分析では意思決定に至るまでにいくつかの段階があり、それらの土台がしっかりしていないと、最終的な成果にはつながらない。
粘り強く改善し続ける
データ分析は評価と改善の反復的なプロセスであり、一度で十分な成果が出ることは殆とんどない。問題設定と問題解決のインフィニティブループを繰り返して、粘り強く改善し続けることで、問題の解像度は高まり、効果の高い問題解決へとつながっていく。とりわけビジネス活動において、状況は刻々と変化していき、それに伴って目的や論点も変化するため、常に監視、調整していく必要がある。
「AIを用いたデータ分析」のプロセス
最頻出のパターンとして「AIを用いたデータ分析」のプロセスを理解しておくことは役に立つ。ただし、AIはデータ分析の1つの手段に過ぎず、簡単な集計やデータの比較のみで効果的な結果が得られることもあることに注意されたい。
「AIを用いたデータ分析」のプロセス
①ビジネス課題をどのように解決できるか検討する
②データの入手、データ品質の確認をする
③データを加工する
④モデルを学習&評価する
⑤モデルをチューニングする
⑥業務に適用する
①業務課題をどのように解決できるかを検討する
データ分析プロジェクトではまず、ビジネス課題の洗い出しと、洗い出した課題をどのように解決できるかを検討する。
AIを活用することも選択肢の一つだが、AIは「何でもできるすごいシステム」ではなく、分類や回帰など適用可能な範囲が限られていたり、100%の精度が期待できない場合もある。そのため、AIを活用する際には実現可能性を意識して業務適用要件を設定する必要がある。
例えば、専門家の判断をAIで自動化する場合、現状より判断の精度が下がる可能性がある。そのため、「AIの役割を不良品の可能性のある製品の絞り込みに限定して、不良品の可能性のあるとAIが判断した製品を再度人が見て判断する」などの対応策を検討する必要がある。新たにAIを導入する際は、汎用性が高く、すでに実績が多い事例からはじめて、徐々に自社固有の課題に対象を広げていくのが良い。(「付録A - AI活用事例」を参照されたい)
また、課題によっては簡単な集計やデータの比較のみで効果的な結果が得られることもあるため、ビジネス課題に応じて最適なアプローチを選択する必要がある。
②データの入手、データ品質の確認をする
分析に応じてどんなデータを使用するべきかを考慮する必要がある。また、そのデータは入手可能か、入手方法や入手コスト、入手したデータ品質についても確認する必要がある。
2-1. データの入手方法
2-2. データ品質の代表的な評価軸(再掲)
③データを加工する
3-1. データの読み込み
機械学習で利用するデータをPythonで扱えるよう読み込む。
3-2. データプロファイリング
データの品質や傾向を確認する。項目ごとの欠損値の数、カーディナリティ、平均・分散などの基本統計量を調べたり、データ分布や項目間の相関を調べることによって、データの状態を確認する。
3-3. データクレンジング(前処理)
AIモデルに入力するための前処理を実施する。データの結合、欠損値補間、名寄せ、正規化、カテゴリ変数のワンホットエンコーディングなどデータに合わせて適切な処理を実施する。
3-4. 特徴量エンジニアリング
今あるデータからドメイン知識などを生かして新しくデータの特徴量(カラム)を作成する。
3-5. データ分割
学習用データとして、説明変数と目的変数(正解データ)からなる表形式のデータがよく用いられる。また、モデルを正確に評価するため、学習データ(モデルの学習で使用)とテストデータ(モデルの評価で使用)に分割する。もし、学習に使用したデータを評価にも使ってしまうと、いわばテストでカンニングしているのと同じで、モデルを正確に評価できない。
④モデルを学習&評価する
4-1. アルゴリズム選択
scikit-learnなどのライブラリでは、アルゴリズムは完全にブラックボックス化されているが、どのアルゴリズムを選択するかはデータサイエンティストのタスクである。「初手としてGBDTを用いてベンチマークとなるモデルを作り、その後、他のモデルと比較してモデルを改善していく」などの方法がよく用いられる。
4-2. モデル学習
学習データ(X_train, y_train)を用いてモデルを学習する。
4-3. 学習済モデルによる予測
学習済みのモデルにテストデータの説明変数(X_test)を入力して予測を実施する。
4-4. モデルの評価
予測結果(y_pred)とテストデータの目的変数(y_test)を比較してどの程度近いか測定し、モデルを評価する。
⑤モデルをチューニングする
評価の結果を受けて、業務利用の要件を満たす精度にまで向上するように試行錯誤する。アルゴリズムの選択、ハイパーパラメータの最適化、特徴量エンジニアリングなどを再検討する。
⑥業務に適用する
モデルが業務利用の要件を満たす精度にまで向上したら、業務適用に向けてシステムを構築する。実装時点では精度が良い場合でも、時間の経過に伴って適合しなくなる場合もあるため、常時監視する必要がある。
データ分析の失敗事例
データ分析プロジェクトのよくある失敗事例を以下に示す。
ケース1. 分析がビジネス上の価値に繋がらない
データ分析の結果をどのようにビジネス上の価値に変換するかを考えていないと、分析結果は活用されずに無駄になってしまう。具体的な失敗事例には以下のようなものがある。
分析に着手する前に、考えられる結果をいくつか仮定して、その結果をどのように利用できるかシミュレーションしておく必要がある。
ケース2. 分析以前に結論が決まっている
分析以前に結論が決まっていて、用意されたストーリーと矛盾する分析結果が受け入れられない場合、分析にかける労力は無駄になってしまう。具体的な失敗事例には以下のようなものがある。
引き返せない意思決定は所与のものと捉え、リスクを最小化したり、成功確率を高めたりすることに目的を変更した上で、分析を実施するのが望ましい。
ケース3. 課題が難しすぎる
解決したい問題は明確だが、直接解決するには難しすぎたり、抽象的すぎたりすると、解決までたどり着かない場合がある。具体的な失敗事例には以下のようなものがある。
解決が困難な場合は、細かく実現可能な問題に分解して段階的に達成したり、「本当に実現したいことは何か」を意識して全く別のアプローチ方法を模索したりするのが望ましい。
ケース4. 分析実効性がない
プロジェクトが始まっても、必要なデータや分析環境が用意できず、分析を実行できない場合がある。具体的な失敗事例には以下のようなものがある。
想定される問題をリストアップし、必要なデータや分析環境を用意できるか入念に確認する(あるいはクライアント側に確認してもらう)必要がある。
ケース5. 手段の目的化
バズワードに振り回されて手段が目的化してしまい、より簡単で効果的なアプローチがあるにも関わらず、不要にコストをかけてしまう場合がある。具体的な失敗事例には以下のようなものがある。
解決すべき課題を明確にした後に解決策を検討する、プロジェクトの計画段階で詳しい人を配置するなどの対策が必要である。
ケース6. ステークホルダーを置き去りにする
前処理後のデータが極端に少ないなど、分析実施中に当初予期していなかった事態が発生することも多い。ステークホルダーに報告せずに分析方針を変更すると、それまで好意的だったステークホルダーも分析全体に懐疑的になりかねない。具体的な失敗事例には以下のようなものがある。
当初予期していなかった事態が発生した場合は、速やかにステークホルダーに報告し、どう対応するか合意を得ることが望ましい。
付録A - AI活用事例
AIの主な活用事例として、製造業、医療、インフラ、金融業、流通業の例を以下に示す。
付録B - データを読み解く4つの視点
データを読み解く上で最も重要なのは、他のデータと比較することである。比較の際には、同じ性質のもの同士の比較となるように比較対象を適切に設定する必要がある。以下にデータを比較する際によく用いられる4つの視点を紹介する。
データを読み解く4つの視点
効果的にデータを比較することで、AIなどの複雑な手法を使わなくても、意思決定に役立つ情報を得られる場合も多い。
付録C - よく用いるグラフ表現
データをわかりやすく可視化するために、よく用いられるグラフ表現を以下に示す。
カテゴリ間の大小関係を比較したい時は棒グラフを用いる。
時系列グラフのように横軸の順序に意味があり、変化量を表現したい時は折れ線グラフを用いる。
データの分布を把握したい時はヒストグラムや箱ひげ図などを用いる。
2変数のデータの関係を把握したい時は散布図を用いる。
付録D 不適切なグラフ表現
世の中には詐欺グラフとも呼べるような読み手を誤解させる不適切なグラフ表現が多く存在する。不適切なグラフ表現としてよく見かけるものを以下に示す。
原点が0から始まっていないグラフは、項目間の差が誇張されてしまう。
原点が0から始まっていても、メモリ間隔が歪んでいる有害なグラフもあり、注意が必要である。
本来同じ軸で表現できるにも関わらず、2軸に分けてスケールを誤魔化したグラフがあり、注意が必要である。
セグメントを不適切にくくった表現にも注意が必要である。
3Dで表現されたグラフは、遠近法で手前の値が大きく見えるので不適切である。
グラフのデザインは文章を書くことに近い。どの情報を強調してどのような情報を捨てるか適切に選択する必要があり、不当に誇張したり矮小化したりするべきではない。なお、グラフを本当の意味で信頼するためには、出典の一次情報自身の質とそこから何をどう算入してグラフにしているのかまで確認する必要がある。
付録E - 違和感を大切にする
違和感は仮説(あるいはメンタルモデル)と観測結果の間にギャップがある場合に感じる感覚である。全てが仮説通りであれば違和感を感じることもないだろう。違和感を感じた場合、そもそもの前提か、仮説か、あるいは観測結果のデータ自体か、そこから導き出される結論のどこかに誤りがある場合が多い。違和感を感じた場合、時間の許す範囲で深掘りすることで、そこが問題発見の出発点となりうる。違和感を感じたならとことん深堀りしたほうがよい。
付録F - 劣化する評価指標
どんな定量的な指標も意思決定に用いるようになり、その計測自体が重要な意味を持つようになると、ハックされて、劣化の圧力を受ける(グッドハートの法則、キャンベルの法則)。数値は現実を推し量る上で役に立つが、それが全てではない。数値にこだわりすぎると物事の本質が見えなくなる。