 | |
| 九份(台湾） |
大規模なシステム開発では、日常的に問題が発生し、べらぼうな数に上る場合があります。
もっとも、筆者が現役で従事していた頃と比べ最近は開発手法が進歩していますし、また筆者が従事してた分野は自動車系とは異なります。
しかし、本質的な部分は、さほど変わってはいないでしょう。
問題といっても様々であり、簡単なバグから、原因が不明でいついかなる時に起こるかわからず、最後に起きてから２〜３年経ち、もう自然治癒したもの（システムは日々変更されているので、こう言うことは間々あります）と思われたものがある日突然連続して現れたりするミステリアスなものまであります（我々は、そのバグの事を幽霊「ゴースト」と呼んでいました）。
中でも厄介なのが、タイミング関連のバグで、特定の状況下に特定のタイミングの下で発生し、実験室での再現が非常に難しいものです。
こう言ったバグは頻度が極めて低く、例えば、仮に100年に１度しか起こらないとすると、通常の実機テストでは検出はほぼお手上げです。
システムを１００年間使い続けようとするユーザーはまずいないので問題ないのではないか？と言えばさにあらず、仮にそのシステムを１００万台出荷したとすると、市場では年間１万回発生することになり ー （このようなタイミングのバグの影響はパフォーマンスの劣化以外はマイナーなことが多いのですが、それは別途検証する必要があります）ー 、もしそれが重大事故を誘引するような性質のものであれば大変な事になります。
こう言ったバグの検出はブラックボックス・テストでは絶望的で、ホワイトボックス・テストが必須となります。
また、システムの品質を上げるには、テスト等で潜在バグ率を下げる方法（限りなく０が望ましいのですが、残念ながら完全に０にできないのが、現在の技術水準です）だけでは不十分で、設計技法も重大な問題になります。
問題の影響を局所化するためにタイトなモジュラー設計を行う事はソースコードの品質を向上するためには必須であり、またこのおかげで重点管理が容易になります。
必ず問題は潜んでいるという前提からシステムの多重化をおこなう事もよく行われます。
例えば、平均故障間隔が１万年の独立したシステムを二重化し、同時に故障しなければ安全が確保されるとすると、平均故障間隔は１億年になります（非常にラフな計算で、前提など詳細は略）。
また、フェールセーフの設計も極めて有効で、故障する際は安全側に壊れるよう設計することで、安全性を確保します。
自動車の例では、止まらない車よりも動かない車の方が安全という考え方です。
次号に続く
