以前、Looker Studioで自サイトのKPIサマリーを作りました。Google Analytics 4（GA4）とGoogle Search Console（GSC）の数値を1画面にまとめられたことで、完成したときには達成感がありました。
しかし前回の記事でお伝えした通り、反省点がありました。
「いつ・何のために見る画面なのか」を決めないまま作ってしまったこと
報告に必要な差分がNotion側にしかなかったこと
そして数値を見たあとにどこを深掘りするかの流れを作れていなかったこと
この3つを振り返り、結局のところ「誰が何のために見る画面か」を決めきれていなかったというのが、前回たどり着いた結論でした。
そこで今回は、いきなりLooker Studioの画面を直すのではなく、要件定義からやり直すことにしました。使ったのは、デジタル庁が公開している「ダッシュボードデザインの実践ガイドブック」に付属する要件定義ワークシートです。現在公開されている最新のワークシートは2024年5月31日版で、これをそのまま使用しました。
この記事では、その要件定義の過程で自分が何につまずき、何を手がかりに考え直したのかをお伝えします。（GA4やGSCの仕様そのものの解説は、この記事では扱いません。あくまで要件定義の考え方に焦点を当てています。）
プロジェクトの基本情報で、目指す状態と現実の制約を言語化した
要件定義ワークシートで最初にあるのは、「プロジェクトの基本情報」についてのページでした。達成すべき目標や関係者、制約、リスクとその許容度、スケジュールなどを書く場所です。
「完成」ではなく「使えている状態」をゴールにする
達成すべき目標の欄を埋めるにあたって、「このプロジェクトが成功したと言える状態は何か」を考えました。前回の反省は、作ったのに使わなかったことです。
そのため今回は、「完成後にどう使えていれば、この改善プロジェクトが成功だと言えるのか」から逆算して考え、次のように書きました。
サイト数値の目標を達成できるように、KPIサマリーを利用してサイト状況の確認・改善・報告が継続的にできる状態
最初につまずいた「リスクと許容度」
最初に詰まったのは、「想定されるリスクと許容度」という欄でした。最初に書けたのは、「データ更新にタイムラグがあり、最新の数値が表示されない」というリスクについてだけでした。
これで書けたつもりでいたのですが、欄の名前を見返すと「想定されるリスクと許容度」となっています。リスクをどこまでなら許容するのか、という部分が抜けていました。
そこで、どの程度の遅延なら許容できるのか、その場合どう対応するのかまで考え直しました。実際にどのくらいの遅延が発生するのかを確認したところ、半日から2日程度であることが分かり、GA4・GSCを直接見ているときの遅延と変わらないため、許容範囲内だと判断できました。あわせて、集計期間を画面上に明記することで対応する、というところまで書き加えました。
目的を整理したら、1つのKPIサマリーに2つの役割があると分かった
次は「ダッシュボードの目的」を考える欄に進みます。ここでは、以下の5W1Hの問いにしたがって4項目について書きます。
Why（目的）
What, so What（判断や行動のために必要な情報）
Who, When, Where（誰がいつどこで見るか）
How（必要な機能やデータ項目、更新頻度）
Whyを書きながら気づいた2つの目的
Whyの項目から書き始めて、気づいたことがありました。自分のKPIサマリーには、2つの目的が混ざっていたのです。
サイト数値を確認し、大きな変動があれば原因候補を探す → 全体数値確認
改善候補となる記事を見つけ、改善の方向性を考える → 改善分析
過去記事の考え方から2画面の案が浮かぶ
この時点で頭にあったのは、以前自分が書いた「利用者に合わせてダッシュボードを分ける」という記事の考え方でした。見る人や目的が違えば、必要な情報や見たい粒度、判断したいことも変わるため、それに合わせて画面を分けるという内容です。
この考え方を思い出しながら、「1つの画面に全部載せるのではなく、目的ごとに画面を分けた方がよいのではないか」という案が自分の中で浮かびました。
ただし、目的が2つあるからといって、すぐに画面を2つに分けるとは決めませんでした。過去記事の考え方にも、「利用者が違えば必ず別画面にする」という意味ではなく、重要なのはその人が行う判断や、その判断に必要な情報が違うかどうかだと書きました。
デジタル庁のフレームで「本当に分ける必要があるか」を確認する
そこで、2画面に分ける案を持ったうえで、次の順番で具体的に書き出しました。
2画面に分ける案を仮に持つ
デジタル庁のワークシートの5W1Hの順に沿って、実際にWhat〜Howまで書いてみる
Whyの言葉だけでなく、見たい情報・主な判断や行動・利用するタイミング・必要な機能のすべてが異なるかを確認する
異なることが確認できたため、2画面構成を採用する
このような流れで、目的ごとに「何を把握し、何を判断・行動するのか」「いつ使うのか」「何の情報が必要なのか」まで整理しました。その結果、全体数値確認と改善分析では利用の流れが異なると分かり、2画面に分けました。
一番難しかったのは、Why・What・Who・Howを「つなぐこと」だった
ここまでの2つの章も含めて、今回の要件定義で一番時間がかかったのは、書き終えた項目同士が、本当に繋がっているかを確認する部分でした。
What, so Whatが「行動だけ」になっていた
その中でも特に詰まったのが、「What, so What」の欄です。最初は、次のように「何をするか」を中心に書いていました。
原因候補を整理する
改善候補記事を抽出する
リライト方針を決める
欄は埋まっていますが、見返してみると、「何を見て、その判断をするのか」という情報が抜けていました。行動だけが書かれていて、その行動の根拠になる情報が書かれていない状態です。
ここで、全体数値確認の画面について改めて考え直しました。この画面で自分がやりたいことは、1段階ではありませんでした。
サイト数値が目標値に対してどのくらいか、変動はあったかをざっと確認する
詳しく見る必要があるか、報告すべきかを判断する
詳しく見る必要があると判断した場合、チャネル別やページ別の数値まで踏み込んで原因候補を整理し、相談・報告する
そこから意思決定者が改善などの判断をする
このように分解することで、確認から深掘り、報告、判断までが一続きの流れになっていることに気づきました。
「行動」だけだったものに、その「判断に必要な情報」を加えました。
改善分析の画面についても、同じ考え方で書き直しました。改善候補となる記事を数値で絞り込み、そのうえで検索クエリと関連指標を確認して改善の方向性を見つける、という流れです。
WhyとWhatとWhoがつながっていなかった
もう1つ繋がっていないと気づいたのは、WhyとWhatの間でした。
全体数値確認の画面のWhyには、当初「必要に応じて原因候補を整理し、改善判断や報告ができるようにする」と書いていました。しかしWhat側を見ると、自分が原因候補を整理し、施策を考え、報告の準備をするところまでが中心になっていて、「誰が改善判断をするのか」がはっきりしていませんでした。
Whyで掲げた目的が、Whatの中の行動からは漏れていたのです。
前の欄で決めた目的が、次の欄の実際の行動として存在しているかを確認する必要があると、ここで気づきました。
この気づきは、プロジェクトの基本情報で書いた関係者の欄にも関連してきました。最初、関係者は「報告を受ける人」としていました。しかし、Whyを見直す中で、KPIサマリーは報告するためだけのものではなく、意思決定者自身が状況を把握し、改善などを判断するためのものでもあると整理し直していました。
そう考えると、元の書き方では、その人が実際に何をする人なのかを表せていませんでした。MTGでのその人の動きとして、報告を聞き、サイト状況を把握したうえで、改善などについて判断することが実際の役割でした。
そこで、関係者の欄を役割そのものを表す「意思決定者」に書き直しました。
「仕様」と「要件」を混同していた更新頻度
最初に書いていた「12時間ごと」は、データがどのくらいの頻度で更新される仕組みか、というシステム側の話でした。ワークシートが問うているのは「必要な更新頻度」だったので、これでは答えになっていませんでした。
そこで、Who/When/Whereの欄を見返しました。全体数値確認は週初めやMTGの前後、改善分析は記事改善前に開く画面でしたが、どちらも「その時点のサイト状況・記事状況を正しく把握したい」という点は共通していました。決まった頻度で更新されるかどうかより、開いたときにその時点の最新の状態が見られるかどうかの方が重要だと気づき、更新頻度を「開いたタイミングで最新のデータに更新される」に書き直しました。
今回難しかったこと
要件定義の中で特に難しかったのは、次の4点でした。
関係者欄に名前だけ置いて終わらせず、その人が実際に何を見て何を判断するのかまで明示すること
「仕様」と「要件」を混同しないこと
What, so Whatを行動だけで終わらせず、その行動に必要な情報までセットで考えること
各欄を単体で埋めることよりも、Whyで言っている目的がWhatにあるか
その行動をする人がWhoと一致しているか
その行動に必要な情報や機能がHowにあるか、という欄同士の接続を確認すること
今回作成した、私の要件定義シートを載せておきます。書き方で迷った時に、良ければ参考にしてください。
まとめ
完成した要件定義シートは、最初と比べて文字数が増えただけでなく、内容が濃く、具体的になったように感じました。この記事で残しておきたいのは、完成したシートそのものよりも、そこに至るまでの試行錯誤です。
最初は、欲しい情報や行動を欄ごとに単体で書いていました。見直しを重ねる中で気づいたのは、前の欄で決めたことが次の欄にちゃんと落ちているかを、都度戻って確認するのが大事だということです。「何を知り、何を判断・行動するために必要なのかから考える」というのが、今回の要件定義を通じてたどり着いた考え方です。
もし要件定義を進める際は、5W1Hを書き終えたあとに、前の欄の目的が次の欄にちゃんと反映されているかを見返してみてください。
要件を言葉として整理できたので、次はこれをプロトタイプに落とし込む工程に進みます。ただ、言葉の上で繋がりが取れているように見えても、実際に画面にしたときに本当にこの流れで使えるのかは、まだ分かりません。
次回は、この要件定義をもとに作ったプロトタイプと、そこで受けたフィードバックについてお伝えします。
著者
名前：minoRi
Tableau Certified Data Analyst（2025年4月取得）。非エンジニアですが、独学でTableauやLooker Studioに触れながら、ダッシュボード作りに関わってきました。このブログでは、そうした試行錯誤の中で気づいたことを、同じように非エンジニアの立場でデータと向き合う人に向けて発信しています。