分析計画と制約｜課題設定・分析計画

このページはプロモーション（広告）を含みます。

課題設定・分析計画（初級・読む30分＋演習40分）

この授業のゴール

• 問い・判断・仮説・指標・データ・方法・成果物・完了条件・担当・期限を1枚の分析計画書にまとめられる
• 時間・データ・費用・利用条件（個人情報など）の制約を洗い出し、計画にどう反映するかを書ける
• 仮説を「判断への影響」と「検証のしやすさ」で優先順位付けし、期限内に収まるように範囲を絞れる
• 「グラフができた」ではなく判断に結び付いた完了条件と、分析で判断できないことを計画書に明記できる

仕事でどう使うか

ここまでの授業で、問い（L01）、意思決定（L02）、仮説と証拠（L03）、指標と分析単位（L04）を個別に作りました。この授業では、それらを1枚の分析計画書にまとめ、誰が・いつまでに・何を・どこまでやるかを決めます。

計画書を作ると、分析を始める前に依頼者と「何が出てきたら完了か」を合意できます。途中で依頼者が変わったり、期限が早まったりしても、計画書を見れば何を優先すべきかが分かります。

前提

次の内容を使います。必要に応じて戻ってください。

• 問いの5要素 → 問題と問い
• 意思決定の3要素と判断表 → 利用者と意思決定
• 証拠マトリクスと否定条件 → 仮説と必要証拠
• 指標定義の7項目 → 指標と分析単位
• 出所と利用条件（データを使ってよい範囲）→ 出所と利用条件

個人情報とは、氏名や会員番号など、特定の個人を識別できる情報のことです。会社の規程や法令で使い方が決められています。この授業では「個人情報を含むデータは、目的と利用範囲を確認してから使う」ことだけを前提にします（法令の具体的な内容は データ利用・法律・権利の読み方 などで扱います。最新の内容は公式情報で確認してください）。

身近な状況：「とりあえず始めて」から3週間後

さくら雑貨の本部で、データ担当のCさんが駅前店の分析を任されました。依頼は「売上減少を調べて、来週の会議に間に合わせて」。Cさんはすぐに作業を始めました。

• 1日目：POSデータを抽出。入口センサーのデータは別部署の管理だと分かり、申請を出した
• 3日目：センサーデータの承認待ち。待つ間に商品別の売上を細かく集計
• 5日目：センサーデータが届いたが、保存期間が3か月で、前年同月と比べられないと判明
• 6日目：会議の前日。商品別の集計は30ページあるが、店長が知りたい「チラシを配るか」の答えはない

Cさんが悪かったのは、作業の速さではありません。始める前に、必要なデータの入手方法と期間、期限内にできる範囲、何が出たら完了かを決めていなかったことです。

分析計画書は、このような失敗を作業の前に見つけるための道具です。

直感的な説明：計画書は「旅のしおり」、制約は「持ち物と時刻表」

旅行に出る前に、行き先・日程・予算・持ち物・乗る電車の時刻を書いた「しおり」を作ると、当日に慌てずに済みます。終電の時刻（期限）を知らずに観光地を回ると、最後に帰れなくなります。

分析計画書も同じです。

大事なのは、全部を回ろうとしないことです。期限と人手は限られているので、判断への影響が大きく、手早く確かめられる仮説から順に調べ、残りは「今回は扱わない」と明記します。扱わないことを書くのは手抜きではなく、範囲を合意するための大切な作業です。

正確な定義：分析計画書の項目と制約の種類

分析計画書（analysis plan）とは、分析を始める前に、目的・範囲・方法・担当・期限・完了条件を文書にしたものです。この教材では次の12項目を1枚にまとめます。

制約（constraint）とは、分析の進め方を限る条件です。

完了条件（definition of done）は、作業量ではなく判断の材料で書きます。悪い例：「グラフを10枚作る」。良い例：「仮説A（工事）と仮説C（地域需要減）を区別する比較結果と、判断表のどの行に当たるかを、店長が会議で使える1枚にまとめる」。

仮説の優先順位は、次の2軸で付けます（この教材の簡易な方法です）。

$$\text{優先度} = \text{判断への影響} \times \text{検証のしやすさ}$$

それぞれを1（低い）〜3（高い）で評価します。判断への影響が3（結果次第でチラシの判断が変わる）、検証のしやすさが3（手元のデータで1日で確かめられる）なら $3 \times 3 = 9$ で最優先です。点数は厳密な測定ではなく、関係者と優先順位を話し合うための目安です。

段階付き例題：駅前店の分析計画書を1枚にまとめる

入力：L01〜L04で作った問い・判断・仮説・指標。期限は5営業日後の会議（前日に店長へ資料を渡す）。分析担当はCさん1人。

ステップ1：仮説に優先順位を付ける。

ステップ2：作業と所要日数を並べ、期限に収まるか確かめる。

合計 $0.5 + 1 + 1.5 + 1 + 0.5 = 4.5$ 日で、5営業日に0.5日の余裕があります。承認が遅れた場合に備え、3日目の午前を中間確認（データがそろっているか）のタイミングにします。

