pdca を止めないための KPI 設計：仮説→施策→計測→学習を確実に回す可視化

「立派なダッシュボードを作ったが、結局誰も見ていない」── KPI を組織に根付かせようとして最も多い失敗パターンです。原因はほぼ1つ、指標が「学習サイクル」と紐付いていないこと。本記事では 仮説→施策→計測→学習 の各段階で何を可視化すべきかを整理します。

PDCA（Plan-Do-Check-Act） / OODA / Build-Measure-Learn の使い分け

サイクルが止まる4大原因

1. 1仮説が曖昧：「効くと思う」だけで、何を信じてるか言語化されてない
2. 2計測方法が後付け：施策を打ってから「これ、どう測ろうか」が始まる
3. 3判定期日が決まってない：いつになったら成功 / 失敗を判断するのか不在
4. 4学習を残す場がない：判定したのに、その学びが次の仮説に反映されない

つまりダッシュボードや BI（Business Intelligence） ツールの問題ではなく、KPI 設計とプロセス設計の問題です。それぞれを順に潰します。

1. 仮説を「数値化可能な形」に書く

仮説は 「If 〜 Then 〜 Because 〜」 の3点セットで書きます。「If 施策 X を打てば、Then 指標 Y が △% 改善する。Because 〜という顧客行動の理屈があるから」。

2. 計測方法を「仮説と同時に決める」

仮説立案フェーズで計測方法を確定しておくのが鉄則。後付けの計測は selection bias / 期間バイアス / 実装漏れ が混入しやすい。

• ベースライン取得期間：施策前の N 週間でベンチマークを取る（季節性を吸収）
• 測定期間：施策後の M 週間（M ≥ N が目安）
• 比較群：A/B test できるなら必須、できなければ Pre/Post 比較 or コホート
• 統計的有意性：「+5pt 改善」と言う前に、p 値か信頼区間で確認する

WITH baseline AS (  -- 施策前の4週間  SELECT    AVG(d1_retention) AS d1_avg,    STDDEV(d1_retention) AS d1_std,    COUNT(*) AS n  FROM cohort_daily  WHERE cohort_date BETWEEN '2026-09-01' AND '2026-09-28'),treated AS (  -- 施策後の4週間  SELECT    AVG(d1_retention) AS d1_avg,    STDDEV(d1_retention) AS d1_std,    COUNT(*) AS n  FROM cohort_daily  WHERE cohort_date BETWEEN '2026-10-01' AND '2026-10-28')SELECT  baseline.d1_avg AS d1_before,  treated.d1_avg  AS d1_after,  treated.d1_avg - baseline.d1_avg AS lift,  -- 簡易 t 値（実運用では scipy.stats.ttest_ind 推奨）  (treated.d1_avg - baseline.d1_avg) /    SQRT(POWER(baseline.d1_std,2)/baseline.n + POWER(treated.d1_std,2)/treated.n) AS t_statFROM baseline, treated;

3. 可視化テンプレ：4ステージダッシュボード

学習サイクルを止めないための 「4ステージ・ダッシュボード」 を提案します。仮説・施策・計測・学習の4つを 1枚の画面に並べ、進捗が一目で分かるようにする構成。

4. 計測の3つの可視化パターン

パターン A: 時系列 with ベースライン帯

施策前の平均 ±2σ を半透明の帯で表示し、施策後の値がそこから外れているかを見る。簡易だが強力。異常検知の可視化（異常検知ハンドブック EP.04）と同じ発想。

パターン B: Cohort（同期入会群）比較

施策の導入前と後で 新規ユーザーの cohort を切り、D1/D7/D30 継続率を比較。ユーザーの履歴が混ざらないためバイアスが少ない。EP.04 の cohort と接続。

パターン C: A/B test の結果表示

棒グラフ + 信頼区間（エラーバー）。2 群の信頼区間が重なっていたら有意差なしと一目で分かる。営業部署や経営層は p 値より「バーが重なってるか」を直感的に理解する。

5. 学習を残す：Decision Log の運用

学習を組織に残すには Decision Log（決定ログ） が一番シンプル。「この仮説を試した → 結果はこう → 次にこう活かす」を 1 仮説 1 行 で記録。3〜6 ヶ月後に振り返ると、「同じ仮説を 3 回試して 3 回失敗した」 のような大事な学びが見えます。

id: H-2026-Q4-012date_created: 2026-10-08hypothesis: |  新規ユーザーの初回起動から24時間以内にプッシュ通知を送ると  D1継続率が42%から+5pt 改善する  Because Onboarding 期の離脱が多いからtarget_metric: D1 retentionguardrail_metric: 課金率, アンインストール率judgment_date: 2026-11-15result:  status: success | failure | inconclusive  target_lift: +3.2pt (95% CI: +1.5 ~ +4.9)  guardrail: アンインストール率 +0.4pt (有意差なし)learning: |  D1継続率は改善したが期待値より低い。仮説 H-2026-Q4-018 で  「24時間後 + 72時間後の2段プッシュ」をテスト予定links:  - dashboard: https://...  - design_doc: https://...  - pull_request: https://...next_hypothesis: H-2026-Q4-018

サイクルを回す3つのコミット

• 計測コミット: 仮説を立てた瞬間に計測方法（指標・期間・比較群）を確定する
• 期日コミット: 「いつ判定するか」を仮説立案時に決める。延長は別の仮説として立て直す
• 学習コミット: 判定後に Decision Log を残す。書かないと半年後には誰も覚えていない

ふくふくの進め方

「ダッシュボードはあるが PDCA が回っていない」というご相談は、指標の整理 + プロセス設計を 1〜2 ヶ月、4ステージ・ダッシュボードの構築を 2〜3 ヶ月、運用に乗せて学習が組織知になるまで含めて 6 ヶ月、というロードマップでお出しします。KPI（Key Performance Indicator） 設計と Decision Log 運用を、可視化図鑑 の作法とセットで導入するのが定型パターン。

次回予告

EP.17 では A/B テストの設計とツール選び。GrowthBook / Optimizely / Statsig / PostHog などの SaaS（Software as a Service） と OSS（Open Source Software）、自前実装の比較、サンプルサイズ計算、SRM（Sample Ratio Mismatch）（割付ズレ）の検出までを扱います。