品質管理の知識を持たないエンジニアはモグラ叩きのループから抜け出せない

ソフトウェアの品質管理というとエンジニアは何を頭に思い浮かべるのでしょうねぇ。設計書やコードのレビューかな。それともバグのチケットの書き方が面倒だなーということかな。

どれを取り上げても品質管理はエンジニアから見ればやらされている感が満載ですよねぇ。

プロジェクトマネージャはその品質管理をやりたくてやっているかと言えば、これまた組織の品質管理部門とか品質保証部門とかPMOとかうるさ方の部署からアレ出せ、コレ出せと言われるので、お作法として、プロジェクトに余計な鑑賞をされないために義務的にやっているといっても語弊はないかもしれません。

どうして品質管理が必要なの

端的に言えば、要件、そう、顧客が実現したい事業上の課題をITで解決するために、プロジェクト化してソフトウェア開発したコードに要件が備わっているかを検証・評価するためです。

とだけではわかりにくいですね。言っていることはわかるけど、みたいな。

ソフトウェアは形状がない、物理的な要素がないので外形的な特徴から計測することでそのソフトェアが持っている能力を測ることができません。とは言え、そのままでいいのかと言えば、それではやりたいことができるかどうかが判別しないのでちゃんとできますよ、としたいわけです。お金かけていますからね。

例えば、スマートフォンは形があり、外形から物理的な特徴があるので工場で生産した出荷前のスマホを設計データの許容範囲の誤差内に収まっているかを測定することで出荷して良いかどうかを評価できます。

一方、スマホの中に入っているOSは、物理的な形状がありません。ですから、仕様どおりの要件がソフトウェアに備わっているかを検証し、評価することが必要です。

全部ができあがってから検証・評価しようとすると、まず組み立てが必要でそこで部品どうしの寸法が違えば組み立てができないです。

ですから、部品の状態の遷移するタイミングの前にその工程で加工した要素が備わっているかを検証・評価した方が良いです。これは物理的に計測可能な対象でも無形上のソフトウェアでも同じです。

ドキュメントならレビューが多いですね。コードならテストですね。ただ、レビューもテストも検証を実施するアクティビティの一つでしかありません。

ざっくりとアクティビティを並べればこんな感じでしょうか。何を検証するのか、何を評価するのかをはっきりしてないということは品質管理の目的が曖昧でやらされているということと同じですね。

主体性を持ってやらないと品質不良が出易いし、事後対応ばかりになってモグラ叩きの呪いから逃れられませんよ。

これは設計書なりコードを作成するときの作業プロセスに踏み込んで、品質を作り込むプロセス設計をしないといくら品質管理を一生懸命頑張ってもバグは減りません。

だって、対処療法ですから。

身体を鍛え、病気になりにくい体質に変えなければどうしようもないです。身体を鍛えても病気になると思うかもしれませんが程度がかなり違います。些細なことで済むことが多くなるし、それこそ大規模なインパクトがあるケースは想定外になるので。

なので、アウトプットを作るときから要求される品質特性を折り込みしておきたいので作るときから品質を備えた作業プロセスを実行しておきましょう、ということの他はないのです。