前回の話はソフトウェアには「こびと」がすんでいるが、
その「こびと」の正体はソフトウェアに求めたインテリジェントな対応に対する一つの回答であり、
その良くない反応がバグにすぎない
という話である。
したがって、いままでのケースの網羅によるテストではうまく機能しない。
ケースが多すぎて把握するのも、その状態を作るのも非常に手間がかかるからである。
では、どうすればいいのか?
私にも解答はわかりません。
だったら、バグは事前にはわからなく、事後にしかわからない。
と割りきると
バグが起きた状態を把握することを管理、改善していくしかないと思います。
しかし、あまりにもこれでは場当たりてきですから、予防も考えなくてはなりません。
私の経験ではこびとによるバグが関連するバグは以下に対する不理解だったと思います。
1.社会的モラルに準拠するために出来ないこと
2.ビジネスモデルてきに意図的にやらないこと
3.経済的に社会がついてこれないこと
4.まだ、良い要素技術が確立していないこと
5.論理的に矛盾していること
これらを作った時点で考えて誰かがある目的で誰かの為にこびとを世の中に送り出したわけですから、
これらの理解をしようとすることはバグを作りださないことに役立ちます。
そして、広くひろまって、実績があるものは自分たちのBESTな案ではなく、BETTERだというだけで、
そしてそれを判断するには技術力より社会力のほうが重要だということです。
そして、それはいまではなく作り出されたときの状況下の判断力も必要だということです。
3,4,5は技術者は得意なのですが、1,2はわかっていても領域外ということで、
無関心を装ってしまいます。
そして、本来1,2が得意な人たちは、3,4,5が苦手で、それが正しい判断なのかが判断できずにいます。
ドッグイヤーと言われるIT業界ですが、
根本のところは変わっておらず、すでにたいていの問題にはなんらかの解決方法が提示されている現状では、
あたらしい技術用語にびびらない図太さと、社会とのコーディネート力が結果としてソフトウェアのバグを作らないということにつながるのではないか・・・
結局、コンピュータが生物(つまり人間)を模倣しようとしている以上、
その理解の方法も人に対する理解方法と同じようにするしかないのではないか?
バグの削減も、人(自分)の失敗も同じような管理になっていくのかな・・・
だから、バグを作らないために行動することが、新たなステージになるようにしなければならないと思うのです。


