LASSIC Media らしくメディア
システム統廃合の進め方｜棚卸しから集約・廃止の実務
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- M&A・SaaS乱立で生じた重複システムを整理するには、まず現行システムの棚卸しと利用実態の把握から着手する必要があります
- 廃止か集約かを判断するには、利用頻度・重複度・保守コストの3軸で評価するフレームが実務で機能します
- データ統合とマスタデータ整備を並行して進め、段階的に廃止することでリスクを大幅に抑えられます
クラウドサービスの普及やM&Aによる組織統合が進む中、「気づけば社内に同じ機能を持つシステムが複数稼働している」という状況は珍しくありません。部門ごとに導入したSaaSツール、グループ会社の統合で持ち込まれた基幹システム、バージョン違いで並行稼働しているERPなど、重複システムの放置は保守コストの肥大化と管理工数の増大を招きます。
本記事では、こうした重複システムを整理するための「システム統廃合」の進め方を、現行システムの棚卸しから廃止判断・データ統合・段階的廃止まで、実務5ステップで解説します。
目次
システム統廃合とは — 集約・廃止で重複コストを解消する取り組み
システム統廃合とは、組織内に乱立している複数のシステムを評価し、機能が重複しているものを1つに集約するか廃止することで、保守コストと運用負荷を削減する取り組みです。単一のシステムを別のシステムに置き換える「システム移行（リプレース）」とは異なり、「多対1」または「完全廃止」という整理が中心となります。
IPAが2025年6月に公表した「DX動向2025」では、レガシーシステムの刷新が日本企業のDX推進において重要な技術利活用テーマとして位置づけられています*1。重複システムの温存はレガシー化を加速させる要因の一つでもあり、統廃合はDX推進の前提条件としての意味を持ちます。
M&A・SaaS乱立・老朽化 — 統廃合が必要な3つの背景
システム統廃合が課題となる背景として、主に3つの状況があります。一つ目はM&Aやグループ再編で、買収先・統合先がそれぞれの基幹システムをそのまま持ち込んだ結果、同種のシステムが並行稼働するケースです。
二つ目はSaaSツールの乱立です。各部門がそれぞれ気に入ったSaaSを導入した結果、顧客データ管理ツールや経費精算ツールが社内に複数存在する状態になります。ガバナンスが効かないまま放置すると、データが分散し、突き合わせコストが増大します。
三つ目はシステムの老朽化と部分刷新の積み重ねです。古いシステムを全廃せずに新システムを部分導入した結果、旧システムが並行稼働し続けるケースがこれにあたります。IPA「DX白書2023」でも、システムの刷新が遅れると技術的負債が拡大するという課題が報告されています*2。
システム移行（リプレース）との違い — 「多対1」か「完全廃止」が核心
システム移行（リプレース）は基本的に「旧システムAを新システムBに置き換える」という1対1の対応です。一方、システム統廃合では「複数のシステムを1つに集約する（多対1）」か「完全に廃止する」かの意思決定が中心となります。
この違いは実務上の難易度に直結します。移行ではデータの移し替えが主課題ですが、統廃合では「どのシステムを残すか」という業務要件の整理と、複数システムから集約先へのデータ統合が並行して発生します。プロジェクト管理の複雑さが一段上がるため、計画段階での十分な準備が不可欠です。
ステップ1 — 現行システムの棚卸しと利用実態の把握
システム統廃合を進める最初のステップは、組織内に存在するシステムの全量を把握する棚卸しです。このステップをおろそかにすると、後の判断が根拠不足のまま進んでしまい、廃止後に想定外の業務停止を招くリスクがあります。
棚卸し対象の範囲定義 — 業務別・部門別に洗い出す
棚卸しを始める前に、調査対象とする範囲を定義します。全社一括での実施が理想ですが、規模が大きい場合は業務ドメイン（販売管理・会計・人事・顧客管理など）または部門単位でスコープを区切り、段階的に進める方法が現実的です。
洗い出す項目として最低限押さえるべきは以下の4点です。
- システム名と主要機能：正式名称と「何ができるか」を1〜2行で記載
- 稼働年数・バージョン：老朽度の判断材料になります
- 利用部門・利用者数：実際に使っている組織単位を把握します
- 年間保守費用・契約形態：コスト削減の試算に直結します
棚卸しシートはスプレッドシートで管理するのが一般的です。システムが多い場合は、まず「年間費用が発生しているもの」から優先して調査すると、コスト観点での優先順位が早期に見えてきます。
利用頻度・保守費用・担当者の3指標を揃える
システムの全量を把握したら、各システムについて「実際に使われているか」を確認します。登録されているが誰も使っていないシステムや、担当者が退職して引き継ぎが宙に浮いているシステムは、廃止の第一候補です。
確認すべき3指標は次のとおりです。まず利用頻度として、月次のログイン件数や処理件数を把握します。SaaSであれば管理画面から確認できます。次に保守費用として、年間の保守・サポート費用を金額で把握します。最後に主担当者と業務オーナーとして、「誰がそのシステムの責任者か」を明確にします。廃止時に合意を得る相手が不明だと、判断が止まります。
ステップ2 — 機能の重複・依存関係の特定
棚卸しで現行システムの全量が揃ったら、次は「どのシステムとどのシステムが同じ機能を持っているか」を特定します。このステップが統廃合の根拠を作る核心作業です。重複の特定が甘いと、廃止後に「実は別の用途で使っていた」という事態が発生します。
機能マップで重複箇所を可視化する — 機能×システムのマトリクス活用
各システムが持つ機能を横軸に、システム名を縦軸に並べた「機能マップ（機能×システムのマトリクス）」を作成します。同じ機能セルに複数の○が付く箇所が重複候補です。
たとえば「顧客マスタ管理」という機能がCRMとERPと販売管理システムの3つで重複していれば、この3つが統廃合の候補グループになります。機能粒度は「大分類（顧客管理）」だけでなく「中分類（見積管理・受注管理）」まで掘り下げると、「一部機能だけ移管して残りは廃止」という部分的な整理もできるようになります。
システム間の連携・依存を調べる — API・バッチ・ファイル連携の洗い出し
機能の重複が特定できたら、次はシステム間の連携経路を調べます。廃止しようとしたシステムが別のシステムにデータを送っている場合、廃止すると連携先が動かなくなります。
連携の種類は大きく3種類です。API連携（リアルタイムにデータをやり取り）、バッチ処理（夜間などに一括でデータを転送）、ファイル連携（CSV・Excelを手動または自動で渡す）です。これらを洗い出し、「廃止したときに影響を受けるシステムはどれか」を一覧化します。依存先が多いシステムは廃止の優先度を下げ、依存先がないシステムを先行廃止するのが実務上の定石です。
ステップ3 — 廃止・集約の優先順位付け
棚卸しと機能評価のデータが揃ったら、どのシステムを優先的に廃止・集約するかを決定します。感覚や声の大きい部門の意向だけで決めると、後になって混乱が生じます。評価軸を揃えた客観的な判断プロセスが必要です。
利用頻度×重複度×保守コストで評価する
廃止判断に使いやすい3軸は「利用頻度」「重複度」「保守コスト」です。各軸を3段階（高・中・低）で評価し、スコアが高いシステムを廃止候補の上位に置きます。
| 評価軸 | スコア高（廃止優先） | スコア低（廃止後回し） |
|---|---|---|
| 利用頻度 | 月次ログイン数が少ない・ 使用者が限定的 |
日次で多数のユーザーが アクセスしている |
| 重複度 | 同種機能を持つシステムが 他に2つ以上ある |
この機能を持つのは このシステムだけ |
| 保守コスト | 年間保守費用が高いか 改修工数が大きい |
保守費用が低く 安定稼働している |
| 依存関係 | 他システムへの連携が ない・少ない |
多数のシステムから 参照・連携されている |
4軸の評価が出そろったら、廃止優先スコアが高い順にランキングを作成します。スコアは意思決定の補助ツールであり、最終的には業務オーナーと情報システム部門の双方が合意した判断を優先します。
「集約先」か「廃止」かの判断基準
評価の結果、重複しているシステムについて「集約先（残すシステム）」と「廃止（なくすシステム）」を決定します。集約先の判断基準として、実務でよく使われるのは以下の観点です。
- 機能網羅性：廃止するシステムの必要機能を代替できるか
- スケーラビリティ：今後の利用者増・データ増に耐えられるか
- ベンダーサポート状況：サポート期限が近い・終了しているシステムは集約先から外す
- データ移行のしやすさ：廃止側から集約先へのデータ取り込みが技術的に可能かどうか
「どちらも同等に必要」という場合は、機能を整理して一方を完全廃止し、もう一方に機能追加するという選択肢も検討します。既製品のSaaSであれば、廃止対象の機能をアドオンや設定で補完できる場合があります。
ステップ4 — データ統合・マスタデータ整備の進め方
廃止・集約の方針が決まったら、データ統合の準備を進めます。複数システムにまたがって存在するデータを、集約先システムに正しく取り込むことは、統廃合プロジェクトの中でも技術的難易度が高い作業です。
マスタデータ名寄せと統合ルールの設定
複数のシステムで管理されてきたマスタデータ（顧客マスタ・商品マスタ・取引先マスタなど）には、同一の実体が異なる表記やコードで登録されていることがあります。たとえば「株式会社ABC」「（株）ABC」「ABC株式会社」が別レコードとして存在する状態です。これを統合先で統一しないまま取り込むと、重複データが大量発生します。
名寄せ作業では、まず統合先のマスタ定義（コード体系・表記ルール）を確定します。その後、廃止側のデータを変換ルールに沿って整形し、突き合わせ検証を実施します。名寄せの精度は業務品質に直結するため、業務部門の担当者が確認に参加できる体制を整えます。
廃止後のデータ保管と参照方法を決める
廃止するシステムのデータをどこに保管し、どのように参照できるようにするかは、法令上の要件（電子帳簿保存法など）や業務上の必要性（過去帳票の参照など）を踏まえて決定します。
主な選択肢は3つです。集約先システムに移行する（過去データも含めて取り込む）、アーカイブシステムに保管する（専用の参照用ストレージに退避してリードオンリーで保持）、CSVなどの汎用形式でエクスポートして保管する（システムを廃止しデータだけ残す最小構成）です。保管期間の法令要件と、実際に参照する頻度を照らし合わせて選択します。
廃止後の参照方法が決まったら、業務部門に周知します。「廃止したシステムで確認していた情報は、〇〇から参照できます」という案内を事前に準備することで、廃止後の混乱を防ぎます。
ステップ5 — 段階的廃止の実行と切り替え後の確認
データ統合と移行準備が整ったら、いよいよシステムの廃止を実行します。このステップでは「一斉廃止」は避け、並行稼働期間を設けた段階的な廃止を基本とします。
並行稼働期間の設計 — リスクを最小化する移行期間
並行稼働期間とは、廃止予定のシステムと集約先システムを一定期間同時稼働させ、業務に支障がないことを確認してから旧システムを停止する期間です。一般的に、業務の繁忙期を避け、月次締めや四半期末などの業務サイクルを1〜2周確認できる期間を設けることが望ましいとされています。
並行稼働中は以下の点を確認します。まずデータの整合性として、旧システムと集約先システムで同じ業務データが一致しているかを検証します。次に業務フローの完結として、日常業務（登録・更新・参照・帳票出力など）がすべて集約先システムで代替できることを確認します。問題がなければ旧システムの廃止を確定し、停止日を業務部門に周知します。
廃止後の業務確認とシステム停止手順
システム停止の手順は、事前に文書化しておきます。停止前に実施すること（最終バックアップ・データエクスポート・アーカイブ保存の確認）と、停止後に実施すること（契約解除・ライセンス返却・アクセス権の削除）を順序立てて整理します。
SaaSの場合は契約解除の手続きに締め日や通知期限がある場合が多く、停止予定日の2〜3か月前から手続きを開始することでトラブルを防ぎやすくなります。オンプレミスのシステムであれば、サーバーやストレージの処分計画も合わせて立案します。廃止完了後は、棚卸しシートのステータスを「廃止済み」に更新し、台帳を最新の状態に保ちます。
統廃合で失敗しない3つのポイント
システム統廃合は、プロジェクトの進行中に想定外の課題が出やすく、完了まで時間がかかる傾向があります。実務上よく見られる失敗パターンと、その対処法を整理します。
廃止判断に「業務オーナー」の承認を得ることが前提となる
情報システム部門が技術的な評価を行っても、最終的な廃止の意思決定は「そのシステムを業務で使っている部門のオーナー」の承認が必要です。承認を得ないまま廃止を進めると、「そのシステムがないと月次の帳票が出せない」「実は別の用途で使っている機能があった」という反発が後になって発生します。
プロジェクト発足時に各システムの業務オーナーをステークホルダーとして明確化し、廃止判断の各フェーズで確認・合意を取るステップを設計に組み込みます。情報システム部門が「決めた」ではなく、業務部門が「納得して廃止する」という形にすることが、円滑な統廃合の前提条件です。
段階廃止せず一斉廃止で混乱するリスク
コスト削減を急ぐあまり、並行稼働期間を設けずに複数システムを同時に廃止すると、業務上の問題が一度に噴出します。特に月次・年次の締め処理が絡む場合、移行直後に「旧システムでしか出せなかったデータが必要になった」という事態が起きやすくなります。
段階廃止の原則は「最も依存関係が少なく、利用者が少ないシステムから順に廃止する」ことです。1件廃止するたびに学習が得られ、次の廃止がスムーズになります。一斉廃止は「廃止の準備が完全に整っている」という確証がある場合を除き、実務上は推奨されません。
外部パートナーに依頼すべき範囲の見極め方
システム統廃合を内製で完結させようとすると、棚卸し・機能評価・データ移行・廃止手続きのすべてを社内リソースでまかなう必要があります。情報システム部門のメンバーが通常業務と並行してプロジェクトを進める場合、特にデータ統合・名寄せ・依存関係の洗い出しで工数が膨らみやすくなります。
外部パートナーへの依頼が効果的な範囲は、主に現行システムの棚卸し支援（ヒアリング設計・台帳整備）、機能マップの作成と重複特定、データ移行・名寄せの設計と実装、廃止後の動作検証の4点です。これらは専門的な経験が短期間での品質に直結する領域であり、初めて統廃合プロジェクトに取り組む組織では外部知見の活用が有効です。
一方、廃止の最終判断と業務オーナーとの合意形成は、外部には委ねられない内部の意思決定プロセスです。外部パートナーが提供するのはあくまでも「判断材料の整備と技術的な実装」であり、廃止の決定責任は組織内に残ります。
まとめ — システム統廃合を着実に進める5ステップ
本記事では、M&A・SaaS乱立・老朽化などを背景に重複したシステムを整理する「システム統廃合」の実務ステップを解説しました。要点を3点に集約します。
第一に、棚卸しと利用実態の把握が統廃合の基盤です。システム名・利用頻度・保守費用・担当者の4項目を揃えることで、廃止判断の根拠が生まれます。第二に、廃止判断は「利用頻度×重複度×保守コスト×依存関係」の4軸で評価し、業務オーナーの合意を得てから進めます。第三に、データ統合（特にマスタデータの名寄せ）と段階的な廃止を組み合わせることで、業務への影響を最小化できます。
統廃合は単なる「システム削減」ではなく、組織のITガバナンスを整える中長期的な取り組みです。特にデータ移行と依存関係の洗い出しは専門的な知見が求められる場面が多く、外部パートナーの活用を検討する際は、元請（プライムベンダー）として設計から廃止完了まで一貫して支援できる体制を持つ事業者を選ぶことが重要です。
よくある質問
システム統廃合にはどのくらいの期間がかかりますか
対象システムの数や依存関係の複雑さによって大きく異なります。SaaSツール数本の統廃合であれば3〜6か月で完了するケースがあります。一方、基幹システムが複数絡む統廃合では、棚卸し・機能評価・データ移行・段階廃止を合わせると1〜2年規模のプロジェクトになることも珍しくありません。期間の見積もりには、まず棚卸しを実施して対象システムの依存関係と数を把握することが先決です。
SaaSツールの統廃合と基幹システムの統廃合は進め方が違いますか
基本的なステップ（棚卸し→機能評価→廃止判断→データ統合→段階廃止）は共通ですが、難易度と考慮点が異なります。SaaSは契約解除の手続きや契約期限が複数存在するため、スケジュール管理が重要です。基幹システムは既存業務への影響範囲が広く、データ移行の設計とテストに多くの工数がかかります。SaaSから着手して進め方を学習し、段階的に基幹システムの統廃合に移行するアプローチが実務上取り組みやすくなります。
廃止するシステムのデータはどのように保管すればよいですか
法令上の保存義務（電子帳簿保存法（電帳法）における電子取引データの保存義務など）と、業務上の参照頻度を踏まえて方針を決めます。頻繁に参照する可能性があるデータは集約先システムに移行するか、リードオンリーのアーカイブシステムに保管します。参照頻度が低いデータはCSVやPDF形式でエクスポートしてストレージに保存する方法が管理コストを抑えやすくなります。保存期間は法令要件（最低7年など業種・書類種別により異なります）を確認してから設定してください。
統廃合プロジェクトは内製でできますか、外部に頼むべきですか
システム台帳の整備や廃止判断の意思決定は内製で進めるべき部分ですが、依存関係の調査・データ移行設計・名寄せ処理・廃止後の検証は専門知識が求められます。特に初めて統廃合プロジェクトに取り組む組織では、これらの技術的作業を外部パートナーに依頼することで、工数と品質リスクの両方を抑えやすくなります。外部依頼範囲を明確にした上で、元請（プライムベンダー）として設計から完了まで一貫して対応できる事業者を選ぶことがポイントです。
システム統廃合と「システム移行」は何が違いますか
システム移行（リプレース）は「旧システムAを新システムBに1対1で置き換える」取り組みです。一方、システム統廃合は「複数のシステムを1つに集約する（多対1）」か「完全に廃止する」ことが中心です。統廃合では廃止対象の選定と業務オーナーの合意形成という意思決定プロセスが加わります。また、複数システムからのデータ統合が発生するため、1対1移行よりもデータ整合の管理が複雑になります。
著者：テレリモ総研編集部 鈴木 亮佑
ITアウトソーシング・システム開発のご相談はLASSICへ
元請（プライムベンダー）として、貴社のシステム統廃合・データ移行・運用保守をトータルでご支援します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
