地震で被災された皆様、復旧を心よりお祈り申し上げます。
さて、そんな天災のような「予想外の要因でシステムが止まる場合」というのをふと考えていました。システムを作る側、提供する側はどこまでのことを「想定して」くみ上げていけば良いのでしょうね。
昔、某日本最大手通信会社で某テレホンショッピング受注システムの設計を担当したときの話なのですが、当時の言語はANSI-CでWindows3.1のMS-Cコンパイラ、DBはNT3.51上のOracleでミドルウェアにPRO*Cを使った開発、当時すっげー最先端、でした。この時用意した「想定範囲」は「商品種類1023個」「受注個数一商品辺り999個」としました。まぁ「Ｃ的にキリのいい数字」＆「画面入力３桁までＯＫ」ってヤツですね。ところがこれについてモメにもめたんです。「想定範囲を超えたらどうするんだ。エラーにする気なのか？ そんなことはできない。顧客の注文はすべて受けねばならないのだから制限をなくせ」というのが担当された窓口のＳＥさんの意見。この人のハンコがないと設計が決まらないと言うのに、当時の私からすれば「斜め上」のクレームで頭を抱えたわけですね。私の意見は、「一回の電話注文で「一種類999個以上の注文をする」「商品種類を1024種類以上する」一般人がどれだけいて、それに対して販売会社側は外商も営業も立てないでハイハイと受注するのか？」と。あくまでもシステムは「対一般顧客」であって「対業者」でもなければ「対バイヤー」でもない、それが前提で要件もそうなってますよね？と。
最後には担当窓口ＳＥさんの上の方まで列席して、４時間、延々と私はしゃべり続け、結果、「想定範囲」は「商品種類1023個」「受注個数一商品辺り9999個」、それを超える注文の場合は受けられないことを設計書およびマニュアルに明記することで同意ができました。でも今だ思うのです。「一注文あたり一万個の商品を1024種類、一回の注文でお願いしてくる一般顧客」ってホントにいるのだろうか、と。もし、そんな顧客が出たら、それこそ、今回の地震のような「予想外の斜め上」な出来事なんじゃないのかな、と。
その上限が妥当なのかどうかを検証する手段が当時どれくらいあったのか、全く持って不明なのでくわしくはツッコめませんが、いくら上限を持ったところで、超えられちゃったらどうしようもないと思うんだけどな、と思う私がここにいます。