前回は、デジタル庁の「ダッシュボードデザインの実践ガイドブック」を参考に、ダッシュボードの要件定義をやり直しました。5W1Hで、誰が何のために使い、何を知って、何を判断・行動するのかを言葉にした回です。

「5W1Hで要件定義からやり直す～ダッシュボード改善奮闘記 第1回～」

その前の回では、作ったのに使えていなかったダッシュボードについて、3つの反省点について振り返りました。

「作ったダッシュボード、全然使ってない！～ダッシュボード改善奮闘記 第0回～」

今回は、その要件定義を実際の画面に落とし込んだ「プロトタイピング」の記録です。

要件定義を終えた時点の私は、「ここからはレイアウトを考える工程だ」と思っていました。要件定義で必要とした情報を、見やすく並べればプロトタイプになると考えていたからです。

ところが画面にしてみると、「この並びで判断がつながる？」「この操作をして何が分かる？」と、要件定義のときには見えていなかった問いがいくつも出てきました。

この記事では、仮レイアウトを作り、レビューを受けながら実装に進める状態まで進めた過程を、途中の迷いも含めて書きます。Looker Studioで本番の画面を作り始める前までの話です。

なお、ダッシュボードは目的の違いから2画面に分けています。

• 全体数値確認用：目標との差や数値変動を確認し、必要に応じて原因候補を掘り下げ、相談・報告・改善判断につなげる

• 改善分析用：タイトル・ディスクリプション改善（TD改善）やリライト候補の記事を見つけ、ページ別・検索クエリ別のGSC数値から改善の方向性を考える

デジタル庁が示すプロトタイピング

この改善奮闘記では、デジタル庁の「ダッシュボードデザインの実践ガイドブック」を参考に、実際のダッシュボードを見直しています。前回の要件定義編に続き、今回もガイドブックの手順を参考にプロトタイピングを進めました。

ダッシュボードデザインの実践ガイドブックとテンプレート_デジタル庁

ガイドブックでは、「プロトタイプを元にチームや周囲の関係者と話し合うことで、ダッシュボードのQCD（= 品質とコスト、納期）向上が期待（p.15）」できると書かれています。

プロトタイピングのゴールは、次の2つとされています。

• ダッシュボードのイメージがわかるプロトタイプを作成すること
• レイアウトやデータの内容を関係者間で合意すること

このゴールに向けて、ガイドブックの手順に沿って進めました。ただ実際には、自分で考えては手が止まり、ガイドブックに戻って足りない点に気づく、という場面のほうが多かったです。

1. 要件定義どおりに並べるだけでは足りなかった

まず情報を一覧にした

ガイドブックでは、最初に「載せるべき情報を整理する」として、「整理した要件を元に、ダッシュボードに必要な情報を整理し、一覧化（p.16）」するよう書かれています。

私もガイドブックの一覧例（p.17）にならって、スプレッドシートで一覧を作りました。列は、一覧例と同じ「指標の分類」「情報の詳細」「補足情報」「グラフ候補」の4つで考えました。

「何を判断する？」で一覧を見直した

最初は、一覧に挙げた情報を、そのまま画面に並べればよいと考えていました。

ところが一覧の情報をひとつずつ「この情報を見て、何を判断するのか？」と確かめると、載せ方を見直したい箇所が出てきます。実際に見直したのは、次のような点です。

• 目的に寄っていない情報 → 目的に沿って修正

• 意味の薄い列 → 削除

• 目標値との差 → 目標値がある指標にだけ表示した

• 前期間との比較が必要になりそうな箇所 → 洗い出す

要件定義で決めたことを画面に並べるだけだと思っていましたが、実際には要件定義の中身をひとつずつ確かめ直すことになりました。

2. 画面の都合より「見る目的」で配置した

レイアウトは、ガイドブックで用意されている「縦横6分割のレイアウトグリッドをひいた16:9の画面用テンプレート」（p.23）を使って考えました。

16:9に収めようとして、ページを分けすぎた

要件定義では、画面の制約を「デスクトップPCでの閲覧」としていました。そのため最初は、デスクトップPCの16:9の画面に収めることを強く意識していました。Googleスライドで仮レイアウトを作り始めたときも、それぞれの画面を次のような複数のページに分けるつもりでした。

• 全体数値確認用

  ・サマリー

  ・GA4詳細

  ・GSC詳細

• 改善分析用

  ・改善前後確認

  ・ページ・検索クエリ別

