Software Quality.com

ここではSoftwareに関連する様々な用語を解説します。

 

言葉はコミュニケーションのための重要な手段です。

言葉があるから人間同士の会話が成立し、認識が共有され、グループやチームによる対応が効果的になります。

しかしその一方で、言葉の持つ意味やイメージ、捉え方が個々人で異なっているために、行き違い、認識違いによる問題・障害発生も多くなっています。

求められるSoftwareを協力して作り上げるなど、一つの目的を達成するために集う関係者は、可能な限り言葉を合わせて認識を共有する必要があります。

現在は、大規模化、複雑化したSoftwareを作り上げるために複数の組織（場合によっては国も異なる）が連携して開発を行う場合があり、用語・言葉の意味、捉え方を一致する重要性はますます大きくなっていると言えるでしょう。

 

<<品質に関連する用語の解説>>
普段から使っている言葉なので分かっているようで、実は分かっていないかもしれない。

そんな言葉を自分の理解に基づき説明してみました。
下記の内容はあくまでも私見ですので絶対視しないようにご注意ください。

■Quality＝品質（ひんしつ）

「品質:quality」という言葉には、これまで様々な人々が様々な定義をしてきました。
誰もが知っていて日常でも使っており、自分では理解していると思っているのに、他の人にわかりやすく説明するのが難しい言葉でもあります。
まずは国語辞典（大辞泉）で「品質」を調べてみると、「品物の質」と載っていました。
多くの方がそう認識している、つまり多くの方がその意味を狭く捉えているのは間違いないと思われます。
しかし、この捉え方は間違いではないものの、定義のうちの一部分でしかありません。
用語「品質」には多くの定義があるので、唯一画一的な答えはないことを前提に私なりの理解で説明を試みます。

私が「品質」という言葉に対して、「ああ、そういうことなんだ！」と納得するきっかけとなった定義はISO9000:2000のqualityの定義でした。

　本来持っている特性が、要求事項を満たす程度

はじめは何を言いたいのか、何のことなのかがまるで理解できませんでしたが、次に示すような整理を経て納得したのでした。

　本来持っている　　　　　　　→　もともと持っている
　特性（＝特質）　　　　　　　　→　（そのものだけが持つ）性質
　要求事項を満たす程度　　→　１つまたは複数の要求する事項のうち、どのくらいを満足しているかの度合い

※ある対象が持っている性質が、要求する事項をどの程度満たしているか（の程度）が品質

さらにこの定義には”主語がない”のですが、暗に要求する側と、要求される側があるのだけは分かります。
要求する側については神様、豚君、鳥、宇宙人など誰であってもかまわないのですが、ひとまず「人間（ある人）」としておくのが妥当でしょう。
（他のものでも成り立ちますが、我々がこの用語を活用するのは「人間」の場合に限っても問題ないと考えました）

以上のことから、”ある対象”に”ある人”が要求する事項（・・・・・はこうあってほしい、こういう・・・・が欲しい＝Ａ）に対して、ある対象の特性（Ｂ）・・・・がどの程度満足しているかが品質だ、ということになります。

 

この定義から、いろいろなことが分かりますので以降で整理していきます。

[補足]
ここで「特性」とは、備わっている性質、特徴のことです。
例えば、大きさ、重さ、色、匂い、機能、などいろいろあります。
なお、ソフトウェアの典型的な特性を表すものの一つに、「ソフトウェア品質特性」や「利用（時の）品質」などがあります。

・品質:quality は「品物の質」だけを指しているわけではない
以上で整理した品質の定義で”ある対象”を”品物”に、”ある人”を”私”に置き換えれば、「品物の質とは、私がその品物に求める事項を（品物の特性・性質が）満した程度のこと」、もうちょっと分かりやすく整理すると、「（私にとってその）品物の質とは、私がその品物に求める事項を品物の特性・性質が満した程度のことです。」となりますね。
なるほどこれだと分かりやすい。理解できます。
しかし、”ある対象”に”品物”ではない別の対象を置いたとしても、この定義は成立します。

 

例えば以下のようにになります。

