バグのないプログラムを提出したら怒られた!

そんな経験ありませんか?

僕もちょっと前にやってたシステムで一番苦労したのは「障害がこれほどまでに少ない原因」を説明することでした。そりゃ優秀な人間が集まって作ってるからですよって言いたいんだけどさあ…

酷い話なのは、「システム開発にはバグが付き物」ってのはみんなわかっているわけですよ。で、UTとかITとかいう工程で何%くらいはバグが出るはず、という一般的な指標に基いて評価するわけですね。でもSTとか本番でバグが出るとしこたま怒られる。UT/ITでバグが検出されてなかったらなおさら。もちろん、バグにもいろいろな種類があるわけで、作る側からしたらしょうがないってのもありますよ。でもねえ、作るものが小規模であったり適切に機能分解されていると相対的なリスクが減った結果、指標値に満たないことなんてよくあるんですよね。優秀な人がやっていたら尚更で。

完璧なものを作るのは難しいという世界において、品質を担保するというのはどこまでお金をかけるかという話に近いものがあります。だから、テストは本来的にはリスクマネジメントの世界として捉えるべきですよね。潜在するリスクをどう評価し、どこを重点的に頑張るのか。当然リスクをゼロにすることはできません。できたらノーベル賞モノですよ。

本来はここに個人の能力という大事なファクターがあるんですが、それを入れてしまうと一般論的なマネジメントが出来ません。そういうところも含めてリスクをどう取っていくかというのがSEの現場の本来の課題なんですけどね。銀行のお仕事とかやっていると金は掛かっても構わんからバグ0でとか言われるわけですよ無理ですよそのくせ下流工程でバグでないと怒るわけで…

ぶっちゃけ、その開発者の数を減らしてハードをパワーアップした結果として余計な機能を削ぎ落したほうがいいんじゃないっすかーとかいつも思うわけですよ。パフォーマンスに懸念があるって言ってアセンブラでバグを作りこむようなことをするくらいならハード買った方がリスク少ないわけですよ。そりゃハードのほうが保守費も含めると高くつく気がしますけどね、バグが開発工程から本番運用までに与えるリスクベースの見込み金額とどっちが高いのってそりゃ大抵の場合増えた開発工数も含めて考えるとバグですよ。

リスクを正しく判断できるシステム開発でありたいものです。