No.116: ワーストケースに対応しなければならないとき
prjmc staff
前回、ノーマルケースとワーストケースを区別するという話をさせていただきました。ワーストケースを考慮して通常的にそれに対応しようとすると、不必要に期間やコストを消費してしまうので、時と場合によってはノーマルケースだけを前提としたものとし、ワーストケースは別立てで考えるというものです。
これはリスク管理の一部と言えるかも知れません。リスクは、潜在しているもので、顕在化した場合に備えて予防措置を含めた何らかの対策をしておくものです。ただし、必ず発生するとは限りません。発生する確率が非常に低い可能性もありますし、発生しないままで終わり、心配が杞憂で終わることも多いでしょう。その様なリスクは、万が一発生してしまった場合は受け入れてしまうという判断も十分あります。
しかし、もし発生してしまった場合にその影響や被害が甚大である場合、人命や事業の存続に関わる様な場合は、そうはいきません。
私は、企業に勤めていたときに、このワーストケースの摘出を漏らし、将来に重大なインシデントを引き起こしたかも知れなかったプロジェクトを経験しました。
ある社外の会合に参加していた時に、営業担当から緊急の電話が入りました。確か、当日その営業担当は顧客先でシステムの引き渡しに立ち会っていたはずでした。引き渡しの最中に営業担当から入る電話といえば、現場で対処できない重大な問題が発生したという連絡にほぼ間違いありません。
顧客は、大規模な施設を運営しており、私の部門から当該施設内の各部屋の入退室を管理するシステムを導入するところでした。それぞれの部屋で重要な情報や材料を扱っているので、部外の人間が入れないよう、入室を、場合によっては退室もICカードや生体認証を使って行うというものです。
問題は、引き渡しの際の動作確認の一つとして緊急解錠試験を行った時に発生しました。これは火災の発生など緊急事態の時に、中央制御室からの操作で全扉を解錠するという機能です。部屋の中にいる人は、いざという時はサムターン(ホテルの非常階段等にカバー付きで設置されていたりするもの)を使用して退出できますが、その様な手間をかけずとも直ちに脱出できる様になります。また、延焼中に消防士が各部屋をまわって取り残された人がいないか確認することを可能にします。
導入したシステムは、緊急解錠の手段として中央司令室のコンピュータから各扉のコントローラにネットワークを通して解錠の指令を出していたのですが、いくつかの扉においてそれが届かないケースが発生してしまったのです。
営業担当から連絡を受けた私は、ただちに状況を理解しました。原因は明らかでした。ITに詳しい方であれば理解いただけると思いますが、ネットワーク上の通信手順には、時間はかかることがあるが確実に相手に届けることができるプロトコル(TCP)と、直ちに送信するが確実に相手に届くかは確約できないプロトコル(UDP)があります。緊急解錠に使用しているプロトコルは後者でした。
出荷前に社内の環境で実施したテストでは問題はありませんでした。しかし、そのことが顧客のサイトにおける本番の環境で同じ様に動作する保証にはなりません。ワーストケースに対する考慮が欠落していたのです。システムの出荷までに何度かデザインレビューの機会がありましたが、残念ながらそこに注意が向かうことがありませんでした。大いなる反省です。
電話の向こうで顧客側の面々をお待たせしている状況でもあり、ネットワーク上の通信を使って緊急解錠の指令を行うのではなく、中央司令室から全扉まで専用の信号線を引いて、直接緊急解錠信号を送る様に追加工事することを即決しました。
その工事にはさらに1ヶ月以上の期間を要し、顧客へのシステム引渡しを遅らせてしまいましたが、滅多に発生しないケースであっても、いざ火災の時にその様な事態になってしまっては人命に関わります。
システムのライフタイムの間に火災が発生することはそう起こり得ることではないし、発生したとしても緊急解錠は全て正常に動作するかも知れません。しかし、万が一の事態が発生した時に、システムが原因で人命をリスクに晒すわけには絶対にいきません。引き渡し確認の段階で見つかって良かったと思いました。
これも、ノーマルケースとワーストケースを分けて考える一例です。ノーマルケースと同じ方法では対処できないので、ワーストケースに特化した対応を、追加コストを発生させて行ったのです。
あなたの組織では、プロジェクトが実現するものの前提条件として、ノーマルケースとワーストケースを意識しているでしょうか。安易に見過ごして、将来に禍根を残す様なことになっていないでしょうか。
