6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

データ解析の流れ備忘録

Posted at

はじめに

  • この記事はデータ解析の流れについてのまとめです。
  • 書籍「データ解析の実務プロセス入門」の「第2章 データ解析のプロセス」におけるデータ解析の流れをベースに、それぞれのプロセスについて、実務で得た所感を加えた形でまとめています。
    • 所感については都度追加予定です。

データ解析の流れ

1. 目的設定

最善の目的設定

  • その時点で最善の目的設定を行うこと。
    • 目的設定で、解析の出せる価値の上限が決まるので、現実的な制約を抜きにして考える。
  • プロセスは反復するものであるため、最初に明確な目的を設定することは必須ではない。大雑把でok。
  • 第一に最良の目的。その次にデータ。最後に手法。

目的設定のアプローチ

  • 大きく分けると2つのアプローチがある

仮説検証型アプローチ

  • データ解析者や依頼者が持つ仮説の正誤を、データを用いて検証するアプローチ。
    • 大雑把な目的からスタートする
      • 利益の向上
      • 顧客の把握
      • 問題点の改善
    • 大雑把な目的を、ロジックツリーを用いて分解、細分化する
      • 利益 = 売上 - 原価
      • 売上 = 客単価 × 来客数...

探索型アプローチ

  • すでにあるデータを様々な切り口から眺めることによって目的を生み出すためのアプローチ。

正しい目的設定の重要性

  • 目的設定が間違えていると、価値を出すことができない。
    • 最初から正しいゴールを設定する必要はないが、なぜこのゴールを目指すのか、なぜその時点で最良と言えるのかは常に説明できるようにすること。

2. 分析計画

目的の妥当性の確認

  • 1.の理想的想定から離れて、現実に立ち戻って実現可能性を考える。
  • 目的に対して費用対効果や技術的実現性について検討する。結果、目的に問題があることがわかれば、再度目的設定のプロセスに戻る。
  • 目的の妥当性の確認
  • 1.の理想的想定から離れて、現実に立ち戻って実現可能性を考える。
  • 目的に対して費用対効果や技術的実現性について検討する。結果、目的に問題があることがわかれば、再度目的設定のプロセスに戻る。

担当者の明確化

  • データ解析における各責務の担当を決定する。
    • 責任者
    • 意思決定者
    • 未決事項の管理・決定者
    • 相談窓口
    • データ解析者
  • 担当の兼務は可能。ただしその場合も、役割の明確化は行うこと。

私的メモ

  • 実務の中では、PJのキックオフMTGなどで資料にも記載した上で認識合わせを行い、担当者を明確化した
  • 加えて会議体などを整理することで、意思決定のプロセスも明確にした

評価指標と達成基準の設定

  • 分析の成功を判断する上での明確な評価指標と達成基準を設定する
    • データ解析をしないと分からないという意見もあるが、データ解析のプロセスを反復するという前提上、必須といえる。
      • 分析を実行してそれなりの結果が出たにも関わらず、判断ができず、無意味に分析を継続してしまう
      • 十分な期間を待たずに効果なしとみなされ、打ち切りとなる
      • データ解析は外部から基準を設定しない限り、終わらない
  • 指標は分析と直結したものを使用すること
    • データ解析をもとに立案した施策はあくまで最も成功率の高いものであり、100%利益向上を保証するものではない。それを認識せず、売上の上下だけでデータ解析を評価すると、誤った判断をもたらす
    • 曖昧な評価指標を用いると、分析内容ではなく、指標の作り方や測定の仕方によってデータ解析の正否が左右されてしまう

成果物の設定

  • 分析前にどのような成果物が求められるかを事前に擦り合わせておくと齟齬が生じづらくなる
  • 齟齬は主に2つの原因で生じる
    • 対象者のレベルに合っていない
      • 必要以上に難しい言葉を使わない
      • どう読み取り、解釈するかの説明を必ず加える
      • 依頼者のデータ解析経験に応じて、アウトプットの形式を検討する
    • ニーズに合っていない
      • 成果物の使用用途により、作成すべきもの、形式が変わる
        • 詳細な検証結果の報告書か、提案用のプレゼン資料か、仮説を裏付けるエビデンスか、、

私的メモ

  • 成果物の認識合わせは言葉だけで実施するのは難しいと思います。
  • ロジックは抜きにした形で構わないので、具体的な成果物のサンプル、モックを作成しておくと顧客との擦り合わせがスムーズに進みます
  • 分析設計を行う際に整理を行うべき項目については下記スライドが参考になりました。

