データ分析概論

データ分析とは、「問題解決につながる優れた意思決定を下すために、データから目的に沿った知見を得ようとするプロセス」である。あくまで「優れた意思決定」を下すことが目的であるため、「優れた意思決定」に役立つ材料が得られるなら、分析手法は何でも（統計学や数理モデル、機械学習、テキストマイニング、単純な集計、あるいは単なる見える化でも）構わない。

データ分析の価値は「その分析により意思決定を改善することで得られる効用」で決まる。意思決定に全く寄与しない、あるいは意思決定の結果が重要でないならば、多くの費用を払ってまでデータ分析する価値はない。

なお、時代や文化的な背景、データ獲得や施策実施にかけられる予算、許容できるリスクや期待されるリターンなどによって、何が「優れた意思決定」なのかは変わってくる。唯一絶対の「正しい意思決定」を追求するより、様々な制約条件の中で「これが良い」と納得できる「優れた意思決定」につなげることが重要である。

現在科学的に「正しい」とされていることは、「今のところ反証されずに残っている仮説」にすぎず、実験によって「正しくない」と証明される可能性（反証可能性）が残されている。

ある時期まで正しいとされていた仮説が否定されることも多い。例として以下のようなものが挙げられる。

長年反証されずに残っている仮説は、「長年反証されてない＝毎回仮説通りの結果になる」ため、自然と再現性を満たすことになる。

仮説思考では問いに対して仮説を立て、仮説の検証に必要なデータのみを集める。適切な仮説を立てることさえできれば、その仮説が棄却されるにせよ、採択されるにせよ、必ず意味のある結論が得られる。

仮説思考の図

網羅試行では今あるデータから事実、結論を導き出す。データに偏りがあると間違った結論が導かれてしまい、かといって、データをまんべんなく集めようとすると莫大な時間がかかってしまう。また、時間をかけて分析したが、当たり前の結論しか得られなかったということにもなりかねない。

網羅思考の図

セブン＆アイ・ホールディングス会長の鈴木敏文さんは「仮説が先、データが後である」と繰り返し言及している。

仮説を立てる前にデータを集めすぎるのは網羅試行の罠にはまりやすく、後知恵バイアスによってデータに過剰に適合した仮説を立ててしまうことにも繋がる。ただし、全く情報がないと筋の良い仮説は立てられないため、実際には仮説構築においても必要最小限の情報を利用する。

現実のデータ分析では、考え方の指針がなければ変数が多すぎて優れた意思決定につなげるのは難しい。そこで、データ分析を進めるための指針として以下のプロセスを紹介する。

データ分析のプロセス

①構造を理解する

②目的を設定する

③論点を抑える

④仮説を立てる

⑤データ収集＆仮説検証

⑥意思決定

基本的に、問題として表面化していることは氷山の一角に過ぎないため、問題発生の背後にある構造を理解しなければ、問題の本質が捉えられず的外れな意思決定をしてしまう。「優れた意思決定」を下したければ、問題の裏にある背景や構造を整理して、解像度高く理解しておく必要がある。

構造を整理し、理解するためには、因果ループ図が役に立つ。因果ループ図に論理の飛躍や因果関係の矛盾を見つけたら、対象への知識や情報が足りておらず、まだ気づいていない要素があることが原因であることが多い。その場合は、関連情報を収集する、ステークホルダーにインタビューする、実際に現場に足を運ぶなど、徹底的に調査することで知識を深める必要がある。

例）学校教育の因果ループ図

構造の解像度を高めることは、後続の問題設定プロセス（目的の設定・論点を抑える・仮説を立てる）の土台となる極めて重要な項目ではあるが、あくまでも問題設定のための手段にすぎない。解像度を高めるために必要以上に過度な時間や労力をかけるべきではない。ただし、問題設定でつまずく場合、そもそも解像度が低いことが原因であることが多いので、「①構造を理解する」に立ち返って解像度を高めることに時間を費やす必要がある。

なお、経営者など旗振り役をする人は、意思決定すると同時に、意思決定の背景を高い解像度ですべてのステークホルダーに共有して、ステークホルダーを巻き込んでいくことが求められる。背景を高い解像度で共有しておかないと、現場で手段が目的化したり、理解不足による不毛な争いが起こって意志の統率が難しくなる。

構造の解像度を高める際に役立つ考え方には以下のようなものがある。

解像度を高めるためのさまざまな考え方

「優れた意思決定」を下すためには、「何をするか？」「どうやってするか？」の前に「どんな状態を望んでいるのか？」を徹底的に深堀りする必要がある。ここで間違って、手段の目的化をしてしまうと、目的を達成しても望みの状態にはたどり着かない。まずは、「今、目的と思っているもの」はなんのために達成したいのかをとことん深掘りし、「真の目的」を達成するための「小目的」として適切かどうかを見極める必要がある。その後、目的と現状とのギャップから解くべき問いを明確にする。

