で、前のバグ管理の話のときに書こうとした、信頼度成長曲線の話。
信頼度成長曲線は、横軸に期間、縦軸に累積のバグ量をとると、だんだん収束していく。。。はず(^^;)
っていうのもだけど、実際にやると、必ずしもそうならないと思う。
たしかに、納品局面において、バグは収束しているんだけど、その途中の局面では、急速にバグが出るという状況が何度も発生してしまうと思う。
どーしてそういうことが起こるかというと、
(1)仕様変更がおこり、なにも手段を講じないとデグレードするから
→そのデグレード部分が急激にバグになる
(2)テストで、秘孔を突いてしまうと、一気にバグが出るから。
で、問題なのは(1)。
信頼度成長曲線が語られる文脈は、昔のウォータフォール型開発で、仕様変更が頻繁に起こらないことを前提にしていると思う。なので、修正により精度が上がっていくことになる。
一方、現在の場合は、仕様変更が頻繁に起こるから、デグレード対策をしておかないと、アウト!になる。とくに、インターフェースの仕様変更が起きるようなケースでは、関連箇所に対する変更通知が確実でないと、デグレードが起こる。
このとき、関連箇所が全部確認できていれば、そこに通知するだけで問題ないが、そもそも、関連箇所全部が見えていればインターフェースの仕様変更って言うのはそんなにおこんないわけで、それが起こるということは、なんらかのインターフェース設計に問題があるって言うことになる。
なので、その辺、体制を立て直さないと、デグレードになるリスクが多い。
これを防ぐには、リグレッションテストで、はじけば良いわけなんだけど、そのリグレッションテストも全部やっている時間がない。
で、そのために、ある程度の自動化って言うことになるけど、インターフェースが頻繁に変わると、この自動化も、たいへんになる気がする。。
なんで、たぶん、やってないだろう。。
そーすると、修正したときに、デグレードになってしまい、信頼度成長曲線は、わけわかんないことになってくる。
で、この場合、バグが収束するか、発散するかの決め手は、主線が、どうなっているかによるんですけどね。主線が、発散しなければ、どうにかなるし、逆に主線が発散してしまう(あるいは、矛盾がおきたり、できなくなってしまう)と永遠に発散してしまう。
この場合、主線が固まると、急速にバグは収束する。
で、主線ってなに?っていう話になってしまうが、それはまあ、今回は置いておくとして(気が向いたら書きます)
てなわけで、信頼度成長曲線をそのまま信じるのは危険だし、
「なんでデグレードするんだ!」っていう上司に限って
デグレード対策してない(だから、デグレードするんだよ)し
そもそも、なんで、上司の問題なんだ?って聞いちゃいそうだし。。
念のために、この問題は、今度説明しておくか。。
簡単に言うと、インターフェースは担当者では読みきれないのよ。
インターフェースは、対外に関するので、対外との交渉担当である
マネージャーじゃないと管理できない。
でも、問題は、その対外担当のマネージャーが、自分の仕事を理解できない
構造にあるって言うこと(これは、昔は違った)なんだけど。。ね。