ゼロディフェクト運動の悪影響(20061005)

2006.10.5

ゼロディフェクト運動の悪影響…

　前回は、突然、ＩＰ電話“トラブル”の話になってしまったが、品質問題を考える上では教訓として学ぶ点は多い。品質に関する技術が大きく変わりつつある理由の2つ目、プログラム問題の典型でもあるからだ。
　　→　「品質担保に於ける技術の錯綜問題」 (2006年9月28日)
　　→　「ＩＰ電話トラブルを眺めて」 (2006年10月2日)

　電話網のような話になると、事業はサービスであり、一般商品の開発に必要な技術とは大きく違う印象を持つが、プログラムが品質を左右するという点では同じことである。
　いまや、ソフト(プログラム)が商品の機能を決めるようになっているから、ソフトの品質が大きな影響を与えるということ。

　問題は、ハードとは違い、ソフトの品質を図る方法が確立されていないため、未だに試行錯誤が続くこと。　例えば、徹底的にバグ取りをせよ、というだけでは、どの程度なら十分なのかわからない。しかし、そんなマネジメントをよく見かける。

　ケータイなど文字通り、徹夜の連続でバグ潰しに当たる。だが、それでも問題は発生する。バグ無しを保証できるプログラムなど、夢の世界に近い。
　巨大な通信インフラは高度なコンピュータと複雑なプログラムで動くが、同じ通信分野であっても、小さなチップと組み込みソフトで動くようなケータイの如き小さな商品とは違うと思ったら大きな間違いである。どちらも、同じようにバグが発生しているのだ。

　どんなものだろうが、コンピュータはダウンすることがある。それがこまるなら、それに対処した仕組みをつくるしかない。これが原則である。インフラだろうが、端末だろうが、関係ないのである。
　バグゼロもあり得ない。すべての条件で問題なく稼動することを確かめるには膨大な時間を要するから、できる訳がないのである。バグを除きにいくら努力したところで、考えていなかった条件下ではトラブルは発生する可能性がある。これは避けられない。

　などということは、言われなくてもわかっている、というのが日本のマネジメントの体質である。それなら、どのように対応しているのかといえば、優秀な人に頑張ってもらう、という以上ではなかったりする。
　これではどうにもなるまい。

　もちろん、どうしたらよいかは知られている。
　バグは必ず発生すると言っても、全体がダウンすることは滅多にない仕組み作りが存在するからだ。これはバグ潰しに力をいれたから、ダウン率が低いのではない。ダウンしても、それが大きな影響を与えないように、上手く設計しただけのこと。全体設計が優れたプログラムなのである。
　これは、ゼロディフェクトという発想ではなく、ディフェクトを容認する設計とも言える。そのかわり、トラブルの兆候をいち早く発見する仕組みを考えたり、トラブルが発生しても重大な問題を引き起こすことがないようにしたり、たとえ重大問題が顕在化してもすぐに対処できる体制を整えることに全精力を注いでいるのである。

　このことは、ゼロディフェクト運動とは、こうした方向に水を指す可能性を示唆しているともいえる。
　目に見える不良や、わかり易いバグ潰しにいくら頑張ったところで、全体の質は向上しないからである。絨毯爆撃的なバグつぶしは、“浅知恵”に陥りかねないということ。又、そんなバグ潰しをやればやるほど、全体設計のノウハウを身に着けることから遠ざかる。
　錯綜するプログラムは、どうモジュールに分けるかが先ず勝負なのであり、ゼロディフェクト運動同様の発想はモジュール内での話なのである。

　ところが、すべてにゼロディフェクト運動を持ち込もうと考える人がいる。なかには、バグが出ないようなプログラム書きのサポートシステム構築を狙おうとの正論もあるが、大半は、古典的な精神論。細かなミスを許すな式の運動と見て間違いない。
　お蔭で、全体設計の工夫はできない。

　しかも、プログラムといっても、現実の利用場面は“電子回路上”。そこには様々な物理的な要因がからんでくる。そこでも何が発生するか、わかったものではない。異常が発生したら、防止できるようなプログラムを考えている商品は僅かである。正常な環境を前提とした、理想的な“ゼロディフェクト”プログラムを目指して人を育成してきたから当然かも知れぬ。

　例えば、船の遭難信号と同じ周波数の電波がコードレス電話から発信されるトラブルが相次いでいるそうだ。特定の条件の時だけ発生するのだが、そんなことは予想だにしていなかったに違いない。⁽¹⁾

　要するに、漫然とゼロディフェクトを要求するような技術マネジメントはマイナスに働くようになってきたのである。
続く　→　(2006年10月10日予定)
　--- 参照 ---
(1) http://www.ntt-east.co.jp/release/0609/060926.html

　技術力検証の目次へ＞＞＞　　　　トップ頁へ＞＞＞