この記事はエンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar 2021の13日目です。

アドカレ経由で興味を持ってくださった方のために自己紹介をします。asazutaigaです。フロントエンドエンジニアをしています。

私が特に興味を持っているものは、人とシステムの境界面、すなわちユーザインターフェース一般です。もちろん、境界面を考えるにあたっては【人（あるいは使われ方、ビジネス）】と【システム】という「境界面で接する二項」についても熟知する必要がありますが、その圧倒的に異なる二項を境界面でどのように協調させてより高い効果を得るか、ということに一番関心があります。

アドカレの趣旨的には、より実務方面に依った「エンジニアとデザイナーの協働・歩み寄り」「エンジニアが画面デザインをどう勉強するか（あるいはその逆）」系のお話が多そうなので、また別の角度からデザインやエンジニアリングということについて切り込めないかなと思い、この記事を作成しています。（と言いつつ、読書ノートにいい感じの理由付けをしただけって感じもしますが…）

この記事では、樽本哲也『ユーザビリティエンジニアリング - ユーザエクスペリエンスのための調査、設計、評価手法』（2005初版, 2014第2版, オーム社。以下「本書」）を読んで、私なりに参考になったなと思う内容をメモふうに書いていきます。なお、引用は末尾括弧内にページ数を示します。その他の引用がある場合は適宜出典を示します。「いわゆるデザイン」（視覚的なデザイン）の話はほぼ出てこないのですが、ひとつのシステムを作っていくうえでの不易として、特にUI・UXに興味がある人にとっては充実した内容となっているので、読む価値はあるなと思いました。

Notes

ユーザビリティ

ユーザビリティの訳語として「使いやすさ」がよく使われます。ただ、「ユーザビリティ＝使いやすさ」と捉えていると、“ユーザに対する思いやり”や“ユーザフレンドリ”といった主観的な概念と混同してしまいます。つまり、ユーザビリティとはユーザにとって「あれば嬉しいけれど、なくても困らない」というレベルの要求であると誤解してしまうのです。（中略）しかし、ユーザービリティはもっと重大な意味を持っています。それは「使える」という意味です。つまり、「ユーザービリティに問題がある」ということは「使えない」という意味でもあるのです。(3-4)

きわめて重要な認識であるにもかかわらず、言われるまで強くは意識していませんでした。Usable=使えるなので当たり前なんですが、なんとなく「使いやすさ」の意味で使ってしまいがちなので、あるあるネタかもしれませんね。

ISO 9241でのユーザビリティの定義では、「効果＝ユーザが目標を達成できるかどうか」、「効率＝なるべく最短経路で目標を達成できるかどうか」、「満足度＝ユーザに不愉快な思いをさせていないかどうか」の3つを満たして、初めてユーザブルであるそうです（参考： ISO 9241-11のWikipediaリンク（英語））。この3項のいずれも欠けてはならないというのが重要そうですね。

システム要件の分類でよくつかわれる機能要件・非機能要件という分類よりも、この「効果」「効率」「満足度」のどれに対してどの要件が紐づくのか、といった脳内整理をする方が、最終目標を意識しながらより良いシステムを作れそうだなと感じました。

ユーザエクスペリエンス（UX）

（前略）仮にユーザビリティが満点であっても、その製品への評価は中程度にとどまるということです。（12）

ソフトウェアの場合も、見た目が魅力的な製品の方がユーザは使いやすく感じます。皮肉にも、どんなにユーザビリティを追求したとしても、それだけでは最高のユーザビリティは得られないということです。（12）

UXとは製品の開発が終わってから“上”に被せるものではありません。 製品開発の一番最初（企画段階）から地道に積み重ねていかない限り、優れたUXは実現できません。（16）

今となっては当たり前の知識のような気もしますが、改めて本書が2005年に国内で出版されているという事実に驚きを禁じえません。

ユーザの声

ユーザの声を聞くというのは、極論すれば単なる“ユーザ任せ”に過ぎません。ユーザから出された「〇〇が欲しい」といった明示的な要求にこたえるだけでは不十分です。ユーザ自身が気づいていないような暗黙の要求まで満たしてこそ、プロの設計者としての存在価値があるのです。（25）

本書はここ以外でも、徹底してエンジニア／デザイナーがユーザの言いなりにならないよう戒めます。

現実世界では、「ここを少し変えてくれたら良くなりますよね？」という類の具体的な要望がやってくることが非常に多いです。仮にそのような要望があったとしても、一度エンジニア／デザイナー目線で根本にある問題へと立ち返り、それを解決する方法を考える、というプロセスを挟むのは大事だということですね。

アンケート

アンケートは量的調査の手法です。自社製品に対するユーザ全体の満足度などを調べるためには適した手法ですが、個々のユーザの個別の体験をこと細かく調べるための手法ではありません。（27）

直近でとある社内システムのリプレイスを担当しているのですが、先日、「既存のシステムの中で、どの画面を眺めている時間が長いか？」というアンケートをユーザに対して投げかけました。これは、機能開発のロードマップを作っていくうえで、まず一番利用頻度の高い機能を作って、触ってもらいながら改善していくのが適切であろうと考えての内容です。システムのコアな部分の設計にアンケートを用いるのは恐らく間違いですが、こうした開発計画の方針を立てるような場面ではアンケートも使えるなという印象を持ちました。（要するに、どんな調査手法も使いどころを間違えてはいけないということですね）

「師匠と弟子（Master/apprentice）」

「師匠と弟子」という人間関係モデルに基づいたユーザインタビュー手法の解説です。

この手法ではインタビューアを弟子、ユーザを師匠と見立てて、師匠の体験を弟子に“継承”します。基本プロセスは以下のようになります。

