ここでいうバグというのは、不具合とか、故障とか呼ばれるものの総称と考えてください。
ふたつのソフトウェアモジュールA,Bがあるとして、それぞれ単体では検査にパスしているとします。
結合したときに、テストに失敗しました。
それはインターフェースの仕様についての解釈がA,Bそれぞれの実装者で異なっていたからです。
以下のケーススタディについて考えてください。
1.インターフェースの仕様記述がまずかった
これは仕様書のバグですか？
しかし仕様書のバグを取っても、製品は正常に動作しませんね。
では仕様書を直す意味はどこにあるのでしょうか。
2.AとBどちらの実装者が修正するべきでしょうか。
上記1.で仕様書のバグを先に取れば、この問題は簡単に片付きそうです。
3.A,Bの修正工数に大きな差があると見積もられたらどうするべきでしょうか。
Aが直す工数→10日
Bが直す工数→1日
どんなに原則論を並べてもBが直すべきだという主張が出てきます。
上記2.でAが直すべきという結論が出ていたとしてもなおです。
この場合、おそらくAの実装者は、自分に都合よく仕様を理解して、少ない工数しかかけていないかもしれません。
つまり10日というのは、”かけるべきだったのにかけなかった工数”の代価の可能性が高いのです。
4.過去にかけた工数とこれからかける工数の間に価値の差があるか。
納期の1ヶ月前の1日と1週間前の1日で重みが違うかということです。
これは納期後にもっと大きな差となります。
実装ミスから生じたバグを原因として、仕様を変えてしまうことも恥じるべきではありません。
ＱＣＤについて考慮すれば、原則論だけでは商売にならないことが分かるはずです。
ここまでの議論もコンセンサスが取れていないことが多いように見えます。
特に”むかしとったきねずか”のある偉い人が困ったチャンを演じます。
些細な提案としては、大きなしゃもじに「ＱＣＤのトレードオフ」と書いたものを会議などで活用するべきかと思います。
原理原則にこだわりすぎるひとが出てきたら、このしゃもじを掲げるのです。
まぁ、そういう風に議論を誘導できる人がいない会議ならどうせ無意味でしょうが。
原理原則に徹底的にこだわるべきなのは、仕様を決めたり試作の現場であって、生産現場では柔軟性が必要なのです。
ただし釘を刺しておかなければなりません。
それは、柔軟な対応を逆手にとって手抜きをする連中への対応です。
ようするに、ロクに仕様書も読まず、面倒な部分は実装を遅らせ、締め切りが過ぎてから、”この仕様のままでは間に合いそうにありません”という風に仕様の変更を要求する手合いです。
不可抗力かわざとなのかは判断付けにくいですが、この手の寄生虫型ビジネスに目をつむりだすと、もうその現場はだめです。
コメント