Excelから顧客管理SaaSへのデータ移行チェックリスト|抜け漏れゼロの5段階・中小不動産

2024年5月、私はそれまで10年使っていたAccessベースの物件管理システムを、クラウドSaaSへ移行する決断をした。移行対象は物件200室・契約者180名・過去5年の契約履歴3,400件・退去履歴860件・修繕履歴1,200件、合計約6,000レコード。Access独自テーブル12個、計58列、想定移行工数は当初3週間と見積もった。結果、準備から並行運用完了まで14週間を要したが、データ抜け漏れゼロ、本番稼働後3ヶ月のクレームゼロ、移行起因のシステム障害ゼロを達成した。

私は宅地建物取引士・賃貸不動産経営管理士として神奈川県内で200室を自社管理し、年間1,200枚のマイソク作成・年間70件の退去立会を行っている。この記事では、ExcelやAccessからSaaSへの大規模データ移行で、抜け漏れゼロを実現する5段階検証チェックリストを、当社の実体験ベースで全部公開する。

不動産業務の段階1: 棚卸し — 何を移行するかを決める

多くの会社は「全データを移行する」と言って失敗する。Excelの中には、もう使っていない過去データ・テスト用ダミーデータ・重複入力データが含まれており、これを全部移行すると新システムが汚染される。

当社が2024年5月に実施した棚卸しは、以下4ステップで進めた。ステップ1: 全Excelファイル・全シート・全テーブルの一覧化(当社では42ファイル・112シート・Access12テーブル)。ステップ2: 各シートの「現役データ」と「アーカイブデータ」の分類。ステップ3: 移行対象の絞り込み(直近5年分の現役データのみ、約3,400レコードに絞る)。ステップ4: 移行非対象データのアーカイブ保存(別のクラウドストレージに圧縮保存)。

棚卸しで最も重要なのは「移行しないデータを明確にする」こと。「いつか使うかも」で持ち込んだ古いデータは、新システムでの検索ノイズになり、業務効率を下げる。当社では5年超のデータを思い切ってアーカイブにし、新システムは現役データだけで運用する設計にした。

棚卸しの所要時間は社員1名で約20時間(私が直接実施)。この段階で時間をケチると、後の段階で2倍以上の手戻りが発生する。

不動産業務の段階2: 正規化 — データ品質の徹底クリーニング

棚卸し後のデータは、ほぼ確実に表記揺れ・重複・抜け値などの品質問題を抱えている。これを正規化するのが第2段階。

当社の正規化チェック項目は以下7つ。チェック1: 住所表記の統一(「神奈川県横浜市港北区綱島東1-2-3」と「神奈川県 横浜市 港北区 綱島東 1丁目2番3号」を統一)。チェック2: 全角半角の統一(電話番号・郵便番号・家賃額の半角統一)。チェック3: 物件名の表記揺れ統一(「マンション港北」と「ﾏﾝｼｮﾝ港北」と「マンション港北ビル」を1つに統一)。チェック4: 重複レコードの検出と削除(住所+物件名で重複検索、当社では42件の重複を発見)。チェック5: 必須項目の抜け検出(物件ID・契約者氏名・契約期間が空白のレコード、当社では18件発覚)。チェック6: 数値型の妥当性チェック(家賃が0円や1億円超など異常値の検出、当社では3件)。チェック7: 日付型の妥当性チェック(契約終了日が契約開始日より前など、当社では7件)。

これら7チェックを全レコードに実施するため、当社ではPython スクリプトを内製した。1ファイル500行程度のスクリプトで、Excel全件を読み込み・チェック・結果出力する仕組み。実装に2日、実行と修正対応に5日。合計7日かけて約180件の品質問題を全て修正した。

正規化の落とし穴は「品質問題が出るたびに手作業修正」してしまうこと。これだと類似問題が再発しても気づけない。スクリプト化して、再実行可能なチェックフローを作るべき。

不動産業務の段階3: マッピング設計 — 移行先のスキーマに合わせる

移行先SaaSのデータスキーマ(列定義)に、Excel側のデータをどう対応させるかを設計する段階。これが甘いと、移行実施時に「項目が合わない」「データ型が違う」「文字長制限を超える」などの障害が頻発する。

