バックアップはある。でも、何時の仕事まで戻せる？｜業務システムの再開条件を確かめる

新しい業務システムを頼むとき、「バックアップは取りますか」と聞く。必要な確認です。ただ、「取っています」という返事だけでは、止まった後にどの仕事から再開できるかまでは分かりません。

前日の状態へ戻ったとして、その後に受けた注文はどうするか。画面は開いても、添付した日報の写真が戻らなかったら仕事を続けられるか。控えがあることと、会社として続きを始められることを分けて考えると、開発前に確かめる範囲が具体的になります。

社長は、止まっても早く戻ってほしい。現場は、復旧を待つ間にも届く注文や報告を置き去りにできない。難しい操作を社員に覚えてもらう話ではありません。技術を担当する側と、仕事の続きを確かめる側で、何を確認するかを合わせるための考え方です。

戻る時点と、仕事を再開できる時刻は違う

まず分けたいのは、「どの時点の記録を取り戻せるか」と「再び仕事に使えるまで、どれくらい待つか」です。前者は、控えに含まれる仕事の範囲。後者は、環境を準備し、データを戻し、必要な画面や帳票を確認するまでの時間に関わります。

例えば、前日の夜に取った控えを使うなら、その後に増えた記録を別に確かめる必要があるかもしれません。頻繁に控えを取っていても、戻す環境や担当者の手配に時間がかかることはあります。逆に、早く画面が開いても、昨日までの数量しか入っていなければ、そのまま今日の出荷には使えません。

何分で戻る、何時間分なら失ってよい、という共通の正解は置きません。注文受付、在庫、日報、月次資料では、後から補える情報も、待てる時間も違います。止まると次のどの仕事に影響するかを見て、優先して戻すものを決めます。

IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版・本文33ページでも、バックアップの対象や頻度、保管方法、戻すための手順書の整備を案内しています。保存する道具を選ぶだけでなく、戻す準備も確認する、という出発点として参考になります。

卸の仮定例：在庫を戻しても、出荷した現物は戻らない

ここからの二つの例は、開発前の確認方法を説明するための仮定です。Ｂ．Ｉ．Ｙの顧客で起きた障害や、実際の復旧時間・対応実績を紹介するものではありません。時刻も説明用で、特定のサービスの仕様ではありません。

卸の会社で、注文、在庫、納品書を同じ仕組みで管理しているとします。午前中に商品を出荷した後、午後二時にシステムが使えなくなり、前日夜の控えへ戻すことになった。どこを確認すれば、同じ商品をもう一度出してしまわずに仕事を再開できるでしょうか。

画面の在庫が前日夜の数に戻っても、午前中に出た荷物が倉庫へ戻るわけではありません。受けた注文、準備中の注文、出荷済みの注文を、現物の動きと照合する必要があります。出荷先へ渡した納品書や配送の控えなど、実際に使える資料を開発前に洗い出します。

この例で確認したいのは、復元後に足りない分を、誰が、何を根拠に補うかです。担当者が記憶だけで数量を入れ直す形にせず、注文や出荷の目印を使って、どこまで確認したか残す方法を相談します。控えの取得後に訂正や取消があった一件も含めます。

すでに渡した納品書と、復元後に作り直す帳票の扱いも決めます。同じ番号の書類をもう一度出したとき、単なる再表示なのか、取引を新しく登録する操作なのか。画面の数字が合うことだけでなく、相手へ二重に出荷や請求をしないところまで、再開の条件として見ます。

建築の仮定例：日報の一覧だけで、写真も戻ったと考えない

別の仮定例です。建築会社が、日報の文章と現場写真を業務システムで扱うとします。復元後に日報の一覧は出たものの、記録から開く写真が見つからない。これでは、一覧が戻っただけで仕事を再開できるとは言えません。

システム内の記録と、添付ファイルの保管場所が分かれている場合は、それぞれ何がバックアップの対象なのかを確認します。日報を一件選び、写真、現場との結び付き、必要な帳票までたどれるかを見る。ファイルが何枚あるかだけでは、どの日報の写真かを確かめられないからです。

また、日報は昨日の時点、写真は別の時点に戻るなら、組み合わせに食い違いが残るかもしれません。採用する仕組みで、関連する記録をどの時点にそろえられるかを開発側へ確認します。具体的な復元方法は保存の仕組みで変わるため、ファイルを手で足せばよいと決めつけません。

