このユニットの結論
大きな障害のあと、システムは「ある時点のデータ」に戻して再開します。その時点より後に入力したデータは、戻らないことがあります。
業務ごとに「どの時点まで戻せればよいか」を決め、その時点に本当に戻せることを、バックアップの取り方と戻す訓練で確かめることが、データを守る要件の中身です。
1. 何の話か
このユニットは、非機能要件（06-01）のうち、障害のときに失ってよいデータの範囲の話です。
たとえば、午後3時に大きな障害が起き、システムを前の晩の状態に戻して再開したとします。朝から午後3時までに入力した受注や作業の記録は、システムの中から消えています。誰が、何を、どうやって入れ直すのか。そもそも入れ直せるのか。これが「どこまでデータを失ってよいか」という問いです。
2. なぜ必要か
失ってよい範囲が決まっていないと、
- バックアップ（データの控え）を、どのくらいの間隔で取ればよいか決められない
- 障害のあと、どの時点に戻すかをその場で決めることになる
- 戻したあと、失ったデータを誰が入れ直すのかが決まっておらず、業務が混乱する
ということが起きます。控えを取る間隔を短くするほど、費用と仕組みの手間は増えます。
3. このユニットで分かること
- 「どの時点まで戻せればよいか」の考え方
- バックアップと、別の場所へ写し続ける仕組みの違い
- 戻せることを確かめる方法
- データを守る目標で、AIに任せてよいことと人間が決めること
4. 「どの時点まで戻せればよいか」
障害のあと、どの時点のデータまで取り戻せればよいかの目標を、RPO（目標復旧時点）と呼びます（06-01）。
- 「直前まで」なら、失うデータはほとんどない
- 「1時間前まで」なら、最大で1時間分を失う
- 「前の日の夜まで」なら、最大で1日分を失う
どれを選ぶかは、失ったデータを業務の側で取り戻せるかで考えます。
| 業務のデータ（教材上の例） | 失ったときに取り戻せるか |
|---|---|
| 紙の伝票をもとに入力したデータ | 伝票が残っていれば入れ直せる |
| 取引先から画面で直接受けた注文 | 取引先に問い合わせないと分からない |
| 他のシステムから連携で受け取ったデータ | 送り元から送り直してもらえるか次第 |
取り戻す手段がないデータほど、戻す時点を「直前」に近づける必要があります。
止まってよい時間（06-03）とは別の目標です。「すぐ戻るが、1日分を失う」ことも、「時間はかかるが、何も失わない」こともあります。2つを組み合わせて決めます。
5. 控えの取り方の違い
| 方法 | 考え方 | 注意点 |
|---|---|---|
| 定期的なバックアップ | 決めた間隔で、データの控えを取っておく | 前の控えから障害までの間のデータは失う |
| 変更の記録を残す | 控えに加えて、その後の変更を順に記録し、控えのあとに足していく | 記録そのものを守る必要がある |
| 別の場所へ写し続ける | データを別の場所へ、ほぼ同時に写し続ける | 誤った操作や壊れたデータも、そのまま写る |
最後の点は見落とされがちです。別の場所へ写し続ける仕組みは、機器の故障や災害には強い一方、誤ってデータを消したときは、写した先でも消えます。そのため、写し続ける仕組みがあっても、前の時点に戻せる控えを別に持つのが一般的です。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 10年分のデータ移行
- 約36本のシステム連携
- Vendor B / クラウドブリッジの担当範囲に、クラウド基盤が含まれる
アステリア案件の業務ごとの目標復旧時点、バックアップの間隔・保管場所・保管期間、別の場所へ写す仕組みの有無は、正本に記載がありません。未確定 バックアップを誰が担当するかも、正本に記載がありません。未確定
6. 戻せることを確かめる
控えを取っていることと、控えから戻せることは別です。一般的には、次を確かめます。
- 控えから、実際にデータを戻す手順を試したか
- 戻したデータが、壊れずに業務で使えるか
- 戻す作業に、どれだけ時間がかかったか（止まってよい時間に収まるか）
- つながっている他のシステムと、戻した時点がずれたときの扱いを決めたか
最後の点は、システムが多くつながっているほど大切です。自分のシステムだけ前の晩に戻すと、その後に送り元から受け取ったデータや、送り先へ渡したデータとの間に食い違いが生まれます。どちらのデータを正しいとし、どう送り直すか（07-05）を、あらかじめ決めておきます。
7. THINK — 「クラウドだから消えない」
（教材上の例）データを守る目標を決める打ち合わせで、次の発言がありました。
「クラウドの上に置き、別の地域にも自動で写しているので、データが消えることはありません。バックアップの目標を別に決める必要はないでしょう。」
問題
この考えで、目標復旧時点を決めずに進めてよいでしょうか。
判断例を開く
判断
進めるべきではありません。
確認すること:
- 誤って消した・上書きしたデータも、写した先で同じように消えないか
- 前の時点に戻せる控えはあるか。どのくらい前まで戻せるか
- 控えから戻す手順を、実際に試したことがあるか
- クラウドの事業者が守る範囲と、自分たちが守る範囲はどこで分かれているか
写し続ける仕組みは、故障への備えの一つです。誤った操作や壊れたデータへの備えとは別に考えます。
8. よくある失敗
- 控えを取っているだけで、戻す訓練をしていない
- 業務ごとの違いを見ず、全部のデータを同じ間隔で守る
- 戻したあとに失ったデータを、誰がどう入れ直すかを決めていない
- 連携でつながる相手のシステムと、戻す時点のずれを考えていない
9. 成果物との接続
- REQ-003 非機能要件一覧：業務ごとの目標復旧時点と、確かめ方を管理する
- OPS-008 災害復旧計画・訓練結果：どの時点まで戻すかの計画と、実際に戻せたかの訓練の結果を残す
- CUT-003 切り戻し計画書：本番切替に失敗したとき、どの時点の状態に戻すかを決める
10. AI WORKFLOW — 業務ごとの「取り戻せるか」を整理させる
指示例:
「次の業務の一覧について、業務ごとに、①入力されるデータの元（紙・画面・連携など）、②失ったときに取り戻す手段の候補、③業務の担当に確かめる質問、を表にしてください。目標復旧時点やバックアップの間隔は提案しないでください。」
11. REVIEW — AIの整理を確認する
- AIが、目標の時点や控えの間隔を書き足していないか
- 「取り戻せる」とした手段が、実際に業務で使えるか、担当に確かめたか
- 連携で受け取るデータの扱いが抜けていないか
12. 人間が判断すること
- 業務ごとの目標復旧時点
- 控えの間隔・保管場所と、それにかける費用
- 戻したあとに失ったデータを入れ直す担当と方法
13. 判断演習
あなたの部署では、社外の研修の申し込みを画面で受け付けています（教材上の例）。
障害でこのシステムを前の晩の状態に戻したとき、何が起き、誰が何をする必要があるかを書き出してください。そのうえで、前の晩に戻す目標でよいかを考えてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
データの守り方は、「どの時点まで戻せればよいか」を業務ごとに決め、その時点に戻せることを訓練で確かめることです。
控えを取っているだけでは足りません。戻したあとに失ったデータを誰がどう取り戻すかまで決めておきます。