このように多くの方や国語辞典が”品物の質”と考えている「品質」の対象は、人や組織、行動などあらゆるものが該当する可能性があり、品物（しなもの）だけに閉じないのです。
品物だけが品質の対象ではない。このことをよく覚えておいてください。

・人によって品質が異なる
”ある人”の要求する事項があり、その要求をどこまで満足するかが「品質」ですので、品質を評価する基準は「”ある人”の要求事項（求めるもの）」になります。
話を分かりやすくするために、ここにＲという名前のロールプレイングゲーム（ゲームソフトＲ）があるとしましょう。
このソフトウェアの品質（を評価した結果）はどうなるかというと、私のようにロールプレイングゲームが嫌いな人の場合は評価が悪くなりがちです。
そもそもそのタイプのゲームは嫌いなので、あまり高い評価はつかないでしょう。
一方、うちの妻のようにロールプレイングゲームが好きな人がゲームソフトＲを評価すると、私の評価結果よりは高くなると思われます。
このように、品質の評価対象物が同じでも、評価する人間（品質の定義でいうところの”ある人”）が変われば、品質が異なることに注目してください。
そうです、人によって品質（を評価した結果／裏を返せばその人が求めるもの）は異なるのです。
人間は一人ひとり、考え方、価値観が異なります。そのことが同じ対象であっても、人によって品質が異なる現象を引き起こす根源です。

　　　　　　「品質は誰かにとっての価値である」　　Ｊ．ワインバーグ

・ソフトウェア品質とは？

以上の解説に基づき「ソフトウェア品質」とは何かを考えてみましょう。

品質の定義に従えば、ソフトウェア品質とは、

 

　　　ソフトウェアが持っている性質が、要求する事項をどの程度満たしている程度

 

になります。

では、”ソフトウェアに要求されること”とは何でしょうか。

 

まずはソフトウェア自体（そのもの）に求められる事項です。

・必要な機能が装備されていること（機能性） 　　・止まることなく動くこと（信頼性） 　　・分かりやすいこと、使いやすいこと（使用性） 　　・反応が速いことやメモリやDISKを必要以上に使わないこと（効率性） 　　・直しやすいこと（保守性） 　　・いろいろな機器や環境でも使えること（移植性）

　　　　※これらは「ソフトウェア品質特性」と呼ばれているものです。

 

そして、ソフトウェアを使うことで求められることは以下のようなものになります。

・使うことで目的・目標が達成できること（有効さ） 　　・目標を達成する上で正しさと完全さのために使った資源（効率） 　　・結果として満足すること（満足度） 　　・使う人、仕事、設備、製品が使われる環境（利用状況）

　　　※これらは「利用時の品質」と呼ばれているものです。

 

一般的にはこれらすべてが「ソフトウェア品質」と言われている事項になります。

 

個人的には普段の仕事の中でも「（ソフトウェアの）品質」の捉え方があまりにも狭く、そのことが様々な誤解や不適切な行動につながっていることを実感しています。

 

※唯一の考え方で、他には無い、ということではありませんのでご注意ください。

■品質保証(quality assurance)
品質保証には、企業の一方的な都合や自分本位の考え方を排除し、顧客や業界（つまり社会に）に安全や安心を提供する役割があります。
つまり、（製品）品質が間違いない、大丈夫であることに責任を持つことです。
そのためには、最低限作り上げる製品が要求事項を満たしたことを確認できてから納品する、リリースすることが必要になります。
言い換えると、作り上げる製品が要求事項を満たしたことをまだ確認できていない状態では、あるいは要求事項が満たされていないことが分かっているのであれば（確認できるまで、あるいは要求事項が満たされるまで）納品しない、リリースしないことが必要です。
以上のことが確実に実践できている組織が「品質保証している」組織ということになります。
今や社会的に、いや、実際は製造業の世界で常識になっている「品質保証」ですが、ソフトウェア業界に関しては「まだまだ常識ではない」状態だと思います。

ちなみに、この「品質保証」の「品質」は”製品（の品質）”であり、それを保証するために製品構築過程で必要な活動を確実に行うことが意図となっています。

