「1人での登録完了は不可能だった」
この一文が、開発者としての思い込みを崩した。
シニア向けのUIにはこだわってきたつもりだった。大きなタップターゲット、シンプルな導線、明快なフォントサイズ。「高齢者に優しいUI」として意識してきた要素は、確かに盛り込んでいた。それでも現実は違った。
自分が「大丈夫だろう」と思っていた画面が、72歳のユーザーにとっては「何をすればいいのかわからない画面」になっていた。テスト後に感じたのは、恥ずかしさと、それ以上の学びへの驚きだった。
自治会DXと「シニアファースト」という難題
「自治会DX」は、紙の回覧板とアナログ運営に依存している自治会業務をデジタル化するWebアプリだ。ベテランSEの共同開発者と2人で開発を進めている。主なユーザーは60代以上の自治会理事と一般住民で、機能は回覧板・届出・不審者通報・安否確認の4つに絞った。
このプロダクトで最も難しいのは、ターゲットユーザーの定義だ。
「シニア向け」という言葉は広い。60代のスマートフォンに慣れた人もいれば、70代でらくらくフォンを使いLINEだけをかろうじて使っている人もいる。自治会の住民は後者に近い層が含まれることが多い。「スマートフォンでLINEはできるけど、アプリをインストールしたことがない」「YouTubeのログインは家族が代行している」という人たちだ。
開発の原則として「シニアファースト設計」を掲げてきた。
- タップターゲットを48px以上に設定する
- エラーメッセージをやわらかい文言にする（赤い警告ではなく、黄色みがかった穏やかな表現）
- 専門用語を使わない
- ステップ数は最小限にする
これらの原則を意識して実装してきた。しかし原則を意識することと、原則が実際のユーザーに機能することは、別の話だった。
3月19日のデモ会: 「自分たちのサービス」という感覚
ユーザーテストの前日となる3月19日夜、次年度継続理事6名を対象にデモ会を実施した。
全員がLINEログイン→世帯登録→アプリ利用まで完了した。iPhoneユーザーでも、事前に懸念していたLINE認証のCookie分離問題は発生せず、スムーズに動作した。
開発日記にはこう記している。
特に評判が良かった点:
- 機能面の充実度
- シニア向けに意識した使いやすいUI/UX
さらに予想外の収穫があった。
理事たちから、「見守り機能への関心」「空き家問題への対応」といったテーマが自発的に出てきたのだ。これは単なる「便利ツールの導入」ではなく、「自分たちのサービスを一緒に作っている」という感覚が醸成され始めたサインだった。ユーザーが自分事として関わり始めると、こういう会話が生まれる。
次は全理事20名へのデモ会だ。6名のデモが成功した。勢いがある。
その高揚感の中で、翌日のユーザーテストを迎えた。
ユーザーテスト#001: 72歳のらくらくフォンユーザー
友人の祖母が72歳で、らくらくフォンを使っているということを知り、テストに協力していただけないかお願いした。
らくらくフォンはシニア向けに設計された端末で、画面が大きく、システムフォントが標準より大きく設定されていることが多い。指で操作するタッチ感度も、一般的なスマートフォンとは異なる設定になっている。まさに想定ターゲットユーザーの端末だ。
テストは本番環境で、家族が隣で見守る形で実施した。アプリの改善をしている最中であることを説明し、「一人で使ってみてください」という状況を作った。
結果は一行で表せる。
1人での登録完了は不可能だった — 家族のサポートがあって初めて完了
6名の理事デモで感じた「これでいける」という感触が、この一行で覆った。
ここで強調しておきたいのは、テストを実施したのが「オンボーディングUX改善適用前」の状態だったということだ。デモ会の成功を受けて、ログイン画面・登録フロー・配布チラシの全面改善を設計・検討していた。しかしその改善はまだ「計画段階」だった。つまり、「これまでの設計」に対してテストした結果が、「不可能だった」という答えだった。
何が問題だったのか。テストで特定されたP0課題は3件あった。
P0課題①: 「ログイン」という言葉がわからない
最初の躓きは、ログインボタンの文言だった。
ログイン画面には「LINEでログイン」というボタンを配置していた。LINEアカウントを使ってOAuth認証するという、現代のWebサービスでは標準的な仕組みだ。開発者にとっては当然のものに見える。
しかし72歳のユーザーにとって、「ログイン」は存在しない概念だった。
開発日記の記録が印象に残っている。
「ログイン」はシニアの語彙にない（YouTubeのログインも家族が代行している）
YouTubeのログインも家族が代行している。この一言が全てを物語っている。LINEは使えている。しかし「LINEを使って何かにログインする」という行為は、経験として存在しない。だから「LINEでログイン」というボタンを見ても、何をするボタンなのかが理解できない。
さらに問題は複合していた。
「ログイン」が分からないだけでなく、「LINEの何かが起動する」という予測もできない。ボタンを押したら何が起こるのか、わからない状態でボタンを押せるだろうか。
「壊れたらどうしよう」「何か変なことになったら困る」という感情が、操作の前に立ちはだかる。
修正の方針は明確だった。ボタンのラベルを「登録をはじめる」に変更する。LINEの名前はボタンから外し、「LINEの画面が開きます」と補足説明として案内する。技術的な正確さより、ユーザーが取るべき行動を示す言葉を選ぶ。
ボタン文言の変更は、一見些細な修正だ。しかし実態は、「ターゲットユーザーの語彙にない言葉でボタンにラベルをつけていた」という設計の根本的な誤りを修正することだった。
P0課題②: チェックボックスに気づかない
利用規約への同意画面にも問題があった。
20×20pxのチェックボックス。「チェックを入れて同意してください」というよくあるUIパターン。開発者にとっては見慣れたものだ。しかしテストで、72歳のユーザーはこの小さな正方形に気づかず、その後も「タップして状態を変えるUIパーツ」として認識することができなかった。
Webフォームのチェックボックスは、ITリテラシーが前提のUIだ。「四角い枠をタップすると中にチェックマークが入り、同意が完了する」という操作パターンは、フォームへの入力経験がなければ直感的に発見できない。
改善案を3つ検討した。
- 案A: カード全体をタップ領域にする大型トグルカード方式。タップ時に背景が緑色に変わりチェックアイコンが表示される
- 案B: 同意ステップを独立したページとして分離し、「同意する」ボタン一つで操作させる
- 案C: チェックボックスのサイズを大きくする（例: 48×48px）
ZeronovaZeronova案Aを採用した。カード全体（最低タップ領域48px以上）をタップエリアとし、チェック時は緑背景とチェックアイコンで状態変化を明確に示す。未チェック時には「上の枠をタップして同意してください」というガイドテキストも表示する。合言葉フローと招待コードフローの両方に適用した。
P0課題③: 合言葉のコピー&ペーストが困難
3つ目の課題は、登録フローの中核にあった。
このアプリでは、住民が登録するために「合言葉」と呼ばれる認証フレーズが必要だ。管理者（自治会理事）がチラシに印刷して住民に配布する。住民はチラシを見ながら合言葉を入力し、世帯番号を確認して登録を完了する。
問題は「チラシを見ながら入力する」という操作にあった。
QRコードを読み取ってLINE認証を経由し、合言葉入力画面に到達するまでに、複数回のページ遷移が発生する。LINEアプリ内ブラウザでは、テキストのコピー&ペーストが困難なケースがある。シニアユーザーにとって、紙のチラシを見ながらスマートフォンに文字を手入力することは、それだけで相当なハードルだ。
解決策は「QRコードのURLに合言葉を埋め込む」方式だった。
チラシに印刷するQRコードのURLに ?passphrase=〇〇〇 パラメータを追加する。住民がQRコードを読み取るだけで、LINE認証後の合言葉入力画面に自動入力される。手入力が不要になる。
実装は想定より複雑だった。LINE OAuth認証はページ遷移を伴うため、URLパラメータはそのまま保持されない。認証前にsessionStorageへ退避させる設計にした。
しかしここで競合バグが発生した。開発日記にはこう記録されている。
競合バグを発見・修正: 同一レンダーサイクルでリダイレクトeffectがsessionStorageに保存→自動入力effectが即座にremoveItemする問題
「URLから読み取ってsessionStorageに保存するeffect」と「sessionStorageから読み取って入力フィールドに適用しremoveItemするeffect」が、同一のレンダーサイクルで実行される。保存された値が即座に削除されてしまう。
解決策は「URLから読み取った場合はremoveItemしない」という分岐を追加することだった。sessionStorageへの書き込みと読み取りの競合は、Reactのuseeffect実行タイミングの理解が求められる種類の問題で、ローカル環境の単体テストでは再現しにくい。本番のOAuthフロー全体を通して初めて発覚するケースだ。
P0課題3件を即日対応した判断
P0課題3件を、テスト実施当日中に実装完了させた。
「見つかった課題はバックログに積んで優先度をつけ、次のスプリントで対応する」というのが一般的な開発フローかもしれない。しかし今回は選択の余地がなかった。
20名デモ会まで時間がない。そして、「1人では登録できない」という事実が3件残っていれば、20名規模のデモで複数人が詰まる場所になる。シニア層の場合、一度「壊してしまったかもしれない」と感じると、その後の試みをためらう傾向がある。
特にこの3件は、それぞれが「1人での登録完了を不可能にする直接原因」だった。
- 「ログイン」の意味がわからない → 最初のボタンを押せない
- チェックボックスに気づかない → 同意ステップを突破できない
- 合言葉が手入力できない → 認証を完了できない
いずれか一つでも残っていれば、それだけでユーザーが登録を完了できない。全て同日中に解消する以外の選択肢はなかった。
P1課題への展開
P0課題を即日対応した後、P1課題（重要だが即日対応は不要な課題）も実装した。
カレンダーモーダルの閉じ方
ゴミ出しカレンダーを開いた後、「閉じ方がわからない」という問題があった。「背景タップでモーダルを閉じる」という操作は、シニアユーザーにとって発見不可能に近い。下部にあった「閉じる」ボタンも、スクロールしなければ見えない状態だった。
解決策はモーダルをボトムシート形式に変更することだった。画面下部からせり上がるデザインにし、上部に大きな閉じるボタン（48px）を設置する。ドラッグハンドルバーを追加し「下にスワイプで閉じる」という操作のヒントを提供した。iPhoneの標準UIパターンに近い形にすることで、LINEなどのアプリで見たことがある操作になる。
らくらくフォン対応: clamp()の単位の罠
らくらくフォンのシステムフォントサイズ拡大に対応するため、CSSの clamp() でフォントサイズに上限を設定した。
しかし最初の実装には問題があった。
/* ❌ 全てrem: システムフォント拡大時に上限が効かない */
font-size: clamp(1.5rem, 1.875rem, 2.25rem);
/* ✅ max値をpx: システムフォント拡大でも上限が固定される */
font-size: clamp(1.5rem, 1.875rem, 36px);
clamp() の3値すべてをrem（ルートフォントサイズ比）で書くと、システムフォントサイズが拡大された場合に全ての値が比例拡大される。相対関係が変わらないため、上限制限が実質的に機能しない。max値をpx（絶対単位）にすることで、システムフォントをどれだけ拡大しても指定したpx値を超えない制限が働く。
これはセルフレビューの段階で、「ターゲットユーザーのらくらくフォン環境」を想像して初めて気づいた問題だった。通常の環境でテストしている限り、まず発見できない。
P1実装の後にセルフレビューを実施し、この clamp() の単位問題を含む5件のバグを発見、全て同日中に修正した。
このテストから得た3つの学び
「ログイン」はシニアの語彙にない
開発者が自明だと思っている言葉が、ターゲットユーザーには存在しない概念かもしれない。「ログイン」「アカウント」「認証」はITリテラシーを前提とした用語だ。
ボタンのラベルは技術的に正確である必要はなく、ユーザーが取るべき行動を示す言葉であるべきだ。「LINEでログイン」ではなく「登録をはじめる」。LINEは補足説明として「手段」を伝えるための情報にとどめる。
この原則は、「ダッシュボード」「設定」「プロフィール」といった慣用的なUI用語にも当てはまる。シニア向けアプリで使う言葉は、一つひとつ「この言葉はシニアの経験に存在するか」を確認すべきだ。
チェックボックスはシニアの経験にないUIパターン
「四角い枠をタップして状態を変える」という操作パターンは、Webフォームへの入力経験がなければ直感的に理解されない。
重要なのは、「気づきやすさ」「タップしやすさ」「状態変化の明確さ」の3条件が揃って初めて機能するUIになるということだ。サイズを大きくするだけでは「気づきやすさ」が上がっても「タップして状態を変えるパーツだ」という認識には至らない可能性がある。状態変化を色と形の変化で明確に伝えることが、「正しく操作できた」という確認につながる。
「感情設計」とは操作の「前」の設計だ
UIデザインでよく議論されるのは、「操作のしやすさ」だ。しかし今回のテストから学んだのは、「操作の前の感情」を設計することの重要性だった。
「LINEでログイン」というボタンは、「何が起こるかわからない」という不安を生んでいた。「本人確認」という文言は「公的な手続きが必要なのかもしれない」という緊張感を与えていた。操作のしやすさを改善するより前に、操作を始める前の心理的ハードルを下げる必要があった。
「間違えても何度でもやり直せます」というメッセージを操作の「前」に配置すること。「LINEの中身は見られません」という安心の言葉をログイン画面に置くこと。これらは機能の改善ではなく、感情の設計だ。
次は20名デモへ
ユーザーテスト#001でP0課題3件を特定し、全て即日修正した。P1課題も実装し、セルフレビューで追加のバグを5件発見・修正した。
デモ会の成功体験と、ユーザーテストの厳しい現実。この両方があって初めて、「20名デモに向けて本当に準備できた状態」と言えるようになった。
シニア向けアプリの開発において、「想定ユーザーに実際に使ってもらう」ことは、設計レビューやコードレビューで代替できない検証だ。「大丈夫だろう」と思っていた設計が「不可能だった」という事実を突きつけられた経験は、それ以降の判断基準を変える。
理事6名のデモ成功が「自分たちのサービスを一緒に作っている」空気を生んだのと同じように、1件のユーザーテストが「開発者として正しいものを作れている」という自信の根拠を変えた。
準備の量より、準備の質が問われる段階になってきた。
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。