障害の在り処

システム開発に障害はつきものです。トラブルね。テストなんて問題を出しきるためにするものなんだから、起きないほうがおかしい。でも、起きると問題視される場合があります。もちろん、問題視するのはプロセスがきちんとしていない（本来やるべきことをやるべきタイミングでやっていない）とか、コミュニケーションに問題があるとか、そういう障害そのものではなくてそれが起きた真の原因を問題視しているわけですが、結果として言い訳のしづらい（ようは不注意でしたとしか言い様がない）ところまで追求されてしまうと責任がどうとかという議論に変わってしまうことが多く、それゆえに真の原因を隠蔽する言い訳になることがままあります。
複数の、色々なレベルの人で作っている以上、品質のばらつきはどうしても生じるし、隅から隅までを上位者がレビューするわけにもいかない（それができるならダメな人の分は自分で全部作ったほうが早いことも多い）ので、最終的には「特定個人」の問題に障害が帰結しちゃったりして、それはそれで分析する意味がない話になってしまいます。実際にそうやって人を入れ替えることで解決しちゃったりするし…

なんでこういうことになるかというと、障害は発生するもの、という前提をおいていながら、結果に対して責任を求めるということがあるからだと思います。明らかにそのフェイズで出るべき障害が出た時に

• なぜ出たのか
• どうすれば改善されるのか
• この障害のために改修する費用は誰がどう負担するのか

を事細かにレポートせよ、と言われたらどう思いますか？次は出すなって言っていると思いますよね。でも、障害は一定件数出ることを前提にしているわけですよね。そうすると特に最後の問はおかしい。本来は、障害発生率に見合っただけの工数積み増しが事前に行われていて、その範囲を超えない限り、余っても「良かったね」で終了なんですよ。

障害が発生している場合に問題になるのは、最初においた前提から大きくマイナス方向に乖離した時。その場合はもちろんこのような問が発生し、それに答える必要があります。でも、前提以下の障害発生率なのに改善を求められるというのはちょっとおかしい。それは障害そのものへの改善ではなくて、障害が少なかった原因を分析して、それがたまたまではないのであれば、そのうまくいったプロセスを次も適用することで前提の障害率を下げる＝工数を下げる＝開発効率化である、というところに持っていくのが正しいやり方なはず。

品質を管理するというのがシステム開発においては先々の開発効率化につながる、ということを政治に明け暮れる上位者には意識してほしいなあって思いますね。