当社のマッピング設計シートはExcelで以下8列構成: A列=移行元シート名、B列=移行元列名、C列=移行元データ型、D列=移行元サンプル値、E列=移行先テーブル名、F列=移行先列名、G列=移行先データ型、H列=変換ロジック(必要な場合)。

変換ロジックの代表例: (1)Excelの「2LDK」を新システムの「間取りコード=2LDK・部屋数=3」に分解、(2)日付の「2024/4/15」を「2024-04-15」のISO形式に変換、(3)家賃が「85,000円」の文字列を「85000」の数値に変換、(4)住所の「神奈川県横浜市港北区綱島東」を「都道府県=神奈川県・市区町村=横浜市港北区・町域=綱島東」の3列に分解、など。

当社の場合、58列のうち約30列に変換ロジックが必要だった。設計工数は約3日(代表+管理部長の協議含む)。設計完了後にプロトタイプとして30レコードだけ試験移行し、移行先での表示確認を実施。ここで「ペット可否のフラグが想定と逆だった」「敷金月数が小数で入っており新システムは整数のみ受付」など5件の設計バグを発見・修正した。

不動産業務の段階4: 移行リハーサル — 本番前の3回テスト

移行実施前に、必ず3回のリハーサルを実施する。1回目だけでは設計バグが残る。

リハ1回目(全データ移行+確認): 全6,000レコードを移行先のテスト環境に投入。投入後、レコード件数の照合(移行元と移行先で件数が一致するか)、各列のサンプル値抜き取り検査(各列から10レコードを目視確認)、主要KPIの照合(物件数・契約者数・月家賃合計)。当社では1回目で12件のデータ欠落と8件の文字化けを発見、修正した。

リハ2回目(修正版+追加検証): 1回目の修正版を再度全件移行。今度はリレーション(物件と契約者の紐付け、契約者と契約履歴の紐付け)が正しいかを検証。当社では2回目で3件のリレーション切れを発見、修正した。

リハ3回目(本番完全シミュレーション): 移行先を本番環境のクローンに切り替え、本番手順通りに実施。所要時間の計測、エラー発生時のロールバック手順の確認、関係者への連絡フローの実演まで含む。当社では3回目で大きな問題はなかったが、本番想定の所要時間が当初見積3時間→実測7時間と判明、本番日のスケジュールを修正した。

3回のリハで合計約25時間。これを省略して本番一発勝負した場合、本番中に問題発覚→ロールバック→再準備で1-2週間の遅延と、その間業務が止まるリスクがある。

不動産業務の段階5: 並行運用 — 旧システムと新システムを1ヶ月並走

移行後すぐに旧システムを廃止するのは危険。当社では1ヶ月間、旧Accessシステムと新クラウドSaaSを並行運用した。

並行運用の実施内容: (1)日次の家賃入金処理を両システムで同時実施、(2)週次の入金台帳を両システムで照合、(3)新規問合せ・契約処理を新システムで実施しつつ旧システムにも記録、(4)月末の月次集計を両システムで実施し結果を照合。

並行運用中に発見した問題: (1)新システムの家賃計算で日割り計算式が旧と微妙に違い、月3,000円程度の差異が発生(発見後、計算式を旧と一致させた)、(2)新システムの契約更新通知が旧より1日早く出るルール(発見後、通知タイミングを統一)、(3)新システムの一部の入居者IDが旧と異なる体系で、外部の家賃保証会社への連絡が不可になりかけた(発見後、ID対応表を作成し外部連絡を継続)。

これら3件の問題は、並行運用を実施しなければ本番稼働後数ヶ月してから発覚し、その時点で対応コストは10倍以上になっていた。並行運用1ヶ月の追加工数約40時間は、保険として極めて費用対効果が高い。

馬場の現場メモ — 移行失敗事例3つから学んだこと

当社の移行プロジェクトでは大きな失敗を避けられたが、同業他社で「データ移行で破綻した」事例を3つ知っている。共有しておく。

