利用者タスクを起点に情報アーキテクチャを監査する方法

サイトマップを描き直す前に、事業上重要な利用者タスクを選び、現実に使われ得る入口から完了までの経路を追ってください。混雑したメニュー、高い離脱、情報が見つからないという声だけでは、原因が構造全体にあるとは判断できません。情報不足、曖昧なラベル、関連リンクの欠落、検索結果の弱さ、操作部品の使いにくさを切り分け、観察された失敗に対応する最小の修正を試してから、移行や全面再設計の妥当性を判断します。

監査は、どの意思決定に答えるべきか

監査は「どこを直すか」「移行時に何を維持するか」「再設計を承認できるだけの根拠があるか」といった、具体的な判断に答えるよう設計します。情報アーキテクチャは、利用者が情報を見つけ、現在位置と選択肢を理解し、目的のタスクを完了できるようにする組織化、ラベル、ナビゲーションを扱います。そのため対象は抽象的な平均利用者ではなく、指定した利用者層、端末、言語、権限、開始地点、ページ種別、利用状態に限定します。

• 判断：セクション修正、名称変更、移行準備、または再設計の根拠確認
• 範囲：対象者、タスク、開始地点、端末、言語、権限、状態
• 証拠区分：既知の事実、観察した行動、専門家所見、未検証の仮説
• 対象外：コンテンツ棚卸し、技術SEO監査、適合性評価、再設計そのもの

根拠から代表的なタスク集合をどう作るか

タスクは、利用者が認識できる結果として書き、行き先のメニュー名や正解の経路を文面に含めません。GOV.UKの調査指針は、利用者が何をしようとしているか、現在どう行っているか、どこで問題を経験し、どのような結果を必要としているかを学ぶよう勧めています。アクセス解析、サイト内検索ログ、問い合わせ記録、既存調査、インタビュー、観察、利用者対応担当者の知見は証拠候補になりますが、利用者以外の意見は裏付けが得られるまで仮説です。

• 頻度だけで選ばず、影響が大きいタスク、難しいタスク、十分に支援されていない利用者のタスクも含めます。
• 各タスクに対象者、発生契機、想定する開始地点、成功した状態、必要な情報または操作、証拠の出所を付けます。
• アクセス解析、離脱、検索ログ、問い合わせは問題を探す入口にはなりますが、それだけで利用者の意図、原因、正しい修正方法までは確定できません。
• Digital.govの事例でも、既存調査から現実的なタスクを作り、テスト前に対象範囲を確認しています。

タスクと経路の記録表には何を残すか

一つの記録表に、タスクの根拠、成功条件、想定到達先、現実的な開始地点、閲覧・関連リンク・検索の各経路、判断地点の手掛かり、観察結果、失敗分類、修正案、担当者、再テスト条件を結び付けます。利用者が必ずトップページから始めるとは限りません。検索エンジン経由の詳細ページ、部門トップ、ログイン後の画面など、それぞれで見える選択肢と、誤った選択から復帰できるかを記録します。

タスク型IA監査が問うのは、サイトマップの整然さではなく、現実の経路で必要な結果へ到達できるかです。

WCAG 2.2の達成基準2・4・5は、プロセスの結果または途中のページを例外として、ページ群内のページを見つける方法を複数用意することを求め、関連リンク、サイトマップ、検索、包括的なナビゲーションを手法として示しています。この観点は代替経路の点検に使えますが、一つの記録表や一部の確認結果だけでアクセシビリティ適合性を判断してはいけません。

メニューだけでなく経路全体をどう点検するか

経路点検では、外部からの入口、グローバル・ローカルナビゲーション、一覧やハブ、ページのまとまり、見出し、パンくずなどの位置情報、関連リンク、サイト内検索、最終的な情報や操作までを通して確認します。Microsoftの指針は、利用者の視点、一般的なタスク、メンタルモデルに沿ったナビゲーション計画を勧め、ラベルには正確さ、親しみやすさ、簡潔さ、読み取りやすさ、選択肢間の見分けやすさを求めています。

