第55回コラム
「想定外と設計値」
情報アーキテクチャ専攻 教授 南波幸雄
「想定外と設計値」
東日本大震災およびそれに伴う津波、東京電力福島原発事故などを契機に、想定外という言葉をよく目にするようになった。残念ながら想定外は、言い訳と責任逃れに使われているように思われる。「想定外の津波の規模だったので、対処できなかった」とかいうようなものである。この裏には、自分たちは想定の範囲で対応できるように設計し構築したので、想定を超える事態に対処することは自分たちの責任ではなく、想定値を策定したものの責任である、と言っているように聞こえる。
ギネス規模の防潮堤も、残念ながら今回の津波には無力であった。だからといってそれ以上の規模の防潮堤を作ることが、現実的な解になるとは思えない。何事もコストと便益のバランスのより決められるからである。仮に30mの津波に耐える防潮堤を作ったら、絶対に安心か。それでも45億年におよぶ地球の歴史のタイムスパンで考えれば、それ以上のものが「絶対に」来ないとは言えない。
工学的な観点から考えれば、設計値は起こりうる確率と、起こった場合の被害コスト、対応するためのコストなどを考えて決定される。三陸地方に設置されていた防潮堤でも、今までの規模の津波に対しては、有効だったのである。また今回破壊されたものでも、少なくとも破壊されるまでは、津波のエネルギーの一定部分は吸収し、ない場合に比べて津波が町を襲う時間を遅らせた効果はあったと思う。
情報システムの世界にも、想定外は良くある。例えば要件の考慮不足であったり、予期できないシステムの挙動や外部脅威の発生であったりする。
要件の考慮不足は、経験の浅い設計者が対象とするビジネスを十分に理解していない場合に多く発生する。これを避けるためには、ユーザーの要望、要求だけでなく、その背景になるビジネスの状況も含めて把握し、要求の内容を理解したうえで、これを要件（仕様）としてまとめなければならない。しかしこのようにしても、StandishグループのCHAOSレポートは、構築されたシステムの機能の内、ほとんど(rarely)使われていない機能と全く(never)使われていない機能の合計は、64%もあると報告している。
こうなると一所懸命努力して、仕様漏れのないように最大限の要件をまとめると、実際には使われない機能を設計・構築していることになる。これは費用の無駄であり、納期の長期化につながり、結果的にシステムの複雑化に起因する品質低下の要因になりうる。
予期できないシステムの挙動はいろいろとある。いわゆる潜在バグの様な問題は、テスト漏れで発見されていなかったバグが、使用環境の変化により顕在化することである。またシステムの負荷が、使用条件が変わったりある範囲を超えると、急激に増加して、スローダウンしたり停止してしまったりすることもある。これに関しても事象が出現すると、テスト不足だとか仕様環境の想定が正しくなかったなどを批判される。
最近騒がれている標的型ウィルスのような、予期せぬ外部脅威の発生は、ウィルス対策ソフトウェアに頼っている、ウィルス対策を無力化するインパクトがある。こうなると今までの入り口で防ぐ考え方から、出口を見張って脅威が侵入されていないかを確認する事後対策の併用を考えなければならない。
これらの事象は本当に設計者、開発者の問題なのであろうか。確かにそういわれても仕方がない状況は多々ある。しかし必ずしもそうでない場合もある。
システムを設計するときは、当然使用環境を想定し、それをカバーできる設計値を決め、それで定めた条件をクリアできるように構築し、テストで確認する。このときに何を設計値として取り入れ、何を落とすかは、設計者のセンスに求められる場合もあるが、多くは経済学的な費用対効果により決定される。
こうなると設計値は、そのときの使用環境とそのシステムのライフタイム内の使用環境の変化を予測して決めざるを得ない。しかしそうしても、外部環境が予測外の変化をすると、設計の元となる条件が変わってしまうことは否めない。結局想定外が出現してしまうのである。
想定外の事態が勃発したときに、想定外を嘆いても何にもならない。直ちに対策をとらなければならない。これは津波の場合は、安全なところへいち早く逃げる事であり、情報システムの場合は、事態に対処し、影響の拡大を防ぐとともに、影響範囲を特定することである。
これを可能にするということは、備えておくことができないことに対処するわけであるので、最終的に現場の対応力（現場力）に依存することになる。言い換えれば組織能力を高い状態に保つことが求められている。しかし組織能力は、一朝一夕に高めることはできず、不断の努力が必要となる。これは最終的にマネジメントの問題に帰結するのである。その意味でもCIO（情報担当役員）の役割が重要になる。