なぜ品質保証「部門」が必要なのか

2013-05-31 06:33

昨日公開されたこの文書は、その理由を考える上で「教材」として素晴らしいものだ。

結論から言うと、今回の事態の原因は弊社のミスです。アプリケーションファイルに、辞書のデータベースファイルが含まれていませんでした。これにより当然の事ながら、まったく検索不可能になりました。単純なミスでした。こういったミスを犯さないようにたくさんの防御策があるのですが、今回はそれらをすり抜けられてしまいました。それを検証します。

via: 大辞泉1.0.1不具合騒動の顛末 | HMDT Blog

こうした「失敗」が公に、正直に語られることはめったに無い。多くの場合は企業の厚い壁の底に隠されてしまう。私が大学の教員だったらこれを教材として使うところだ。

私が見たところ一番の問題はここだ。

でも、みんなでテストすれば、誰がかが気付きそうなものです。ところが、この修正はほんとに軽微なもので、もうすでにみんな1.1の開発に没頭していたいので、テストを省略してしまいました。これが、落とし穴その3。結果的には、これが一番の問題でした。

via: 大辞泉1.0.1不具合騒動の顛末 | HMDT Blog

つまり「ちょっと直しただけだからテストしなくてもいいよ」となったわけだ。こう聞くと働いた経験のない人は「なんて馬鹿な」と思うだろう。しかし人間は馬鹿なものである。なんて馬鹿な、ということをやるのだ。

従ってそれを防ぐためには「仕組み」を作らなくてはならない。この「仕組み」が増えることは一般的に効率とか柔軟性の低下につながる。しかしそれは「大きな失敗をする危険性」とのトレードオフになる。このトレードオフをきちんと理解している限り、「仕組み」を増やすことによる効率性の低下はコントロールできる。

問題は

この文章を公開しくれた人がそのトレードオフに気がついていないのではないかと思える点だ。

問題は常に起きます。ミスもどうしたって起きます。それが被害として出回らないように、弊社を含めて開発会社は幾重もの予防策を施しています。大部分は未遂で済みます。それでも、その隙間をすり抜けることは、絶対に起きます。すり抜けてしまったら、被害が広まらないように防ぎます。経緯を見直して、次回に役立てます。技術ってのは、その繰り返しです。それしかないです。しんどいですが、それしかないです。

via: 大辞泉1.0.1不具合騒動の顛末 | HMDT Blog

「問題は必ず起きる」という認識は正しい。しかし対策のところが「しんどいですが、それしかない」の精神論に流れてしまっている。もし私がこの会社に業務を委託している身分だったら

「ああ、この会社はまた同じようなことをやるな」

と発注を停止するところだ。

今回HMDTが直面した問題は、まさしく品質保証「部門」がなぜ独立した部門として存在しているかの説明になっている。ちょっと昔話をしよう。

私が最初に働いた会社では、みんな灰色の作業服を着ていた。（当時はそうだったんですよ）入社して最初に気がついたのは、帽子の色が２種類あることだった。紺色と紫。なぜ違うだ？

後で知ったのは、紫は品質保証部門の人とのことだった。つまり帽子のいろまできっちりわけているわけだ（一説には、ライセンス生産した米国の会社でやっていることをそのまま真似たとも言われていたが）

工場実習に行くと、現場のおじさんたちが「おう、品証がいないうちにちょっと直しとけ」とかこっそり直したりする。つまり日々の業務の「邪魔」にもなっているわけだ。そもそも品質保証部門は役にたっていないじゃないか、そういう議論は定期的に起こっていた。

しかし

そうなっているのは、そうしなくてはならない理由があるからだ。今回のHMDTのトラブルも開発者がチェック及びリリースを兼ねていたところに一番の問題がある。そりゃ新しい仕事にかかりっきりになっていたら「ちょっと直しただけだから出しといて」となるわな。しかしそれではいかんのだ。

ここは開発者の苦労や苦悩や事情を全く理解しない「鬼のような」別の部門のアウトサイダーに「必ず」チェックさせなくてはならない。それ故ほとんどの会社では「品質保証」を担う「部門」が存在する。独立してだ。もちろん小さな企業ではそれは難しいのはわかっている。自慢じゃないが私が小さな会社に勤めているときはそれで随分お客様に迷惑をかけた。しかし方法はあるはずだ。痛い目に何度かあって私だって改善したぞ。

それを「しんどいですが、それしかない」の精神論に堕してしまうところが「またやる」と判断する理由だ。

いや、それは当然理解している。ただ書かなかっただけだ、ならばいいのだが。