ユーザビリティとは｜「使いやすさ」を要件・受入基準にどう書くか

社内システムのリニューアルで現場にヒアリングをすると、最も多く返ってくる声が「今のシステムが使いにくい」です。そこで要件定義書に「ユーザビリティの高いシステムとすること」と書いたところ、ベンダーから「具体的にはどういう状態を指しますか」と差し戻された、という場面は珍しくありません。

やりとりが止まってしまう理由は、発注側の理解不足ではありません。「使いやすさ」は、測り方を決めない限り、誰が読んでも同じ意味にならない言葉だからです。測れない言葉のまま仕様が確定すると、完成後に「現場が使いにくいと言っています」と伝えても「ご提示の要件は満たしています」と返され、手直しは追加見積として扱われます。検収の場で発注側が不利になる構造は、要件を書いた時点ですでに決まっています。

一方で、ユーザビリティは本来「主観」ではありません。国際規格・日本産業規格はどちらも、利用者と利用状況を特定したうえで「目標をどれだけ達成できるか」の度合いとして定義しています。つまり、誰がどの業務をどんな環境で行うのかを決めれば、達成率や所要時間として測れる対象になります。「使いやすい」を測れる言葉に翻訳する作業は、専門知識がなくても手順化できます。

本記事では、ユーザビリティとは何かを規格の定義から最小限に押さえたうえで、評価指標の選び方、要件定義書への書き方 4 ステップ、受入基準への落とし込み、ユーザビリティテストの費用範囲、ベンダーへの確認質問例までを、発注担当者の視点で順に解説します。読み終えたときに、要件定義書のどこに何を書けばよいかが決まっている状態を目指します。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ユーザビリティとは？ISO・JISの定義と評価の3つの観点

ユーザビリティとは、「使いやすさ」を漠然と指す言葉ではなく、特定の利用者が特定の状況で目標をどれだけ達成できるかを表す度合いです。ここでは発注の会話で必要な範囲に絞って定義を押さえます。

ISO・JISの定義と有効性・効率・満足度の3観点

日本産業規格 JIS Z 8521:2020 は、ユーザビリティを「特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い」と定義しています（JIS Z 8521:2020）。対応する国際規格は ISO 9241-11:2018 で、内容は同じ 3 要素で構成されています（出典: ISO 9241-11:2018、2018年）。

この定義で重要なのは、次の 2 点です。

3 つの観点は次のように整理できます。

「使いやすいシステム」という表現がベンダーに伝わらないのは、この 3 観点のどれを指しているのかが示されていないためです。逆に言えば、観点を選んで数値に置き換えれば、要件として成立します。

ニールセンのユーザビリティ5要素を表で把握する

実務では、ユーザビリティ研究者ヤコブ・ニールセン氏による 5 つの品質要素も広く参照されます（Usability 101: Introduction to Usability）。規格の 3 観点より細かく、どこを測るべきかの当たりをつけるのに向いています。

社内業務システムの場合、毎日使う担当者と月末だけ使う担当者が混在します。どちらを重視するかで要件が変わるため、表のどの行を優先するのかを社内で決めておくと、要件定義の議論が速く進みます。

ユーザビリティとUI・UX・アクセシビリティの違い

ベンダーとの打ち合わせで用語が混ざると、合意したつもりの内容がずれます。4 語の関係を最小限で押さえておきましょう。

要件定義書に書くときは、UX のような広い語を避け、ユーザビリティとアクセシビリティに分けて記述するほうが合否の判断がしやすくなります。発注の流れや費用相場から整理したい場合は、UIUXデザインの発注についてまとめた記事も参考になります。

「使いやすいシステム」と要件に書くと検収で何が起きるか

定義を押さえたうえで、測れない言葉のまま進めた場合に何が起きるかを時系列で見ておきます。ここを理解しておくと、後半の要件化の意味が変わって見えてきます。

検収で「使いにくい」が通らない理由

検収は、契約に書かれた基準を満たしているかを確認する手続きです。したがって、合否の判断材料は契約書・要件定義書・受入基準に書かれている内容に限られます。

「ユーザビリティの高いシステムとすること」という記述には、合否を分ける境界線が存在しません。境界線がない要件は、実務上「ベンダーが提示した画面設計のレビューを発注側が承認した時点で満たされた」と解釈されます。画面設計書に承認印を押していれば、その後に出た「使いにくい」は要件未達の根拠になりません。

