SaaSを解約する前にデータを書き出す。開けるファイルと戻せる業務の違い

SaaSの解約に伴うデータ移行では、「書き出したデータで必要な業務を戻せるか」を最初に確かめます。ZIPを展開でき、CSVを表計算ソフトで開けても、添付ファイルがどの案件に属するか、誰がいつ更新したか、親子のレコードをどう結び直すかまでは分かりません。

僕なら、解約の承認条件を「対象データが揃っている」と「移行先や保管環境で業務を再現できる」の二段に分けます。どちらか一方でも未確認なら、解約日は確定しません。問題は、その再現をどこまで試せば経営者が解約を承認できるかです。

答えを得るには、全データを眺めるより、添付・履歴・参照関係を持つ業務を一つ選び、出口から戻すところまで通してみるのが有効です。公式に確認できる製品仕様を根拠にしつつ、自社の承認条件は業務への影響から決めます。

SaaSの解約とデータ移行は「開けた」で完了しない

まず公式仕様として確認できるのは、アーカイブの容器と中身が別物だということです。Google Takeoutの公式ヘルプは、ZIPはほぼすべてのコンピューターで開ける一方、実データの形式はサービス、データ種別、利用目的に応じて選ぶ必要があると案内しています。2026年9月21日時点の確認です。圧縮ファイルを展開できたことは、データ移行の入口を通ったという意味にとどまります。

CSVも同じです。MicrosoftのDataverse公式ドキュメントでは、画面からのエクスポートは単一テーブルをCSVで出力する機能として説明されています。一方、同じExcel／CSVの入出力ではImageとFileが未対応で、作成者、作成日時、更新者、更新日時などのシステム項目も対象外です。上記は2026年9月21日時点で確認した製品固有の仕様であり、すべてのSaaSに共通する話ではありません。しかし「行が出ているから、必要な情報も全部ある」とは限らないことをよく示しています。

僕は実務上、エクスポートの成功をファイルの有無や行数だけで判定しません。本文、添付、変更の経緯、レコード同士のつながりを別々の検査対象にします。経営者が見るべきは、その欠損によって契約確認、問い合わせ対応、引き継ぎといった自社の仕事が止まるかどうかです。

技術担当から「CSVは出せます」と報告されたとき、問い返すべきなのは「では、どの添付がどのレコードのものかを特定でき、更新の経緯も追えますか」です。この問いに答える材料がなければ、データの出口はまだ確認できていません。技術的な報告を経営判断へ変換する考え方は、経営と技術をつなぐ人がいないと、会議は決まらないでも詳しく扱っています。

添付・履歴・参照関係を含む再利用テストの例

例として、親レコードに取引先、子レコードに案件、案件に添付された合意書、更新者と更新日時が分かる履歴がある業務を考えます。特定製品の画面を再現するものではありません。出口テストの対象を決めるための非数値のモデルとして、機密性の低い検証用データか、社内ルールに沿って扱える実データを一つの業務単位として選びます。

書き出したファイルを保管しただけでは、検査になりません。元のSaaSを見なくても業務の意味を復元できる環境を用意し、次の順で確かめます。

1. 親レコードと子レコードの本文を開き、案件がどの取引先に属するかを特定する。
2. 合意書を開き、その添付が対象案件のものだと、ファイル名以外の対応情報から確認する。
3. 更新者と更新日時を追い、現在の内容に至る経緯として必要な履歴を読めるか確認する。
4. 主キーまたは代替キーを使い、子レコードや添付から正しい参照先を一意にたどれるか確認する。

四つを順に見る理由は、本文、添付、履歴が個別に残っていても、互いの対応を失えば業務資料として再利用しにくいからです。選んだ業務について本文を読み、根拠となる添付を開き、経緯を追い、参照先を特定できた時点で合格にします。

