はじめに — ダッシュボードはいつのまにか「眺めるだけの場所」になる
私たちは、342世帯の自治会の業務をスマートフォンで完結できるWebアプリに置き換える開発をしています。回覧板や安否確認をアプリで確認できるようにするものです。そのアプリには、自治会の役員が世帯名簿の状況を確認するための管理画面があり、その中に「集計タブ」という画面があります。地区ごとの登録率などの数字が並ぶ、いわゆるダッシュボードです。
この記事は、その集計タブを「数字を眺めるだけの画面」から「次の行動を始める起点」へ作り変えたときの、判断の記録です。きっかけは現場で感じた何気ない要望でしたが、最終的にはダッシュボードという画面の役割そのものを定義し直すことになりました。
ダッシュボードを作っていると、いつのまにか「数字を見せる場所」で手が止まってしまうことがあります。グラフを置き、パーセントを並べ、色をつける。見栄えは整います。でも、その数字を見た人が次に何をするのかは、画面の外に放り出されたままです。「で、これを見たあと、私は何をすればいいの」という問いに、ダッシュボード自身が答えていない。今回向き合ったのは、まさにそこでした。同じ違和感を、自分が作った管理画面に対して抱いたことのある方には、判断の流れごと参考にしてもらえると思います。
要望は「一覧で見たい」から始まった
このアプリの開発には、少し変わった事情があります。私はこのアプリの開発者であると同時に、この自治会の役員でもあります。つまり、自分が作った管理画面を、自分が現場で使う立場にあります。
その現場の使用感から、ある要望が立ち上がってきました。要約すると「管理画面で、アプリを登録している世帯と、まだ登録していない世帯の一覧が見られると便利そう」というものです。
最初は単純な要望に見えました。一覧表示を1つ足せばいい。けれど、たとえ自分で思いついた要望でも、額面どおりに受け取って実装すると、本当に必要なものを外します。なぜ一覧が欲しいのか、その一覧で何をしたいのかを、何度か自分に問い直してほぐしていきました。
問い直すうちに、手がかりになる言葉が出てきました。「一覧で見れないと、いちいち世帯名簿で1件ずつ確認することになる」。そして、要望の核心はここに行き着きます。開発日記には、このときの要望がこう残っています。
誰が登録できていないのかをすぐに確認できるといいなと思っての提案でした。
つまり欲しかったのは「一覧」という機能ではなく、「未登録の世帯をすぐ把握して、その人たちに声をかける」という行動でした。一覧は、そのための手段にすぎません。ここを取り違えて「一覧表示機能」だけを作っていたら、おそらく「便利だけど、結局あまり使わない画面」が1つ増えていたと思います。
背景には、その少し前の理事会での出来事がありました。登録がまだ済んでいない数世帯について、本人たちは「登録したい」という意思は持っている、ということが分かっていたのです。意欲はあるのに完了していない。放っておけば、その人たちは静かに離脱していきます。役員として現場で感じた「すぐ確認したい」は、この「意欲はあるのに進んでいない人」を取りこぼさないための要望でした。
これで、解くべき問題が明確になりました。「未登録の世帯一覧を表示する」ではなく、「声をかけるべき相手を最短の手順で特定し、実際に動けるようにする」。要望の言葉をそのまま実装に渡すのではなく、その奥にある行動まで降りてから設計に入る。たとえ自分で出した要望でも、いったん分解する。今回の判断は、ここから全部が変わりました。
三つの置き場所を並べた
要望の核心が「行動」だと分かったうえで、ではその一覧をどこに置くか。三つの案を並べました。
A案は、既存の世帯名簿タブに絞り込み機能を足すやり方です。名簿タブにはもともと「アプリを使っているかどうか」を世帯ごとに示す表示モードがありました。ただしこれは全世帯にしるしを出すだけで、未登録だけを抜き出す機能がありません。50世帯あれば50件すべてをスクロールし、しるしを目で見て選り分けることになります。そこに「未登録だけ表示」の絞り込みを足すのがA案です。データの編集はもともと名簿タブの役目なので、置き場所としては自然に見えました。
B案は、集計タブの中に未登録世帯のリストを直接埋め込むやり方です。集計タブは登録率などの数字を見る画面なので、そこに「未登録世帯はこの方々です」というリストをそのまま続けて出す。
三つ目は、未登録世帯のための専用ページを新しく作る案です。一覧の見せ方を制約なく作り込めますが、その代わり、役員が覚えて行き来する画面が1つ増えます。たまにしか管理画面を触らない役員にとって、画面の数が増えること自体が「どこを見ればいいか」を分かりにくくします。
最初に思いついた一案は、A案寄りでした。集計の数字をタップしたら名簿タブの絞り込み済みの状態に飛ぶ、という導線です。集計と名簿、それぞれの役割を保ったまま橋を架ける考え方で、きれいに見えました。役割が混ざらないので、設計としても素直です。
きれいに見えたのですが、要望の核心を「行動」と定義し直したあとで見ると、A案にも専用ページ案にも共通の弱点がありました。画面の移動が一回挟まることです。集計を見て、別の画面へ移り、そこで一覧にたどり着く。設計図の上では一本の線でも、使う人にとっては「移動」という体験が確かに発生します。
選択肢を三つ並べたうえで、判断の決め手をどこに置くかが次の問題でした。実装の重さでも、コードの綺麗さでもなく、「使う人が頭の中で踏む手順の短さ」を決め手に据えることにしました。
役員が頭の中で踏む手順を書き出す
どの案が良いかを決めるために、役員が実際に頭の中で踏む手順を書き出してみました。開発日記には、A案だとこうなる、と残しています。
集計画面を開く → 数字を見る → 誰が未登録か知りたい → 名簿タブに移動して絞り込み（ここで遷移コストが入る）→ やっと一覧が見える
文字にすると当たり前に見えますが、「名簿タブに移動して絞り込み」のところに、見落としやすい負担が隠れています。とくに、この管理画面を実際に操作するのが誰かを思い浮かべると、その負担は無視できませんでした。
このアプリの管理画面を使うのは、自治会の理事です。住民が順番に引き受ける役で、その多くは60代から80代の方々です。ITに詳しいから理事になったわけではありません。こうした方にとって、画面を移動すること自体が、はっきりとした負担になります。「戻る」を押したときにどこへ戻るのか分からなくなる、さっきどのタブを開いていたのか思い出せない。一覧にたどり着くまでに、操作の不安が何度も挟まります。移動はゼロ秒では終わらず、迷いと確認の時間がそのつど積み上がります。
B案なら、その手順はこう縮みます。集計画面を開く、数字を見る、すぐ下に未登録の一覧が見える、気になる世帯をその場で開ける。画面の移動がゼロになります。
ここで、B案を実装で支えられるかを、実装を担うClaude Codeと確認しました。
ZeronovaZeronova「集計タブ＝行動の起点」という再定義
B案を選びました。理由は、要望の核心である「すぐ確認して動く」を最優先するなら、画面の移動を挟む案はすべて失格になるからです。判断の決め手を「使う人が踏む手順の短さ」に据えると、答えは自然に一つに絞られました。
ただ、B案を選ぶというのは、単に一覧の置き場所を決めたという話ではありませんでした。集計タブと名簿タブ、二つの画面の役割を定義し直すことでもありました。
それまで集計タブは「数字を眺める場所」、名簿タブは「世帯を登録・編集・削除する場所」でした。B案を入れると、集計タブに「数字 → 対象者 → その場で動ける」という流れが生まれます。そこで、役割をこう引き直しました。名簿タブは編集の場、集計タブは俯瞰と行動の起点。前者は1件ずつ世帯と向き合う場所、後者は全体を見渡して「次に誰に動くか」を決める場所です。
この線を引いたことで、二つの画面は「機能が重複している」のではなく「役割を分担している」状態になりました。同じ未登録世帯の情報が両方の画面に出てきても、それは重複ではありません。名簿タブでは1件の編集対象として、集計タブでは行動のきっかけとして、別の文脈で立ち現れます。重複に見えて重複ではない、という整理ができたのは、置き場所ではなく役割から考えたからでした。
開発日記に、この再定義を一般的な言葉でこう書き残しています。
ダッシュボードは「数字を見せる」だけでは不十分。「数字 → 該当する具体的な対象 → アクション可能なツール」までを1画面で繋ぐと、意思決定速度が桁違いに上がる。
「数字を見せる」で止まっているダッシュボードは、見た人に「で、次は」という宿題を渡しています。その宿題を画面の側が引き受けて、「次はこの方々です。ここから動けます」まで用意する。それが「行動の起点」という再定義の中身です。
あわせて、地区ごとの登録率を示すバーの色も見直しました。それまで全部同じ色だったバーを、登録率に応じた三段階の色に変えています。これは見た目の小さな変更に見えますが、「どの地区から手をつけるか」という判断を、説明文を読まなくても直感で下せるようにする変更でした。色の意味の使い方そのものは別の話になるのでここでは深追いしませんが、これも「俯瞰した結果から、すぐ次の行動へ」という同じ狙いの一部です。数字を見せるだけだったバーが、「次はここ」という指差しに変わった、と言ってもいいかもしれません。
データを見る人と動く人が同じなら
ここまでは自治会向けアプリの集計タブの話でしたが、この再定義は、もっと広い場面に置き換えられます。
鍵になるのは「データを見る人と、それを受けて動く人が、同じかどうか」です。
大きな組織では、この二人はたいてい別人です。分析する担当がいて、数字をレポートにまとめ、それを受け取った別の担当が動く。だからその種の組織向けのダッシュボードは、深く掘り下げて分析できることに価値を置いて発展してきました。見る人は「分析するために」見ているのであって、見たその場で動くわけではないからです。深い分析機能は、見る人と動く人が分かれているからこそ意味を持ちます。
ところが、小さな組織では事情が違います。自治会の役員も、個人開発のチームも、小さなお店の店主も、数字を見る人がそのまま動く人です。レポートを誰かに渡すわけではありません。見て、決めて、自分が動く。
たとえば、個人開発者が自分のサービスの不具合の件数を見る画面を思い浮かべてください。件数が増えたと気づいても、そこから「どの不具合か」「どの記録を見るか」「どこを直すか」へ進むのに別の画面を何度も開く作りなら、その画面は数字を見せた時点で仕事を終えています。逆に、件数の行をそのままたどれば原因の記録に届くなら、気づいた瞬間に手が動き始めます。同じ数字を出していても、次の一歩がつながっているかどうかで、画面の働きはまったく変わります。
この「見る人＝動く人」の状況では、ダッシュボードに求められるものが変わります。深い分析機能よりも、「見たその場から、次の行動へ最短でつながること」のほうが効きます。数字とアクションの間に画面の移動が一回挟まるだけで、その移動コストが行動そのものを止めてしまうからです。分析の深さで勝負する設計を、そのまま小さな組織に持ち込むと、いちばん必要な「すぐ動ける」が痩せます。
しかも、止まりやすいのは頻度の低い行動です。毎日やる作業なら、多少手順が長くても体が覚えます。けれど「未登録の人に声をかける」のような、たまにしか発生しない行動は、手順が一つ増えるだけで「また今度でいいか」に流れます。頻度が低い行動ほど、起点を1画面に集約する価値が高い、ということです。今回の未登録世帯への声がけも、まさに「たまにしか起きないが、放置すると人を取りこぼす」種類の行動でした。
だから、もしあなたが小さな組織やチームのための管理画面を作っているなら、ダッシュボードを設計するときに一度立ち止まる価値があります。問いは三つです。「この数字を見た人は、次に何をするのか」。「その次の行動は、この画面の中から始められるか、それとも別の画面へ移動させているか」。そして「移動させているなら、その移動は本当に必要か、それとも数字のすぐ下に行動の入口を置けないか」。
「数字を見せる」で完成だと思っていた画面が、実は半分しか仕事をしていなかった、ということは珍しくありません。残りの半分は、見た人を次の一歩へ送り出すことです。
むすび
最初の要望は「一覧が見られると便利そう」という、ごく小さなものでした。それを額面どおり受け取って一覧表示を足していたら、機能は1つ増えても、現場で本当に必要だった「すぐ確認して動きたい」には届かなかったと思います。
自分で出した要望の言葉ではなく、その奥にある行動を見にいったこと。そして、一覧の置き場所を決める作業を、ダッシュボードという画面の役割を定義し直す作業として捉え直したこと。この二つが、今回いちばん大事な判断でした。三つの案を並べたときも、決め手にしたのは実装の都合ではなく、使う人が踏む手順の短さでした。
ダッシュボードは「数字を見る場所」だと、つい思い込みます。でも、見る人がそのまま動く人なら、その画面は「行動の起点」まで担えます。数字の隣に、次の一歩の入口を置く。それだけで、画面の価値はずいぶん変わります。
関連記事
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。