カーブアウト IT 分離でよくある失敗 5 パターン ― 中堅・中小企業の現場から｜カーブアウト IT完全ガイド第6回
カーブアウト IT 分離は、中堅・中小企業にとって「人生で 1〜2 回」のイベントです。そのため社内に経験者がほとんどおらず、初めて取り組む経営者・情シスが多くの落とし穴を踏みます。
本記事では、過去案件で繰り返し見られる 失敗 5 パターンを、実例（個別案件が特定されない範囲で抽象化）と回避策とともに解説します。
失敗パターン①：TSA 期限超過
何が起きるか
TSA で「Day 1 から 6 か月以内に IT 分離完了」と約束したが、実際には 6 か月経っても M365 テナント分離が終わらず、TSA を延長することになり追加コストが発生した。
典型的な経緯
- サイン前の準備が不足し、Day 1 までに移行計画が固まらない
- Day 1 後に詳細計画を立て始めるが、移行ツールベンダーの空きが取れず開始が 2 か月遅れる
- データ移行を始めると、想定の 3 倍のデータ量が発覚
- TSA 終了 1 か月前に「終わらない」と判明、延長交渉
影響
- TSA 延長料金（通常単価の 1.5 倍）
- 売り手側のリソース拘束継続
- 買い手の新会社運営計画の遅延
回避策
- サイン前に詳細計画：第4回タイムラインに沿って、サイン前から移行計画を立てる
- データ量の事前測定：「だいたい◯ TB」ではなく実数で測る
- 移行ツールベンダー枠の事前確保：FLY / MigrationWiz / Quest は数か月前から枠取り
- TSA 期間を最初から余裕を持って設定：理論最短ではなく、想定の 1.5 倍で組む
- マイルストーン管理：第4回の M1〜M8 で進捗判定
失敗パターン②：共有データの押し付け合い
何が起きるか
SharePoint / 共有ドライブ / ファイルサーバの中に、「売り手も買い手も使いそうなデータ」が大量にある。「どちらの会社が引き取るか」で議論が長引き、最終的に両社で同じデータを重複保有するか、どちらかが諦めて全削除する。
典型的な経緯
- サイン前は「データの仕分けは後で」と先送り
- Day 1 -2M でデータ仕分けを始めると、共有データが想定の 5 倍
- 部門会議で「これは私たちの部門も使う」が連発し合意できず
- 結局、両社で同じデータを重複保有 → 法的リスク・コンプライアンス事故の温床
影響
- 個人情報・機密情報の重複保有によるコンプライアンスリスク
- 移行コストの二重化
- 部門間の信頼関係悪化
回避策
- サイン前から仕分け開始：完璧でなくても 70% の精度でドラフトを作る
- 仕分けルールを 3 段階に簡素化：「全部持っていく」「全部残す」「分割」の3択
- オーナー部門を明確化：データ単位で「誰が判断するか」を明示
- 法定保存義務の優先：会計・税務・労務データは法定保存期間に従う
- デフォルト方針を決めておく：「迷ったら売り手側に残す」のような原則
- 詳細手順：共有データの境界線問題 で実務を解説
失敗パターン③：SaaS 契約の名義残存
何が起きるか
Day 1 後、新会社が使い始めた SaaS の契約名義がまだ旧親会社のまま残っている。請求書が旧親会社に届き、旧親会社の経理が「これは新会社に請求して」と差し戻し続けるか、最悪、旧親会社が「もう関係ない」と支払を停止して SaaS が利用停止になる。
典型的な経緯
- サイン前の SaaS 棚卸しが不十分で、隠れた契約（個人クレカ決済 SaaS など）が漏れる
- TSA で「主要 SaaS は名義変更する」と決めたが、対象リストが不完全
- Day 1 後の運用で「あの SaaS、まだ旧親会社契約だった」が次々発覚
- 一部 SaaS で支払停止 → 業務停止
影響
- 業務停止
- ベンダーへの再交渉（足元を見られて単価が上がる）
- 旧親会社・新会社双方の経理混乱
回避策
- サイン前の SaaS 全棚卸し：個人クレカ決済を含めて漏れなく洗い出す（第2回参照）
- TSA に SaaS 契約一覧を別紙添付：何を、いつまでに、誰が名義変更するか明示
- 契約名義変更チェックリスト：Day 1 後の最優先タスクとしてリスト化
- ベンダーへの事前通知：「カーブアウトに伴う名義変更の可能性あり」を事前に伝える
- 更新月カレンダー：Day 1 直後に更新月が来る契約は最優先で対応
失敗パターン④：旧テナントへのアカウント残存
何が起きるか
TSA 終了後、売り手側の旧 M365 / GWS テナントに、対象事業に異動した（はずの）従業員のアカウントが残存している。ライセンス課金が発生し続けるだけでなく、退職同等の処理がされていないため情報漏えいリスクになる。
典型的な経緯
- Day 1 で対象従業員に新アカウントを発行（旧アカウントは「とりあえず残す」）
- TSA 期間中、対象従業員は新旧両方のアカウントで作業
- TSA 終了時、旧アカウント整理のチェックリストが不完全
- 数か月後、ライセンス棚卸しで「未利用アカウントに毎月課金されている」が発覚
- アカウント自体は休眠だが、メール・OneDrive のデータは残存
影響
- ライセンス課金の継続（年間数十万円〜数百万円）
- 情報漏えいリスク
- 監査指摘事項
回避策
- TSA に旧アカウント削除条項を明記：いつまでに誰が何を削除するか
- アカウント削除リストを 2 段階で作成：「即時削除」「TSA 終了時削除」の2分類
- 削除前のアーカイブ取得：法定保存期間中はアーカイブとして保管
- 削除後の検証チェック：旧テナントの監査ログで「対象従業員のサインインが 0 件」を確認
- 詳細手順：テナント分離後のクリーンアップ参照
失敗パターン⑤：共存期間中のデータ漏えい
何が起きるか
Day 1 から TSA 終了までの **共存期間（6〜12 か月）**中、対象従業員は新旧両方のテナントへアクセスできる状態。DLP / Sensitivity Label の設定が間に合っておらず、対象従業員が 旧親会社の機密情報を新会社に持ち出してしまう。
典型的な経緯
- Day 1 時点でアクセス制御ポリシーが未整備
- 対象従業員が業務継続のため旧テナントの SharePoint にアクセス
- 「自分が作った資料だから」と新会社の OneDrive にコピー
- 中には旧親会社の機密情報（顧客リスト、取引先情報、人事評価データなど）が混入
- 数か月後、旧親会社が監査で発覚 → 法的紛争
影響
- 機密情報・個人情報の漏えい
- 法的紛争（営業秘密侵害、個人情報保護法違反）
- 旧親会社・新会社間の信頼破綻
回避策
- Day 1 までに DLP / Sensitivity Label を整備：共存期間中のアクセス制御参照
- 対象従業員への教育：「持っていい情報・持っていけない情報」のルールを明文化
- アクセスログ監査：共存期間中、旧テナントへの対象従業員アクセスを継続監視
- Information Barrier の検討：必要に応じて Microsoft 365 の Information Barrier を活用
- 持ち出し可能データの事前リスト化：「これは持っていって OK」のホワイトリストを明示
- データ持ち出しの記録：従業員が持ち出した資料を申告制で記録
まとめ：5 つの失敗パターンの共通項
5 つの失敗パターンに共通するのは、いずれも **「サイン前の準備不足」と「TSA 設計の甘さ」**に起因することです。
| 失敗パターン | 根本原因 | 最も効く回避策 |
|---|---|---|
| ① TSA 期限超過 | スケジュール過小評価 | サイン前の詳細計画＋ 1.5 倍バッファ |
| ② 共有データ押し付け合い | 仕分けの先送り | サイン前から仕分け開始＋ 3 段階ルール |
| ③ 契約名義残存 | SaaS 棚卸し漏れ | 個人決済まで含めた全棚卸し |
| ④ アカウント残存 | クリーンアップ計画の不在 | TSA に削除条項明記＋ 2 段階削除リスト |
| ⑤ 共存期間データ漏えい | アクセス制御の遅れ | Day 1 までに DLP / Label 整備 |
これらの失敗は、サイン前 3 か月の準備期間で 80% は防げます。逆に「サインしてから IT を考える」アプローチでは、5 つすべての地雷を踏みます。
カーブアウト IT 分離のセカンドオピニオン
これらの失敗を回避するには、自社の状況を客観的に評価するセカンドオピニオンが有効です。情シス365 の Project365 では、サイン前段階での無料相談を受け付けています。「いま自社のカーブアウト IT 計画にどんなリスクがあるか」を 60 分でフィードバックします。
まとめ
- カーブアウト IT 分離の失敗は 5 つのパターンに集約される
- いずれも「サイン前の準備不足」と「TSA 設計の甘さ」が根本原因
- サイン前 3 か月の準備期間で 80% は防げる
- 経験不足は外部セカンドオピニオンで補える
次回（最終回）は、カーブアウト後の小規模情シス問題と、分社後の IT 運用体制を解説します。
関連リンク