ところが考えを進めると、この分け方には問題がありました。

• ページ移動が増える

• 分析の途中で画面が切れる

• 集計期間などの条件を、ページ間でどう共有するかも考えないといけない

そこで、「情報が多いから分けているのではなく、16:9に収めたいから分けているだけでは？」と気づいたのです。

「情報量が多くなる場合は、ページを分割したり、ナビゲーションを設計（p.20）」する、とガイドブックには書かれています。なので、ページを分けることも選択肢のひとつですが、私の分ける理由が「情報量」ではなく「画面サイズ」になっていました。

最終的に、それぞれの画面をどちらも1ページにし、同じ目的・同じ判断の流れにある情報は縦スクロールで続けて見る形に決めました。1画面に収まる見やすさよりも、実際にダッシュボードを使うときの使いやすさと、設計のしやすさを優先しました。

「何のために置くか」を考えた

次に、それぞれの情報について、次のことを説明できるか考えました。

• なぜここに置くのか

• なぜこの大きさなのか

• なぜ表なのか、なぜ折れ線なのか

• なぜ同じような指標を別の場所にも置くのか

どの問いも、「その画面で利用者が何をするのか」から答えを決めるようにしました。

具体例：数値カードと、GA4主要数値の表

全体数値確認用の画面には、「数値カード」と、「GA4主要数値の表」の両方にPV数やセッション数を置いています。同じ指標が2か所に出てくるので、重複して見えるかもしれません。ただ、2つの役割は違います。

• 数値カード：サイト全体の数値が目標値や前期間と比べてどうなっているかを確認し、詳しく見る必要があるかを判断する役割

• GA4主要数値の表：チャネル別・ページ別・セッションの参照元別に切り替えて、変化がどこで起きているのかを探す役割

カードで「何か起きている」と気づき、表で「どこで起きているか」を探す、という順番でつながっているので、両方置きました。

こうして、要件定義で考えた「何を知り、何を判断するか」を、配置のレベルまで落とし込みました。

3. レイアウトを「分析する順番」として考えた

改善分析用の画面は、「全体を見る → 候補を探す → 記事を選ぶ → その記事を詳しく見る」という使う順番に合わせて、上から下へ配置しました。

操作は、中部の「ページ別GSC主要指標」の表で記事をクリックすると、その右側の「検索クエリ別GSC主要指標」の表と、下部の主要指標・時系列推移がその記事に絞り込まれる想定です。

ダッシュボード設計の原則のひとつとして「構造を伝える」があります。そこには「最初に全体を示す情報を得られ、次にその詳細に辿り着けるように、レイアウトや導線を設計（p.22）」する、と書かれています。

今回の画面では、この「全体から部分へ」の順番が、そのまま改善分析の手順にできました。レイアウトは「どこに何を置くか」だけでなく、「最初に何を見て、次に何を選び、選んだあと何を見るか」という分析の導線でもあります。

4. 「操作できる」だけでは足りなかった

2画面とも仮レイアウトができたので、普段サイト数値を一緒に確認している方に、レビュアーとして見てもらいました。

ワイヤーフレームでは伝わらなかった

改善分析用には「イメージが湧いた」と返ってきた一方で、全体数値確認用には次のようなコメントをもらいました。

実際にグラフのビジュアルを見るまでイメージが湧かないかもです

そこで、Looker Studioで数値カードやグラフ、表を簡易的に作り、レビューする人がイメージしやすいモックアップを作りました。

作ってみると、表の列構成や前期間比較の見え方、操作したあとに何が変わるのかまでは伝わりにくいと分かりました。プロトタイプは作り込みが少なければいいというものでもなく、今回の場合は、レビューする人が判断できる具体度まで作る必要がありました。

説明しようとして自分で不足に気づいた

モックアップを見たレビュアーからは、次の質問が届きました。

目的のうち「目標との差や数値変動を確認し」こちらはイメージできました！

「必要に応じて原因候補を掘り下げ、相談・報告・改善判断につなげる」こちらはどういう風にこの画面をつかうイメージでしょうか？

私が想定していた使い方は、次の手順です。（GSC主要数値の表も、似たイメージでした。）

1. GA4主要数値の表の右側にある「ディメンション」の小さな枠で、表の中身をチャネル別・ページ別・セッションの参照元別に切り替える

2. 切り替えながら数値を見て、異常値や急増・急減しているところを探す

