予約フローが完了画面に到達したものの、参加者が誤った日付を選んでいたとします。このセッションを「成功」と見なすかどうかは、その調査で何を測定しようとしていたかによって決まります。タスク成功率（タスク完了率とも呼ばれます）は、タスクの完了が具体的に何を意味するのかをチーム内で合意できていて初めて、真価を発揮します。

基本的な計算式は、有効な試行回数に対する成功した試行回数の割合に100を掛けたものです。例えば、20人中16人の参加者が同じタスクを問題なく完了した場合、観察された成功率は80%になります。これは今回の調査条件下におけるこのサンプルについての数値であり、将来のすべてのユーザーについての確定的なデータではありません。

セッションを見る前に「成功」を定義する

参加者のゴールに見合った、客観的に観察可能な基準を設定しましょう。チェックアウト画面に到達すること、何かしらのチケットを購入すること、そして適切なチケットを購入することは、それぞれ異なる結果です。タスクシナリオでは進め方のヒントを与えずにゴールを示し、リサーチ計画書にはオブザーバーが何を成功とカウントするのかを明確に記録しておきます。

ニールセン・ノーマン・グループによる成功率の解説では、このシンプルな指標の価値が説明されています。成功率が有用であるかどうかは一貫した採点にかかっており、特に誰かがサポートを受けたり、途中で断念したり、失敗しているのに本人は成功したと思い込んでいるような場合に重要になります。

モデレーターのサポートやシステムトラブルへの対処方針は、事前に決めておきましょう。テスト機器の不具合による中断は、事前に定めたルールに沿って除外して構いません。一方、先に進めなくなって利用をやめてしまったケースは、ユーザー体験そのものを物語るデータです。失敗した試行をひそかに除外してしまうと、誤解を招く数値になってしまいます。

「部分的な達成」も可視化しておく

タスクによっては、完了に至るまでに複数の重要な段階が含まれることがあります。適切な口座を見つけられたものの出金条件を誤認してしまったり、モデレーターから必須項目を指摘されて初めてフォームを送信できたりする場合です。最終的な数値の陰に重要な課題が埋もれてしまわないよう、こうしたケースもきちんと記録しておきましょう。

レポートで二者択一の成功率を用いる場合は、どのようなケースが該当するのかを明記します。「一部成功」という枠を設けたり加重スコアを使ったりする場合は、そのルールを説明し、通常の完了率であるかのように見せない配慮が必要です。また、比較対象となるバージョン間では、採点ルールを統一しておく必要があります。

デザイナーにとっては、単なる分類よりも、観察されたつまずきの短い記録のほうが役に立つことがよくあります。「失敗」は結果を示すだけですが、「正しい配送日を選択できたが、住所入力のエラーから復帰できなかった」という記録があれば、チームで具体的な改善に向けた調査ができます。

パーセンテージと一緒に不確実性も提示する

サンプルサイズが小さいと、推定値にはブレが生じます。分母を示さずに「80%」とだけ報告すると、5回中4回の成功も100回中80回の成功も同じように見えてしまいますが、その精度には大きな差があります。割合の推定を目的とした調査では、有効な試行回数と適切な信頼区間を併記しましょう。

SauroとLewisによる完了率の信頼区間に関する研究では、この課題に適した手法が検討されています。特に成功率が0%や100%に近い場合は、単純な対称型の信頼区間を機械的に適用することは避け、観察されたわずかな数値の差を確実な改善と決めつけないようにしましょう。

完了率とあわせて、そこに至るまでの体験も見る

タスクが成功したという事実だけでは、操作に手間取ったのか、不安を感じていたのか、あるいはストレスを感じたのかまでは分かりません。行動観察やエラーのログ、そしてSingle Ease Question（SEQ）などを組み合わせることで、結果の背景にある体験を読み解きやすくなります。試行錯誤を繰り返してようやく成功した人もいれば、迷いなく間違った道を進んでしまう人もいます。

プロトタイプテストでは、プロトタイプ自体の制約によるものなのか、最終的なデザインでも起こりうる問題なのかを見極めることも大切です。タスク、参加者、採点基準、調査条件が揃って初めて、数値の比較が意味を持ちます。数字だけでは見落とされてしまう背景情報も補いながら、チームがどこを改善すべきか判断できるように結果をまとめましょう。