【プログラマが知るべき97のこと – #03】あなたはユーザーではない：推測せず、行動を観察する

概要

開発者は、自分にとって分かりやすい操作であれば、ユーザーにとっても簡単なはずだと考えがちです。しかし、ユーザーは異なる知識や経験、習慣を持っています。実際の操作を観察することで、思い込みでは気づけない問題を発見し、より使いやすいソフトウェアを設計できます。

なぜ開発者はユーザーの行動を誤解してしまうのか？

私たちは、自分と他人が同じように考え、行動すると思い込んでしまうことがあります。心理学では、この傾向を**「偽の合意効果（False Consensus Effect）」**と呼びます。

ソフトウェア開発では、この思い込みによって、開発者には直感的でも、ユーザーには分かりにくいインターフェースが生まれることがあります。

開発者は日常的にコンピューターを使い、画面の構成や操作パターンに慣れています。問題が起きても、別の方法を試して解決策を見つけることができます。

しかし、一般のユーザーが同じ知識や経験を持っているとは限りません。ソフトウェアの内部構造を理解しているわけでもなく、必ずしも知りたいと思っているわけでもありません。

ユーザーが求めているのは、ソフトウェアの仕組みを理解することではなく、自分の仕事を完了することです。

開発者には明らかなボタンでも、ユーザーはその意味に気づかないかもしれません。

その原因はユーザーの知識不足ではなく、開発者の思い込みを前提とした設計にある可能性があります。

大切なのは、「開発者自身がユーザーではない」ということです。

ユーザーが実際に何をするのかを観察する

ユーザーを理解するための有効な方法は、実際の業務に近い課題に取り組む様子を観察することです。

例えば、スプレッドシートを開発しているとします。

「セルを選択してSUM関数を入力してください」と指示する代わりに、次のような課題を与えます。

「先月の支出の合計を計算してください」

後者は目的だけを伝え、操作方法を指定していません。

そのため、ユーザーがどの機能を選び、どこで迷い、どのように問題を解決するのかを観察できます。

観察中は、ユーザーに考えていることを話してもらいましょう。ただし、途中で操作に割り込んだり、すぐに手助けしたりすることは避けます。

ユーザーが迷ったときには、次のように考えてみてください。

• なぜ、この操作を選んだのか？
• どのような結果を期待していたのか？
• なぜ、別の選択肢に気づかなかったのか？

こうした場面には、インターフェースの問題を発見するためのヒントがあります。

目的はユーザーの操作能力を評価することではなく、ソフトウェアが自然な行動を支援できているかを確かめることです。

ユーザー観察から学べる4つのこと

1. ユーザーは似たような間違いをする

複数のユーザーに同じ課題を与えると、似た手順で操作し、同じ場所で間違えることがあります。

多くの人が同じボタンを見落としたり、同じ説明を誤解したりする場合、問題はユーザー個人ではなく、インターフェースの設計にあるかもしれません。

だからこそ、「ユーザーはこう操作するはずだ」と会議で推測するだけでは不十分なのです。

実際の行動を観察し、繰り返し発生する問題を改善することが重要です。

2. 困ったとき、ユーザーの視野は狭くなる

開発者は問題が発生すると、別のメニューを開いたり、ほかの操作を試したりします。

しかし、一般のユーザーは操作に行き詰まると、問題が起きた場所に注意を集中させることがあります。

その結果、画面の別の場所にある解決策を見つけにくくなります。

そのため、必要な説明は問題が発生した場所に表示することが重要です。

例えば、入力形式が間違っている場合、別のヘルプページに説明を用意するよりも、入力欄の近くにエラーメッセージを表示する方が分かりやすいでしょう。

ツールチップや状況に応じたガイドは、ユーザーが作業を中断せずに問題を解決する助けになります。

3. ユーザーは効率より慣れた方法を選ぶ

開発者はショートカットや効率的な操作を好みます。しかし、ユーザーにとって最も重要なのは、作業を無事に終えることです。

一度うまくいく方法を見つけると、より速い方法があっても、その操作を使い続けることがあります。

例えば、キーボードショートカットを使わず、毎回メニューからコピーや貼り付けを行う人もいるでしょう。

そのため、多くの操作方法を用意するよりも、まずは誰でも見つけやすく、分かりやすい基本操作を提供することが大切です。

ショートカットは便利ですが、基本的な使いやすさの代わりにはなりません。

4. ユーザーの言葉と行動は必ずしも一致しない

ユーザーへのヒアリングや機能要望の収集は重要です。しかし、ユーザーが説明する内容と、実際の行動が異なることもあります。

例えば、便利そうだと思って新しい機能を要望しても、実際にはほとんど使わない場合があります。

これはユーザーの意見を無視すべきだという意味ではありません。

重要なのは、ユーザーの言葉だけで判断せず、実際の行動と照らし合わせることです。

両者に違いがある場合、その理由を確認することで、本当のニーズを理解しやすくなります。

観察結果をソフトウェア設計に活かす

観察で得た気づきは、具体的な設計改善につなげる必要があります。

これらの考え方は、要件定義やソフトウェア開発にも役立ちます。

仕様どおりに動作する機能でも、ユーザーにとって使いにくい場合があります。

技術的に正しいことと、使いやすいことは同じではありません。

VAONのようなソフトウェア開発チームにとっても、必要な機能を把握するだけでなく、ユーザーが日常業務でどのようにシステムを利用するのかを理解することは重要です。

開発時には、次の問いを意識することが役立ちます。

「ユーザーは迷わず、無理なく目的を達成できるだろうか？」

実際の操作を観察することで、思い込みだけでは得られない答えを見つけられます。

まとめ：推測する前に観察しよう

開発者とユーザーでは、ソフトウェアに対する知識や経験が異なります。

開発者にとって当たり前の操作でも、ユーザーには分かりにくいことがあります。

ユーザーを観察すれば、繰り返される間違いや、操作に迷う原因、想定外の行動を発見できます。

ユーザーの行動を一日中議論するよりも、実際の作業を一時間観察する方が、多くの気づきを得られる場合があります。

優れたソフトウェアは、開発者の想像ではなく、ユーザーの実際の行動を理解したうえで設計されるものです。

「プログラマが知るべき97のこと」シリーズについて

本シリーズでは、プログラマーに役立つ技術的な知識だけでなく、問題解決の考え方やソフトウェア開発における実践的な教訓を紹介します。

本記事は、Giles Colborne（ジャイルズ・カルバン） 氏による『プログラマが知るべき97のこと』の第03項目、「ユーザが何をするかを観察する（あなたはユーザではない）」 を参考に、その中心的な考え方を整理したものです。

原文のメッセージを大切にしながら、ソフトウェア開発の現場で活かせるように解説しています。

VAONのソフトウェア開発サービスについてはこちら