• 手掛かりは到達先の内容を正しく予告しているか
• 近接する選択肢を利用者が区別できるか
• 現在位置と階層、次にできることが分かるか
• 誤った選択後に戻る道や別経路を認識できるか
• 重要なページ種別、端末、言語、権限、状態で経路が変わらないか
• 検索結果の関連性と名称から、正しい到達先を選べるか

WCAG 2.2の達成基準2・4・6は、提供される見出しとラベルがトピックまたは目的を説明することを求めています。達成基準3・2・3は、利用者が変更を開始した場合を除き、ページ群で繰り返されるナビゲーション機構の相対順序を一貫させるよう求めますが、ローカルナビゲーションや補助ナビゲーションを禁止してはいません。検索の利用自体はナビゲーション失敗の証明ではなく、利用者に適した正当な代替経路である場合があります。

不確かな経路にはどの調査手法を選ぶか

検証手法は、解決したい不確かさに合わせて選びます。専門家点検と既存データは疑わしい箇所を絞るために使い、専門家が懸念しただけの事象を「利用者が失敗した」と報告しません。カードソートは、参加者がコンテンツをどうまとめるかを調べ、オープン型では作成したグループにどのような名称を付けるかも把握する手法です。ただし、実際のページを通る経路全体の検証にはなりません。

• 分類やカテゴリー語が不確かなら、カードソートで期待するまとまり方と言葉を調べます。
• 階層とラベルから目的地を見つけられるかが不確かなら、ツリーテストで画面デザインの影響を切り離します。
• 実画面のナビゲーション、手掛かり、操作、関連リンク、検索、復帰、完了までが対象なら、タスク型ユーザビリティテストを行います。
• 完了、支援、誤選択、戻り、所要時間、検索語の変更、到達先への確信、参加者の説明から、判断に必要な項目だけを選びます。

ツリーテストは、画面デザインの影響を減らして、階層とラベルから目的地を見つけられるかを切り分けて調べられますが、実画面の手掛かり、操作部品、関連リンク、検索結果の挙動までは評価しません。NISTは、ユーザビリティテストを代表的な利用者が代表的なタスクを行う検証として説明し、完了、エラー、所要時間、定性的な発言、満足度を証拠の例に挙げています。参加者が選んだ経路の違いと説明は、一部の参加者が目的地へ到達できた場合でも、曖昧な分類やラベルを見つける手掛かりになります。

所見を限定修正または再設計の判断へどう変えるか

まず失敗を分類し、その分類に対応する最小の変更を選びます。重要度、影響を受ける利用者、観察された頻度、失敗の結果、証拠の強さ、他の修正への依存関係を明示して優先順位を話し合い、判断を一つの総合点に隠しません。全面再設計へ進む根拠になるのは、重要タスクの失敗が関連する複数の文脈で繰り返し観察され、構造に起因し、限定修正では合理的に解消しにくい場合です。

• カバレッジ：必要な情報、操作、状態が存在しないか不完全
• 入口：想定される開始地点にもっともらしい経路がない
• ラベル：手掛かりが到達先を説明せず、言葉も不統一
• 分類：置き場所が期待と異なり、カテゴリーが重なる
• 位置把握：現在位置、階層、次の選択肢が分からない
• 関連リンク：必要な場面に次の経路がない
• 検索：結果が不足、不適切、誤解を招く、または選びにくい
• 一貫性：名称、順序、動作がページ間で予期せず変わる
• 操作：構造は妥当でも、画面上の部品や表現が利用を妨げる

修正後は、影響を受けたタスクを同じ主要な開始地点と文脈で再テストし、完了だけでなく誤選択、支援、戻り、検索語の変更、利用者の説明も比較します。ここで扱ったWCAGの観点だけでは、サイト全体のアクセシビリティ適合性は確認できません。アクセシビリティ上の疑問が生じた場合は、有資格または十分な専門性を持つ担当者による別の適合性評価を組み込み、タスク設計や構造上の判断がチームの能力を超える場合は、経験ある情報アーキテクトやUXリサーチャーを関与させます。