プロダクト上では単に「経費を申請する」という操作に見えても、実際に行う人は領収書を探し、適用される予算を確認し、社内規定をチェックしたうえで、場合によっては誰かに承認をもらってからでないとフォームに入力すらできません。タスク分析とは、インターフェースの外で発生する作業も含め、目標を達成するために必要なプロセス全体を解き明かす手法です。

この分析によって、行動、判断、情報、そして依存関係が構造化されます。目的は、現在のプロダクトの操作手順が「あるべき姿」だと決めつけるのではなく、ユーザーが本来何を達成しようとしていて、どこに支援が必要なのかを理解することです。

境界線が明確な目標を選ぶ

まずは「人」と「得たい結果」から始めます。「ダッシュボードを使う」はツールとのやり取りにすぎませんが、「午後の発送前に対応が必要な配送を特定する」はれっきとした目標です。後者のように捉えることで、ダッシュボードが役に立っているのか、不足があるのか、あるいは作業のほんの一部にすぎないのかが見えてきます。

設定する境界によって、どこまで文脈を含めるかが決まります。狭すぎると負担の原因になっている事前準備が見落とされ、広すぎると業務全体の記述になってしまいます。Nielsen Norman Groupによるタスク分析の入門記事では、人々が目標を達成するために取る行動の情報を集め、構造化する方法が解説されています。

現状の動きと、提案したい未来の姿は明確に区別してください。既存のプロセスを観察する前に理想のフローを描いてしまうと、新しい提案では対応しきれない細かな業務責任を見落とすおそれがあります。

手順とその背景にある理由を集める

コンテキスト評価（Contextual Inquiry）やシャドーイングによる観察は、記憶だけでは再現しにくい細かなステップを浮き彫りにします。一方でインタビューを行えば、判断の理由や稀な例外、安全面や時間的な制約で観察できないアクションを補えます。どちらか一方だけで完結させようとせず、可能な限り組み合わせて活用しましょう。

架空の配送オペレーションを例にすると、配車担当者が「本当に遅延している荷物」と「単に追跡データの更新が遅れているだけの荷物」をどう見分けているかを観察します。タイムスタンプを見比べたり、ドライバーに連絡したり、顧客へ事前連絡を入れるべきか判断したりといった部分にこそ本質的な仕事があります。画面上のクリック手順を追うだけでは、そのタスクの本当の難しさは見えてきません。

各ステップで必要となる情報、使われるツール、他者への引き継ぎを記録しましょう。不足している情報、連絡がつかない同僚、作業の中断、通常の手順が使えない状況など、例外ケースについても掘り下げます。役割や拠点によってやり方が異なることも考慮しつつ、実際に作業を行う人たちと一緒に内容を検証してください。

複雑さに適した表現手法を使う

短い定型作業であれば、シンプルな手順リストで十分かもしれません。階層型タスク分析（HTA）は、目標をサブゴールや操作へと分解し、順序や条件を整理します。認知的タスク分析（CTA）は、特に専門性の高い業務において、判断や知識、思考の負荷といったメンタルな側面に焦点を当てます。

デザイン上の意思決定を左右しうる、適切な詳細度を選びましょう。キーストロークまで細かく記録すると重要な引き継ぎが見えなくなる一方、大まかなフェーズだけでは判断に必要な情報が隠れてしまいます。不確実性が潜んでいる部分こそ、詳細に書き出す価値があります。

分析結果をデザインへの問いに変換する

配送の例で言えば、配車担当者には「古い情報」と「対応が必要な例外」を確実に見分ける手段が必要だとわかるかもしれません。そこから、ステータス表示の変更、エスカレーション手順の見直し、データ品質の改善といったアプローチが導かれます。すべての課題を新しい画面機能で解決しようとするのではなく、本質的なニーズと文脈を特定することが重要です。

得られた知見を、ユーザーフローや現実的なタスクシナリオ、要件定義に反映させましょう。そして、提案した解決策が機能するかを関係者とともに検証します。タスク図は検討や修正を重ねるための道具であり、単にそのフロー通りに作ったからといってプロダクトの成功を保証するものではありません。