発注側が不利になるのは、主張が弱いからではなく、主張を支える基準が最初から存在しないからです。

手直しが追加費用になる分岐点

完成後の手直しが無償対応になるか追加見積になるかは、ほぼ次の 1 点で分かれます。

「3 画面の入力を 1 画面にまとめてほしい」という要望は、要件に画面数や所要時間の基準がなければ、後者に分類されます。要件定義の段階で所要時間や操作ステップ数に触れていたかどうかが、後の交渉力をそのまま決めます。

現場の「使いにくい」を翻訳せずに進めた場合のコスト

要件に翻訳されなかった現場の声は、どこにも記録されないまま仕様が確定します。その結果として起きやすいのが、「納品されたが現場が旧システムの運用を続けている」という状態です。

この状態のコストは、追加改修費だけではありません。並行運用による二重入力、利用率が上がらないことによる投資回収の遅れ、次回の社内稟議が通りにくくなる影響まで含まれます。要件化の手間は、これらと比較して判断する対象です。

ユーザビリティを測る評価指標（タスク達成率・所要時間・SUS）

要件に書くためには、先に測り方を決める必要があります。発注担当者が扱える指標は、行動から測るものと、主観を数値化するものの 2 系統に整理できます。

行動で測る4つの指標

専門的な計測環境がなくても、次の 4 指標は社内で取得できます。

このうち最も扱いやすいのがタスク達成率です。業務を完了できたかどうかという二値で判定できるため、合否の基準を書きやすく、ユーザビリティ指標の中でも基本に位置づけられています（Success Rate: The Simplest Usability Metric）。

所要時間を指標に使うときは、平均値だけでなく中央値も見てください。一部の利用者が極端に時間をかけると平均が引っ張られ、実態が見えにくくなります。

主観を数値化する指標（SUS）の読み方と基準値

満足度のような主観も、標準化されたアンケートを使えば数値として扱えます。代表的なものが SUS（System Usability Scale）です。10 問・5 段階で回答し、0〜100 に換算します。

複数の研究を集計した結果では、平均スコアは 68 とされており、68 を上回れば平均以上、下回れば平均以下と解釈されます（Measuring Usability with the System Usability Scale (SUS)）。ただし 0〜100 のスコアは百分率ではないため、「68 点だから 68% の達成度」という読み方はできません。あくまで他システムと比較するための目安として扱ってください。

発注時には、SUS を単独の合否基準にするよりも、タスク達成率などの行動指標と組み合わせるほうが扱いやすくなります。主観スコアは回答者の構成によって振れやすく、1 点差の議論に意味を持たせにくいためです。

目標値は現行システムの実測から決める

指標を選んだあと、多くの発注担当者が止まるのが「何%にすればよいか分からない」という点です。ここでゼロから数字を作る必要はありません。現行システムで同じ業務を測り、その実測値を出発点にします。

手順は次の通りです。

1. 対象業務を現行システムで 3〜5 名に実施してもらい、所要時間と完了の有無を記録する
2. 記録から現状値を出す（例: 受注登録の平均所要時間 7 分、達成率 60%）
3. 新システムの目標値を現状値から設定する（例: 4 分以内、達成率 90% 以上）
4. 測定条件をメモに残す（対象者の習熟度・使用端末・データ件数）

この方法なら、根拠を問われたときに「現行システムの実測に対して何割の改善を求めている」と説明できます。目標値の妥当性をベンダーと議論する土台にもなります。

ユーザビリティを要件定義書に書く4ステップ

測り方が決まれば、要件定義書に書けます。ここでは非機能要件として記述する手順を 4 段階に分けて示します。

ステップ1 代表タスクを3〜5個に絞る

全画面・全業務にユーザビリティ要件を設定すると、測定も検収も現実的に回りません。業務のうち、次の条件に当てはまるものを 3〜5 個選びます。

• 利用頻度が高い（毎日・毎週発生する）
• 利用者数が多い（部門横断で使う）
• 現場の不満が集中している
• 止まると業務影響が大きい

例えば受注管理システムなら、「受注を新規登録する」「受注内容を修正する」「当日出荷分を一覧で確認する」といった粒度です。画面名ではなく、業務として完結する単位で切り出すと、後の測定がしやすくなります。

ステップ2 対象利用者と利用状況を特定する

