プロの開発者なら品質を確保できるのは当たり前

ソフトウェア開発の現場では、QCD（品質、コスト、納期）のバランスが重要と言われることがある。バランスと言っても、実際問題としてどれかを後回しにすることはあり得ないので、各項目について「それなりのレベル」を確保することが求められるが、コスト（お金）や納期（日時）は客観的な数値なので分かりやすい反面、品質なら幾らでも恣意的に解釈可能なので、結果的にバランスのしわ寄せは品質に来ることが多い。

そんな品質後回しの作業現場には、首をひねりたくなるような言葉が飛び交うことになる。

品質は評価部門で確保するので心配するな
納期最優先でドンドン作れ
バグが多ければ追加人員を投入する

こんな発言を聞く場合、大抵は右肩上がりの障害件数と共に開発現場はデスマーチ一直線となってしまうようだ。もちろん、テストを増やせば取り除けるバグも増えるかも知れないが、それは起こってしまった問題の対処療法に過ぎず、何ら本質的解決策にはなっていない。穴の開いた船底から頑張って水を掻き出したところで、その穴を塞がない限り船の浸水は止まらないのだ。

考えてみれば直ぐに分かることだが、品質確保は短期的な施策で解決できるようなものではない。例えばバグを見逃してしまったのはレビューでの実施が不充分だったせいかも知れないし、それは忙しいことを口実にレビューを省略したことや、レビューを実施していても問題を指摘できるだけのスキルがグループ内に備わっていなかったせいかも知れない。コーディングに問題がある場合も同様に、コードレビューの実施方法に問題が有ったのかも知れないし、防御的プログラミングを行っていなかった開発姿勢に問題が有ったのかも知れない。品質確保のための有効な手立てを今まで打っていないのに、開発の最終段階になって品質云々で騒ぎ出すのは、自らの開発姿勢に根本的な原因が有るように思えて仕方がない。

本当の意味で「バランスの良い」開発者の場合、予めテストしやすい構成にしておく、単体テストコードの準備により手作業でのテストを減らす、問題発生のリスクが高いところから重点的にテストする、異常発生時に問題が直ぐ分かる仕組みを入れておくなど、品質確保のための対策を事前に実施済みであることが多い。だから本格的な品質評価が始まっても、致命的な問題は見つからないし、障害の発生件数も大したことない。むしろ、ソフトウェア開発のプロフェッショナルが行う仕事なら、その程度の品質確保策は出来て当たり前と思えるし、これが出来ないのなら、それはプロの仕事とは言えない気がする。プロの開発者なら品質確保を他人任せにせず、自らの力で確実に抑えるのではないだろうか。