と言うお客さまの要望があった時、ＩＴエンジニアであるみなさんは何を考えますでしょうか。いや、むしろそこからゼロベースで考え始めているようではエンジニアリングとしてまだまだ未熟かもしれません。

もちろん実現方法は色々ありますからそこは考える必要があるのですが、「２４時間３６５日稼働」という具体的な要求事項はともかくとして、こうした長時間稼働することを前提とした信頼性品質を

　高可用性(High-Availability)

と言って何十年も前から存在するものであり、ニーズとしてあるのですから慌てるようなものではありませんし、ニーズとして明確化されていなくてもお客さまのビジネスモデルに照らして一般的に検討するものです。

可用性とは「継続して稼働できる能力のこと」のことを指します。

もっと噛み砕いていうと「使いたい時に使える状態が日頃から維持できていること」と言えます。こうした要望を織り込んだシステムやソフトウェアを導入されるユーザー企業において利用目的はさまざまですが、たとえば業務システムであれば「会計」「人事」にはじまり「生産管理」や「受発注」など、企業を支える基幹業務で利用されていることが多いでしょう。

中でも国内企業だけでなく、海外拠点などを置かれているグローバル企業であれば時差の都合上２４時間３６５日稼働するシステムの導入要望は、いちいち聞き取りをしなくても火を見るより明らかで、むしろ要望が出てくる前に察してこちらから提案するかあるいは最初から想定した見積りになっていなくては話になりません。

そんなシステムであれば、『システム停止』が即業務の停止やサービスの停止に直結するケースも少なくありません。ビジネスに支障をきたす可能性も考慮に入れる必要があります。

業務やサービスが止まるということは、その時間の売上が下がるということです。これが銀行であれば、利用者の生活にも支障が出るかもしれません。

たとえば、年商１００億の企業だとすると、年間およそ２００営業日だとして業務を１日止めれば0.5億の損失になりかねないということです。

24時間365日止まらない高可用性システムを構築したい、というユーザー企業が多いのも当然だと言えます。

そのようなシステムであれば元来「停止」させてはいけないのですが、10年も20年もビジネスモデルが変わることなく、ソフトウェアを更新するでもなくずっと使い続ける…と言うのは不可能です。

ビジネスモデルはいずれ必ず変わりますし、システムに改修を加えなくてはならない時期も来るでしょう。その際にはシステムを停止しなければならない日もくるはずです。

ゆえに、高可用性システムには必ず

　計画停止
　計画外停止

の２つについて検討しなければなりません。

「計画停止」には大別すると

　・データメンテナンス
　・システムメンテナンス

の２種類があります。先ほど言った「ビジネスモデルの変化」によるシステムの改修などはシステムメンテナンスとなります。データメンテナンスはたとえば、「銀行窓口やＡＴＭで15時以降に振込むと翌朝に振り込まれることになる」…のがいい例でしょう。

データは常にリアルタイムに処理されているわけではなく、まとめて一気に処理されている間、システムを停止させなければならないと言った運用ケースもあります。

また「計画外停止」にも２種類あり、

　・システム障害（ソフトウェア障害／ハードウェア障害等）
　・データ障害

があります。それぞれのシチュエーションを想定し、

　「問題が発生しないよう（発生頻度が少なくなるよう）にする施策」
　「問題が発生しても影響が出なくなるようにする施策」
　「問題が発生して影響が出た場合に復旧させる施策」

のそれぞれを検討します。

こうしたことは、ソフトウェア開発に直接関係しないものも含まれます。
視覚的にわかりやすく、MECE（漏れなくダブリなく）表現するなら次のようになるでしょうか。

基幹システムに近ければ近いほどＢＣＰ(事業継続計画)あるいはコンティンジェンシープランとして、いざという時に備えたリスク対策が必要になってきます。

ここまで要件を徹底して固めるからこそ、ソフトウェアとして

　「何を実装すればいいか」
　「どこまでをシステム化すればいいか」

を特定できるようになるわけです。
構成に落とし込むのであれば、次のようになります。

一般的に業務システムなどは、

　「クライアント」
　「アプリケーションサーバー」
　「データベースサーバー」

の３層から成りたっていたりすることが多いですよね。

これはリスク分散の考え方や、ＣＰＵ／メモリの負荷分散を視野に入れているためですが、実際にはどの層が障害となってもシステム停止に直結してしまいます。

昨今、業務時間内稼働を中心としたコアタイムシステムではなく、稼働時間の拡大を主としたモアタイムシステムの要求が非常に増えています。

グローバル展開を見据えたものなのか、社会インフラの利便性を向上するためなのかはわかりませんが、そうした市場ニーズにおいて高可用性システムを当然のごとく視野に入れて、設計検討できるようなエンジニアになっていかなければ、今後

　提案段階で機会損失につながりかねない

と言うことを知っておくと良いでしょう。
　
こうした課題に対して都度検討、都度設計するエンジニアも多いと思いますが、システムやビジネスの多くはある要件に対して、

　検討すべきコト、設計すべきモノ

というのはある程度定型的に決まっています。ビジネスでもシステムでも、おおよそのフレームワーク（型）が決まっているからです。

毎度毎度ゼロから検討しなければならないようなケースは、スキマ戦略やニッチ戦略によって、既存モデルが再利用できないようなケースの場合だけです。

それ以外では、

　どんな現状(AsIs)に対し、どんな理想(ToBe)を求められれば、
　どんな実現方法を検討すればいいのか？
　どんな作業をすればいいのか？
　どんな成果物を作ればいいのか？
　どんな方法で説明すればご納得いただけるのか？

は概ね定型化できます。それができないのは、心理的なバイアス（恣意的傾向）がはたらいているからです。つまり、属人的であることを容認しているがために起きているだけなのです。