はじめに — 「研究を読んだ」と「研究を使える」は別問題
シニア向けのプロダクトを設計するとき、最初にやることはたいてい「調べる」です。タップ領域は何ピクセル必要か、1画面に情報をいくつ載せていいか、専門用語をどこまで言い換えるべきか。論文やデザインガイドラインを読み込めば、答えのかけらは見つかります。
問題はその先でした。自治会DXプロジェクトでは、登録フローを設計するために21本の学術研究を調査し、その結論を1本の調査レポートにまとめていました。レポート自体は完璧で、「なぜこの登録フローにしたのか」を問われたら、根拠つきで答えられる状態です。
ところが、登録フロー以外の画面を作るとき、その21本の知見をもう一度活用する手段がありませんでした。レポートは「なぜ方向性Cを選んだか」という意思決定の記録であって、新しい画面の前に立ったときに「何をチェックすればいいか」を教えてくれる道具ではなかったのです。
この記事は、その調査レポートを「開発中に即座に参照できるチェックリスト」へ翻訳した日の記録です。チェックリストそのものは社内の運用資産として管理しているため全文は載せませんが、どういう構造にすれば研究知見が形骸化せずに使われ続けるのか、その設計思想を共有します。なお本プロジェクトは元同僚のベテランSEとの共同開発で、レビューの過程で受けた指摘が判断を何度も修正しています。
調査レポートのままでは、なぜ使えなかったのか
開発日記には、この日の核心になった一文を書き残しています。
研究知見は「翻訳」しないと使えない。調査レポートは「なぜ」を記録し、チェックリストは「何をすべきか」を指示する。この2つは別のドキュメント。
ここを混同していたのが出発点の誤りでした。調査レポートは思考の記録で、読み手は「設計判断を後から検証したい人」です。一方でチェックリストの読み手は「いま画面を作っていて、抜けがないか確認したい人」です。必要としている情報の粒度も、読むタイミングも、まったく違います。
同じ知見でも、登録フローのために最適化された文章は、設定画面や届出フォームの設計者には届きません。研究を「読んだ」状態から「使える」状態にするには、用途別に作り直す翻訳作業が必要だったのです。
3層構造にした設計思想
チェックリストをClaude Codeと一緒に組み立てるとき、最初に決めたのは「フラットな40項目リストにはしない」という方針でした。理由は2つあります。
ひとつは「長すぎると読まない」。40項目を一列に並べたチェックリストは、画面を作るたびに全部読み返す気にならず、結局使われなくなります。もうひとつは「根拠がないと形骸化する」。「なぜこのルールなのか」が分からないルールは、例外に直面したときに判断できず、機械的に当てはめるだけの儀式になります。
そこで、用途を3つの層に分けました。
第1層: 設計原則 — 迷ったときに立ち返る判断軸
画面設計に迷ったとき、最初に立ち返る少数の原則です。たとえば「1画面に提示する情報のまとまりは3つまで」という原則は、加齢にともなうワーキングメモリの制約に関する研究（Bopp & Verhaeghen, 2005）が根拠です。もうひとつ挙げると「操作を求める前に不安を取り除く」。これは、シニアが操作につまずいたとき自分を責める割合が極端に高いという調査知見に基づいています。原則の数は意図的に7つに絞りました。多すぎると「立ち返る場所」として機能しないからです。
第2層: チェックリスト — レビュー時に1項目ずつ確認する
設計やレビューのときに具体的に確認する項目群です。レイアウト、タップ操作、フォーム入力、フィードバック、ナビゲーション、文言の6カテゴリに分かれています。ここで重要にしたのは「基準値を必ず添える」ことでした。たとえば「タップ領域は十分か」では判断できませんが、「タップ領域は最小48px四方を確保しているか」なら、コードを見れば誰でも判定できます。曖昧な問いはチェックリストとして機能しないという、地味だけれど効く学びでした。この第2層の全項目は社内の運用資産として管理しています。
第3層: 根拠リファレンス — なぜそのルールなのかを引ける
各原則とチェック項目が、どの研究・どのユーザーテスト知見に紐づくのかを引けるようにした層です。研究番号、核心となる数字、設計への示唆を1件ずつ対応させています。この層がある効果は大きく、例外に直面したとき「この項目はなぜ存在するのか」を3秒で引けるので、「機械的に従う」か「根拠を理解した上で例外と判断する」かを選べるようになります。根拠を切り離さずに同梱したのが、形骸化を防ぐ最大の仕掛けでした。
3層をひとことで言えば、「迷ったとき（第1層）→ 確認するとき（第2層）→ なぜか知りたいとき（第3層）」という、読み手の状況別に入口を分けた設計です。
PM-AI 対話: チェック項目の粒度をどう決めたか
チェック項目をどの粒度で書くかは、最初の難所でした。Claude Codeと相談しながら方針を固めています。
ZeronovaZeronovaこの対話で決めた「基準値はチェックリストに書くが、正となる数値の定義はコードに一本化する」という分離は、後からフォントサイズの可変対応を入れたときにも効きました。チェックリストを書き換えずに、参照先の定義だけを更新すれば済んだからです。
作って終わりではなかった — AI自動評価と人間の再評価
チェックリストは作った瞬間に主要画面6種と管理画面12種へ即座に適用しました。ここで一番の学びが出ます。
Claude Codeにチェックリストで各画面を機械的に評価させると、優先度の高い指摘から低い指摘まで一通り挙がってきます。見落とし防止としては明確に有効でした。緊急度の高い課題は、エラー色の不統一や、誤解を招く文言など、その日のうちに直しました。
問題は優先度が中〜低と判定された項目です。コードを実際に読み直して再評価したところ、判断が次々にひっくり返りました。開発日記にはこう残っています。
AIエージェントによるチェックリスト評価は「見落とし防止」に有効だが、文脈を理解した再評価が不可欠。今回P2・P3の5件中5件が再評価で判断変更になった。
5件中5件です。たとえば「画像ビューアにスワイプのヒントがない」という指摘は、チェック項目だけ見れば違反です。しかし実際のコードでは「前へ」「次へ」のボタンとページ番号が常時表示されていて、スワイプは補助的な操作にすぎませんでした。チェック項目の前提（スワイプが唯一の操作手段である）が、その画面には当てはまっていなかったのです。
ここから引き出した原則はシンプルです。チェックリストは判断の補助であって、判断そのものではない。自動評価は「抵触している箇所」を漏れなく挙げるのが得意ですが、「なぜ抵触しているか、それは本当に問題か」は文脈を理解した人間が決める。第3層の根拠リファレンスを用意しておいたのは、まさにこの再評価を3秒で始められるようにするためでした。
確認ダイアログの扱いも、再評価で判断が変わった例です。当初は「OS標準の確認ダイアログは分かりにくいので、全箇所を独自デザインのダイアログに置き換える」と計画していました。しかし再評価で優先度を下げます。OS標準のダイアログは、シニアが普段使っているメッセージアプリの確認画面と同じ見た目で、むしろ馴染みがあります。「削除しますか」「取り消しますか」のような操作内容が明確な場面では、標準ダイアログでも意味は十分に伝わる。約25箇所を独自ダイアログに置き換える工数に対して、改善効果が見合いませんでした。ただし「このスマホでの利用を中断する」のように操作の意味が複雑な場面では、結果を補足できる独自ダイアログが必要です。一律で置き換えるのではなく、操作の複雑さに応じて使い分ける、という結論に落ち着きました。
意味のある色は、機械的に統一してはいけない
自動評価の指摘を文脈で却下した例として、もうひとつ印象的だったのが色の扱いです。エラー表示の色が画面によって赤だったりばらついていたため、評価では「エラー系の赤を、より穏やかな警告色へ統一せよ」という指摘が出ました。ここまでは妥当です。
ところが評価エージェントは「画面内のすべての赤を統一せよ」と踏み込んできました。これは却下しました。安否確認の画面には、災害モーダルの枠線や「被害あり」を示すボタンに赤を使っています。この赤は単なるスタイルではなく、災害の深刻度を伝える意味を持った色です。穏やかな警告色に変えると、緊急性そのものが弱まってしまう。
最終的に、エラーメッセージの赤だけを警告色へ変更し、災害の深刻度を示す赤は意図的に残しました。「赤を統一する」というルールは、表層だけ見れば一貫していて気持ちがいいのですが、その赤が何を意味しているかを読み取れるのは、画面の文脈を理解した人間だけです。チェックリストや自動評価が「ルールの一貫性」を測れても、「そのルールがこの場所で守るべきものか」までは測れない、という線引きを具体的に体験した一件でした。
「用語を変える」と「意味を伝える」は別の問題
文言の層で象徴的だったのが「ログアウト」の扱いです。シニアに通じないからと、最初は「終了する」に変えました。ところが開発者レビューで「それは『アプリを閉じる』『退会する』と誤解される」と指摘を受けます。
ここで気づいたのは、用語を別の単語に置き換えただけでは意味は伝わらないということでした。「ログアウト」が分からない人に「終了する」と見せても、操作の結果がイメージできない点は何も変わっていません。最終的に採用したのは、単語の言い換えではなく「操作の結果を具体的に説明する」表現と、目立たせすぎない配置と、安心できる確認ダイアログを組み合わせる形でした。
通知機能の文言でも同じ構造の問題が出ました。専門的な通知用語を避けて言い換えると、今度は「掲載すること」と「相手のスマホに届くこと」が区別できなくなる。最終形は、1行目で操作を示し、括弧内で結果を補足する二段構成に落ち着きました。用語変換のチェック項目は、単語の対応表ではなく「操作の結果が伝わっているか」を問う項目として第2層に組み込みました。
管理者もシニアである、という認識の修正
もうひとつ、レビューで根本から覆った前提があります。当初は「住民向け画面は厳しく、管理画面は管理者が操作に慣れている前提なので緩めでよい」と考えていました。
これは誤りでした。このプロジェクトの管理者は、自治会の理事です。輪番制で順番が回ってきた60代から80代の住民であって、ITに詳しいから管理者になったわけではありません。管理画面にも住民向けと同じ水準のチェックリストを適用すべきだ、という指摘を受けて方針を変えました。「ユーザー」と「管理者」を別人格として扱う暗黙の前提が、シニア向けプロダクトでは成立しないことがあるという学びでした。
指摘を直すときも、段階的に
チェックリストが洗い出した課題のうち、もっとも数が多かったのが、操作の失敗を画面いっぱいのポップアップで知らせている箇所でした。シニアにとってこのポップアップは、どこを押せば消えるのか分かりにくく、画面内に静かに表示されるエラーへ置き換える必要があります。対象は管理画面全体で約30箇所ありました。
ここで一度に全部直さなかったのは、意図的な判断です。30箇所を一気に書き換えると、不具合が出たときにどの変更が原因か切り分けられません。世帯名簿、安否確認、おしらせ管理と設定、その他、という4つのまとまりに分け、まとまりごとに「実装する、不具合を確認する、修正する、コミットする」を1サイクルとして回しました。
この段階運用は実際に効きました。最初のまとまりでは、エラー表示がスクロール領域の外に出てしまい高さ計算が崩れる不具合が見つかり、表示位置を領域内へ移しました。次のまとまりでは、操作をキャンセルしたときに前のエラーが消え残る漏れを発見し、クリア処理を追加。さらに別のまとまりでは、通知の送信に成功するとカードごと画面から消えてしまい、肝心の完了メッセージが見えなくなる問題が出たので、メッセージをカードの外に独立表示する形へ直しました。1まとまりずつ閉じていたからこそ、これらの不具合が次のまとまりに持ち越されず、その場で潰せました。
チェックリストは「何を直すべきか」を教えてくれますが、「どう直すと安全か」までは書いてくれません。指摘の数が多いときほど、修正そのものを段階に分けて、各段階で不具合を確認してから次へ進む。チェックリストを運用資産として回すというのは、洗い出しだけでなく、この直し方の規律までを含むのだと実感しました。
まとめ — チェックリストを「運用資産」として育てる
この日やったことを振り返ると、新しい機能はひとつも作っていません。すでに持っていた知見を、使える形に翻訳しただけです。それでも主要画面と管理画面のクリティカルな課題がその日のうちにゼロになりました。蓄積した研究は、置いてあるだけでは資産になりません。読み手の状況別に入口を分け、根拠を切り離さず、人間の再評価とセットで運用して初めて、設計の精度を底上げし続ける資産になります。
完全版のチェックリスト本体は、ユーザーテストを重ねるたびに第3層へ実地知見を追記しながら、社内の運用資産として継続管理しています。この記事で共有したのは中身のリストではなく、それを支える3層構造の設計思想です。
最後に、この作業をAIと進めたことについて補足します。研究知見を構造化し、画面を機械的に評価して見落としを拾う部分は、Claude Codeとの協業が大きく効きました。一方で、自動評価の指摘を「本当に直すべきか」と再評価し、前提が崩れたチェック項目を文脈で却下する判断は、人間が引き受ける領域でした。AIは網羅性で、人間は文脈で。この役割分担を意識的に設計したことが、チェックリストを形骸化させなかった理由だと考えています。
同じ構造の課題に向き合っている方へ、関連する記事も置いておきます。実際のユーザーテストで何が起きたかは「72歳のシニアにアプリを使ってもらって見つかった3つの致命的な問題」に、避けるべきUIパターンの具体例は「シニア向けUIで避けるべきパターン」に、用語の言い換え運用は「シニア向けUIでカタカナ語を全廃した話」に、プロジェクト全体の設計判断は「自治会DXで学んだシニア向けWebアプリ開発の設計判断」にまとめています。
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。