1. インタビューアはユーザに“弟子入り”する。
2. ユーザは仕事を見せながら説明する。
3. インタビューアは、不明な点があればその場でどんどん質問する。
4. 一通り話を聞いたら、インタビューアは理解した内容をユーザに話して、間違ってないかどうかチェックしてもらう。(31)

私の職場でも、エンジニアがユーザ（＝オペレーションスタッフ）にある意味で「弟子入り」する業務体験を実施しています。ただし目的は少し違って、「業務知識を得て、システムの理解に役立てよう」というのが趣旨になっています。それはそれで（例えばジョインしたばかりのエンジニアが業務について知るためなど）有効だなと感じています。

ただ、長く勤めてから同じような業務体験、あるいはユーザインタビューを実施する場合、エンジニア／デザイナーは当然そのシステムを作っている側なので、詳しくて当たり前だという前提ができてしまいそうなのが、この手法の難しいところです。エンジニア／デザイナー側は、無知のベールと言いますか、一度自分の知識を横に置いてはじめてそのシステムを触る人のつもりで教えを請うのがよさそう。難しいですが。

インタビュー

ユーザに会って、いきなりインタビューを始めようとしても上手くいきません。ユーザとインタビューアの間にまだ 「信頼関係（ラポール）」 が構築されていないからです。(53)

ユーザが心配しているのは、「果たして自分は役に立つのだろうか？」ということです。（53）

これは、社内で既に気心の知れている相手に対してインタビューする場合であってもそうなんだろうなと思います。イントロで、インタビューの目的と、どういうスタイルでインタビュー進めるのか（つまり、根掘り葉掘り聞いていきますよ、ということ）を説明して、不安を払拭する必要がありそうです。

ディティールの度合がわからないと、ユーザは差し当たり抽象的なレベルで話を終えてしまいます。そんな時はディティールの度合を具体的に指示すると、ユーザはインタビューアの要求水準を理解して具体的な話を始めてくれます。

＜質問例＞

• 「一番最近〇〇したときのことを教えてください」
• 「差し支えなければ、ここで△△を見せていただけませんか」
• 「最初はどうするのですか。その次は（その前は）どうするのですか」
• 「××ができないときはどうするのですか」（56）

消化不良のインタビューにしないために大事なコツだと思います。

Tプロトタイプ

『水平プロトタイプ』とは、ウェブサイトのトップページと第一階層のページだけを用意するようなプロトタイプです。（中略）一方、『垂直プロトタイプ』とは、特定の機能だけを持ったプロトタイプのことです。（中略）この2つを組み合わせると、実際にユーザが作業を行ってみることができるようになります。このように、 ある程度の質と深さを持ったプロトタイプを『Tプロトタイプ』 といいます。(104-105)

このようなクリック操作中心のプロトタイプを制作するときに一番大切なのは、「すべてのリンクやボタンをクリックできるようにすること」です。（109）

これはめちゃくちゃ良いプロトタイピングの具体的な方法論ですね。プロトではどうしても単機能に絞って開発をすることになりますが、実際にユーザに触ってイメージをつかんでもらう上でこうした配慮は必要そうですね。（なお、クリック後の遷移先は、共通のダミーページでもよいそうです。）

ヤコブ・ニールセン

ヤコブ・ニールセンが提唱した「10ヒューリスティック」と呼ばれるユーザビリティについての一般的なルールについても評価手法の中で触れられています。

外部の評価者が綿密にこれらの基準をクリアしているかを評価する、というのはあまり現実的ではないので、エンジニア／デザイナーが自分の普段作っているシステムを見つめなおす際の「眼鏡」として使うくらいがいいかもしれませんね。

1. システム状態の視認性を高める (Visibility of system status)
2. 実環境に合ったシステムを構築する (Match between system and the real world)
3. ユーザーにコントロールの主導権と自由度を与える (User control and freedom)
4. 一貫性と標準化を保持する (Consistency and standards)
5. エラーの発生を事前に防止する (Error prevention)
6. 記憶しなくても、見ればわかるようなデザインを行う (Recognition rather than recall)
7. 柔軟性と効率性を持たせる (Flexibility and efficiency of use)
8. 最小限で美しいデザインを施す (Aesthetic and minimalist design)
9. ユーザーによるエラー認識、診断、回復をサポートする (Help users recognize, diagnose, and recover from errors)
10. ヘルプとマニュアルを用意する (Help and documentation)

（出典：https://ja.wikipedia.org/wiki/ヤコブ・ニールセン

また、本書の後半では、ニールセンの以下のような面白い別の経験則も語られます。

ヤコブ・ニールセンはテストする人数と発見できるユーザビリティ問題の数に関する公式を明らかにして、 「5人のユーザでテストをすれば、ユーザビリティ問題の大半（約85％）を発見できる」 という説を唱えました。（171）

「じゃあ5人分だけテストして見つかった問題をすべて直せばいいよね」という単純な話ではないようですが、ユーザテストを実際に実施していくにあたってはかなり前向きになれる数字ですね。（わりと経験則での数字なので微妙な気持ちになるのも事実です。）

感想・まとめ

後半、ユーザテストの具体的な手法についての部分は現代だと実際に適用するのは難しいかもしれませんが（なんならLogRocketとか道具の面では発達しているので選択肢は圧倒的に増えてますね）、特に前半部の理論面で勉強になることが多かった印象です。より現代的手法に寄せたUCD言論がそろそろ登場してきてもいい頃なのかなみたいなことも感じました。

あと、ニールセンの話は面白そうなので、本人の著作も読んでみようかなと思います。（訳書は『モバイル・ユーザビリティ』くらいしか現行でぱっと安く読めるのがなさそう。原著のほうが安い）