利用品質・ユーザビリティ(usability)・人間中心設計
コンピュータシステムは人間にとって役立つものであるべきですが、本当に役に立つシステム、人間に優しいシステムとして開発されているのでしょうか。
多くの企業で開発され、運用、保守されているシステムの使いやすさと、そのライフサイクルにおいて利用者・ユーザーを含めた人間中心の活動がなされているのかについては大きな課題があると思われます。
ここでは、システムまたはソフトウェア開発プロセスの視点からユーザビリティ（使いやすさ）を考察します。
■ユーザビリティ（使いやすさ）とは？■
「使いやすさ」という言葉だけを捉えると、完成した製品がどの程度使いやすいか？という一点だけを考えればよいと思いがちです。（私もそうだと思っていました。）
そのこと自体は一部間違いではありませんが、現在はもっと視点を広げて考える必要があるようです。
その理由は、使いやすさをある局面だけを見て判断することができないこと、そして利用する人や利用するための状況が変化すれば製品の「使いやすさ」が変化するためです。
さらに、外部環境（例えば新技術の出現など）が変化すると、それまで使いやすかった製品が、使いづらい製品になる可能性もあるからです。
→システムの使いやすさは、システムが持っている特性だけではなく、システムの外部環境が変化することで悪化する可能性があります。例：時間とともに、より便利に、より複雑に、より多くの機能を求められる
それらのことを包含して、「使いやすさ」とは以下の事項を含んだ総合的な概念で捉えられているようです。
・利用者の視点で製品を開発すること
・使いやすさを考慮した設計を行なうこと
・意図した使いやすさが組み込まれていることを評価すること
・使いやすさが維持できているかを監視し、継続的に製品を見直すこと |
■利用品質って何？■
ユーザビリティ（usability-使いやすさ）の特性がISO 9241-11で定義されています。
この規格ではユーザビリティを「特定の利用状況において、特定のユーザによってある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い」と位置づけています。
簡単に言えば、システムを利用する立場で捉えた品質が利用品質です。
その特性は以下の３事項となっています。
利用品質の特性 | 定義 |
| 有効性 (Effectiveness) | ユーザが目標を達成する上での正確さ、完全性。 |
| 効率性(Efficiency) | ユーザが有効性を満たして目標を達成する際に費やした資源。 |
| 満足度 (Satisfaction) | 製品を使用する際の、不快感のなさ、及び肯定的な態度。 |
また、ユーザビリティの定義に登場した”利用状況 (Context of use)”とは、「ユーザ、仕事、装置（ハードウェア、ソフトウェア及び資材）、並びに製品が使用される物理的及び社会的環境」となっています。
例えば、システムの利用状況には、どんな人が使うのか、その人たちのコンピュータリテラシー（使いこなし能力）はどの程度か、どんな場所で使うのか、どんな環境で使うのか、などが該当します。
■使いやすいシステムを実現・維持する－人間中心設計プロセス■
使いやすく、人間にとって役に立つシステムを実現し、維持するための方法論として「人間中心設計プロセス」が存在します。
これは「ISO13407:1999 （JISZ8530:2000）インタラクティブシステムの人間中心設計プロセス」にまとめられているものですが、その概要を下表に示します。
ＳＴＥＰ | 概要 |
| ※人間中心設計の必要性の特定 | 人間が利用して何かの結果や成果を得るためのシステムを開発する場合、（使う側の）人間の使いやいシステムを設計し、実装する必要があります。その必要性を特定し、ユーザー側、開発する側双方で認識を合わせることが重要になります。
人間中心設計の必要性認識がなければ、以下の人間中心設計活動の要素も不十分、不適切な活動になるでしょう。 |
| （１）利用状況の把握と明示 | システムを利用する環境や制約事項、想定する利用者の能力や特徴などを把握し、明示する |
| （２）ユーザーと組織の要求事項の明示 | システムを利用するユーザーや組織を特定し、そのユーザー・組織がシステムを利用する際に必要な要件（要求事項）を明示する
特にこの時点で「どこまでをシステムに委ね、どこまでを人間が対応するのか（＝機能配分）」を適切に見定める必要がある
（何でもITに委ねることが最適解にはならない） |
| （３）設計による解決案の作成 | ・これまでの経験や様々な情報源から取得される既存の知識・情報、多様な職種により設計（解決）案を検討し、提案する
・実際の設計作業によって要求事項を満たす（複数の）解決案を具体化する
複数（多く）の解決案が存在する場合は、選定基準などを定めて１つまたはいくつかの候補に絞り込む
シミュレーション・プロトタイプ・モックアップなどの手段により、設計案を試作することも考慮する
・ユーザーに設計案（解決案）を提供し、解決案に沿って想定される作業（又は作業の模倣）をしてもらう
・実際に作業をしてもらったユーザーから、設計（解決）案へのフィードバックを取得し、その結果から設計（解決）案を見直し、必要な場合変更を行なう
（目的達成までこれらの作業を繰り返す） |
| （４）要求事項に対する設計の評価 | 要求事項を満たす設計(解決）案になっているかどうかを評価する
途中途中の簡易な評価、部分的な評価から、専門家による評価・本番環境での妥当性確認、長期間のモニタリングまでを含むため、開発プロセス＋運用プロセスのどの段階でどのような評価を行なうのかを企画・計画時点で明確にし、実施する必要がある |
| ※特定ユーザー及び組織の要求事項を満足 | 人間中心設計活動（上記タスク(1)～(4)の繰り返しを含む）の結果、特定したユーザーと組織の要求事項を満足する |
■人間中心設計プロセスの期待効果■
・開発・保守作業における手直し・手戻りが最小化することによる生産性の向上
・利用者の学習時間、訓練・支援対応工数の最小化
・利用者の満足度向上
・システムを使うことで得られる効果（生産性）の最大化／システムを活用する組織の競争力向上