適切な目的の設定できているかの条件として、しばしばSMACという概念が用いられる。

適切な目的の条件

適切でない目的の例

上位の目的と下位の目的との間に飛躍がある、あるいは一貫性がない、そもそも目的の深掘りができないなどに該当する場合は、解像度が低いため「①構造を理解する」に立ち返る。

適切な目的を設定できたら、現在抱えている問題に対する論点、つまり「何をして、何をしないか？」を洗い出し、適切な論点に絞り込む。

問題解決のための適切な論点は、仮説がすぐに思いつくぐらい十分に掘り下げられていて、実際に解くことができ、解決したときの目的に対するインパクトが大きい。

適切な論点の条件

適切でない論点の例

論点が一つしか出せない、うまく深掘りができないなどに該当する場合は、解像度が低いため「①構造を理解する」に立ち返る。

問題に対する適切な論点を絞り込めたら、その解決策の仮説（仮の答え）、つまり「どうやってするか？」を洗い出し、良い仮説に絞り込む。

問題解決のための良い仮説は、検証でき（反証可能）、論点に対して明確で明瞭な仮説になっていて、次のアクションに結びつく。また、仮説は実際に実行されないと意味がないため、面白そうと思える、ワクワクする仮説は評価が高くなる。

良い仮説の条件

悪い仮説の例

良い仮説が思いつかない場合は「③問を抑える」に戻ってさらに論点を掘り下げるか、解像度が低いため「①構造を理解する」に立ち返る。

仮説を立てたら、その仮説を検証するため、小規模な実験、数理モデルに基づくシミュレーション、過去の類似事例のリサーチなどによってデータを集める。仮説を裏付けるデータばかりを集めてしまうのを防ぐため、仮説を立てる段階で、仮説の検証に必要なデータと検証方法を考えておき、データが出た時点で仮説の成否がわかるという状態が理想的である。

データは現実の一側面を切り取ったものに過ぎず、全ての情報を完全に表現することはできない。適切にデータ取得の対象を選択できていたとしても、データ取得の背景によってデータの見え方が変わってくる。

当然だが、ピントのズレたデータや誤情報だらけのデータから有益な結論は得られない。

そのため、データを集める際には、「データが利用ニーズに対して適合しているか」「データが現実を正確に反映しているか」などに注意を払う必要がある。データ品質を測定する主な評価軸には次のようなものがある。

データ品質の代表的な評価軸

さらに、データ分析において、途中で多種多様なバイアスが入り込んで意思決定を左右することが知られている。これらのバイアスはデータ分析の段階ごとに４つに大別するとわかりやすい。

データ分析の段階別４つのバイアス

データを取得したら、予め定めておいた検証方法に従って仮説を検証する。統計学や数理モデル、機械学習なども仮説を検証するための１つの手段に過ぎず、仮説を検証できるなら単なる四則演算でも良い。

どれほど時間をかけてデータ分析しても、どれほど正確な結果が得られても、実行されなければなんの意味もない。そして、納得してもらえなければ決して実行されることはない。データ分析を「優れた意思決定」につなげるためには、ステークホルダー一人ひとりが「その意思決定がどんな価値を生み出すのか」を自分事として具体的にイメージできるように、コミュニケーションをとる必要がある。日頃からビジョンを語り、組織全体で共有しておくことには大きな効果がある。

前述のように、データ分析では意思決定に至るまでにいくつかの段階があり、それらの土台がしっかりしていないと、最終的な成果にはつながらない。

データ分析は評価と改善の反復的なプロセスであり、一度で十分な成果が出ることは殆とんどない。問題設定と問題解決のインフィニティブループを繰り返して、粘り強く改善し続けることで、問題の解像度は高まり、効果の高い問題解決へとつながっていく。状況は時々刻々と変化しており、それに伴って目的や論点も変化するため、常に監視、調整していく必要がある。特に、分析モデルや学習データは背後にいくつもの前提があるため、その前提と限界を常に念頭に置かなければならない。

最頻出のパターンとして「AIを用いたデータ分析」のプロセスを理解しておくことは役に立つ。ただし、繰り返すがAIはデータ分析の１つの手段に過ぎず、単純な集計や見える化のみで効果的な結果が得られることもあることには注意されたい。

「AIを用いたデータ分析」のプロセス

①ビジネス課題をどのように解決できるか検討する

②データの入手、データ品質の確認をする

③データを加工する

④モデルを学習&評価する

⑤モデルをチューニングする

⑥業務に適用する

データ分析プロジェクトではまず、ビジネス課題の洗い出しと、洗い出した課題をどのように解決できるかを検討する。