使う人の確認も必要です。管理者が写真を開けても、現場の担当者が自分の工事を開けるかは別の確認です。普段の役割で必要な記録を見つけ、次の日報を登録し、事務所がそれを確認できるところまで、仕事として試します。

復旧を急ぐからといって、全員へ管理者権限を渡す方法を前提にしないことも大切です。戻す対象には記録だけでなく、必要な設定や利用権限が含まれるのか。再設定が必要なら誰が行うのかを、機能の説明と一緒に聞きます。

止まっている間の仕事を、戻った後に置き去りにしない

システムを直している間も、電話での注文や現場からの報告は届くかもしれません。元の控えを戻す仕事と、停止中に進んだ仕事を記録へ反映する作業は分けて準備します。後者が決まっていないと、再開直後に紙や口頭の確認が集中します。

例えば、停止中の受付を会社で決めた様式へ残すなら、受付日時、対象の仕事、相手、数量、対応した人など、後から照合するための項目を選びます。普段の画面を紙へ全部写す必要はありません。何を受け、実際に何を進めたかを、別の人でも追える範囲にします。

戻った後は、どの控えまで反映済みかを確認し、同じ一件を複数人が入れ直さないよう担当を決めます。停止前の記録がどこまで戻ったか分からないまま、全件を新しく入力し始めない。復元した側の記録と、停止中の控えを突き合わせる順番を相談します。

ここで社長に決めてもらいたいのは、どの操作を再開してよいと判断するかです。例えば、注文の受付だけ先に始め、在庫の確定や帳票発行は照合後にする方法も検討できます。ただし、仕事を分けて再開できるかは、仕組みの依存関係によります。途中の状態を安全に使えることまで、開発側と確認して決めます。

復元の確認は、別の場所で一件の仕事を終える

開発を頼むときは、「バックアップあり」に加えて、戻して使えるかをどこまで確認するかを聞いてください。試験用の環境に戻せるか、どんな記録を使うか、本番に影響しない方法は何かを、担当者と先に合わせます。読者自身が本番のデータへ上書きして試す手順を勧めるものではありません。

確認する一件には、入力した記録、添付、必要な出力を含めます。一覧を開けたところで終えず、担当者が必要な情報を探し、その後の作業を一つ終えられるかを見る。その際、外部への通知や帳票送信を誤って実行しない検証条件も決めておきます。

結果には、使った控えの時点、戻した対象、確かめた仕事、見つかった不足を残します。試験でかかった時間は、その条件での結果であり、実際の障害時にも同じ時間で戻せる保証ではありません。使う環境やデータ量、担当者の対応時間が変われば、必要な準備も変わります。

既製サービスなら、保存の対象、戻せる期間、復元の依頼方法と費用を提供元へ確認します。個別開発なら、保存と復元を誰が管理し、試験、手順書、操作説明をどの範囲に含めるかを見積もりで確かめます。日常の保守と、障害時の調査・復旧支援が同じ範囲かも、契約前に確認しておきたい点です。

今日できるのは、止まると困る一つの仕事を選ぶこと

いま使っている在庫表、受注ソフト、日報の仕組みから、止まると困るものを一つ選んでください。「最後に何時の記録へ戻せるか」「戻るまでの仕事を何へ控えるか」「誰が、何を確かめたら再開するか」を一行ずつ書きます。分からない欄は、今から開発会社や管理担当へ聞く項目です。

全部の仕組みに同じ備えを求めなくても構いません。出荷のように現物が先に動く仕事か、翌日まで待てる集計かで、必要な確認は変わります。技術の名前より、一つの仕事の続きを説明できることが、必要な開発や支援範囲を選ぶ材料になります。

埼玉県川口市のＢ．Ｉ．Ｙは、今の紙やExcelの仕事を確かめ、必要な部分を作り、導入時の説明や運用中の相談まで支援範囲を確認して進める育てるシステム開発をご案内しています。バックアップや復元確認、障害時の支援をどこまで行うかも案件ごとに合意するもので、無条件の復旧保証は置きません。開発から直接相談でき、顧問契約は前提ではありません。

公式LINEへ「システムが止まった後、どの記録から仕事を再開できるか分かりません。作る前に確認したい」と一言お送りください。止まると困る仕事を一つ伝えるところから相談できます。