ステップ3：制約と代わりの手段を書く。センサーの保存期間が3か月のため前年比は使わない。公園前店のデータの承認が3日目までに来なければ、駅前店の工事日と非工事日の比較だけで暫定報告し、仮説Cは「未確認」と明記する。会員データは今回使わない（判断に不要で、利用目的の確認に時間がかかる）。

ステップ4：完了条件と判断できないことを書く。完了条件は「仮説AとCを区別する比較結果と、判断表の該当行を書いた1枚メモを、会議前日に店長が受け取っている」。判断できないことは「来店減の原因の断定」「チラシを配った場合の効果の大きさ」「競合店開店の影響」。

出力：12項目を埋めた1枚の計画書（本授業の自力課題で、別の事例で作ります）。

意味：計画書があれば、上長は初日に範囲と期限の妥当性を確認でき、Cさんは「判断と無関係な商品別集計」に時間を使わずに済みます。

操作して理解する：期限が短くなったら、どの仮説を外すか

次のコードは、仮説ごとの優先度と所要日数から、期限内に調べられる仮説を優先度の高い順に選びます。期限 deadline_days を変えて、計画がどう変わるかを確かめましょう。

# 各仮説: (名前, 判断への影響1-3, 検証のしやすさ1-3, 所要日数)
hyps = [("A:工事", 3, 3, 1.5), ("C:地域需要減", 3, 2, 1.5),
        ("B:天気", 2, 3, 0.5), ("D:競合店", 2, 1, 3.0)]
common_days = 2.0      # どの仮説でも必要な作業（品質確認・報告作成など）
deadline_days = 5.0    # 使える営業日数

ranked = sorted(hyps, key=lambda h: h[1] * h[2], reverse=True)  # 優先度の高い順
used, chosen = common_days, []
for name, impact, ease, days in ranked:
    score = impact * ease
    if used + days <= deadline_days:
        used += days
        chosen.append(name)
        print(f"{name}: 優先度{score} → 調べる（累計{used}日）")
    else:
        print(f"{name}: 優先度{score} → 今回は扱わない")
print("調べる仮説:", chosen)

出力：

A:工事: 優先度9 → 調べる（累計3.5日）
C:地域需要減: 優先度6 → 調べる（累計5.0日）
B:天気: 優先度6 → 今回は扱わない
D:競合店: 優先度2 → 今回は扱わない
調べる仮説: ['A:工事', 'C:地域需要減']

sorted(..., key=..., reverse=True) は、各仮説の「影響×しやすさ」が大きい順に並べ替える関数です。同点（CとBはどちらも6）の場合は元の並び順が保たれます。

試してほしい変更：

• deadline_days = 4.0 にすると、Aだけが入り（累計3.5日）、Cは入らず、0.5日のBが入ります（累計4.0日）。期限が短いと、優先度が同じでも所要日数の短い仮説が残ることが分かります。そのとき、Cを外したことを「判断できないこと」に書く必要があります。
• Bの天気は、Aの比較で雨の条件をそろえれば追加の日数なしで扱えます。このように、作業をまとめて扱えるかを考えるのも計画の工夫です。コードの点数は目安であり、最終的な範囲は依頼者と合意して決めます。

発展：計画を変更するときの手順と、事前に固定すべきもの

計画は変えてよいが、変更を記録する：データを見て新しい事実が分かったら、計画を変えるのは自然なことです。ただし、変更日・変更内容・理由・承認者を計画書の末尾に追記します。

事前に固定すべきもの：判断基準、否定条件、主な指標の定義は、結果を見る前に固定しておくべきものです。これらを結果を見てから変えると、望む結論に合わせた分析（後付けの分析）になります。研究では、仮説と分析方法を事前に公開する事前登録という仕組みがあります（研究の問い・新規性・検証などで扱います）。

利用条件と倫理の確認：個人単位のデータ（会員の購買履歴など）を使う場合は、収集時に示した利用目的の範囲内か、社内の承認が必要かを、計画の段階で確認します。多くの分析は、個人を特定しない集計値で十分に答えられます。必要以上に細かいデータを使わないこと（データ最小化）は、リスクを下げ、承認も得やすくします。具体的な法令やルールは組織や国で異なり、変わることもあるため、執筆時点（2026年）の一般的な考え方として理解し、実務では社内規程と公式情報を確認してください。

担当の明確化：作業の担当（実施する人）だけでなく、確認する人（集計の誤りをチェックする）と承認する人（範囲・公開を決める）を分けて書くと、誤りの見逃しや「誰が決めたのか分からない」状態を防げます。

よくある失敗

失敗1：完了条件を作業量で書き、判断に使えない成果物になる

誤った完了条件：「売上・来店者・購入率のグラフを日別・曜日別・商品別に作成する（計15枚）」

なぜ誤りか：15枚のグラフができても、店長がチラシを配るかを決められるとは限りません。作業量は達成できても、目的（判断）は達成されません。

