2001年04月04日
元々認知科学で「プロトコル」と言うと被験者の様々な行動を指しますが、ユーザビリティ評価の世界では「発話プロトコル」のことを指すようです。つまり、「プロトコル分析」とは、被験者（ユーザ）が評価対象機を操作する間に「あれ？」とか「これはどういう意味だろ？」とか口にするのを注意深く拾って、彼らが操作ステップのどの部分で混乱したり壁に突き当たってしまったりするのかを検証する手法のことを意味します。思考を口に出すという意味で「シンク・アラウド（Thinking Aloud）法」とも呼ばれます。
これだけ聞くと、手軽にしかも確実に製品の問題点を発見できるような気がしますが、実はそう簡単ではありません。
まず問題解決に取り組んでいる被験者というのはそう思考を口に出してはくれません。実はこれはとても熟練のいる作業で、普通は考え込んでしまえばしまうほど無口になってしまいます。つまり一番肝心な部分を聞き出すのが難しいということです。
よく海外のユーザ・テストの風景を見ると、被験者の目につく場所に大きく「Think Aloud !!」などと書かれた張り紙がされていたりします。被験者が度々これを目にして「話ながらやらなくちゃいけないんだったな」と思い出してくれることを期待してのことです。
またテストの進行役が「今何を考えてますか？」と発話を促したりもします。ただこれらはあまりやりすぎると問題となります。認知科学的な観点で言えば、ただ黙々と課題に取り組む過程と、他人に説明をしながら取り組む過程は明らかに異なると言われています。今認知科学の世界でホットなキーワードに「内省」というのがあります。
広辞苑第５版によると、
ない‐せい【内省】
深く自己をかえりみること。反省。「冷静に自己を―する」「―的」
と定義されます。認知科学における思考支援研究でも、この内省を促すことがより質の高い思考につながると考えられています。そして矛盾するようですが、この内省を促すためには思考過程を一旦頭の外に出してしまうことが重要だとも言われています。「頭の外に出す」というのは、声にして出してみたり、紙やワープロに文字として書き出してみたりといったことです。ひっくりめて「外化する(Externalize)」なんて言ったりもします。つまり発話プロトコルの生成を強制するといことは、普通に人が自然に課題に取り組む状態に比べて内省を促していることになり、結果としてはより質の高い思考がなされ、課題達成率に影響してしまう（上の話で考えれば良くなる？）ことになります。いや、成績があがるならいいじゃないか、と言われるかも知れませんが、ここでもう一度考えていただきたいのが、「それが本来取りたかった実験結果か？」ということです。以前のコラムでも書いたように、ユーザテストの最大の意義は、より日常場面に近い状態でのデータ収集です。開発チーム内では得られない「使用現場」での情報にこそ価値があるはずです。普通の人は普段自宅でプロトコル発話をしながら道具を使ったりはしません。普通の場面が（極力）普通の場面（に近い状況）で課題に取り組んだ場合のデータを収集しないと意味がないのではないでしょうか？
また、達成率の話が出ましたが、プロトコル分析法は遂行時間計測との相性もよろしくありません。プロトコル発話は相当に負荷の高い活動なので、本来の課題への取り組みがそれだけおろそかになります。人によってはしゃべりだすと手が止まってしまったまま、延々と話しつづける人もいます。このような状況下では純粋にユーザが課題をどれくらいの時間で遂行できるか、という計測をしてもほとんど意味がないと言えます。
では、この様々なパフォーマンス測定と相性の悪いプロトコル分析法、一体どのような場合に有効なのでしょう？それは純粋にユーザにとって自然なインタラクションはどうあるべきか、問題点はどこにあるのか、といったことを「発見」するためのフェーズであると言えます。ユーザのプロトコルの中には「答え」はありません。「きっかけ」を見つけるための手法なのです。だから出来上がった製品の出来不出来をきっちり評価したいパフォーマンス測定と相性が悪いのかも知れません。
もうひとつユーザの発話プロトコルにはやや泥クサイながら利用方法があります。それは設計者やマネージャーの説得です。やはりユーザに「難しい」とか「わかんないや」言われるのは、どんなに自信家の設計者でもショッキングです。アンケートやインタビューでそう「答えられる」よりも説得力があります。実際にできるはずと思っていたことができてくれないのですから。この現場（あるいはビデオ）を、「ウチの製品は十分使いやすい」と信じている設計者やマネージャーに見せることは非常に効果があります。
いずれにせよ、プロトコル分析が非常に効果を持つのは、出来上がった製品を吟味する段階というよりは、「まず何から手をつけよう？現状（現行製品）の問題はどこにあるんだろう？」というフェーズであるという気がします。多分、人数をそうたくさん取る必要はありません（やればやっただけ問題点は出てきますが、いずれ切りがある話でもないので）。多分、ものの数人も実施してみれば、おのずとこれから取り組まなければならないことが見えてくると思います。開発に携わっていない事務職の人や家族を捕まえてきて、ちょっと使ってもらうだけでまずは十分です。いずれ定量化できる話でもなければ、テスト結果の正統的な分析方法が存在するわけでもないのです。「ちゃんとした分析方法が決まっていない？まさか！」と思われるかも知れませんが、プロトコル分析法に関する専門書を紐解いても具体的に被験者のどういう言葉から何をどう読み取れ、なんて書いてありません。せいぜいビデオ録画や後のテープ起こしの効率化に関する解説がなされているだけです。冒頭で
「プロトコル分析」とは、被験者（ユーザ）が評価対象機を操作する間に「あれ？」とか「これはどういう意味だろ？」とか口にするのを注意深く拾って、彼らが操作ステップのどの部分で混乱したり壁に突き当たってしまったりするのかを検証する手法のこと
と書きました。偉そうに「手法」と呼ばれていますが、実際のところはそんな程度です。是非開発の初期段階にでも、お気軽に実施してみて下さい。