「とりあえず東阪災対」という思考停止。〜その事業継続性、本当に必要ですか？〜

ちょっとしばらく思い立ったことがあって、「なぜ」について、言及してしばらくネタを書いていきます。

なぜ？を問わない非機能要件の秘密

システム開発の現場において、最も「なぜ」が問われないまま決まってしまう要件があります。 それは機能要件ではなく、「非機能要件」の領域です。

特に「可用性（Availability）」や「事業継続性（BCP）」に関しては、多くの現場で思考停止が起きています。 「とりあえず24時間365日止まらないように」 「何かあった時に備えて、なるべく堅牢に」 こうした漠然とした不安と期待だけで、莫大なコストがかかる設計が採用され、誰もその理由を説明できないまま運用コストを払い続ける。そんなケースがあまりに多すぎます。

今回は、その象徴的な例である「東阪災対（東京・大阪の災害対策）」について考えました。

思考停止のキーワード「東阪災対」

日本のエンタープライズITにおいて、東京と大阪（あるいは関東と関西）の2拠点でシステムを稼働させる構成は、ある種の「黄金律」のように扱われています。

「要件定義書にDR（Disaster Recovery）必須と書いてあるから」 「データセンターが被災したら困るから」

もちろん、理由が明確なケースはあります。 銀行の勘定系システム、保険会社の事故対応コールセンター、あるいは人命や社会インフラを支えるシステム。これらは、たとえ関東一円が壊滅的な被害を受けたとしても、1秒たりとも止めるわけにはいきません。コストをかけてでも二重化する明確な「なぜ（理由）」が存在します。

しかし、世の中のすべてのシステムがそこまでの重要度を持っているわけではありません。 ここで一度、冷静に問いかけてみてください。

「もし関東が壊滅的な被害を受けている状況下で、本当にその社内システムを大阪で動かし続ける必要があるだろうか？」

社員自身が被災し、避難生活を余儀なくされている状況で、経費精算システムや、緊急性の低い社内ポータルが24時間止まらずに動いていることに、どれほどの意味があるのでしょうか。 この問いに明確にYESと答えられるシステムは、実はそれほど多くないはずです。

「データを守ること」と「サービスを続けること」の混同

なぜ、こうした過剰な構成がまかり通るのでしょうか。 その原因の多くは、「データの保護（Backup）」と「サービスの継続（Continuity）」の混同にあります。

• データの保護（Backup）： これは大抵のシステムで必須と考えられます。データが消えてしまえば、復旧はおろか企業の存続に関わります。したがって、物理的に離れた遠隔地にバックアップデータを転送・保管することは、極めて有効かつ必要な投資です。むしろバックアップ自体を取得していなかったり、遠隔地保管を含む複数サイトへの保管をしていないことは問題です。

• サービスの継続（Continuity）： こちらは、「東阪災対」のように、即時に切り替えられる予備の稼働環境を持つことを指します。

ここをまぜこぜにしてはなりません。

「データさえ遠隔地にあれば、サービス再開は震災から1週間後一ヶ月後でも構わない」という業務であれば、高額なホットスタンバイの待機システムは不要です。バックアップからのリストア手順さえ確立されていればいいのです。

「なぜ」を残さないことが生む無駄

24時間365日の無停止運用も同様です。 夜間に誰もアクセスしないシステムに、深夜の障害対応要員を張り付かせ、高価な無停止構成を組む必要があるのでしょうか。

「念のため」という言葉は、思考の放棄です。 「金融系だから」「昔からそうだから」など、理由のないままに過剰な安全マージンを取り続けることは、リソースとコストの浪費でしかありません。

「なぜ、このシステムにそのレベルの事業継続性が必要なのか？」 「なぜ、このシステムはバックアップだけで十分と判断したのか？」

アーキテクトの仕事は、高スペックな構成図を描くことだけではありません。 ビジネスの要求レベルを見極め、過剰な部分を削ぎ落とし、「やらないこと」を決めること。そして、「なぜやらなかったのか」という決断の記録を残すこと。

それこそが、将来の誰かが「謎の超高可用性システム」に苦しめられる悲劇を防ぐ唯一の方法なのです。