「使いやすさ」を、感覚で終わらせない
ヒューリスティック評価とユーザビリティテストを学び直して考えたこと
2026年7月11日、鹿児島で開催されたHCD-Net主催「【九州開催】ヒューリスティック評価・ユーザビリティテスト ワークショップ」に参加しました。講師は、NPO法人人間中心設計推進機構（HCD-Net）副理事長の水本徹さんです。
水本さんは、ゲームメーカーや医療機器メーカーなど幅広い業務分野で、人間中心設計を用いて顧客満足度の高い製品を開発してこられた方です。現在は、その経験を活かし、組織への人間中心設計プロセスの導入に注力されています。人間中心設計やUXデザインに関する学会発表や講演も多数手がけておられます。和歌山大学で博士（工学）を取得し、人間中心設計推進機構認定人間中心設計専門家、日本人間工学会認定人間工学専門家でもあります。研究や理論だけでなく、開発現場と組織への導入の両面から「使いやすさ」に取り組んでこられた方の講義です。
ワークショップの前半では、専門家が画面や製品の問題を発見する「ヒューリスティック評価」を学び、後半では実際に人が操作する様子を観察する「ユーザビリティテスト」を体験しました。講義を聞くだけでなく、参加者自身が手を動かして評価し、発見した問題を共有するところまで含む実践的な内容でした。
10年以上前からHCD（人間中心設計）やUXデザインを学び、私たちなりにUIデザインやWeb制作の実務の中で実践してきました。画面設計や情報設計だけでなく、ユーザーインタビューやワークショップ、業務システムの改善にも携わっています。今回、あらためてユーザビリティ評価を学び直そうと考えたのは、自分たちが日々行っている判断を、もう一度きちんと説明できる形にしたかったからです。
経験を重ねるほど、「こちらのほうがよい」という判断はできるようになります。一方で、その判断が経験者だけに通じる感覚的なものになっていないか、立ち止まって考える必要もあります。
なぜ、この画面は使いにくいのか。誰にとって、どのような問題が起こるのか。それを他者と共有し、検証し、次の設計でも再利用できる形にするにはどうすればよいのか。今回のワークショップは、その問いをあらためて考える機会になりました。
「使いやすさ」は、誰にとってのものか
ISO 9241-11では、ユーザビリティを考えるうえで主に次の要素が扱われます。
- 有効さ
- 効率
- 満足度
- 利用状況
重要なのは、単に操作できるかどうかではありません。目的を正確に達成できるか。過度な時間や負担をかけずに達成できるか。不安や不快感を抱かずに利用できるか。そして、それを誰が、どのような目的と環境で利用するのか。
同じ画面でも、毎日使う熟練者と初めて利用する人では使いやすさの意味が変わります。管理者と一般ユーザーでも違いますし、時間に余裕のある人と現場で急いで操作する人、パソコンで利用する人と移動中にスマートフォンで利用する人でも違います。
つまりユーザビリティは、製品の中に固定的に備わっている性能ではなく、ユーザー・目的・環境の関係の中に生まれる品質です。そのため評価を始める前に、「誰が、何のために、どのような状況で使うのか」を明確にしなければなりません。
ペルソナを間違えると、設計も評価も間違える
今回、あらためて重要だと感じたのがペルソナの役割です。
ペルソナというと、年齢、職業、家族構成、趣味などを並べた架空の人物プロフィールを思い浮かべるかもしれません。しかし、少なくとも業務システムやWebサービスを設計するうえで特に大切にしているのは次の二つです。
- その人がどのような役割を担っているか
- その人が何を達成しようとしているか
同じシステムを利用していても、入力担当者、承認者、管理者、閲覧者では必要な情報も操作も異なります。入力担当者にとっては間違えずに素早く入力できることが重要かもしれませんし、承認者にとっては判断に必要な情報を短時間で比較できることが重要です。管理者には、個別の情報だけでなく全体の状態を把握できることが求められます。
役割とゴールを誤って設定すれば、要求も、画面も、評価項目も、ユーザビリティテストで与えるタスクも間違える可能性があります。ユーザーを理解するためにつくったペルソナが、逆に実際のユーザーを見えなくしてしまう。
ただし、最初から完璧なペルソナをつくらなければならないという意味ではありません。ペルソナも一つの仮説です。調査やテストの結果、実際の行動と合わないことが分かれば、ペルソナのほうを修正しなければなりません。人間中心設計とは、最初に人間を正しく定義し、その定義どおりにつくることではなく、人間についての仮説を持ち、設計し、観察し、間違っていれば前提まで戻ることです。
ペルソナについては、井登友一さんの「『ペルソナって古くないですか？』という質問を受けた話」も参考になります。この記事では、ペルソナは単なる調査結果の要約ではなく、ユーザーの価値観や期待する文脈をプロジェクトの参加者が理解し、感情移入するためのものだと説明されています。また、実在する特定の個人をそのまま写すものではなく、調査で得られた一次情報を解釈し、価値観や文脈的なゴールを凝縮したモデルとして位置づけられています（note）。
参考記事：https://note.com/corobutika/n/n274686d577d1
ペルソナに関する次の書籍も参考になります。
https://amzn.asia/d/097g4vyN
刊行から年数がたっているため、現在のサービス環境や開発手法とそのまま一致しない部分はあるかもしれません。それでも、ペルソナを単なるプロフィールシートではなく設計の判断基準として扱うための基礎を理解するうえでは、今なお参照する価値があると思います。
ヒューリスティック評価は「詳しい人の感想」ではない
ヒューリスティック評価は、ユーザビリティに関する原則やガイドラインに照らし、インターフェースの問題を発見する方法です。代表的なものに、ニールセンのユーザビリティ10原則があります。
- システム状態の視認性
- システムと現実世界の一致
- ユーザーの主導権と自由
- 一貫性と標準
- エラーの防止
- 記憶ではなく認識を促す
- 柔軟性と使用効率
- 美的で最小限のデザイン
- エラーの認識・診断・回復を支援する
- ヘルプとドキュメント
こうして項目だけを並べると、一般的なUIのチェックリストに見えるかもしれません。しかし水本さんの話を聞きながら、これらは表面的な画面表現を確認するだけの原則ではないと、あらためて感じました。
たとえば「システム状態の視認性」は、ローディングマークを表示すれば満たされるという話ではありません。今、何が起きているのか。操作は受け付けられたのか。処理は完了したのか。自分は今どの段階にいて、次に何をすればよいのか。ユーザーが自分の置かれている状況を理解できるか、という問題です。
「記憶ではなく認識を促す」という原則も、実務では非常に重要です。前の画面で見た番号を覚えておかなければならない。以前の操作手順を記憶していなければ進めない。どの項目が選択済みか、画面を見ても判断できない――こうした設計は、システム側で保持・表示できる情報を、ユーザーの記憶へ押し付けています。画面を見れば判断できる状態をつくることは、見た目を整えること以上に重要なデザインです。
今回、水本さんの解説とワークを通して、ニールセンの10原則を知識として思い出しただけでなく、一つひとつの原則を実際の利用状況と結び付けて考える必要があることを、あらためて学びました。原則に違反している箇所を探すだけでは不十分で、その違反によって誰に、どのような問題が起きる可能性があるのかまで考えて、初めて評価になります。
もう一つ、専門家評価の方法として認知的ウォークスルーも紹介されました。ヒューリスティック評価が原則と画面を照らし合わせる方法であるのに対し、認知的ウォークスルーは、ユーザーがタスクを達成するまでの一連のステップを想定し、各ステップで「次に何をすべきかが分かるか」「その行動を実行できるか」「結果を理解できるか」を一段ずつ確認していく方法です。
興味深いのは、評価が始まる前、ステップを定義する段階そのものに気づきが多いということです。タスクをどこまで細かく分けるかによって、見える問題は変わります。粗すぎれば途中の迷いを見逃しますし、細かすぎれば実際のユーザーの認知単位とずれてしまいます。ステップの粒度を決めること自体が、すでにユーザーの行動を想像する作業であり、評価の一部なのだと感じました。
sHEM（structured Heuristic Evaluation Method）は、見る角度を意図的に変える方法
今回のワークショップでは、sHEM（構造化ヒューリスティック評価法）についても学びました。sHEMでは、評価の視点を大きく次のカテゴリーに分けます。
- 操作性
- 認知性
- 快適性
- 習熟度
- 特別な配慮を必要とするユーザーへの対応
これらは、さらに次のような側面として捉えることができます。
- 人間工学的な側面
- 認知的な側面
- 感性的な側面
- 経験や習熟度の側面
- ユニバーサルデザインの側面
同じ画面を見ていても、操作性の問題と認知性の問題は異なります。
ボタンが小さく物理的に押しにくいのか。ボタンの存在に気づかないのか。ボタンに書かれた言葉の意味が分からないのか。押した後の結果を理解できないのか「ユーザーがボタンを押さなかった」という一つの現象にも複数の原因が考えられ、原因が違えば改善方法も変わります。
ボタンを大きくすれば解決するとは限らず、表示位置や言葉、前後の情報構造から見直す必要があるかもしれません。
sHEMの価値は、チェック項目が多いことだけではありません。
同じ画面を、異なる観点へ意識的に切り替えながら繰り返し見ることにあります。経験を積むと、自分が発見しやすい問題と見落としやすい問題が生まれます。視覚表現に詳しい人はレイアウトや認知の問題には気づきやすい一方で、身体的な操作負荷や熟練者の効率性、特別な配慮を必要とするユーザーの問題を見落とす可能性があります。評価の視点を構造的に分けることは、個人の得意分野や経験による偏りを減らすことにもつながります。
1997年に公開されたsHEM
sHEMについて紹介してもらったのが、黒須正明氏による「structured heuristic evaluation method（sHEM）」のページです。
http://www.interq.or.jp/tokyo/kurosu/article/970820his.html
1997年に公開されたページで、現在のWebサイトとして見ると装飾はほとんどなく、研究資料に近い形式です。しかし、そこで扱われている問題は今も古びていません。Webサイトやアプリの表現方法、使用する端末、技術環境は1997年から大きく変わりましたが、人が情報を知覚し、意味を理解し、次の行為を決め、結果を解釈するという基本的な構造は大きく変わっていません。
このページでは、ユーザビリティ評価を実際のユーザーを用いる方法と用いない方法に整理したうえで、専門家による評価を構造的に行う方法としてsHEMが示されています。特に興味深いのは、評価項目を単純な一列のチェックリストとして並べるのではなく、人とシステムとの関係を複数の側面から捉えようとしている点です。
チェックリストを使っているだけで、すべてがヒューリスティック評価になるわけではありません。「長くデザインをしてきたから、こちらのほうがよいと分かる」という判断と、「この原則に照らすと、この利用状況ではこのような問題が起きる可能性がある」という評価は、似ているようで異なります。経験は重要で、経験がなければ発見できない問題もあります。しかし、その経験を他者と共有し、検証し、再利用するためには、判断を支える構造が必要です。
チェックリストは、正解集ではなく「組織の記憶」である
今回のワークショップで、特に実務へ取り入れたいと思ったのが、評価に使うガイドラインやチェックリストを育てていくという考え方です。この点も、水本さんの話からあらためて学んだことの一つです。
最初は、ニールセンの10原則やsHEMのような既存の知見を参考にすればよいと思います。しかし実際の業務では、対象となる製品やユーザーによって発生しやすい問題が異なります。業務システムでは入力ミスや権限の違いが重要になり、ECサイトでは商品を比較し購入を決定するまでの不安を減らすことが重要です。採用サイトでは利用者が自分に関係する情報を発見できるかどうかが重要になり、医療機器では一度の誤操作が与える影響を、より慎重に考えなければなりません。
一般的な原則だけで、すべての案件を同じように評価することはできません。そのため、自分たちの案件で繰り返し起きた問題を、組織独自のチェックリストへ追加していきます。反対に、何度評価しても問題として現れず、実際のユーザー行動とも関係しない項目は、削除や統合を検討します。
チェックリストを育てるとは、項目を増やし続けることではなく、評価結果やユーザーからのフィードバックをもとに判断基準そのものを更新していくことです。そう考えると、ガイドラインやチェックリストは正解集というよりも、組織が過去の失敗を忘れないための「記憶」に近いものになります。
ある案件で見つかった問題を、その案件だけの修正で終わらせない。なぜ問題が起きたのか。どのようなユーザーに影響したのか。どのように改善したのか。別の案件でも起こり得るのか。それを言葉にして残すことで、個人の経験が初めて組織の知識になります。
プロテアは小さな会社です。だからこそ、一人が得た経験を、その人だけのものにしないことが重要だと思います。デザインガイドラインや評価チェックリストは、制作物の表現を統一するためだけのものではなく、過去に何を見落とし、何を学び、次に何を確認すべきかを伝えるためのものです。
ユーザビリティテストでは、意見より行動を見る
後半のユーザビリティテストでは、実際に人が操作する様子を観察しました。ここで重要なのは、ユーザーの意見を聞くことだけではありません。ユーザーは必ずしも、自分がなぜ迷ったのかを説明できるわけではないからです。
長い時間迷った後でも「特に問題ありません」と話すことがあります。何度も操作をやり直していても「普通に使えました」と答えることがあります。これは、ユーザーがうそをついているわけではなく、本人の主観的な評価と実際に起きていた行動上の問題が、必ずしも一致しないということです。
だから、発言だけでなく行動を見ます。どこで手が止まったのか。何を見落としたのか。どこを何度も往復したのか。何をクリックできると思ったのか。どの言葉を、設計者とは異なる意味に解釈したのか。操作後の状態をどのように理解したのか。設計者が想定した操作と、ユーザーが実際に行った操作の間にある差を観察します。
ユーザビリティテストは、ユーザーに正解を尋ねる方法ではなく、設計者が持っていた仮説と現実の行動がどこでずれているのかを発見する方法です。
また、テストをしていると、参加者が迷っている様子を見て操作方法を教えたくなることがあります。しかし、すぐに助けてしまえば、どこで、なぜ迷ったのかが分からなくなります。参加者を試験しているのではなく、設計を評価している――その前提を、実施者も参加者も共有することが大切です。
専門家視点とユーザー視点
ヒューリスティック評価とユーザビリティテストは、どちらか一方だけを行えばよいものではありません。専門家評価では、既存の知見や原則から問題が起こりそうな場所を効率的に発見できます。しかし、専門家が問題だと考えたことを、実際のユーザーが問題に感じるとは限りません。反対に、専門家が見落としたところで、ユーザーが思いもよらない行動をすることもあります。
だからこそ、専門家の視点で仮説を立て、ユーザーの行動によって検証します。そして、ユーザーの行動から発見した新しい問題を、次の評価基準やガイドラインへ戻す――この循環が重要です。
ISO 9241-210が示す人間中心設計も、利用状況の理解、要求の明確化、設計、評価を一度だけ順番に実施するものではありません。評価の結果によっては、設計だけでなく要求や利用状況の理解そのものへ戻ります。場合によっては、「そもそも想定していたユーザーが違っていた」「解決しようとしていた問題が違っていた」というところまで戻らなければなりません。
評価は、完成した画面の間違いを探すためだけの工程ではなく、自分たちの前提が現実と合っているかを確かめるための工程でもあります。
『荘子』の「混沌」の話
懇親会での水本さんの話の中で、特に印象に残ったものの一つが『荘子』の「混沌」の寓話でした。出典は『荘子』「応帝王」です。
中央の帝である混沌には、人間のような目、耳、鼻、口にあたる七つの穴がありませんでした。混沌から厚遇を受けた二人の帝は、その恩に報いるため、混沌にも人間と同じ七つの穴を開けてあげようと考え、一日に一つずつ穴を開けました。そして七日目、混沌は死んでしまいます。
二人は、混沌を苦しめようとしたわけではありません。自分たちにあるものを相手にも与えようとし、自分たちから見て不完全に思える状態を、よりよい状態へ改善しようとしたのです。しかし、その善意による改善が、混沌そのものを壊してしまいました。
この話を人間中心設計やUXデザインの文脈で聞いたことが、とても印象に残りました。ユーザー中心、人間中心という考え方にも、同じ危うさがあるという指摘だったのではないかと考えています。
私たちはユーザーを理解したつもりになり、ペルソナという形を与え、行動を分類し、ゴールを定義します。UIを分かりやすくし、操作を効率化し、迷いを減らそうとします。それ自体は必要なことです。しかし、理解しやすくするためにつくった「型」が、実際の人間を覆い隠してしまうことがあります。
ペルソナに合わない行動を例外として捨ててしまう。効率化できない時間をすべて無駄と見なしてしまう。迷いや曖昧さを、すべて除去すべき問題として扱ってしまう。自分たちが理解できる人間へと整えるために、混沌へ穴を開けるようなことをしていないでしょうか。
人間を理解するための方法が、人間を単純化しすぎる方法になっていないか。その危険を自覚することも、人間中心設計には必要なのだと思います。
工学として考えること
水本さんの話から、もう一つ強く印象に残ったのが「工学として考える」でした。
工学というと、効率化や機能追加を思い浮かべがちです。しかし本質は、目的を明確にし、その方法を検証し、再現可能な形にすることだと思います。「なんとなく良い」で止めず、判断の根拠を言語化し、次の案件でも再現できる手順に落とし込む。それが、デザインを工学として扱うということではないでしょうか。
同時に、その介入によって何が失われるのかも考える必要があります。クライアントから課題が来ると、つい画面を足す、説明を増やすといった解決策に飛びつきがちです。しかし、その問題は誰に、どの程度の頻度で起きているのか。対応するかどうか、どの優先度で扱うかまで判断する。その思考の型を持つことが、工学として考えるということなのだと思います。
「工学」そのものを体系的に学んだ経験はないため、素人なりの理解として書いています。
「違和感」を構造化し、体験へ翻訳する
プロテアでは、Webサイトや業務システムをつくる際に、ユーザーや現場の中にある違和感を見つけることを大切にしています。ただし、違和感を見つけるだけでは仕事になりません。
なぜ違和感が生じるのか。誰に、どのような状況で起きるのか。認知の問題なのか、操作の問題なのか。情報が不足しているのか、反対に多すぎるのか。その結果、ユーザーの行動や業務に何が起きるのか。それらを構造化し、設計可能な形へ翻訳する必要があります。
今回、ヒューリスティック評価とユーザビリティテストを学び直したことで、自分たちが感覚的に行ってきたことを、より明確なプロセスとして捉え直すことができました。
美術を学び、Web制作を続け、人間中心設計やUXを学んできました。それらは、別々の経歴ではないのかもしれません。「人はどのように見て、感じ、理解し、行動するのか」私の中では、その一つの問いでつながっています。美術で培った感覚を、そのまま個人の感性として提示するのではなく、他者と共有できる構造へ変える。そして、構造化した知識だけで人間を理解したつもりにならず、実際の行動へ戻って確かめる。その往復が、プロテアの仕事にも必要なのだと思います。
学びの場をつくってくださった方々へ
今回のワークショップでは、手法や知識だけでなく、人間中心設計に向き合う姿勢そのものを学びました。
ニールセンのユーザビリティ10原則やsHEMを、単なるチェック項目として扱わないこと。チェックリストを固定された正解集にせず、実際の評価やユーザーの行動をもとに育てていくこと。人間を理解するためのモデルが、かえって人間を見えなくする可能性を忘れないこと。そして、工学的に考えるからこそ、何かを変更するだけでなく「何もしない」という選択肢も持つこと。
いずれも、知識としては断片的に知っていたことかもしれません。しかし、水本さんの豊富な実務経験に裏付けられた言葉と、実際のワークを通して、あらためて自分の中へ入ってきた感覚があります。
長年にわたりゲーム、医療機器、産業分野などで人間中心設計を実践し、その知見を組織や次の世代へ伝えてこられた水本さんから、鹿児島で直接学べたことをありがたく思います。また、今回の場を主催されたHCD-Netの皆さま、運営を担当された株式会社シナプスの今門克行さんをはじめ、準備や進行に携わってくださった皆さまにも感謝します。
講義だけでなく、参加者同士で考え、評価し、質問し、交流できる場を設けていただいたことで、知識を実務へ持ち帰るための貴重な時間になりました。
人間中心設計に関する知識や方法は、東京や関西など一部の地域だけに集まっていても、社会へ十分に広がりません。九州、そして鹿児島の地でこのように実践的な学びと交流の場がつくられていることには、大きな意味があると思います。（九州ファンとして。）HCD九州に関わる皆さまが積み重ねてこられた活動があるからこそ、今回のような機会が実現したのだと思います。
今回得た学びを、参加して終わりにするのではなく、自分たちの仕事へ戻し、評価の方法やガイドラインとして少しずつ育てていきたいと思います。そして、プロテアの中だけに閉じず、案件や地域を越えて、よりよい製品やサービスをつくるための知識として共有していきたいと考えています。
水本さん、HCD-Net、HCD九州、株式会社シナプス、運営に携わられた皆さま、そして一緒にワークへ参加した皆さま、本当にありがとうございました。
僕に何ができるのか
画像の少ない文字だらけのレポートになりなんだか申し訳ない気持ちにもなりましたが、アウトプットの大切さにようやく気がついたので続けていきたいと思っています。
そもそも、僕が人間中心設計やユーザビリティに関心を持つようになった根本には、娘のハンディキャップがあります。僕は医師にはなれません。治療をすることも、医学的な判断をすることもできません。それでも、デザイナーとしてできることはないだろうかと考えるようになりました。
ハンディキャップや生活上の困難を抱える人が、必要な情報へたどり着きやすくなること。複雑な手続きや分かりにくい仕組みによって、さらに負担を抱えなくて済むこと。自分の状況を理解し、選択し、少しでも安心して行動できること。同じような悩みを抱えている人が、よりよく生きるために、微力であってもデザインを通じて関われるのではないか。それが、僕にとっての原点です。
「なんとなく使いにくい」「どこを見ればよいのか分からない」「間違えそうで不安になる」そうした感覚は、設計の入り口として大切です。しかし、それだけでは、なぜ変更する必要があるのかをクライアントや開発者へ説明できません。
誰が、どのような状況で困っているのか。その問題によって、何ができなくなっているのか。どのように改善すれば、その人の行動や生活を少しでも支えられるのか。個人の感覚として受け取った違和感を、他者と共有できる問題へ変え、検証し、改善する。そのための方法の一つが、ユーザビリティ評価なのだと思います。
最後に、鹿児島についての写真はしっかり撮っています。
