地震前提から脱却せよ
国際規格ISO/IEC27031から学ぶ

ITサービスを継続させる仕組みとしてIT-BCPという言葉が使われるようになったが、多くは災害対策（ディザスターリカバリー）と同じ意味で使われていることが多い。しかし、過去に地震災害などで実際にITサービスが止まったケースがどのくらいあるだろう。

今求められているのは、災害対策のためだけでなく、
ヒューマンエラーを含めたあらゆるリスクから、ITサービスを継続させる視点だ。

■ITサービス継続の国際規格
2011年3月に、IT業務継続計画の実質的な国際規格となるISO/IEC27031（ITサービス業務継続ガイドライン：IRBC）が公開された（ISO/IEC27031：Guidelines for Information and Communication Technology Readiness for Business Continuity）。 このガイドラインは、情報セキュリティに関する国際標準の一部として策定されているが、IT担当者には分かりやすく、IT-BCP（※）の策定ポイントが述べられている。
※：ガイドラインでは IRBC （ICT Readiness for Business Continuity）と記載されているが、本文ではIT-BCPと表示する。

IT-BCPを策定する上では、既に公開されているITSMS（ISO20000ITサービスマネジメント、いわゆるITIL：2005年）とISMS（ISO27001情報セキュリティ：2006年）、そして現在審議中のBCMS（ISO22301事業・業務の継続性）が関係してくる。これらの標準に一部重複する形で、しかもITサービスの継続に関して詳細に解説されているのが、当ガイドラインである。

■BCPは、IT-BCPと連動する
業務継続を求められる重要なビジネス機能は、通常ITに依存しているため、BCPはIT-BCPと連動する。ガイドラインの１つ目の特徴は、ビジネスとの連携を強め、BCMのPDCAサイクルにIT-BCPのマネジメントシステムを組み込むことが強調されている点である。ビジネス側に、IT側の現状のリソース状況、対策に必要なコスト（初期費用と継続費用）と効果、技術的制約等を説明し、ITの回復能力について脆弱点を含めてビジネス側からの承認を求める。ITとビジネスは各々のPDCAサイクルで連携する必要がある（図２⇔の部分を参照）。 

 
■脅威は自然災害だけではない
２つ目の特徴は、IT基盤やシステムに影響があるすべての事象や事件（セキュリティ関係を含む）を想定しており、脅威を地震などの自然災害に特定していない点だ。IT-BCPは全社BCPと同じではない。実際、地震によってシステムが停止し、それが直接原因で業務が中断したケースは、過去にはほとんどない（ただし、将来的にもないというわけではない）。 

ITがビジネスの足を引っ張るという、IT担当者にとっては最悪のケースでの脅威は、①オペレーションミス、②プログラムエラー、③パフォーマンス低下、④情報漏えい、⑤コンピュータウィルスなどである。従って、訓練に関しても代替システムへの切替やシステム回復作業だけでなく、上記①∼⑤が発生した場合の回復訓練が含まれていなくてはいけない。

■緊急時の初動対応こそ重要
３つ目は、IT-BCPの対応フェーズを、予防、検知、対応、回復、改善と定義している点である。BCP関連の他ガイドラインと比較すると緊急時の初動対応に重点が置かれている。十分な予防策を講じた上で、障害の早期検知、被害を最小化する迅速な対応が重要だということだ。図３では、経済産業省の事業継続計画策定ガイドライン（2005年）で定義されているフェーズを左端に記載している。このガイドラインはISO27031と同様、情報セキュリティを発端にしているが、結果として回復フェーズが強調された地震用のBCPが意識されている。

■ガイドラインに加えて考慮すべき点
ITサービス業務継続ガイドラインでも触れられていることだが、業務中断を引き起こし、業務に混乱をきたすシステム障害こそ、IT-BCPで取り組むリスクである。それらのリスクを引き起こす真の原因を以下のようにまとめた。
１.要員に関する問題：担当者のスキル不足、教育や周知不足、プログラム保守やシステム運用の属人化
２.プログラムに関する問題：改修を重ねた複雑なアプリケーションの使用による問題の分かりづらさ
３.システムリソースに関する問題：リソース不足、想定外の大量アクセスの発生、サポート切れソフトウェアやハードウェアの使用
４.予算の問題：システム開発・運用の予算削減によるリスク対応力の低下
５.システム要求への問題：無理なシステム機能要求、短期間での対応、頻繁な例外処理の発生 