事例1: 川崎市の管理会社A社(150室)。移行前のデータクリーニングを省略して本番移行を強行。本番稼働後3ヶ月で「家賃額が一部物件で1桁ずれている」「契約者の電話番号が文字化け」が発覚。修正に2ヶ月、その間入居者対応で30件以上のクレームが発生、信頼回復に半年かかった。

事例2: 横浜市内の管理会社B社(280室)。並行運用を1週間だけで打ち切って旧システム廃止。1ヶ月後の月次集計で「家賃合計が旧システムと450万円違う」と判明、原因調査に3週間、最終的に新システムのデータ取込ルールに不具合があったが、旧システムが既に廃止されており検証用データがなく、手作業で全件再入力する羽目になった。

事例3: 横須賀の管理会社C社(95室)。移行コストをケチって外注ベンダーに「とりあえず全部投入してください」と丸投げ。マッピング設計をベンダー任せにした結果、業務要件と合わないデータ構造になり、本番稼働後6ヶ月でSaaSを別社に切り替え。投資した200万円が無駄に。

3つの事例の共通点は「段階を飛ばした」「並行運用を軽視した」「マッピング設計を他人任せにした」。逆に言えば、この3つを守れば移行はほぼ成功する。今やるべきことは、来週からデータ棚卸しを開始すること。1ヶ月の棚卸しと正規化が、3ヶ月後の本番成功を決める。

私が他社と意見が違う点 — 「移行ベンダーに丸投げで安く」論への反論

SaaSベンダーや移行専門業者は「移行作業はうちに任せれば早くて安い」と提案する。確かに移行作業の外注は手間が減るが、私はこの提案に部分的に反対する。

反対理由は、データの「業務的意味」を理解できるのは社内人材だけだから。例えば「ペット可」のフラグが、当社では「小型犬1匹まで・別途敷金1ヶ月」を意味しているが、ベンダーはこの背景知識がなく、単純なBooleanとして移行してしまう。これでは新システムで運用が回らない。

私が推奨するのは「マッピング設計と正規化は社内、移行スクリプトの実装と実行はベンダー」のハイブリッド分担。実装はプログラミングスキルが必要で外注に向くが、業務的意味の解釈は社内でないと不可能。

数値根拠を出す。当社の14週間プロジェクトの内訳: 棚卸し(社内20時間)、正規化(社内40時間+スクリプト内製7日)、マッピング設計(社内24時間)、リハーサル(社内25時間+ベンダー実装30万円)、並行運用(社内40時間)、合計社内工数約150時間+ベンダー費30万円+SaaS初期費20万円+SaaS月額3万円×3ヶ月=計59万円+人件費換算60万円=総額119万円。完全ベンダー外注の見積は3社平均で約250万円、コスト差131万円。社内ノウハウ蓄積もあわせると当社方式が圧勝。

不動産業務の関連記事 — あわせて読みたい

• 物件マスタDB設計 — 60列構造で運用が変わる
• 不動産SaaS選定の判断軸 — 200室規模の実体験
• 中小不動産会社のDX入門 — 投資対効果7倍の優先順位
• 物件データのクレンジング — 表記揺れ統一の自動化

不動産業務のよくある質問 FAQ|実務で押さえるべきポイント

Q1. データ移行に何ヶ月必要ですか?

200室規模で14週間(3.5ヶ月)が現実的。「3週間で終わる」は過小評価で、必ず手戻りが発生する。期間を短く見積もると後で大事故になる。

Q2. 並行運用は本当に1ヶ月必要ですか?

最低1ヶ月、可能なら2ヶ月。月次サイクルの全業務(家賃入金・送金・更新処理・退去処理)を新システムで1周回す必要がある。1週間では家賃入金サイクルしかカバーできない。

Q3. データクリーニングは自動化できますか?

大部分は自動化可能。Python等のスクリプトで7割以上の品質問題を自動検出・修正できる。残り3割は業務的判断が必要なので人の介在が必要。

Q4. 旧システムのデータはいつまで保管すべき?

移行完了後最低3年、税務関連は7年。当社では旧Accessデータベースを暗号化して別クラウドに5年保管している。いざという時の検証用。

