ワンポイント

使い勝手が悪くても「品質が良い」？

2026.10.02

ISO 9000の定義を読み解く

バグがない、欠陥もない。そんな製品は「品質が良い」と言えるのだろうか。品質マネジメントの国際規格ISO 9000の定義に照らすと、答えは少し意外なものになる。本稿では、品質の定義を言葉ごとに読み解き「使い勝手が悪くても品質が良い」と言える理由と、その裏に潜む落とし穴を解説する。

ISO 9000は品質をどう定義しているか

ISO 9000は、品質マネジメントの基本的な考え方と用語を定めた国際規格である。品質マネジメントシステムの要求事項を定めたISO 9001も、用語はこの規格に拠っている。日本語版はJIS Q 9000として発行されている。

ISO 9000は2026年5月に第5版が発行されたが、本稿では日本で広く使われているJIS Q 9000:2015の訳で紹介する。同規格は、品質を「対象に本来備わっている特性の集まりが、要求事項を満たす程度」と定義している。短い文だが、押さえるべき言葉が三つある。

一つ目は「本来備わっている特性」である。
特性とは「特徴付けている性質」のことで、機器であれば測定範囲や精度、耐久性などがこれに当たる。
規格の注記は、「本来備わっている」とは「付与された」とは異なり、対象の中に存在していることだと説明している。
さらに別の注記で、対象の価格のような付与された特性は、品質特性ではないとしている。
二つ目は「要求事項」である。品質の良し悪しは、製品単体で決まるのではなく、要求事項との関係で決まる。
三つ目は「程度」である。注記には、品質という用語は「悪い」「良い」「優れた」などの形容詞とともに使われることがあるとある。品質は、あるかないかではなく、どの程度満たしているかで語られるのである。

品質が良いとは「要求事項を満たしている」こと

この定義に従えば、品質が良いとは、製品の本質的な特性がひとまとまりとして要求事項を満たしている状態を指す。満たしていれば品質は良く、満たしていなければ品質は良くない。ここで注意したいのは「バグがない」「欠陥がない」ことと「ユーザーの要求に合っている」ことは別問題だという点である。

例えば、温度を記録するソフトウェアにバグが一つもなくても、顧客が求める記録の保存期間や出力形式に対応していなければ、品質が良いとは言えない。だからこそ、製品を開発する企業にとって大事なのは、ユーザーの業務をよく理解することである。ユーザーの業務に沿って製品を開発し、サービスを提供しなければならない。

使い勝手の悪さは品質と無関係なのか

では、使い勝手はどうか。筆者は講演で「使い勝手の良し悪しと品質の良し悪しは無関係である」と説明している。要求事項を満たしてさえいれば、使い勝手が悪くても、定義上は良い品質だと言えるからである。

例えば、操作画面が古めかしく手順も多いが、求められた測定を正確に行い、要求どおりの記録を残す機器があるとしよう。この機器は、定義に照らせば品質が良いことになる。逆に、どれほど操作が快適でも、求められた測定ができなければ品質が良いとは言えない。使い勝手を磨くことは顧客満足を高めるが、それは要求事項を満たしたうえでの話である。

ただし、ここには補足が必要である。規格でいう要求事項には、明示されたものだけでなく、通常暗黙のうちに了解されているニーズや期待、義務として要求されるものも含まれる。誰もが当然と考える最低限の使いやすさは、書かれていなくても要求事項になりうるのである。

また、医療機器では使いやすさが安全に直結する。国際規格IEC 62366-1は、安全に関わる医療機器の使いやすさ（ユーザビリティ）を製造業者が分析・評価するためのプロセスを定めている。正確に言えば「使い勝手は、要求事項に含まれていない限り、品質の良し悪しとは関係しない」ということになる。

落とし穴は「ユーザー要求そのものの誤り」

要求事項を満たしていれば品質が良い。この考え方には、大きな落とし穴がある。そもそもユーザー要求が間違っていることがあるのだ。

例えば、営業やマーケティングの担当者が集めてきたユーザー要求が、たまたま話を聞いた一部のユーザーの声にすぎないことがある。別の業界で集めた要求をもとに、同じ製品を製薬業界にも提供してしまうこともある。製薬業界には固有の要求がある。

例えばFDA（米国食品医薬品局）の規則21 CFR 11.10(e)は、電子記録の作成・変更・削除について、操作の日時を記録する監査証跡を求めている。記録を変更しても、以前の記録内容が見えなくなってはならないとも定めている。他の業界で集めた要求には、こうした項目が含まれていないかもしれない。

厄介なのは、この誤りが社内の検査では見つからないことである。検査は仕様どおりに作られているかを確認するものであり、仕様が現場に合っているかまでは確かめないからである。誤りは製品が顧客の現場で使われて初めて明らかになり、そのときの手戻りは大きい。

検証と妥当性確認（バリデーション）

ここで役立つのが、検証と妥当性確認の区別である。JIS Q 9000:2015は、検証を「客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること」と定義している。一方、妥当性確認（バリデーション）は「特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること」である。

検証が「仕様どおりに作ったか」を問うのに対し、妥当性確認は「意図した使い方に合っているか」を問うのである。料理にたとえれば、検証はレシピどおりに作ったかの確認であり、妥当性確認はそのレシピが食べる人に合っているかの確認である。だからこそ、ユーザー環境でのバリデーションが重要になる。

規格の注記も、妥当性確認のための使用条件は実環境の場合も模擬の場合もあるとしている。製品が、その製薬企業のプロセスに対して妥当かを実際に確認する。ソフトウェアであれば、CSV（コンピュータシステムバリデーション）と呼ばれる活動がこれに当たる。

筆者は、機器やソフトウェアを納める企業も、顧客のバリデーションに必要な情報を提供し、その結果を次の製品開発に生かすべきだと考える。例えば、顧客のバリデーションでは、機器の仕様書や試験の記録、ソフトウェアの変更履歴などを求められることがある。こうした資料をすぐに示せる企業は、顧客にとって安心して選べる取引先になる。

また、顧客のバリデーションで見つかった不一致は、自社がユーザー要求を読み違えていたことを知らせる貴重な情報でもある。要求事項を満たしているかを自社で確かめ、目的に合っているかを顧客とともに確かめる。この二つがそろって、初めて「品質が良い」と胸を張れるのである。