バックアップの取り決め、発注時に確認したか

「サーバーが落ちました」「データが消えました」——もしオフショア先やフリーランスのエンジニアから突然そう連絡が来たら、御社は何をどこまで取り戻せるでしょうか。考えたくない想定ですが、実際に答えられる現場責任者は多くありません。契約書を見返しても、機能要件や納期についてはびっしり書いてあるのに、バックアップや障害時の対応については一行も触れられていない、ということがよくあります。

これは担当者の怠慢というより、見落とされやすい構造があるためです。バックアップや災害対策は「動くものを作る」という開発の本来の関心事とは別枠にあり、見積もりの表にも載りにくい項目だからです。つまり、聞かなければ出てこない話なのに、発注側も開発側も「相手が触れてくるだろう」と思い込みがちな、いわば抜け落ちやすい隙間の話になっているわけです。

この記事では、なぜバックアップ・災害対策の取り決めが契約の中で抜け落ちやすいのか、その構造を整理したうえで、発注前・契約中に確認しておきたい観点を具体的に紹介します。

なぜバックアップの話は「後回し」にされやすいのか

開発プロジェクトの打ち合わせでは、画面のデザインや機能の優先順位、納期といった「目に見える成果物」の話が中心になります。バックアップや災害対策は、システムが正常に動いている限り存在感がなく、誰も困っていない状態では議題に上がりにくいテーマです。

さらに、バックアップの実施主体が誰なのかという点も曖昧になりがちです。インフラをクラウドサービス上に構築している場合、「クラウド事業者側で自動的にバックアップされているはず」と発注側が思い込んでいるケースは少なくありません。しかし実際には、クラウド事業者が保証するのはインフラ基盤の可用性までで、アプリケーションのデータ自体のバックアップ設定は利用者側（この場合は開発会社、あるいは発注企業自身）が個別に設定する必要がある、という切り分けになっていることがほとんどです。ここの境界線を知らずに契約を進めると、「誰かがやってくれているはず」という空白地帯が生まれます。ここは、次に契約書を確認するときにそのまま使える視点なので、メモしておくといいところです。

独立行政法人情報処理推進機構（IPA）が公表している「中小企業の情報セキュリティ対策ガイドライン」では、情報資産の消失・改ざんに備えた対策の一つとしてバックアップの実施が取り上げられており、どの範囲のデータを、どのくらいの頻度で、どこに保管するかをあらかじめ定めておくことの重要性が示されています（IPA「中小企業の情報セキュリティ対策ガイドライン」第3版、5章 情報セキュリティ対策の実施：https://www.ipa.go.jp/security/guide/sme/about.html）。システム開発の契約という局面においても、この「誰が・いつ・どこまで」の取り決めがないまま進んでしまうことが、後の不安の種になります。

「データが消えたらどうなるか」を分解してみる

バックアップの不安を漠然と抱えたままにせず、いくつかの要素に分けて考えると整理しやすくなります。

• 取得頻度：バックアップが毎日なのか、週次なのか、あるいは任意のタイミングでしか取られていないのかによって、復旧できる時点（どこまでデータが戻るか）が大きく変わります。
• 保管場所：バックアップデータが本番環境と同じサーバー・同じ地域に置かれている場合、災害や大規模障害が起きたときにバックアップごと失われるリスクが残ります。
• 復旧にかかる時間：バックアップが存在していても、実際に復旧作業にどれくらいの時間がかかるのかは別問題です。復旧手順が整備されていなければ、データはあっても「すぐには戻せない」状態になり得ます。
• 責任の所在：障害発生時に誰が一次対応し、誰が復旧作業を実施し、その費用は契約のどの範囲に含まれるのか。ここが契約書に明記されていないと、いざというときに「それは契約範囲外の追加作業です」という話になりかねません。

この4点は、特にオフショア開発やフリーランスへの発注で見落とされやすい項目です。オフショア開発、品質不安の正体を整理するという記事でも触れていますが、遠隔での発注は「見えないところで何が行われているか」が不安の中心になりやすく、バックアップ体制もその一つに含まれます。実務上はここがポイントで、見積もりの安さだけで判断せず、この4点が契約書や仕様書のどこかに記載されているかを確認する習慣をつけておくと、後の交渉がスムーズになります。

発注前・契約中に確認しておきたい観点

バックアップ・災害対策の取り決めは、契約を結ぶ前であればシンプルに質問すれば済む話です。すでに契約が進んでいる案件であっても、保守契約の見直しのタイミングなどで確認を入れることは十分可能です。

1. バックアップの取得主体を確認する：インフラ事業者側の標準機能なのか、開発会社が個別に設定するものなのかを明確にしてもらいます。
2. 取得頻度と保管期間を数字で聞く：「定期的に取っています」という曖昧な回答ではなく、例えば「日次で30日分保管」のように、具体的な数字で答えてもらえるかを確認します（この数値自体は一例であり、実際の頻度・期間は業務内容やデータの重要度に応じて案件ごとに取り決めるものです）。
3. 復旧テストの実施有無を聞く：バックアップが取れていても、実際に復旧できるかを試したことがなければ、いざというときに機能しない可能性があります。
4. 障害発生時の費用負担を契約書に明記する：復旧作業が保守契約の範囲内なのか、別途見積もりが発生する追加作業なのかを事前にすり合わせておきます。

このあたりは保守契約の範囲とも深く関わる話で、保守契約を結ばないとどうなるか、価格構造で読むで扱っている内容とも接続しています。バックアップ体制の確認は、単体の質問というより保守契約全体の中でどう位置づけられているかを見る視点として持っておくと、発注側が意識しておきたい論点が整理しやすくなります。

実際に障害が起きてから「誰がバックアップを取っていたのか分からない」という状態に陥ると、復旧の初動が遅れるだけでなく、責任の押し付け合いにもつながりかねません。契約前の一言の確認が、後のトラブルの規模を大きく左右するところです。

まとめ

• バックアップ・災害対策は、機能要件や納期と違って議題に上がりにくく、契約から抜け落ちやすいテーマです。
• 「取得頻度」「保管場所」「復旧時間」「責任の所在」の4点に分けて確認すると、漠然とした不安を具体的な質問に変えられます。
• 発注前の質問はもちろん、既存の契約でも保守契約の見直しのタイミングなどで確認を入れることができます。