１１１．システム障害と信頼性の確保（1,440字）

先週金曜日（10月12日）、首都圏の鉄道で自動改札機が使用できなくなるという大規模トラブルが発生しました。

当日朝のニュースでは一部の駅に留まるような報道でしたが、自宅の最寄駅に入ると、すべての改札機が全開状態で、ＩＣカードをかざすこともなく、素通りできました。

そして、会社側の最寄駅に着くと、こちらも同じく全開状態で、素通りして改札口を出ました。

その日の夜のニュースでは、トラブルの原因が判明しており、またもや、ソフトウェアに起因したものだと報道されていました。

昨今は、コンピュータとネットワークが強固に結びついているせいか、システム障害と称するトラブルが続出している感が強くあります。

この１年あまりを振り返ってみても、重大かつ大規模な事例に事欠かないことがわかります。

一例として挙げれば、
ＩＰ電話、航空座席予約、パスモ、ＴＯＴＯｅｔｃです。

システム障害の特設サイトはこちら
http://itpro.nikkeibp.co.jp/99/trouble/index.html

一つひとつの事例には、色々な原因が存在し、また分析も成り立つことだと思います。ここでは、自分なりに経験上から考えてみることにします。

＜原因＞
　①システムが大規模化、かつ複雑さを増している
　②低コスト、かつ短納期の案件が増えている
　③開発や構築案件の増大で、技術者が不足している
　④オープンシステム化で機器同士の結合度が下がっている

＜結果と事象＞
　①システム全体を把握・理解している技術者が少なくなっている
　　→部分から全体は類推できない
　②社内外双方からの要求の増大により、プロジェクト内は一種の混乱状態
　　に置かれている
　　→テスト不足や打ち切りが起きる
　③従前以上にプロジェクトメンバが混合部隊で構成されており、一体感や
　　質的維持ができなくなっている
　　→プロジェクトの完成や品質保証ができない
　④マルチベンダー（複数メーカ製品）の採用は、相互の機器の検証や保証
　　を十分でなくした
　　→表面上は標準規格の採用で問題は少ない筈だが・・・。

こうして問題点を列挙して行くと、それなりに原因はつかめるのですが、解決に向けてとなると困難さがつきまといます。

今回の自動改札機の例のように、一部ベンダー（供給者）のみが該当することも多いのです。先例のＮＴＴや全日空のときもそうでしたが、一部の機器を入替えたために障害や不具合が起きてしまうことも少なくありません。

こうした事例では本稼動しているシステム全体を動かしてテストし直すということが現実にはできないのです。

従って、部分的にテストして動作確認を行ないます。しかし、それが成功したからと言って、全体の動作を保証することにはならないだけに、とても厄介です。

システムの信頼性を高めるためには、顧客の要求事項を細部まで明確に詰め、十分な時間と労力を使ってテストを繰り返し、もう大丈夫と言えるまで精度を高めて、本番へ移行しなくてはなりません。

ところが現実は、要求事項を詰めるまでに時間がかかり、その上、途中で変更が入るのが普通で、引渡しの期日は迫って来て、間に合わせや徹夜でのテストを実施し、期限ぎりぎりに滑り込むということが日常茶飯事の状況です。

システム開発や構築が労働集約的作業である限り、こうした状況に大きな変化はやって来ないかもしれません。

もう少し、電源コンセントを入れるだけのプラグアンドプレイやソフトウェアのモジュール化が進展することがこうした事態を少なくする一つの鍵であると思います。

ただ言うは易し、行なうは難しで、もっと色々な要素技術が進歩しなくては現実にはなりません。