個々の問題は互いに関連性があり、まとめて解決することが望ましい。例えば、プログラムの問題は、スキルや予算が問題になることが多く、リソースの問題は、予算とシステム要求が問題になることも多い。そして、これらのITサービスが抱える問題のほとんどは、「ビジネス側からの要求を発端としておりIT部門では断りにくいこともある」。

■ITサービス継続対策としてのクラウド
現在注目されているクラウドによって、ITサービスが抱える問題が解決できないだろうか。クラウドには、①システム資源を保有せず、②ネットワーク上のシステムを使用し、③従量制課金によりスケールアウト・スケールインが容易であり、④実績のあるアプリケーションを利用し、⑤標準的なシステム運用がなされている。また、⑥システムの仮想化、⑦分散処理ができることも特長である（クラウドの提供形態によっては、一部の機能しか実現できないものもある）。 

通常、BCPの観点でクラウドを検討する場合、災害対策を意識したバックアップ取得オプションを含むシステム運用や、障害時の対応に効果がある仮想化、分散処理によるビジネス拠点との同時被災の回避などが注目されている。上記、クラウドの特長の⑤⑥⑦。 

表１は、前述した「ガイドラインに加えて考慮すべき点」を解決する視点でクラウドの他の特長も含めて検証してみたものである。もちろん、現行のシステムをすべてクラウド化するのは難しく、業務のやり方を変更する必要もでてくる。しかし、国内や海外でもクラウドを利用する企業が増えてきている中、クラウドを全く考えないのもリスクではないだろうか。

■東日本大震災から学ぶIT対策のポイント
3月11日に発生した東日本大震災は、広範囲にわたり甚大な被害をもたらした。この貴重な経験を振り返り、現対策の見直しポイントをいくつかまとめてみた。

◆重要IT機器を離す 
データセンターが被災地から離れていたため、データセンターの被害はほとんどなかったと思われる。IT回復作業は、現地のネットワークやPC端末関係が多かった。このことから、少なくとも重要業務拠点とデータセンター（重要IT機器）は、同時被災を回避するためにも離れていた方が有効だと言える。本番センターとバックアップセンターの距離についても、一概に安全な距離は言えないが、例えば電力会社の管轄が分かれるくらいの距離は必要かもしれない。

◆人の移動は前提としない 
バックアップセンターには、なるべく災害発生時に移動することを前提としない方法を検討する。移動する手段がない、キーマンの不在等で移動できる要員がいない場合があるからだ。そのためには、バックアップセンターに常時要員を配置するか、自動化や遠隔操作により移動を最小化する。バックアップセンターに限らず、移動できないことを前提にした業務継続の手段としては、在宅勤務を検討するも有効である。

◆複数のコミュニケーション手段を準備
今回、被災地は通信回線が途絶し、被災地以外は輻輳や発信制限があり、安否確認システムは十分機能しなかった。対策としては、複数のコミュニケーション手段を準備しておくことと、連絡が取れない場合の対応手順を決めておくことが有効だと思われる。前者に関しては、今回の震災で、チャット（Facebook、Twitterなどを含む）やSkypeでの通話は使えたことから、緊急連絡手段に取り込むことも必要ではないか。後者に関しては、連絡が取れない場合は最悪の事態を想定した手順を始める、指示を待たずにできる範囲を決めておくこと、権限委譲などがある。

◆過去から脱却せよ
ITをレジリエンスにすることで、ビジネス継続を支えたいと思う。それには、今までとは異なるIT-BCPの発想が必要だと思う。P.F.ドラッカーの名言「過去から脱却せよ」を「地震前提のBCPから脱却せよ」と置き換えて終わりにする。