12.1 分析から改善までのサイクル
この章で学ぶこと
- 改善のサイクル（PDCA と OODA）の考え方
- データから仮説を立てる方法
- 施策の優先順位を付ける方法
- 施策を振り返り、次の改善につなげる方法
PDCA と OODA
アクセス解析の目的は、数値を見ることではなく、サイトやビジネスを改善すること です（第 1 部）。そのためには、分析 → 施策 → 検証 → 次の施策、という サイクル を回し続ける必要があります。
PDCA
PDCA は、改善のサイクルの代表的な考え方です。
| 段階 | 内容 | アクセス解析での例 |
|---|---|---|
| Plan（計画） | 目標と仮説を決め、施策を計画する | 「料金ページからの問い合わせ率が低いのは、料金表がわかりにくいからではないか」→ 料金表を改善する |
| Do（実行） | 施策を実行する | 料金表のデザインを変えて公開する |
| Check（評価） | 結果を測る | 公開の前後で、料金ページからの問い合わせ率を比べる |
| Act（改善） | 結果を踏まえて、次の行動を決める | 効果があったので、ほかのページにも同じ考え方を広げる |
OODA
OODA（ウーダ）は、変化の速い状況で、すばやく判断して行動するための考え方です。
| 段階 | 内容 | アクセス解析での例 |
|---|---|---|
| Observe（観察） | 状況を観察する | ダッシュボードで、スマホのキーイベント率が先週から急に下がったことに気づく |
| Orient（状況判断） | 観察したことを解釈する | 先週公開したフォームの変更が原因ではないか |
| Decide（決定） | 行動を決める | フォームを元に戻す |
| Act（行動） | 行動する | フォームを元に戻し、数値の回復を確認する |
使い分け
| 場面 | 向いている考え方 |
|---|---|
| 計画的な改善（サイトの改修、コンテンツの改善、広告の予算配分の見直し） | PDCA |
| 日々の変化への対応（数値の急な変化、キャンペーンの途中の調整） | OODA |
ポイント どちらの考え方でも、最も大切なのは サイクルを止めないこと です。「分析したけれど施策をしなかった」「施策をしたけれど結果を見なかった」状態にならないよう、各段階の担当者と期限を決めておきましょう。
仮説の立て方
改善のサイクルは、仮説 から始まります。仮説とは、「〇〇が原因で、△△になっているのではないか。だから □□ をすれば改善するのではないか」という、検証できる考えのことです。
仮説の形
［現状］ 料金ページを見たユーザーの問い合わせ率が 1.2% と低い
［原因］ 料金表のプランの違いがわかりにくく、自分に合うプランを選べないのではないか
［施策］ プランの比較表に「こんな方におすすめ」の行を追加する
［期待］ 料金ページからの問い合わせ率が 1.5% 以上になる
［検証］ 公開の前後 4 週間で、料金ページを見たユーザーの問い合わせ率を比べる仮説の材料を集める
| 材料 | 見る場所 | 例 |
|---|---|---|
| 数値の比較 | 標準レポート、探索 | デバイス別、チャネル別、新規・リピート別で、どこに差があるか |
| ユーザーの流れ | 経路データ探索、ファネル データ探索 | どこで多くのユーザーが離脱しているか |
| 個別の行動 | ユーザー エクスプローラ | 成果に至ったユーザーと至らなかったユーザーの行動の違い |
| 定性的な情報 | ヒートマップ、ユーザーへのアンケート、問い合わせの内容、営業の声 | 「どのプランがいいかわからない」という問い合わせが多い |
| 外部の情報 | 競合のサイト、検索のトレンド | 競合は料金のシミュレーションを用意している |
注意 数値だけを見ていると、「何が起きているか」はわかっても、「なぜ起きているか」はわからないことが多くあります。数値で 場所 を特定し、定性的な情報で 理由 を考える、と組み合わせると、良い仮説を立てやすくなります（第 1 部）。
良い仮説の条件
| 条件 | 悪い例 | 良い例 |
|---|---|---|
| 具体的である | 「サイトをわかりやすくする」 | 「料金表に、おすすめの対象を書き加える」 |
| 検証できる | 「ブランドの印象が良くなる」 | 「料金ページからの問い合わせ率が上がる」 |
| 根拠がある | 「なんとなく、デザインが古い気がする」 | 「プランの違いについての問い合わせが月 20 件ある」 |
| 期待する結果が明確 | 「問い合わせが増える」 | 「問い合わせ率が 1.2% から 1.5% になる」 |
優先順位の付け方
仮説や施策のアイデアは、たくさん出てきます。すべてを同時に行うことはできないので、優先順位 を付けます。
ICE スコア
施策の優先順位を付けるための、簡単な方法の一つが ICE スコア です。
| 観点 | 内容 | 評価（1〜10） |
|---|---|---|
| Impact（効果） | うまくいったときに、成果にどれくらい影響するか | 対象のページのアクセス数や、KGI への近さで考える |
| Confidence（確信度） | うまくいく見込みはどれくらいか | 根拠となるデータや事例があるか |
| Ease（実行のしやすさ） | どれくらい簡単に実行できるか | 必要な時間、費用、関わる人の数 |
ICE スコア = Impact × Confidence × Ease（または 3 つの平均）評価の例
| 施策 | Impact | Confidence | Ease | スコア（積） |
|---|---|---|---|---|
| 料金表におすすめの対象を追加 | 7 | 7 | 8 | 392 |
| フォームの入力項目を 12 個から 6 個に減らす | 8 | 8 | 5 | 320 |
| トップページのデザインを全面的に刷新 | 8 | 4 | 2 | 64 |
| 人気の記事に資料請求の CTA を追加 | 6 | 6 | 9 | 324 |
（評価は例）
ポイント ICE スコアの数値そのものに、厳密な意味はありません。大切なのは、チームで同じ観点で話し合い、「なぜこの施策を先にやるのか」を説明できるようにすることです。
小さく早く試す
「効果は大きそうだが、実行が大変」な施策（サイトの全面刷新など）は、いきなり全体で行うのではなく、一部のページや期間で小さく試せないか を考えましょう。小さく試して効果を確かめてから広げると、失敗したときの損失を小さくできます（この部の第 7 章の A/B テスト）。
施策の振り返り
施策を実行したら、必ず 振り返り を行います。
振り返りで確認すること
| 確認すること | 内容 |
|---|---|
| 結果 | 期待した指標は、どれくらい変わったか |
| 仮説の正しさ | 結果から、仮説は正しかったと言えるか |
| 想定外の影響 | ほかの指標に、悪い影響が出ていないか（例：問い合わせは増えたが、質が下がった） |
| 学び | 次の施策に生かせることは何か |
| 次の行動 | 続ける、広げる、元に戻す、別の施策を試す |
効果の測り方の注意点
| 注意点 | 内容 |
|---|---|
| 季節や曜日の影響 | 施策の前後で、季節やキャンペーンの有無が違うと、正しく比べられない。前年同期とも比べる |
| ほかの施策の影響 | 同じ時期に、広告やメールなど、ほかの施策があった場合は、その影響を考慮する |
| 期間の長さ | 短すぎる期間では、偶然の変動と区別できない。十分なデータが集まるまで待つ |
| 比べる対象 | 可能なら、施策をしていないページやユーザーと比べる（A/B テスト） |
振り返りを記録する
【施策】料金表に「こんな方におすすめ」の行を追加
【期間】2026-09-01 公開。前後 4 週間を比較
【結果】料金ページを見たユーザーの問い合わせ率：1.2% → 1.6%（+0.4 ポイント）
【その他】料金ページの平均エンゲージメント時間が 15 秒増加。問い合わせのうち「プランの違い」の質問が 20 件 → 8 件に減少
【判断】仮説は正しかったと考えられる。ただし 9 月は展示会があったため、10 月も継続して確認する
【次の行動】サービス紹介ページにも、「こんな方におすすめ」の情報を追加する（数値は例）
注意 うまくいかなかった施策も、失敗の記録 として残しましょう。「この施策は効果がなかった」という学びは、同じ失敗を繰り返さないための、貴重な情報です。
よくある質問
Q. 分析はしているのに、施策につながりません。
A. 分析の 問い があいまいな可能性があります。「サイトの状況を分析する」ではなく、「料金ページからの問い合わせが少ない理由を調べる」のように、答えが施策につながる問いを立ててから分析を始めましょう。また、分析の結果を報告するときに、「次に何をするか」の提案を必ず添えることも大切です（この部の第 2 章）。
Q. 施策を実行する権限が、自分にはありません。
A. 多くの組織で、分析する人と、サイトを改修する人、予算を決める人は別です。その場合は、施策の 効果の見込み と 必要な作業・費用 を、決める人にわかる形で示しましょう。最初は、実行のしやすい小さな施策（文言の変更、リンクの追加など）で成果を出し、信頼を得てから、大きな施策を提案するのが現実的です。
Q. 仮説がたくさん出て、どれから試せばよいかわかりません。
A. この章の ICE スコアで優先順位を付けましょう。それでも迷う場合は、影響を受けるユーザーの数が多い場所（アクセスの多いページ、多くの人が通るファネルのステップ）から始めるのが基本です。少ない人しか見ないページを改善しても、全体への影響は小さくなります。
Q. 施策の効果が、はっきりしません。
A. 効果が小さい、期間が短い、ほかの要因の影響が大きい、のいずれかが考えられます。前後比較でははっきりしない場合は、A/B テスト（この部の第 7 章）で確かめるか、より大きな変化が期待できる施策を試しましょう。「効果がはっきりしなかった」ことも、記録に残しておきます。
実践ワーク
自社のサイトについて、改善のアイデアを 5 つ書き出し、ICE スコアで優先順位を付けてみましょう。
| 施策のアイデア | 根拠となるデータ | Impact | Confidence | Ease | スコア |
|---|---|---|---|---|---|
スコアが最も高い施策について、この章の「仮説の形」（現状・原因・施策・期待・検証）で、仮説を書いてみましょう。書いた仮説を同僚に見せて、「根拠は十分か」「検証の方法は適切か」を話し合うと、仮説の質が上がります。実行したら、「施策の振り返り」の形で記録を残し、次のサイクルにつなげましょう。
まとめ
- 改善は、計画的な改善には PDCA、日々の変化への対応には OODA の考え方で、サイクルを止めずに回す
- 仮説は「現状・原因・施策・期待・検証」の形で、具体的で検証できるように立てる
- 数値で場所を特定し、定性的な情報で理由を考えると、良い仮説を立てやすい
- ICE スコアなどで、効果・確信度・実行のしやすさから優先順位を付け、大きな施策は小さく試す
- 施策のあとは、季節やほかの施策の影響に注意して効果を測り、成功も失敗も記録する
次の章では、分析の結果を、社内の人に伝わる報告にまとめる方法を学びます。