参照関係では、表示名よりキーを重視します。Dataverseの公式ドキュメントは、Excel／CSVを取り込む際にテーブルごとの必須列が必要で、一意性の確保には主キーまたは代替キーを使うよう案内しています。2026年9月21日時点の仕様です。製品ごとに取込条件は異なりますが、人が読める名前が同じでも機械が同一レコードと判断できるとは限りません。移行先へ戻す予定がなく、閲覧用に保管する場合でも、親と子を結ぶキーの意味は一緒に残すべきです。

履歴には時点の問題もあります。Google Takeoutの公式ヘルプでは、要求してからアーカイブ作成までの変更が含まれない場合があり、Driveファイルの共有種別・権限の変更や解決済みコメントが例示されています。2026年9月21日時点の確認です。したがって、テストに合格した時点と解約直前の状態が同じだとは決めつけられません。出力要求後に業務を続けるなら、その間の変更をどう確保するかも承認条件に含めます。

解約前の判断台帳で、欠損を「判断待ち」に戻す

僕が実務で提案するのは、出口テストの結果を一枚の判断台帳にまとめる方法です。判断台帳は確認漏れを防ぐための管理方法で、公式機能の説明そのものではありません。最低限、次の列を設けます。

列を埋める目的は一覧の完成ではありません。各欠損を「この状態で業務を戻せるか」という判断へ結びつけます。

たとえば、案件本文と添付は開けても、添付と案件を結ぶ識別子がない場合を考えます。台帳の「出力結果」には取得できたファイルを記録し、「再利用テスト結果」は不合格にします。「未解決の欠損」は添付と親レコードの対応情報、「欠損時の対応」はSaaS上で対応表を別保存する、別の公式エクスポート手段を確認する、または対応が決まるまで解約を延期する、のいずれかです。僕はこの例を、欠損から判断条件を組み立てる手順として示しています。

更新者や更新日時が出力対象外なら、同じように扱います。その履歴が法務確認や顧客対応に必要なのか、現在値だけで業務を続けられるのかを業務責任者が判定します。必要なら代替保存手段が完了するまで不合格、不要なら不要と判断した責任者と理由を残します。「仕様上出せない」は調査結果であって、解約してよいという経営判断ではありません。

エクスポート処理自体の状態も台帳に入ります。Google Workspaceの組織向けData Export公式ヘルプでは、完了後の詳細画面で、完全に実行されたか、エラーによってアーカイブの一部データが欠けているかを確認できると案内されています。2026年9月21日時点の仕様です。エラー表示があるのに、ダウンロードできた部分だけを見て合格にはできません。再出力するのか、欠損を別手段で保存するのかを決め、再利用テストまで終えて初めて状態を更新します。

台帳の最終承認者は、出力作業をした人とは分けて考えるのが安全です。担当者は取得できた事実を報告し、業務責任者は欠損の影響を判断し、経営者は残るリスクを受け入れて解約するかを決めます。役割を曖昧にすると、技術担当の「処理完了」が、そのまま経営の「解約承認」に読み替えられてしまいます。外部の技術責任者を含めて誰に判断を預けるかは、CTO代行を入れると、組織の意思決定はどう変わるのかの整理も参考になります。

解約日は、再利用できた後に決める

解約を承認できるのは、対象データが揃い、選んだ業務単位で本文・添付・履歴・参照関係を再利用でき、エラーと時点差分への対応が台帳上で閉じたときです。ZIPを開けた、CSVを読めた、エクスポート処理が完了した、という個別の事実だけでは足りません。

反対に、欠損が見つかったこと自体は失敗ではありません。解約前に見つけ、代替保存で埋めるのか、その情報を不要と承認するのか、解約を延期するのかを決められれば、出口テストは役割を果たしています。最も避けたいのは、欠損の意味を判断しないまま契約を終了し、元のSaaSを参照できなくなってから業務とのつながりを探すことです。

まず、添付と履歴を持ち、親子関係のある業務を一つ選んでください。その業務を元のSaaSなしで戻せるか試し、結果と欠損を判断台帳へ記録します。最終承認者が「この状態なら必要な業務を続けられる」と確認するまでは、解約日を未確定にします。開けるファイルと戻せる業務を分けるこの承認条件が、解約後も仕事を続けるための線引きです。