規格の定義が「特定のユーザ」「特定の利用状況」を前提にしている通り、ここを書かないと要件が成立しません。タスクごとに次の 4 点を添えます。

「電話応対と並行」のような利用状況は、画面設計の判断に直接影響します。発注側しか知り得ない情報なので、要件に明記する価値が高い部分です。

ステップ3 非機能要件として指標と目標値をセットで書く

ここが要件定義の中心です。指標と目標値を必ずセットにし、測定条件まで含めて 1 文で書きます。

3 行目のように「誰が・何を・どの条件で・どの数値で」まで入ると、ベンダーは見積時に必要な工数を判断でき、発注側は検収時に合否を判定できます。要件定義書全体の構成や進め方はRFPの書き方と合わせて整えると、提案内容の比較もしやすくなります。

ステップ4 過剰要求にならない線引き

厳しい基準を書けばよいというものではありません。次のような要求は、達成の確認コストや作り込みの工数が大きく、見積を押し上げます。

線引きの判断軸は「その基準を満たせなかったとき、本当に受け入れられないのか」です。受け入れられる水準であれば、それは合否基準ではなく努力目標として別枠に書くほうが、見積と交渉の両面で扱いやすくなります。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ユーザビリティを受入基準に落とし込む書き方

要件定義書に書くだけでは、検収で使える状態になりません。受入基準として、測り方と合否の判定方法まで定義する必要があります。

受入基準に必要な4要素

受入基準は、次の 4 要素が揃って初めて機能します。

測定者を決めていないと、受入テストの直前に「誰が被験者を集めるのか」で止まります。発注側が人を出すのであれば、必要人数と拘束時間を要件に書き、スケジュールにも反映しておきましょう。

契約書・検収条件への紐づけ方

受入基準は、契約書の検収条項から参照できる状態にしておきます。実務では次の形が扱いやすいです。

1. 要件定義書の末尾または別紙に「受入基準一覧」を作り、タスクごとに前述の 4 要素を表で記載する
2. 契約書の検収条項で、その別紙を合否判定の根拠として引用する
3. 検収の期間・実施回数・判定者を契約書に書く

別紙に切り出しておくと、要件定義の確定後に数値を調整する場合も、契約書本文を触らずに改訂できます。検収そのものの進め方は検収・受け入れテストの進め方にまとめた手順も確認してください。

合格しなかった場合の扱いを先に決める

受入基準を決めても、測った結果が基準を下回る可能性は残ります。この場合の扱いを事前に決めておかないと、検収期間中に交渉が始まり、稼働予定日が崩れます。

「条件付き検収を認めるか」は、稼働日が固定されている案件では特に重要です。認める場合は、残課題の是正期限と、期限を過ぎた場合の扱いまで書いておきます。

ユーザビリティテストの費用と範囲はどこまで必要か

受入基準に測定を含めると、「それは高額なテストを別途発注することになるのか」という疑問が出てきます。ここは範囲の分け方で大きく変わります。

ユーザビリティテストとは何をするのか

ユーザビリティテストは、対象の利用者に実際の業務タスクを実施してもらい、完了できるか・どこで迷うかを観察する手法です。アンケートで感想を聞く調査とは異なり、行動を見るため、具体的な改善箇所が特定できます。

人数については、少人数でも主要な問題の多くを検出できるという考え方が知られています。ニールセン氏は、5 名のテストで多くの問題を発見でき、大規模な 1 回よりも少人数のテストを複数回繰り返すほうが効果的だと述べています（Why You Only Need to Test with 5 Users）。この見解には議論もありますが、「最初から大規模に測らなくてよい」という判断の根拠にはなります。

見積に含める範囲と費用が変わる条件

ユーザビリティテストの費用は、作業項目のどこまでを委託するかで変わります。見積を読むときは、次の内訳が含まれているかを確認してください。

費用が大きく変わる条件は、被験者を外部から集めるか、プロトタイプを用意して開発前に測るか、記録環境（録画・視線計測など）をどこまで整えるかの 3 点です。社内利用者を対象とした業務システムであれば、外部リクルーティングは不要なケースが多くなります。

自社でできる範囲・ベンダーに任せる範囲の分け方

全部を委託する前提を置かず、次のように分けると現実的な規模に収まります。