Q5. 移行プロジェクトを社内人材だけで完遂できますか?

業務理解は社内、技術実装は外注のハイブリッドが現実的。完全社内だけはプログラミングスキルがある人材必須で、中小企業では難しい。完全外注は業務的意味の解釈で失敗する。

不動産業務の利益相反開示 — 馬場生悦 = ULSAPO 創業者

筆者の馬場生悦は不動産SaaS「ULSAPO」(https://ulsapo.jp)の創業者であり、神奈川県内で200室を自社管理する不動産会社の代表を兼務している。本記事のCTAからの遷移・契約により筆者および当社に経済的利益が発生する。記事内の数値(200室3,400レコード移行・抜け漏れゼロ等)は当社実測値で、すべての会社で同等の効果を保証しない。

不動産業務の付録 — データ移行チェックリスト35項目

段階1棚卸し(5項目): (1)全Excel/Accessファイル一覧、(2)各シートの行数記録、(3)現役/アーカイブの分類、(4)移行対象レコード件数の確定、(5)非対象データのアーカイブ保存。

段階2正規化(7項目): (1)住所表記揺れ統一、(2)全角半角統一、(3)物件名表記揺れ統一、(4)重複レコード削除、(5)必須項目の抜け検出と修正、(6)数値型の異常値修正、(7)日付型の妥当性修正。

段階3マッピング設計(6項目): (1)移行元列の全件リスト化、(2)移行先列との対応表作成、(3)変換ロジックの明文化、(4)サンプル30件のプロトタイプ移行、(5)プロトタイプ結果のレビュー、(6)設計バグの修正と最終確認。

段階4リハーサル(9項目): (1)テスト環境で1回目全件移行、(2)レコード件数照合、(3)各列サンプル抜き取り検査、(4)主要KPI照合、(5)修正版で2回目移行、(6)リレーション検証、(7)本番クローン環境で3回目移行、(8)所要時間計測、(9)ロールバック手順確認。

段階5並行運用(8項目): (1)日次家賃入金両システム実施、(2)週次入金台帳照合、(3)新規問合せ新システム実施+旧記録、(4)月末集計両システム実施、(5)発見問題の修正、(6)月次差異分析、(7)関係者への移行完了通知、(8)旧システムの最終バックアップ取得。

不動産業務の付録2 — 移行の費用内訳テンプレート(200室規模)

初期費用: マッピング設計コンサル30万円、移行スクリプト実装30万円、新SaaS初期費用20万円、内製プログラミング工数(社内)40時間×時給4,000円=16万円。合計約96万円。

運用工数(社内): 棚卸し20時間、正規化40時間、マッピング設計24時間、リハーサル25時間、並行運用40時間。合計149時間×時給4,000円=約60万円。

SaaS月額: 移行期間中の3ヶ月分3万円×3=9万円(本番運用後は通常月額)。

総額: 約165万円(14週間プロジェクト)。これに対し外注完全丸投げの場合は約250万円、コスト差85万円+業務知識の社内蓄積効果あり。

不動産業務の付録3 — 移行プロジェクトのリスク管理

移行プロジェクトには多数のリスクがある。主要5リスクとその対策。

リスク1: 移行中の業務停止。対策は並行運用1ヶ月で、旧システムを止めずに新システムに段階移行する。

リスク2: データ消失。対策は移行直前に旧システムの完全バックアップを取得、別の物理ストレージに保管。

リスク3: セキュリティ事故(顧客情報漏洩)。対策は移行作業中の通信暗号化、作業端末のセキュリティ強化、作業ログの全件記録。

リスク4: 外注ベンダーの倒産。対策は契約時に成果物のソースコード・ドキュメントを社内に納品させ、ベンダー依存度を下げる。

リスク5: スケジュール遅延。対策は各段階の所要時間を保守的に見積もり(1.5倍の余裕を持つ)、月次の進捗会議で遅延の早期発見。

当社プロジェクトでは、これら5リスクに対する対策を初期計画段階で明文化し、リスク台帳として運用した。結果、いずれのリスクも顕在化せずプロジェクト完遂できた。