ＳＷ品質まとめ①品質ってなんですか？
そう聞かれて、きちんと答えられる人はまずいません。
直訳で「品物の…質？」と答えるか、本質から外れて「不良がない…とか？」と答えるのが関の山でしょう。そもそも不良の定義さえおぼつかない状態で、だがしかし、感覚的にはなんとなくわかっているらしい。これが世の中の品質に対する認識の実情です。
しかし、それでは具体的に”品質”を理解していない状態で「品質的に、大丈夫な製品です」とどうやって証明することができるのでしょうか。ＩＴ業界に限らず、多くの製造業界、多くの企業、多くのエンジニアが直面する問題であり、その問題から逃げようとばかりしているから"品質トラブル"、"データ不正"、”自主回収”などが頻発し、社会的な不祥事となります。誠実なモノ作り、誠実なエンジニアリングに取り組むためには、品質とは決して切っても切ることのできない重要な役割を果たします。
だからこそまずは品質保証に携わるか否かに関係なく、モノ作りに関与していく以上、「品質とは何なのか」をきちんと理解しなくてはなりません。
品質を理解しないと、正当性は保証できない
品質という言葉を分解すると、その名の通り『品』の質であることがわかります。
では、『品』とは何か？
これがエンジニアリングすべての原点となります。この原点が正しく理解できていないと、モノ作りすべてにおいて不誠実な対応しかできなくなってしまいます。理解していないのに作るということは、作ったモノが正しいかどうかを証明することができませんし、自信も持てないということを意味するからです。要するに小手先の技術だけが身についてしまう、そんな状態となるわけです。
「品」の歴史
その単語の由来は後ほど語るとして、まずはさらにもっと前の紀元前の古代中国まで遡って、「品」という言葉を取り巻く思想に触れておきましょう。
紀元前80年ごろ、前漢王朝の時代。
当時、官吏（役人）の推挙方法に”郷挙里選”という制度が存在しました。簡単に言えば「正しい行いや考え方をする人が政治をすれば、正しい国づくりができる」という性善説に則った考え方によって、人事を行う仕組みがありました。思想自体に誤りはありませんでしたが、人の心はそれほど正しさに満ち溢れているものばかりではありません。長い年月をかけて、地方の豪族や一部の貴族の権力が強くなっていき、郷挙里選は彼らの政争の道具となって、一部の有力者の推挙しか行われなくなっていきました。いわゆる「身内で固める」「気に入った者だけ押し上げる」と言ったことが横行したわけです。
紀元後200年ごろ、後漢王朝の時代。
『三国志』で有名な魏国の初代皇帝でもあった曹丕という人が”科挙”という新たな人事制度を策定しました。これは「試験によって人の能力を測り、選出する」という画期的な方式でした。試験によって人の能力を測る…というのは現代まで続く採用方法の１つですよね。この平等な評価基準を設け、
その内容によって分類し、その結果によって適正を決める
というのは、歴史的に見ても大きな意味を持つことになりました。つまり、『客観視』するということです。わかりやすく現代風に言えば、プロジェクトマネージャー試験によってＰＭの適性を、データベーススペシャリスト試験によってＤＢＡの適性を判別したのと同じことを１８００年近く前にはすでに考案されていたということに他なりません。
そして紀元後600年ごろ、隋の時代。
ここでは”九品中正法”という制度ができました。すなわち「９つの”品”によって人の適性を測ろうとした」わけです。「上品／下品」「品が良い／悪い」「位が高い／低い」など、現代でいう品位や品格の基となった考え方です。
要するに「品」とは？
私たち日本語の原点が古代中国からもたらされた言葉である以上、中国の歴史から「言葉の本質（語源）」を探るのは妥当といえます。そのうえで”品”の言葉の歴史を紐解くと、品とは
結果として目の前にある事実（表面的な部分）を評価したもの
であると言えるでしょう。私たちソフトウェアエンジニアリングに当てはめて例を挙げるなら、
「きちんと動作していて、求められた機能が実装されていれば、
その中身がスパゲティソースになっていても、問題にはならない」
「中間成果物が存在しておらず、
何一つ証明できるものがなくても、
問題にならない」
ということを意味します。ゆえに”品質”とは本質的に目に見える部分の質、結果としての質だけを指すケースが昔から根付いていたことになります。その歴史的風土があり、そして日本にも輸入され、１０００年以上続いているからこそ、たとえば『出荷検査』という言葉があるように、開発途中の「作り方」「進め方」「基準」「ルール」…といった過程のプロセスがどうなっていても、最後の最後に水際で検査して問題が無ければ”検査済”として、品質のいい製品と認識する文化が根付いているわけです。
ですが、プロセスを見ないからこそ、データ不正などが起きるわけです。
無論それだけで済ませると実際に問題が発生した時に発生する手戻りやリコールにかかるコストも無視できないほど大きくなってしまいます。そのため、近代品質の観点では『品質管理』という考え方が生まれることになりました。
要するにＰＤＣＡフレームワークに則り、一度起きた問題は再発させず、常に改善を繰り返して、より良いモノにしていこうという仕組みが取られるようになったのです。これが、現代の『ＱＣコントロール』と呼ばれる活動に至るまでの社会的経緯です。
また、「品（しな）」の他に”科挙”で出てきた「科（しな）」という言葉がありますが、訓読みではどちらも『しな』と表現されているように、実は源流は同じ意味を示しています。
たとえば、
「科（しな）を作る」
という言葉の意味は”なまめかしいしぐさをする”ですが、元をただせば女性らしさの「品位」を定義した１つの所作を意味しています。
このように、”科”は「ある一定の条件を満たしたものまたはモノ」を指し、古代中国では官吏に推挙できる器の人物かどうかという条件を満たすか否か、品定めをする言葉として用いられていました。
「品」という文字の由来
「色々な器物」の象形から、とりどりの個性を持つ「しな」を意味する「品」という字が成り立っています。このことからもわかるように「品」とは、次のような意味を持っていることを指します。
・中身（プロセス）ではなく外見（成果物）を指している
・「品」という言葉自体の使われ方も、過程よりも事実を指すことが多い
・「科」という言葉も結果を重んじた考え方に則っている
現代における「品」
「品質」という言葉に代表されるように、「品」には”良い品”と”悪い品”があり、その程度を「質」として定めるものとしています。しかし、古代の「品」と同じように現代の「品」も最終的には
"器（利用者から見える部分）"
が評価されなければ意味がないと社会的には定義されてしまっています。ビジネスの大半が結果主義なのもこれと同じことです。「頑張った！」「すごい機能を作った！」と言ったところで、利用する者あるいは利用される者にとってそれが適切でなければ、評価されないのです。ここから読み取れることは、品質は
作るものが決めるのではなく
利用するものが決める
ということです。言い換えれば、
供給する側が決めるものではなく
需要する側が決めるものである
ということを意味します。エンジニアやプログラマーにわかるように説明すると、ソフトウェアにおいて関数間、メソッド間のインターフェース仕様を決める際でも同じことが言えるでしょう。インターフェースの仕様を決める権利を持つのは、常に呼び出される側（引き数を提供される側）であるからです。決して呼出す側、引数を提供する側ではありません。
同様のことは、いたるところに存在します。
たとえば飲食店において、提供される料理が美味しい（品質が高い）かどうかを決めるのは、提供するシェフではなく、提供される顧客の方です。品質が低ければ…すなわち美味しくなければ顧客はクレームを言ったり、ＳＮＳで散々な評価をつぶやいたり、二度と訪れなくなったりします。その評価を決めていいのは顧客側であってシェフ側ではありません。
こうして日本の品質に対する考え方は、「品」と言う語源のあり方を以って現代に根強く残るものとなっています。
しかし勘違いしてはいけません。
ソフトウェア開発という技術もその考え方も、もちろん開発プロセスにおける品質の定義も、全ては欧米からもたらされたモノであり、欧米のエッセンスが随所に刻まれています。
古来よりの日本、および古代中国の「品」に対する考え方が起源となっている品質とは全く異なるアプローチによってつくりこまれたものであることを無視しても、正しい品質証明には至りません。特にＢ２Ｂによる受注生産を主とするソフトウェア開発は、量産のパッケージ製品とは違い、そもそも従来の製造業が考える品質保証の考え方は通用しません。
そのことを、今一度強く認識し、あらためてソフトウェア開発に求められる品質、すなわち『ソフトウェア品質』を正しく理解しなくては、本当に要求されるソフトウェア、満足されるソフトウェアを作成することは難しいでしょう。
最後にまとめたファイルを張っておきます。
個人的にまとめた品質大全ですが、章ごとにまとめたファイルを添えるので、いっそのこと有償化しようと思ったんですけどね。
でも、１章は具体的な内容にまだ入っていないのでやっぱやめときます。
全部で500ページ近くになりますが、まだ整理しきれていない項もあるし、章の順序性が正しくないところもあるかも知れません。
今回は「である」調から「ですます」調に変えて本文としても載せましたけど、正直面倒なので今後はファイルを添えるのが中心になる"かも"しれません。
まぁ、各章ごとそれぞれ部品として独立して読まれるといいかと思います。章の順序にはあまり関係は無いと思ってください。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。