・品質保証をする方法は？
最低限の品質保証の方法は、求められている品質が確実に作りこまれていることを確認できたら、出荷・納品するということです。
反対の表現では、求められている品質が確保できていなければ出荷しない、納品しないということになります。
とはいえ、ソフトウェアを完全にテストするのは不可能ですし、いい加減に作りこんだソフトウェアコードを、最後の段階にテストして検出した欠陥を手当たり次第に叩きのめす・・・・聞こえはいいのですが、ものすごいロス（手戻り）を出しますし、実際にこんな作業方法では納期に間に合うことはないでしょう。

つまり「非現実的」ということです。

現実的に品質保証を実現するには、ものづくりの最初の段階から作り上げる＋段階的な確認の過程、そして納品前の確認まで品質を保証するために必要な対応を一貫して（手を抜かずに）行うことです。

ただし、Softwareには「完全なテストは不可能」という特徴がありますので、どのような確認をどの程度行うのが妥当なのかについては作り上げるSoftwareの特性や制約条件等からあらかじめ十分検討して実現する必要があるでしょう。

 

品質制御という言葉における”品質”の対象範囲は「製品・サービスの特性」にあると思います。

つまり、ここでの”品質”は狭義の意味があります。

それを制御する、コントロールするとは具体的にどういうことなのかを考えてみましょう。

制御＝コントロールとは、ある対象の現在状態から意図的に、ある範囲・領域内などねらって動かすことでしょう。

このことを実現するためには、下記のようなことができなければなりません。

　・制御対象の状態を明確に把握できている／把握するための手段、基準などが存在している。

　・状況把握のために、制御対象を計測、または監視している。

　・計測、監視結果に基づき、必要なレベル、範囲に制御対象を動かす手段を持ち、実際に動かす。

 

システムを開発している皆さんに「ところで”システム”って何だっけ？」と聞くと回答が帰ってこないことが多いです。自分達はシステムを作っている、システム屋だ、なんて言っている張本人が、システムのことを説明できない・・・。とはいえ、これが実情かもしれません。

システムを説明する場合に最低限必要な要素は、「目的」「機能」「有機的な結びつき」です。
正確な定義はＪＩＳやＩＳＯのようなものにお任せしますが、システムとは何かを書いてみます。

　　ある目的を達成するために作られた（あるいは成り立っている）単一の機能、

　　または有機的に結びついてた複数の機能の集合体

大事なことは、”システムには目的がある”、ということ。そしてその目的を達成するために機能（手段）が存在することです。
ですのでシステムの有効性を評価する重要な指標の一つは、目的を（どの程度）達成しているかである、ということになります。
そう考えると単純なんですが、普段よく見る、よく聴く話は「システムの有効性って何で計ればよいのか分からない」という話題だったりします。
この話だけ聴くと「評価の指標」と「尺度」が分からない、という話題に受け取ることもできますが、そもそも目的をはっきりせずにシステムを作ったり、使ったりしているので有効性を評価したくてもできない、というのが本質だと思います

システムの有効性は何で計ればよいのか、を知りたければ、そのシステムは何を目的としているのか、何を目指しているのか、なぜ構築したのかを、自分自身（システムを作って導入すると決めた張本人、あるいは組織）に問いかけるしかないのです。（ごまかしなしの本音でね）
そんなことを知らない外部の人間が、システムの有効性を計る指標・尺度はこれですよ、と提示できるとは思えませんし、そうであるにもかかわらず外部の情報ばかり気にしている方が多すぎます。

責任回避ということなのか、自分が何をしているのかが分かっていないだけか、原因はいろいろあると思います。

＜補足＞

ここで話題にしている”システム”は、ＩＴ、ソフトウェアによるシステムだけを意図しているわけではありません。
目的を果たすために成り立っている機能の集合体であれば、IT、ソフトウェアに限らず何でもよいのです。
信号機システム、浄化システム、都市、国会、日本、地球、宇宙、人間・・・・これらはシステムだと言うことができます。

 

 

 

 

（今後の解説予定）
■品質マネジメント(quality managemant)
■要求事項(requirement(s))