連載の初回にソフトウェアテストの4つの分類をご紹介しました。今回は品質の観点から分類されるテストの中のユーザビリティテストについてご紹介します。

ユーザビリティテストとは？

ユーザビリティテストとは，ソフトウェアの使いやすさを確認するテストです。

皆さんが普段利用されているソフトウェアで，使いにくいと感じることもあるかと思います。機能要件は確かに満たされているけれども，実際使ってみると使いにくい場合があります。使い方がわからずあきらめてしまう場合もあるでしょう。利用者としてはそのソフトウェアは使えないも同然と受け取られてしまいかねません。

機能は豊富だが，使いにくくて誰も利用していないのでは，機能の目的を果たせません。有効に利用されなければソフトウェア開発に対する費用対効果が出てきません。

このようなことが起こらないよう，使いやすさを確保することを重視するケースが増えてきています。ソフトウェアの生産性が向上し，機能要件を満たしていることがあたりまえとなった今，使いやすさの重要性が増しているのです。

そもそもユーザビリティって？

さて，そもそもユーザビリティとは一体何でしょうか。ユーザビリティは，日本語では「使いやすさ」と表現されます。

ソフトウェアのユーザビリティが悪いとか，使いにくいと言う人はいますが，具体的にどう悪いのか説明できる人は少ないのではないでしょうか。「ある画面のボタンが使いにくい」といった場合，ボタンの形が悪いのか，ボタンの色が悪いのか，ボタンのラベルが悪いのか，さまざまな問題が考えられます。つまり，使いにくさの中にはさまざまな原因が存在すると考えられます。

また，テストでは結果を客観的に示す必要があります。ユーザビリティが悪いといった場合にどの部分を指しているのか他の人が理解し，改善につなげられるようにしておかなければなりません。

そのためには，結果を客観的に判断する評価軸が必要になります。

ユーザビリティの評価軸

ここでは比較的一般的な評価軸としてニールセンの10原則をご紹介します。ニールセンはユーザビリティの分野の世界的権威です。10原則はこの分野ではスタンダードとも言えますので，ここでご紹介させていただきます。

ここに紹介するのはあくまで原則です。実際のテストの際にはソフトウェアの特性などに合わせて具体化しチェックリストレベルにするのが良いでしょう。

原文はこちらにあります。

• Heuristics for User Interface Design

各見出しの下に，原文を筆者が意訳したものを載せています。

[1]システム状態の視認性を高める
（Visibility of system status）

《システム上で何が起こっているのか，適切な時間の範囲内で適切なフィードバックをユーザに通知しましょう》

この観点は，システム上の状態をユーザが確認できる手段を示すことにあります。図2内にある①のように，業務の送信ボタンを押したあと，次の画面が開く間に何も表示がないと，ユーザは通信に問題があったのか，サーバで処理中なのかがわかりません。ユーザによってはブラウザの戻るボタンを押して，再び送信ボタンを押す可能性もあります。サーバで処理中であれば，そのことを画面に表示するなどして，ユーザがその時々のシステムの状態を把握できるようなしくみを設けることが大切です（図2の②）。また，処理が完了した旨を通知することも大切なフィードバックの要素です。

[2]実環境に合ったシステムを構築する
（Match between system and the real world）

《システム上では，普段ユーザが利用していたり，聞き慣れている言葉や言い回しを用いましょう。システム指向の用語を用いてはいけません。現実の環境の慣習に従い，現実世界の順序を守り，かつ論理的な順序を持たせましょう》

「聞き慣れている言葉や言い回しを用いる」というのは，ユーザが理解できる言葉でシステムを作るということです。たとえば，ユーザが項目欄に住所を入力して，次の画面へ遷移しようとしたときに，ボタンに書かれたラベルの意味が理解できず，躊躇してしまうような場合です（図3の①）。

図中のボタンの「入力」は，これから何か情報を書き込むときに用いる意味で使うにもかかわらず，入力内容を送信する意味で用いています。画面上で入力した情報をシステムに「入力」するので，ボタンのアクション時の意味は合っているかもしれません。しかしユーザの行動から考えると，入力した情報をサーバに送る，または次の画面へ移動するという意味のラベルにするほうがわかりやすいといえます。ですからこの場合は，入力後に入力情報の確認画面へ遷移することを想定して，図3の②のような「次へ」ボタンが適当です。