想定外を想定する思考
ソフトウェアの開発を行う際には、通常、何らかの想定を行う。システムの動作環境、利用者の使い方、満たすべき仕様や性能について想定を行い、その検討の結果は仕様書のような形で表現され、当事者間の合意を得ることになる。何でもかんでも対処可能な万能システムは存在しないから、（軍事用など特殊な用途を除いて）商業ベースの開発ではその想定を元に合理的な仕組みを構築することになるわけだ。
しかしながら世の中想定通りに物ごとは進まないので、想定していないことも多々発生する。処理負荷増大、ハードウェアの障害、ユーザの誤操作など、良く起こるタイプの事象に対しては経験則も効くし、ある程度上手い対応が可能なのだが、中には「今まで一度も起こったことがない事象」あるいは「滅多に起こらない事象」もあり得る。そんな時にはどのような対処が適切なのだろう？
「たしかにあの件はバグだが、日本信号のある人に聞いたら想定されないユースケースだったと言っていた。そういう場合はどうやってテストで未然に防ぐのですか」
想定されないバグ：知識ゼロから学ぶ ソフトウェアテスト：So-netブログ
この業界に長くいると、だいたいの質問に対して水が流れるように答えることができる。ただこの質問はちょっと困った。
システム稼動の前提条件が崩れてしまう状況においては、システムでの正常な対処も不可能になってしまう。他への影響が及ばないように速やかにシャットダウンし、後は人間の適切な対処を待つというのが一つの対策案だろうし、影響範囲を局地的に抑えこんでシステム全体では動作を継続する場合が適切な場合もあるだろう。
大切なのは「想定の範囲内でシステムを作ることは必要不可欠だが、思考としてその範囲内に留まっていては行けない」ということかも知れない。ここまでは想定内、ここからは想定外と、境界線を引いて終わってしまうようでは、想定した状況の外側に思いを巡らすことが難しい。想定していた条件が成り立たない場合、一体何が起こるのか徹底的に考え尽くす執念が必要なのだろう。
「今回の地震で何が想定外だったか、いま一度、『棚卸し』すべき。インターリスク総研の小柴利夫・上席コンサルタントはこう指摘する。今回の原発事故のように自社では解決できないことは起こり得るが、想定外の事象を整理することで、さらなる対応策を協議したり、その課題を解決できるパートナーを探したりするなど、想定外を潰すことはできる。
http://business.nikkeibp.co.jp/article/topics/20110404/219293/
もっとも、そんな公には想定外の事象も、実際の現場でモノづくりに関わった当事者にはごくアタリマエの常識だったりする。ちょっとした技術者なら、リスク評価のためにいろいろな状況を考えるものだし、可能性が低い事象に限って「もし起こってしまうととんでもない結果になる」ものが多いので、念のためのバックアップ策を練っておいたりする。
費用対効果を検討した結果として、対策の実施が割に合わないのなら（それはそれで合理的な結論だ）、その判断を下したリーダーの責任になるのだが、そもそも何も考えていないのであれば判断の下しようがない。起こりえない状態だからこそ事前に考えておくことが必要なのだし、日頃から考えているからこそイザという時においても状況判断が可能になるのだ。
事故が明るみに出るたび、間違いが許されない業界では、「俺たちの番でなくてよかった」なんて、エンジニアが首をすくめる。想定外が発生して、ようやく現場は、「想定されていた想定外」を語ることが許される。
http://medt00lz.s59.xrea.com/wp/archives/1097
なお、専門家が「想定外」と言い訳をするようでは、それはプロフェッショナルとしての敗北であり、自らの能力不足を認めるようなものではないかと思う。普通の人が思いもつかない状況にまで考え尽くし、あらゆる状況に対してリスク評価を行って、それぞれ適切な手立てをおこなうからこそ専門家としての存在価値がある。想定外を連呼するだけなら素人でも可能だ。政治的な要請により、又は組織からの圧力に負けて、自らの意見を封印したり思考を止めてしまうようでは専門家としての責任を果たしてないと思っている。
想定外という言葉を使うとき、専門家としての言い訳や弁解であってはならない」。土木学会など3学会は、こうした内容を盛り込んだ共同緊急声明を発表した。東北関東大震災や福島第1原発事故について「想定外」を繰り返す東京電力や菅直人首相らに対し、専門家らが苦言を呈したようだ。
「『想定外』言い訳に使うな」 土木など3学会、声明で苦言 : J-CASTニュース
関連
