品質が良いシステムとは何か
品質が良いシステムとは何か、考えたことがあるだろうか。
品質の定義をWikipediaで確認すると、下記記載となっている。
ISOやJISの定義する狭義の品質という意味であれば、提供者又は需要者が定めた仕様から逸脱していないという事である。広義の品質(quality)は非常に広範な概念を含む語であり、一概に定義づけることは難しいが、おおよそ、提供される製品やサービスについて、買い手側である顧客（消費者）が求める特性との合致度と考えられる（合致度が高ければ品質が高いといわれる）。また、上質、すばらしい、高級と消費者が感じれば品質が高いと考えられる。
つまり、システムの品質が良いといった場合、システムが提供する機能が、顧客が定めた仕様(＝要件)を満足している、ということとなる。
要件とシステム提供機能の関係
ここで問題になるのが、顧客の要求が明示されていないケースだ。よくあるのが、いざ使ってみて、なんだか使いづらいというクレームだ。いったん、顧客の要件とシステムが提供する機能の合致度合いにより、パターンを分けてみる。
図1は、要件とシステム提供機能の関係をまとめた図である。図中に番号を振っているが、下記の意味合いである。
①：顧客の要件(明示的な部分)が、システム提供機能で満足されていない
②：顧客の要件(明示されていない部分)が、システム提供機能で満足されていない
③：顧客の要件(明示的な部分)が、システム提供機能で満足されている
④：顧客の要件(明示されていない部分)が、システム提供機能で満足されている
⑤：顧客の要件に関係ない、システムが提供する機能
③と④は、システム品質が良いとされる部分である。
①は、要件通りにシステムが作られていない部分であり、強いクレームとなる。②は、要件は提示していないものの、あらためて考えると本来要件として提示すべきであった部分である。要件提示側に若干の落ち度はあるため、クレームとなるが、弱めのクレームとなる。この部分の多くは当たり前品質に分類されるものである(例えば、顧客が運用開始時に想定していなかったパスワードリセット機能など)。⑤は、顧客にとってはどうでもいい部分であるが、この部分の機能開発について顧客がお金を払う場合は、クレームとなりうる。
高品質なシステムを作るうえでの方針
高品質なシステムを作るうえで大切なことは、図1における、明示されていない要件の部分を可能な限り明示することだ。システムを作る側としては、明示されていない部分の要件を意図して開発する動機がない。なぜならば、それらは要件として提示されていない機能であるため、無駄コストになる可能性があるからだ。したがって、とるべき戦略として、まず要件を可能な限り明示し、顧客側とベンダ側で認識をすり合わせるべきとなる。そして、その要件を満足すべく、開発をしていくことが大事なのである。この作業は面白くはない。面白くはないが大切なことであり、ここをどれだけ丁寧に進められるかが、品質向上の鍵である。