取組の優先順位設定

  • 計画の段階では全ての案を実践するだけのリソースがないことが多いため、優先順位をつける
    • その際、MoSCoW分析が有効
      • 要件をMust, Should, Could, Won’tの4つに分類して整理する手法

関係者との調整

  • 各関係者を巻き込み、協力いただくために、計画設定の段階で調整を行う必要がある
    • 解析の意義を共有する
      • 解析がどのように目的に寄与するのか
    • 具体的にどのような協力が必要かを説明する

計画書の作成

  • どの分析でも共通の計画書のフォーマットを作成することによって、思考の整理が容易になり、関係者の理解も進む。
  • 最低限記載すべきなものは、誰が、なぜ、何のアクションを、どのように、どの手順で、どうするとどうなるのか

3. データ設計

  • どのようなデータをどう設計し、収集し、保存するかが成果を大きく左右する
  • 分析手法とデータは密接に結びつく。ただし、実際の分析では多くの手法を用いて試行錯誤するので、汎用性の高いデータを設計するのがベター

4. データ収集

  • データ収集にはシステムがほぼ不可欠。
  • システムはメンテが必須という認識を持つこと。

5. データの前処理

  • 収集したデータをそのまま分析に利用できるとは限らない。多くの場合は何らかの処理を施す必要がある。分析しやすい形にデータを加工することを前処理という
    • 分析ツールに沿った形式への変換
    • データに抜け漏れや異常が発生していないかの確認
    • 分析用のサーバやフォルダにデータを移す
    • 適切なファイル名でのデータ保存

6. 分析手法選択と適用

  • データを分析ツールにかけて何らかの出力を得るステップ
  • 最も重要なことは、ここに時間をかけすぎないこと
    • このプロセスに熱中しても目的に対して劇的な改善につながることは稀
    • 思ったような結果が出ない場合に設定値をいじっても成果に結びつくことはほとんどない
    • 大事なことは、それ以前のプロセスに誤りがないかを振り返ること
  • 何らかの制限をかけて(分析には30分しかかけない、など)取り組むことが重要

7. 分析結果の解釈

  • 分析結果の生の数値やグラフそのものに宿る価値は乏しく、それらの分析結果を元にドメイン知識からの検証、積み重ねた議論によって解釈されて初めて有益な知見を産む
  • 1つの事実から複数の解釈が生じうる。前提や懸念点が複数あると、同じ事実から複数の解釈を導き出せうる
    • 解釈は、データから導き出された事実と、前提や懸念点などの考慮材料とのセットで生み出す必要がある
  • 解釈は独りよがりになる危険性を常にはらんでいる。
    • 最も簡単な解決法は他人にレビューしてもらうこと。関係者を交え、複数人で解釈する、妥当性を検証する場を設けること
    • 自分一人でやらざるを得ない場合は、一旦日を空けて、解釈を検討すること

私的メモ

  • 自分自身、何度かレビューで解釈の方向性の違いに気づかされました。誤った方向で突き進まないよう、早めにこういった場を設けることをおすすめします

8. 施策の提案

  • 良いデータ解析はあくまで手段であり、それ自体は目的ではない
  • 本来の目的を達成するためには意思決定者にデータ解析の結果を理解してもらい、実践につなげる必要がある
    • 統計結果を理解させて、処方箋を出し、実践させるまでがデータ解析者の仕事
  • 提案時には何が事実・仮説・解釈なのかを明確にする必要がある。これらを混同して伝えると、適切な意思決定ができない
    • 自分自身もPJの中で、報告の際に、ファクト、解釈、示唆(提案)を分けるよう指摘を受けました
  • 提案時に伝えるべき内容は下記の通り
    • 目的
      • 最終的に達成すべきこと
    • 仮説
      • その時点での現象の説明
        • 「Yという事象が発生している。これはXが原因ではないか」というような論理構築
        • その後のデータ解析の段階で真偽を検討する
    • 事実
      • データが正しく収集された前提の元、データから直ちに導けるもの、かつ誰が見ても納得するもの
    • 解釈
      • データや分析結果に対する考え
    • 予測
      • データや解析結果に基づいて未来の状態を推測すること
    • 提案
      • 事実や解釈、予測をもとに実践すべき具体的な施策案
      • 抽象度の高い話をする際には具体的な値をベースにした例を挟む

9. 実施と検証

  • 提案の結果決まった施策を実施するフェーズ
  • データ解析者は施策を滞りなく実施すること、実施後の効果検証を行いやすくするために実施計画と実際の実施状況に何らかのズレがないか、などを観測する

10. 反省(振り返り)

  • 施策後には必ず効果検証を実施すること。
  • ほとんどの場合、施策の成否には外部要因が深く入り込んでくる

私的メモ

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?