「リリースクライテリア決めてくれませんか？」

比較的大規模な開発プロジェクトに品質改善でコンサルに入ると、リリース直前に「クライテリアを決めるのを手伝って欲しい」などと頼まれることがあります。

ウォーターフォール型のプロジェクトにおいて、リリースクライテリアというのは、本来はプロジェクト計画の段階である程度決めておくものです。
そして、最終的なクライテリアから逆算するように工程ごとの終了判定基準を定義し、徐々に石垣を積み上げるようにして終盤に向かっていくというのが理想的な流れです。

ソフトウェアの品質というものは、それ自体を可視化することができません。「そもそも品質とは何か」という永遠の問いもありますが、それはいったん脇に置いて「品質の高い＝バグがない」と乱暴に定義したとしても、複雑巨大化した昨今のシステムに対して「バグはありません」などと証明するのは現実的に不可能です（ソフトウェアテスト7原則の①）

そこで、ソフトウェアそのものの品質を可視化するかわりに、それを作り上げる過程（プロセス）が正しいと証明することによって代替的に「品質に問題はありません」ということを示そうとする、というのが古き良き？ソフトウェア品質保証の考え方の一つです。
要するに、「我々はきちんと開発計画を立て、計画したことをすべてやり切りました。したがって、このプロジェクトの品質に問題はありません」というロジックですね。

ここで重要なポイントとなるのが、このアプローチは「計画ありき」だという点です。過去のデータなどに基づいて精緻な計画が立てられているという大前提がまずあって、それをきちんと実行したから問題ないはずである、という話をしたいわけなので、計画を立てていなければ話になりません。

つまり、終盤になってから思いついたようにリリースクライテリアを作っていては全然間に合わないのですが、実際にはそういうケースが非常に多い。
そして、「『これさえ担保できているから品質はオッケー！』と断言できるロジックを組み立ててくれませんか？（できるでしょ、アナタ品質のプロなんだから！）」みたいな相談がシステムテストの終わりがけになって舞い込むわけです。

そんな時、「品質のプロ」はどうするか――
（いやいや、いきなりそんな無理ゲーを押し付けられても・・・）
と内心苦笑いしつつも、何かしらできることはないかと考えなくてはいけません。何しろ「品質のプロ」wだから。
具体的にどうするかはケースバイケースですが、何をやるにしても後出しのこじつけ感満載で、もやもやした気持ちが残ります。

そんなわけで、これからウォーターフォールでプロジェクトを回そうと考えているプロジェクトマネージャの皆さんは、リリース直前になって慌てることのないように、計画段階からリリースに向けたストーリーを頭の中で組み立てておきましょう。

本日の教訓：段取り八分、仕事二分

ヘッダ画像：UnsplashのGlenn Carstens-Petersが撮影した写真