はじめに
自治会DXプロジェクトで管理画面を設計する中で、ある日、画面上部のヘッダーと、その直下のページ見出しを並べて見ていた。
ヘッダーには「管理画面」と書いてある。その下のh1には「ダッシュボード」と書いてある。
同じ画面を指しているのに、2つの異なる名前が並んでいた。ITリテラシーの高いユーザーなら「同じことだな」と理解できる。しかし、ターゲットユーザーは60〜80代のシニア層だ。「管理画面」と「ダッシュボード」が同じ場所を指すと、直感的に分かるだろうか。
この気づきから、管理画面全体のカタカナ語を洗い出して全廃する作業を始めた。
問題の発見 — 表記揺れの構造的な原因
「ダッシュボード」という言葉は、Web開発の世界では自然に使われる。管理画面のトップページといえば「ダッシュボード」という慣習が、開発者の間で定着している。
Claude Codeとのやりとりでも、最初から管理画面のトップページを「ダッシュボード」と呼んでいた。コンポーネント名、APIのパス設計、コメント。随所に「dashboard」という単語が入り込んでいた。
しかし、ターゲットユーザーを改めて考えると、この言葉は的外れだ。
ターゲットユーザーが60〜80代のシニア層。「ダッシュボード」は英語由来のカタカナ語で、この年齢層にとって馴染みが薄い。さらに「管理画面」と「ダッシュボード」が同じ画面を指す表記揺れは、ITリテラシーの低いユーザーにとって混乱の原因になる。
— jichikai-dx 開発日記 2026-04-02
問題は「ダッシュボード」1語だけではなかった。管理画面全体を見渡すと、他にも開発者が自然に使いがちなカタカナ語が散在していた。
カタカナ語の洗い出しと変換
管理画面全体を読み直して、カタカナ語を一つひとつ確認した。判断の基準は「60代の人がはじめてこの画面を見たとき、意味が分かるか」だ。
変換した主なカタカナ語
| 変換前 | 変換後 | 変換の理由 |
|---|---|---|
| ダッシュボード（h1） | 削除 | ヘッダー「管理画面」があれば冗長 |
| サイトへ戻る | ホームに戻る | 「サイト」というWeb概念が通じない |
| 安否確認（ボタン） | 安否状況 | 「確認」より「状況」が実態に即している |
「サイトへ戻る」は特に印象的な変換だった。
管理者ページのヘッダーに「サイトへ戻る」というリンクがあった。これは住民向けのトップ画面に移動するためのリンクだ。管理者として作業をしていて、住民として利用する画面に戻る。開発者の頭の中では「サイトへ戻る」で意味が通じる。しかし、「サイト」という概念をシニアは持っていない。
ヘッダーの「サイトへ戻る」→「ホームに戻る」に変更（シニアに「サイト」は通じない）
— jichikai-dx 開発日記 2026-04-02
住民向けBottomNavの1番目のタブ名「ホーム」に揃えて「ホームに戻る」にした。管理者が住民としても使う画面への導線だと、直感的に理解できる。
「ダッシュボード」のh1をどう処置するか
「ダッシュボード」というh1見出しをどう置き換えるか、3つの案を検討した。
案A: 「ホーム」に変える 住民向けの概念と混同しないか、という懸念があった。ただし、管理者にとっては管理画面のトップがホームだと理解できるはず。
案B: h1自体を削除する ヘッダーが常に「管理画面」と表示しているため、その直下にもう一度「管理画面」系の見出しを置くのは冗長だ。
案C: 「管理メニュー」にする 「管理画面」というヘッダーと「管理メニュー」というh1が並ぶのは、繰り返しになる。
結論は案Bだった。ヘッダーで役割が伝わっているなら、h1は削除して良い。余計な言葉を増やさないことが、シニア向けUIの基本原則の一つだ。
L2 — カタカナ語全廃という判断
ZeronovaZeronovaZeronovaこのやりとりの後、管理画面全体の文言を一括でレビューし、変換対象をリストアップしてから実装に入った。個別に「これはどうしますか」と聞かれながら進めるより、全体像を把握してから一気に変換する方が判断のブレが少ない。
通知の「強制感」をなくす
カタカナ語の全廃と同日に、もう一つの問題も解消した。
管理者がおしらせを投稿すると、未通知バナーが表示される。「通知を送ってください」というプレッシャーをかける設計だ。しかし、全てのおしらせがプッシュ通知に値するわけではない。内輪の連絡、テスト投稿、後日改めて通知したい内容。様々なケースで「通知しない」という選択が必要になる。
3つの案を検討した。
- 案A: バナーに「通知しない」ボタンを追加する
- 案B: 記事単位で通知可否を選択できるようにする
- 案C: 作成時に「通知する」トグルをつける
採用したのは案Aだった。最小工数で十分な効果が得られる。記事を投稿してから「やっぱり今日は通知しなくていいや」という判断は、投稿後にしかできないことが多い。後から選べる方が、管理者にとって自然なフローだ。
パンくずリンクを全階層に統一する
管理画面の構造は「管理画面トップ → カテゴリ → 下層ページ」という3階層になっている。カテゴリページから管理画面トップへの「← 管理画面」リンクは既にあった。しかし、下層ページからカテゴリへの導線が不足していた。
「戻る手段がある」と「戻る手段が見える」は別だ。BottomNavで戻れる状態でも、パンくずリンクが画面上部に見えていなければ「戻れない」と同じになる。シニアは画面上部の操作対象に集中するため、BottomNavの存在を忘れることがある。
全14ページに親カテゴリへのパンくずリンクを統一した。
- 回覧板系のページ → 「← 回覧板」
- 住民系のページ → 「← 住民・名簿」
- コンテンツ系のページ → 「← コンテンツ」
- 安全系のページ → 「← 安全・防災」
パンくずが「全ページに一貫してある」という状態になると、ユーザーは「← が常にある」と学習できる。ある画面では戻れてある画面では戻れない、という不均一が一番ユーザーを混乱させる。
メニュー項目に説明文を1行加える
管理画面のMenuItemコンポーネントに、descriptionプロパティを追加した。全16メニュー項目のラベルの下に、1行の説明文を表示するようにした。
例を挙げると、「世帯名簿」というラベルだけでは、このメニューで何ができるか分からない。「世帯の一覧・編集・追加」という説明があれば、「ここをタップして大丈夫か」という判断ができる。「巡回管理」という短い名前も、「空き家の巡回計画・チェックリスト」という説明があれば、馴染みのない機能名でも意味が伝わる。
シニアが操作を躊躇う原因の一つは、「タップすると何が起きるか分からない」という不安だ。タップして失敗しても戻れるとは分かっていても、失敗への心理的なハードルが高い。1行の説明が、そのハードルを下げる。
地区名をフリーテキストからマスタ管理に移行
同日の作業で、もう一つの構造的な問題を解消した。
世帯を追加する際の地区名が、フリーテキスト入力だった。これはデータ品質の問題を引き起こす。「第1地区」「第１地区」「第一地区」が混在すると、地区別の集計や絞り込みが正確にできなくなる。
地区は自治会の組織構造であり、滅多に変わらない。名前ごとに異なる世帯データとは性質が違う。マスタデータとして管理すべきものだった。
地区管理ページ（追加・名前変更・並び替え・削除）を新設し、世帯追加フォームの地区入力をドロップダウン選択に変更した。CSVインポート時にも、マスタにない地区名はエラーとして返し、自動作成しない。データ品質を保つには、「エラーで返して先に登録を促す」方が、「黙って自動作成する」より正しい。
フリーテキスト入力は最後の手段。マスタデータに対してフリーテキスト入力を提供すると、必ず表記ゆれが発生する。選択肢が有限な場合はドロップダウン、多い場合はオートコンプリートだが、いずれもマスタからの選択であるべき。
— jichikai-dx 開発日記 2026-04-02
学んだこと — 用語統一はUIの根幹
この日の作業を通じて、明確になったことが一つある。
用語の統一は、見た目の問題ではない。ユーザーのメンタルモデルの問題だ。
同じ画面に対して「管理画面」と「ダッシュボード」という2つの名前が使われていると、ユーザーは「この2つは別のものなのか」と疑問を持つ。特にITリテラシーが高くないユーザーには、「同じものだ」という自明性がない。
コードの世界では、「管理画面のトップはダッシュボードと呼ぶ」という慣習がある。開発チームが開発者だけで構成されている場合、この慣習に疑問を持つことは少ない。しかし、ユーザーが異なる文化・言語感覚を持つ場合、開発者の慣習がそのままUIに出てしまうと、ユーザーの混乱を生む。
シニア向けアプリの開発で、カタカナ語を使う際は毎回「この言葉を知らない人でも意味が伝わるか」を問い直す習慣が必要だと分かった。
関連記事
- シニア向け UI で避けるべきパターン — ユーザビリティの観点から整理したアンチパターン集
- 自治会DXで学んだシニア向けWebアプリ開発の設計判断 — プロジェクト全体の設計判断をまとめた開発記
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。