AIを活用することも選択肢の一つだが、AIは「何でもできるすごいシステム」ではなく、分類や回帰など適用可能な範囲が限られていたり、100%の精度が期待できない場合もある。そのため、AIを活用する際には実現可能性を意識して業務適用要件を設定する必要がある。

例えば、専門家の判断をAIで自動化する場合、現状より判断の精度が下がる可能性がある。そのため、「AIの役割を不良品の可能性のある製品の絞り込みに限定して、不良品の可能性のあるとAIが判断した製品を再度人が見て判断する」などの対応策を検討する必要がある。新たにAIを導入する際は、汎用性が高く、すでに実績が多い事例からはじめて、徐々に自社固有の課題に対象を広げていくのが良い。（「付録A - AI活用事例」を参照されたい）

また、課題によっては簡単な集計やデータの比較のみで効果的な結果が得られることもあるため、ビジネス課題に応じて最適なアプローチを選択する必要がある。

分析に応じてどんなデータを使用するべきかを考慮する必要がある。また、そのデータは入手可能か、入手方法や入手コスト、入手したデータ品質についても確認する必要がある。

機械学習で利用するデータをPythonで扱えるよう読み込む。

データの品質や傾向を確認する。項目ごとの欠損値の数、カーディナリティ、平均・分散などの基本統計量を調べたり、データ分布や項目間の相関を調べることによって、データの状態を確認する。

AIモデルに入力するための前処理を実施する。データの結合、欠損値補間、名寄せ、正規化、カテゴリ変数のワンホットエンコーディングなどデータに合わせて適切な処理を実施する。

今あるデータからドメイン知識などを生かして新しくデータの特徴量（カラム）を作成する。

学習用データとして、説明変数と目的変数（正解データ）からなる表形式のデータがよく用いられる。また、モデルを正確に評価するため、学習データ（モデルの学習で使用）とテストデータ（モデルの評価で使用）に分割する。もし、学習に使用したデータを評価にも使ってしまうと、いわばテストでカンニングしているのと同じで、モデルを正確に評価できない。

scikit-learnなどのライブラリでは、アルゴリズムは完全にブラックボックス化されているが、どのアルゴリズムを選択するかはデータサイエンティストのタスクである。「初手としてGBDTを用いてベンチマークとなるモデルを作り、その後、他のモデルと比較してモデルを改善していく」などの方法がよく用いられる。

学習データ（X_train, y_train）を用いてモデルを学習する。

学習済みのモデルにテストデータの説明変数（X_test）を入力して予測を実施する。

予測結果（y_pred）とテストデータの目的変数（y_test）を比較してどの程度近いか測定し、モデルを評価する。

評価の結果を受けて、業務利用の要件を満たす精度にまで向上するように試行錯誤する。アルゴリズムの選択、ハイパーパラメータの最適化、特徴量エンジニアリングなどを再検討する。

モデルが業務利用の要件を満たす精度にまで向上したら、業務適用に向けてシステムを構築する。実装時点では精度が良い場合でも、時間の経過に伴って適合しなくなる場合もあるため、常時監視する必要がある。

データ分析プロジェクトのよくある失敗事例を以下に示す。

データ分析の結果をどのようにビジネス上の価値に変換するかを考えていないと、分析結果は活用されずに無駄になってしまう。具体的な失敗事例には以下のようなものがある。

分析に着手する前に、考えられる結果をいくつか仮定して、その結果をどのように利用できるかシミュレーションしておく必要がある。

分析以前に結論が決まっていて、用意されたストーリーと矛盾する分析結果が受け入れられない場合、分析にかける労力は無駄になってしまう。具体的な失敗事例には以下のようなものがある。

引き返せない意思決定は所与のものと捉え、リスクを最小化したり、成功確率を高めたりすることに目的を変更した上で、分析を実施するのが望ましい。

解決したい問題は明確だが、直接解決するには難しすぎたり抽象的すぎたりすると、解決までたどり着かない場合がある。具体的な失敗事例には以下のようなものがある。

解決が困難な場合は、細かく実現可能な問題に分解して段階的に達成したり、「本当に実現したいことは何か」を意識して全く別のアプローチ方法を模索したりするのが望ましい。

プロジェクトが始まっても必要なデータや分析環境が用意できず、分析を実行できない場合がある。具体的な失敗事例には以下のようなものがある。

想定される問題をリストアップし、必要なデータや分析環境を用意できるか入念に確認する（あるいはクライアント側に確認してもらう）必要がある。

バズワードに振り回されて手段が目的化してしまい、より簡単で効果的なアプローチがあるにも関わらず、不要にコストをかけてしまう場合がある。具体的な失敗事例には以下のようなものがある。

解決すべき課題を明確にした後に解決策を検討する、プロジェクトの計画段階で詳しい人を配置するなどの対策が必要である。

分析実施中に当初予期していなかった事態が発生することも多い。ステークホルダーに報告せずに分析方針を変更すると、それまで好意的だったステークホルダーも分析全体に懐疑的になりかねない。具体的な失敗事例には以下のようなものがある。

