品質を作るということ


未だにソフトウェアの品質を「上げる」とか「向上させる」とかいう人がいて頭を抱えたくなるのですよ。


こういうことをいう人は、得てして、なんの対策もせずにメンバに作らせた仕様書をレビューしてそのまま通し、顧客などの外部レビューで指摘が多ければ「品質が悪い」とメンバに改善を言付け、顧客の指摘がなければ「品質がいい」と勘違いして後工程のソフトウェアを邁進して作るわけです。


で、その結果作られたソフトウェアはテスト仕様書がまともであれば多大なるバグを検出することができるけれど、それまで設計やコードを書いていたメンバがテストもするのでそれ何でしかソフトウェアのバグは検出されないのです。


その結果、何が起きるかというと、本番でトラブルが起きるわけです。


ソフトウェアの改修には、バグを検出する工程が先になる程コストがかかるのは有名な話で 1:10:100の法則 と既知のことなのだからバグが出たら直せばいいという考えはアホとしか思えないんですけどね。できることはちゃんとやりなさいな、って。


だから物を作るときに、要求される品質を確保できる作業をしなければならないわけで、それはものづくりに関わるプロジェクトメンバ全員の行動を制限しなければならないのです。


どうして制限という言葉を使うかというと、品質を確保するという作業においてはものづくりに関わるメンバが同じ作業をしたら同じ結果を得なければならないから。好き勝手なことをして品質に満たないものづくりをしては困るというか、そんなコストはプロジェクトで負担できるほど余裕なんかなですし、そんな好き勝手をされたら他のメンバが悪い影響を受けてしまいプロジェクト全体として品質が確保できなくなってしまいます。


後工程になって直すのは時間もお金も掛かる。支払う必要のないリソースのコストです。誰かが不良品を作ることを放置してしまうと全員が感染してしまう。これも手直しのために支払う必要のないリソースのコストを負担しなければならくなるのです。


支払う必要のないリソースのコストを無くすためには、ものづくりをするときに品質を確保する作業プロセスを設計し、実現できていることを計測して確かめ続けることです。


それが品質を作るということです。決して、テストでオレオレテストをやって品質はバッチリですということではありません。