結論：一括か段階かは「中核計算を説明できる人がいるか」で決まる
オフコンや長年のカスタマイズを重ねた基幹パッケージの刷新は、規模や予算ではなく 中核計算の仕様を説明できる人が社内にいるか で方式を選びます。
| 条件 | 一括入替が成立する | 段階移行を選ぶ |
|---|---|---|
| 賃料計算・原価配賦の例外処理 | 仕様書か担当者が説明できる | 誰も説明できない／「昔からこうなっている」 |
| 夜間バッチの実行順序 | ジョブネット図がある | 手順書がなく、特定の1人が回している |
| 月次・期末の締め処理 | 処理内容が追える | 締め後の修正手順が属人化している |
| 帳票の出力条件 | 定義が残っている | 条件分岐がプログラム内にしかない |
| 業務停止の許容 | 数日止められる | 入出金・工事が日次で動き止められない |
右側が2つ以上当てはまるなら、一括刷新は 要件定義が成立しません。仕様が書けないものは検収条件も書けないためです。この場合は段階移行を選び、「動いている処理を正解データとして扱う」進め方に切り替えます。
段階移行の定義と、剥がす順序の原則
段階移行とは、稼働中の基幹システムを止めずに、機能を層単位で外部へ切り出していき、仕様が不明瞭な中核計算だけを最後に置き換える刷新方式である。
剥がす順序は、壊れたときの影響が小さい層から と決めます。具体的には出力側からです。
| 順序 | 層 | 対象例 | 失敗時の影響 |
|---|---|---|---|
| 第1層 | 帳票・レポート出力 | 請求書、入出金明細、原価集計表、経営レポート | 出し直すだけ。元帳は無傷 |
| 第2層 | 参照・照会 | 物件照会、契約照会、工事進捗照会 | 見え方だけ。データ更新なし |
| 第3層 | 周辺入力 | 問い合わせ、点検記録、写真、日報 | 中核計算に入る前で止められる |
| 第4層 | 基幹入力 | 契約登録、請求確定、発注・出来高入力 | 元帳が壊れる。切り戻し手順が必須 |
| 第5層 | 中核計算・締め | 賃料計算、原価配賦、月次締め、決算 | 全社影響。最後に移す |
第1層から着手する理由は、旧システムのデータベースを読み取り専用で参照するだけで実現でき、書き込みが発生しないためです。ここで旧データの実態（欠損、コード体系の揺れ、外字）が一通り見えます。第4層以降の設計は、第1層で分かった実態を前提に組み直します。
出力側から着手する具体例としては、経営ダッシュボードで見るべきKPIと現実的な作り方で扱っている集計レポートが典型です。
分割線の引き方：どこで切り、どこを最後まで残すか
機能を「移す／残す」に振り分ける判断基準は4つです。
- 月次・期末の締めをまたぐか — またぐ処理は最後まで残します。締めを分割すると、どちらの数字が確定値か説明できなくなります。
- 整合性の起点になっているか — 他の処理がその結果を参照している処理（賃料確定、実行予算確定）は起点です。起点は後回しにします。
- 過去に遡って再計算が走るか — 賃料改定の遡及適用、原価の期をまたぐ振替など。再計算は新旧両方で走ると二重計上になるため、最後まで片側に固定します。
- 法定帳簿・法定保存に直結するか — 帳簿や保存義務のある書類に直結する処理は、保存要件の確認が終わるまで移しません（保存要件の適否は税理士等にご確認ください）。
不動産業で最後まで残りやすいのは、共益費・日割り・フリーレント・更新料・敷金償却・改定遡及が絡み合う 賃料計算 です。サブリースが入るとさらに、サブリース物件の収支管理をどう設計するかで整理したように、オーナー精算と入居者請求で別々の計算系が並走します。
建設業では、歩掛・実行予算・出来高・原価振替が連動する 工事原価 が該当します。工事台帳は期をまたぐため、日付での分割ができません。
仕様を誰も説明できない処理の移し方
仕様書を復元しようとせず、動いている旧システムそのものを仕様と見なします。手順は以下です。
- 入出力のペアを収集する — 旧システムへの入力値（契約条件、単価、数量、日付）と、出力された結果（請求額、原価、帳票）を対にして抽出します。設計指針として、最低でも月次締めを12回と期末を1回含む期間分を集めます。年1回しか動かない処理を取りこぼさないためです。
- 新ロジックに同じ入力を流す — 出力を1件ずつ突き合わせ、差分の出た件だけを残します。
- 差分の条件を言語化する — ここで初めて仕様が判明します。頻出するのは以下です。
- 端数処理（円未満切捨て／四捨五入／消費税の丸め位置）
- 日割りの分母（月の実日数／30日固定／契約種別で分岐）
- 月中の解約・入居での按分ルール
- 消費税率改定をまたぐ契約の扱い
- 閏年・月末日の扱い（2月の月末応当日）
- 過去に一度だけ手修正された特異データ
- 差分ゼロになるまで繰り返し、確定した条件を文書化する — この文書が新システムの仕様書であり、同時に検収条件になります。
AIにCOBOLやRPGのソースを読ませて要約させる方法は、当たりをつける用途では有効です。ただし AIの読解結果を仕様として採用してはいけません。正しさを保証できるのは入出力の照合だけです。
このように、先に完成した要件定義書を前提としない進め方については要件定義書を書かない開発は成立するか｜FDEの工程を公開で工程を公開しています。
期間ごとに「新旧どちらを正とするか」を決める
段階移行で最も事故が起きるのは、正データがどちらか曖昧な期間 です。フェーズごとに正を1つに固定します。
| フェーズ | 正データ | 新システムの役割 | 現場の入力先 | 差分検知 |
|---|---|---|---|---|
| P0 影運用 | 旧 | 旧データを読み取り複製し、計算を並走させるだけ | 旧のみ | 日次で計算結果を突合し差分一覧を出す |
| P1 出力移管 | 旧 | 帳票・レポートの出力を担当 | 旧のみ | 出力金額の一致確認（レイアウト差は許容範囲を事前合意） |
| P2 部分入力移管 | 業務単位で分割 | 新規に発生した案件を新で処理 | 案件により分岐 | 業務単位ごとの件数・金額の合計照合 |
| P3 中核移管 | 新 | 計算・締めを新で実施 | 新のみ | 旧は同期停止。過去分の再計算は新で実施 |
| P4 旧停止 | 新 | 全機能 | 新のみ | 旧は参照専用で保存。書き込み経路を物理的に遮断 |
このルール設計で外せない原則が3つあります。
原則1：同じレコードを新旧両方で更新可能にしない。 更新できる側が正です。もう一方は必ず読み取り専用にします。「両方で入力して後で合わせる」運用は、締め直前に必ず破綻します。
原則2：正の境界は日付ではなく業務単位で切る。 「4月1日以降は新システム」と決めると、3月契約・4月入居・5月初回請求の案件が新旧に分断されます。「この契約は新」「この工事は旧」と 案件単位で固定 し、案件が完結するまで移動させません。
原則3：P2の期間は、業務単位ごとに完了条件を明示する。 賃貸契約なら「解約または更新まで旧」、工事なら「完工・原価締めまで旧」といった終端を決めます。終端が決まらない案件（長期のサブリース契約など）は、P3でデータ移行する対象としてあらかじめリストにします。
双方向同期を避け、片方向とコード対応表で繋ぐ
新旧をつなぐ連携は 片方向に限定 します。双方向同期は更新競合の解決ルール（タイムスタンプ勝ち、システム優先など）が必要になり、「なぜこの金額になったか」を現場の誰も説明できなくなります。障害時の切り戻しも、どこまで戻せばよいか判断できません。
マスタデータは例外的な扱いが必要です。
- 物件・取引先・勘定科目などのマスタは、更新元をどちらか一方に固定する。 更新元から他方へ片方向で配信します。
- 旧システムのコードを捨てない。 新システム側のテーブルに「旧システムコード」列を持たせます。過去帳票の照会、監査対応、現場の口頭コミュニケーション（「あの物件、旧の3桁コードで言うと…」）で必ず必要になります。
- 半角カナ・外字・機種依存文字の変換表を先に作る。 オフコン特有の外字は自動変換で潰すと元に戻せません。変換前後の対照表をデータとして残します。
旧システムの画面しか入力経路がなく、APIもDB直参照も許されない場合は、RPAで橋渡しする選択肢があります。ただし画面操作の自動化は旧システムの改修で壊れるため、P2までの暫定手段と位置づけます。使い分けはAIエージェントとRPAの使い分け｜不動産・建設の判断軸で整理しています。
段階移行でも失敗する典型パターン
- 「段階」を機能ではなく部署で切る — 営業部は新、経理部は旧、とすると同じ契約データを2部署が別システムで触ることになります。切るのはデータの流れであって組織ではありません。
- 夜間バッチの実行順序を調べずに移す — ジョブネットが図として残っていないケースが多く、順序が変わると締め結果がずれます。移行前にジョブの依存関係を実行ログから復元します。
- 帳票を旧と完全一致させる約束をしてしまう — 罫線位置やフォントまで一致させる合意は、プリンタ依存のコストを丸ごと引き受けることになります。「金額・項目・並び順は一致、レイアウトは新様式」と着手前に合意します。
- 旧データの不整合行の受け皿を決めていない — 旧システムに制約がなく、参照先の消えた行や日付が未設定の行が残っていることがあります。新側の制約で弾かれるため、「移行しない」「保留テーブルへ退避」「手修正」のどれにするかを事前にルール化します。
- 旧システムの参照手段を停止時に失う — 法定保存期間中の照会に備え、P4では画面が動かなくてもデータを検索できる形（CSV＋検索画面など）を残します。保存期間と要件の判断は税理士・監査法人にご確認ください。
この方式でできないこと
- 総コストが一括より安くなる保証はありません。 並行稼働期間は旧システムの保守費と新システムの構築費が重なります。段階移行は「止められない」「仕様が書けない」制約への対処であって、コスト削減策ではありません。
- 旧システムに記録されていない情報は復元できません。 賃料改定の判断理由、値引きの経緯、顧客との口頭合意など、データ化されていない文脈は移行対象にできません。新システムで初めて記録を始める項目として切り分けます。
- AIがソースコードから仕様書を自動生成して完了、にはなりません。 AIは読解の当たりをつける補助にとどまり、正しさの検証は入出力照合でしか行えません。
- 法定帳簿・電子保存の適否は判断できません。 宅地建物取引業法や建設業法の帳簿、電子帳簿保存法の要件適合は、個別に専門家へご確認ください。
- 全業務を新システムに寄せきれない場合があります。 年1回しか動かない特殊計算などは、旧環境を参照専用で残す判断が合理的なこともあります。
まとめ
- 一括刷新の可否は、中核計算の仕様を説明できる人がいるか で判断する。説明できないなら要件定義が成立せず、段階移行が現実解。
- 剥がす順序は 出力 → 参照 → 周辺入力 → 基幹入力 → 中核計算・締め。書き込みが発生しない層から着手する。
- 分割線は「締めをまたぐか」「整合性の起点か」「遡及再計算が走るか」「法定帳簿に直結するか」で引く。
- 仕様不明の処理は、仕様書を復元せず 過去の入出力ペアを正解データにした再現テスト で仕様を確定させる。
- フェーズごとに正データを1つに固定し、同じレコードを新旧両方で更新可能にしない。正の境界は日付ではなく契約・工事などの業務単位で切る。
- 新旧の連携は片方向に限定し、旧コードは新システム側に対応列として保持する。
よくある質問
Q. オフコン基幹システムは一括刷新と段階移行のどちらを選ぶべきですか？
A. 判断軸は「中核計算の仕様を説明できる人が社内にいるか」です。賃料計算や原価配賦の例外処理を誰も説明できない状態なら、一括刷新は要件定義が成立せず段階移行が現実解になります。逆に仕様が文書化され、締め処理も単純なら一括のほうが総期間は短く済みます。
Q. 仕様書がなくソースも読めない処理はどう移行しますか？
A. 仕様書を復元するのではなく、過去の入力と出力のペアを正解データとして扱います。旧システムの入力値を新ロジックに流し、出力が一致するまで差分を潰す再現テストを繰り返します。差分が出た条件（日割り、途中解約、遡及改定など）がそのまま仕様書になります。
Q. 段階移行中は新旧どちらのデータを正にすべきですか？
A. 常にどちらか一方だけを正とし、同じレコードを両方で更新できる状態を作らないことが原則です。正の境界は日付ではなく契約・工事といった業務単位で切ります。月をまたぐ締め処理があるため、日付で切ると同一案件が新旧に分断されます。
Q. 新旧システムを双方向同期してつなぐのは有効ですか？
A. 推奨しません。双方向同期は更新競合の解決ルールが必要になり、どちらの値が採用されたかを現場が説明できなくなります。片方向同期に限定し、業務単位で正を固定するほうが、障害時の切り戻しも単純になります。
Q. 段階移行にかかる期間はどう見積もればよいですか？
A. カレンダー期間ではなく「何回の月次締めと期末を新システムで通すか」で数えます。中核計算を移す段階では、年1回しか動かない処理（決算、更新料の年次計算など）の検証に最低1周期が必要です。業務単位の数と締め回数が期間を決めます。
ご相談について
エクサテックは、不動産・建設の現場に入り込み、仕組みの設計からWebアプリの実装までを同一チームで行っています。株式会社イーリアルティ様への転記エージェント導入でも、契約前の段階から何度も現場に足を運び、実際の作業を見るところから始めました。
「どこから剥がせるか分からない」という段階でも構いません。現行システムの出力帳票と業務の流れを拝見し、第1層から着手できる範囲の切り出しをご一緒に整理します。