当初予期していなかった事態が発生した場合は、速やかにステークホルダーに報告し、どう対応するか合意を得ることが望ましい。

データ分析において、分析モデルは過去のデータや特定の仮定に基づいて構築される。そのため、分析モデルを過信していると、状況の変化や未知のリスクを捉えられず、大きな損失につながってしまう場合がある。具体的な失敗事例には以下のようなものがある。

状況の変化や未知のリスクに対しては、モデルの限界を考慮しつつ、常に再検証と多角的なリスク管理を実施し、必要に応じて分析モデルを再構築することが望ましい。

データ分析の成果物は数字であり、その数字をもとに意思決定が行われる。もし数字が間違っていたら、意思決定を介してクライアントに重大な損害を与えてしまう可能性もある。そのため、分析者は意図通り正確に分析が行われていて、正しい数字が出されていることに責任を持たなければならない。

数字が正しいか少しでも不安になったときは、「この数字に責任を取れるか？もし、会社のお金ではなく自分のお金を投資する場合、自分の分析結果を信用して判断できるか？」と問いかけてみると良い。

データ分析はデータから目的に沿った知見を得ようとするプロセスであり、分析が進んでいるかどうかは「その数字からわかったこと」が積み上がっているかどうかによって判断できる。このとき、「その数字からわかったこと」は、「７月の予測販売個数は１４０±１２」のような単なる計算結果ではなく、「販売量に最も影響を与えるのは気温」のような知見であることが重要。

データ分析が順調に進んでいるかを確かめるために、「その数字から何がわかる？その計算結果から得られる知見は？得られた知見は問題解決に役立ちそう？それとも、脇道にそれている？」と問いかけてみると良い。

データ分析によってどれほど重要な知見を得られても、その知見が意思決定に使えなければ意味がない。例えば、故障を予防するために２日前までに故障予知してメンテナンスしなければならないのに、２分前に故障予知できる分析モデルを作っても意味がない。

分析に取り掛かる前に一呼吸置いて、「この分析によって得られる結果は意思決定にどのように使えるのか？実際と異なる前提を置いていないか？」と問いかけてみると良い。

データ分析の価値は「その分析により意思決定を改善することで得られる効用」で決まる。意思決定に全く寄与しない、あるいは意思決定の結果が重要でないならば、多くの費用を払ってまでデータ分析する価値はない。

データ分析の価値を高めたいなら、「その分析によって意思決定はどう変わったか？意思決定が変わったことでビジネスにどれくらい貢献したか？その結果どれくらいの利益が得られたか？」と問いかけてみると良い。

データ分析はいつでも期待通りの結果が得られるわけではない。期待する成果が得られなかったとき、クライアントに丁寧に説明し、しっかりと練られた次善の策を提案することができれば、クライアントから信頼を得て、次に繋げることができる。

AIの主な活用事例として、製造業、医療、インフラ、金融業、流通業の例を以下に示す。

データを読み解く上で最も重要なのは、他のデータと比較することである。比較の際には、同じ性質のもの同士の比較となるように比較対象を適切に設定する必要がある。以下にデータを比較する際によく用いられる４つの視点を紹介する。

データを読み解く４つの視点

効果的にデータを比較することで、AIなどの複雑な手法を使わなくても、意思決定に役立つ情報を得られる場合も多い。

データをわかりやすく可視化するために、よく用いられるグラフ表現を以下に示す。

世の中には詐欺グラフとも呼べるような読み手を誤解させる不適切なグラフ表現が多く存在する。不適切なグラフ表現としてよく見かけるものを以下に示す。

グラフのデザインは文章を書くことに近い。どの情報を強調してどのような情報を捨てるか適切に選択する必要があり、不当に誇張したり矮小化したりするべきではない。なお、グラフを本当の意味で信頼するためには、出典の一次情報自身の質とそこから何をどう算入してグラフにしているのかまで確認する必要がある。

違和感は仮説（あるいはメンタルモデル）と観測結果の間にギャップがある場合に感じる感覚である。全てが仮説通りであれば違和感を感じることもないだろう。違和感を感じた場合、そもそもの前提か、仮説か、あるいは観測結果のデータ自体か、そこから導き出される結論のどこかに誤りがある場合が多い。違和感を感じた場合、時間の許す範囲で深掘りすることで、そこが問題発見の出発点となりうる。違和感を感じたならとことん深堀りしたほうがよい。

どんな定量的な指標も意思決定に用いるようになり、その計測自体が重要な意味を持つようになると、ハックされて、劣化の圧力を受ける（グッドハートの法則、キャンベルの法則）。数値は現実を推し量る上で役に立つが、それが全てではない。数値にこだわりすぎると物事の本質が見えなくなる。