3. 見つけたところから原因候補を掘り下げ、相談・報告・改善判断につなげる（原因の特定まではこの画面では行わず、必要ならGA4の探索レポートで調べる）

ところが、その回答を打っている途中で気づきました。モックアップで、画面上部の数値カードには前期間との差を表示していたのに、その下に続くGA4・GSCの主要数値の表には現在値しか入れていなかったのです。上の手順で原因候補を掘り下げるのは、まさにこの表です。比べる数値がなければ、原因候補を探すことができません。

前期間との比較が必要だという意識自体は、ありました。ただ、「載せる情報を整理する」で作った一覧表で前期間との差を明記していたのは「現在値」の行だけで、表で見るチャネル別やページ別の行には、何と比べるのかを書いていませんでした。これが、モックアップの表に比較の列が入らなかった一因だと思います。そして「この表をこう使う」と説明しようとするまで、そのことに気づけていませんでした。

すぐにGA4・GSCの表に現在値と並べて前期間との差を表示する形に修正し、修正版のモックアップで改めて確認をお願いしました。

ガイドブックのダッシュボード設計の原則にも、「比較対象を提供する（p.22）」があります。数値だけでは判断が難しい場合には、目標値や前年の値など、比較できる対象を併記する考え方が示されています。

レビューは、完成したものを相手に評価してもらうだけの工程ではないと感じました。「この画面をこう使います」と説明しようとしたことで、「そもそも、この情報だけで本当にその判断ができるのか？」という穴に、気づけたからです。

一番大きかった指摘：何のための操作か

修正版を見たレビュアーからは、次の返信がありました。

正確に言うと「どこをどう操作すると言っているのかはイメージできるが、何のためにその操作をしてどういうoutcomeを得るのかはイメージできない」という感じです

私はここでの「outcome」を、その操作によって何が分かり、その後の判断や行動にどうつながるのか、という意味で受け取りました。

指摘されてみると、私が説明できていたのは「チャネル別・ページ別・セッションの参照元別に切り替えられる」という操作方法まででした。なぜその操作をするのか、切り替えた結果何が分かるのかが、伝わっていなかったのです。

そこで、各ディメンションと各指標を何のために見るのかを言葉にし直し、次のように返信しました。

このやり取りから、操作の説明を次の4段で考えるようになりました。

操作 → 何が分かる → 何を疑える → 次に何をする

チャネル別の例で書くと、こうなります。

1. チャネル別に切り替える

2. どこからの流入が変化しているかが分かる

3. 数値変動の原因候補にあたりをつける

4. 必要なら、GA4の探索レポートなどで詳しく調べる

「この操作ができます」だけでは、使い方を説明しただけでした。「その操作で何を知り、そのあとどう動くのか」までつなげて、ようやく利用者がどう活用するかがイメージできるのだと思います。

レビュアーからは「しっかり考えられているので良いと思いました。」と返ってきました。このやり取りを経て、プロトタイプのレビューを終え、実装に進める状態になりました。「何のためにその操作をして、どういうoutcomeを得るのか」と言ってもらえたことで、自分の頭の中をもう一度整理できたと感じています。

まとめ

要件定義では、5W1Hを言葉として固めました。プロトタイピングでは、そのHowを実際の情報・配置・表示・操作に置き換えて、本当にWhat, so Whatまでたどり着けるのかを確かめました。

プロトタイプは見た目の下書きではなく、要件定義した内容で本当に判断・行動できるのかを確かめるものでした。これが今回いちばん大きな学びです。

次回は、このプロトタイプをもとにLooker Studioで実際の画面を作った話を書く予定です。

自分のプロトタイプで確かめられること

仮レイアウトを作ったら、それを見ながら次の問いに答えられるか確かめてみてください。

• この情報を見て、何を判断するのか説明できるか

• 1つの分析を進める途中で、ページ移動が必要になっていないか

• この情報をここに置く理由を説明できるか

• 画面を見る順番と、実際の分析の手順がつながっているか

• 操作した結果、何が分かり、次に何をするのか説明できるか

• 急増・急減や異常を探す場所に、比べる数値が表示されているか

著者

名前：minoRi

Tableau Certified Data Analyst（2025年4月取得）。非エンジニアですが、独学でTableauやLooker Studioに触れながら、ダッシュボード作りに関わってきました。このブログでは、そうした試行錯誤の中で気づいたことを、同じように非エンジニアの立場でデータと向き合う人に向けて発信しています。