要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

IPAの非機能要求グレードの小項目を理解する(No4/119:目標復旧水準(大規模災害時))

[No1][A.1.4]可用性>継続性>目標復旧水準(大規模災害時)

今回は、目標復旧水準(大規模災害時)だ。

想定したくはないものだが、想定しておかなければならない。大規模災害というのは必ず発生する。大雨洪水で電力の供給や通信線が遮断され、システムが稼働できなくなる場合もある。地震や火災でデータセンターが破壊されてしまう場合もある。それでもいつかはビジネスを再開せねばならず、再開までの目標を決めておかねばならない。

req-definer.com

先の記事で業務停止時における目標復旧水準について説明したが、そこでの目標復旧水準と今回の目標復旧水準で異なる点は、障害の度合いの大きさという点だ。大規模災害の場合、そもそもインターネット回線もつながらなかったり、電力供給すらないことはありえる。それらのインフラがいつ復旧するかどうかすらわからないのに、目標復旧水準といわれても難しいところであるが、ある程度の復旧目標だけは決めておかねばならない。

対象のシステムが社会インフラに関わるシステムであった場合は、数日でなんとか復旧させねばならないし、対象が社会インフラと関わらないシステムであった場合は、数か月動かなくてもなんとかなるかもしれない。要は、そのシステムがないと社会として困るのかどうかで災害時における目標復旧水準が異なる。

目標復旧水準(大規模災害時)についてのまとめ

f:id:req-definer:20220204211213p:plain

[No4][A.1.4]目標復旧水準(大規模災害時)

上図に、目標復旧水準(大規模災害時)についてまとめたものを示す。正直なところ、大規模災害といっても定義が広すぎて検討しようもない部分もある。隕石が落ちてきてデータセンターが壊れたら、そもそも復旧どころではない。なので、今回の水準は、あくまでも目安となる。水準を守れなかったといっても、システム提供側に落ち度がなければ許されるものであると考える。それでも目安は必要であるので、顧客とあらかじめ決めておこう。

結論:大規模災害が起こった時のことについて話し合っておこう