• 発注側: 代表タスクの選定、被験者（社内利用者）の手配、受入テストでの測定立ち会い
• ベンダー側: 画面設計段階でのプロトタイプ提示、設計レビューの実施、指摘を踏まえた改修
• 重要タスクのみ外部委託: 利用者数が多く影響範囲の大きいタスクに限り、専門会社の分析を入れる

重要なのは、受入テストでの測定は「別途のユーザビリティテスト発注」ではなく、受入基準に沿った確認作業として設計できるという点です。測り方を要件で決めておけば、検収の一部として実施できます。

ユーザビリティ要件でベンダーに確認する質問例

ここまでの内容を次の打ち合わせで使える形にまとめます。そのまま読み上げられる質問と、回答の読み取り方をセットで示します。

要件・受入基準について確認する質問

体制・プロセスについて確認する質問

回答の読み取り方

質問への答え方には、傾向が出ます。判断材料として次のように読み取れます。

最後の行のように、要件に異議を示してくる回答は否定的に受け取る必要はありません。達成コストを踏まえた代替案が出てくるのは、要件を読み込んでいる証拠でもあります。

リリース後にユーザビリティを改善する運用と保守契約

要件と受入基準を整えても、稼働後に「使いにくい」が出てこないわけではありません。実際の業務量やデータ件数は、テスト時の条件とずれるためです。一度で完璧にする前提を置かず、改善の経路を用意しておきます。

受入後に出た「使いにくい」の切り分け

稼働後の指摘は、まず次の 3 つに分類します。分類しないまま改修を依頼すると、費用負担の議論が毎回発生します。

分類の判断は、受入基準一覧と検収記録を参照して行います。検収時の測定結果を残しておくことが、この判断を可能にします。

使いにくさを検知する運用

現場の声が上がってくるのを待つのではなく、検知できる仕組みを運用に組み込みます。

• 操作に関する問い合わせを件数と内容で記録し、集中している画面を特定する
• 主要タスクの処理件数・所要時間を定期的に確認し、受入時の数値と比較する
• 稼働 1 か月後・3 か月後に、現場への短いアンケートを実施する
• 入力エラーの発生箇所をログで把握し、項目単位で確認する

とくに問い合わせの記録は、追加の計測を仕込まなくても始められます。どの画面で何件発生しているかが分かれば、改善の優先順位を数値で説明できます。

保守契約に改善工数を含めるかの判断

保守契約を「障害対応のみ」で結ぶか、改善工数を含めるかは、稼働後の状況に大きく影響します。判断の目安は次の通りです。

改善工数枠を持つ場合は、枠の使い道を誰が決めるのか（発注側の優先順位付けの手続き）もあわせて決めておくと、枠を使い切れないまま期間が終わる事態を避けられます。

まとめ：ユーザビリティは「測れる言葉」に翻訳して発注する

ユーザビリティとは、特定の利用者が特定の状況で目標を達成できる度合いです。主観的な感想ではなく、利用者と利用状況を決めれば測れる対象になります。「使いやすいシステムにしてほしい」が通らないのは要望が間違っているからではなく、測り方が決まっていないためです。

発注担当者が取るべき流れは、次の 4 段階に整理できます。

1. 代表タスクを 3〜5 個に絞り、対象利用者と利用状況を特定する
2. タスク達成率・所要時間などの指標と目標値をセットで要件定義書に書く（目標値は現行システムの実測から決める）
3. 受入基準として「対象タスク・測定方法・合格ライン・測定者と時期」の 4 要素を別紙にまとめ、契約書の検収条項から参照する
4. 打ち合わせで指標・測定負担・是正範囲をベンダーに確認し、回答から合意の度合いを読み取る

次の一手は、要件定義書に 1 行追加することから始められます。現場の不満が最も集中している業務を 1 つ選び、現行システムで所要時間と完了の有無を 3 名分だけ測ってみてください。その実測値を使えば、「このタスクを◯分以内・達成率◯% 以上で完了できること」という 1 文が書けます。1 行が書ければ、残りの代表タスクも同じ型で展開できます。

要件定義や発注条件の整理をまとめて進めたい場合は、お役立ち資料に発注担当者向けの資料を公開しています。社内検討の下敷きとしてご利用ください。

ユーザビリティ要件や受入基準の書き方について個別に相談したい場合は、お問い合わせフォームからご連絡ください。要件の整理段階からのご相談にも対応しています。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。