直し方：

完了条件は「誰が、何を受け取り、何を決められる状態か」で書きます。

失敗2：データの入手手続きと所要日数を見積もらない

誤った計画：「1日目：データ抽出、2〜3日目：集計、4日目：報告作成」。ところが、入口センサーのデータは別部署の管理で、承認に3営業日かかった。

計算の比較：

なぜ誤りか：データの入手には、権限の申請、担当者の都合、保存期間の確認など、作業以外の時間がかかります。

直し方：計画書の「データ」欄に、入手方法・所要日数・承認者を書き、手続きの必要なデータは初日に申請します。間に合わない場合の代わりの手段も書いておきます。

失敗3：個人単位のデータを、目的や利用条件を確認せずに使う

誤った進め方：来店減の分析のために、会員の氏名・住所付きの購買履歴を全件抽出し、個人のファイルに保存して集計した。

なぜ誤りか：今回の問い（工事と来店者数の関係）には、店舗×日の集計値で十分でした。必要以上に細かい個人データを扱うと、収集時の利用目的を超える可能性があり、漏えいした場合の影響も大きくなります。

直し方：

1. 問いに必要な最小の粒度を決める（今回は店舗×日の来店数）
2. 個人データが必要な場合は、利用目的と社内の承認手続きを計画の段階で確認する
3. 氏名など識別に使う列は抽出しない、保存場所を決められた場所に限る

計画書の「制約」欄に「会員データは使用しない（判断に不要）」と書いておくと、後から範囲を広げたくなったときにも、確認の手順を踏むきっかけになります。

まとめ

• 分析計画書は、背景・意思決定・問い・仮説と証拠・指標・データ・方法・成果物・完了条件・担当と期限・制約・判断できないことを1枚にまとめる。
• 制約（時間・データ・手続き・利用条件・人手）を先に洗い出し、時間のかかる手続きは初日に行う。
• 仮説は判断への影響と検証のしやすさで優先順位を付け、扱わない仮説は明記する。
• 完了条件は作業量ではなく判断の材料で書く。計画の変更は理由とともに記録する。

用語

分析計画書（analysis plan）

分析を始める前に、目的・範囲・方法・担当・期限・完了条件などを文書にしたもの。

制約（constraint）

分析の進め方を限る条件。時間、データの有無、入手手続き、利用条件、費用・人手など。

完了条件（definition of done）

何がそろえば作業を終えてよいかの基準。判断に必要な材料で書く。

マイルストーン（milestone）

作業の途中に置く確認の締め切り。遅れを早く見つけるために使う。

データ最小化（data minimization）

目的に必要な最小限のデータだけを扱うという考え方。リスクを下げ、承認を得やすくする。

よくある質問

小さな分析でも計画書は必要ですか？

半日で終わる分析なら、12項目すべてでなくても、問い・判断・完了条件・期限の4つを3〜4行で書くだけで十分です。依頼者にその数行を見せて「この理解で合っていますか」と確認するだけでも、手戻りが大きく減ります。

計画書を書く時間がもったいなく感じます。

計画に30分かけて、判断と無関係な集計に2日使う失敗を防げるなら、十分に元が取れます。特にデータの入手手続き（承認・抽出依頼）は、計画しないと待ち時間がそのまま遅れになります。

分析計画とプロジェクト計画の違いは？

分析計画は「何を明らかにし、何が分かれば終わりか」が中心で、問い・仮説・指標・判断できないことを含みます。プロジェクト計画は施策の実行全体（予算、体制、リリース）を扱います。分析計画は、プロジェクト計画の中の調査部分にあたることが多いです。

計画どおりに進まなかったら失敗ですか？

いいえ。データを見て計画を変えるのは自然なことです。大事なのは、変更の理由を記録し、判断基準や否定条件のような事前に固定すべきものを、結果に合わせて変えないことです。

制約がきつくて、判断に必要な証拠が期限内にそろわない場合は？

①問いを期限内に答えられる大きさに絞る、②暫定の結論と不確かさを添えて出す、③判断の延期や小さな試行（1地区だけで試す）を提案する、のいずれかを依頼者と相談します。どの結論も出せない場合の扱いは、次の授業（L06）で扱います。

担当を1人で全部やるときも、確認者は必要ですか？

必要です。集計の誤り（結合の重複、除外漏れ）は自分では気づきにくいからです。チームに確認者がいなければ、上長や依頼者に「この3つの数字（行数・合計・主な結果）を確認してください」と頼むだけでも効果があります。

確認問題

次に学ぶこと

次は しない判断と中止条件 で、分析をしない判断と、分析を途中でやめる中止条件を扱います。計画書の最後の項目「判断できないこと」とあわせて、モジュールの仕上げになります。

データの出所と利用条件は 出所と利用条件、不足時の追加収集は 不足と追加収集 で詳しく扱います。分析結果の報告と合意の作り方は 分析報告・判断・合意（有料版） で学びます。