基幹システムのリプレイス・再構築：進め方と支援会社への相談タイミング

老朽化、保守期限、業務変更への追随不足を理由に基幹システムのリプレイスを検討しても、すぐに全面刷新を決める必要があるとは限りません。まずは業務への影響、使い続けられる期限、暫定策の限界を把握し、構想策定と現行調査を始めるべき状態かを判断します。

この記事では、方式の組み合わせ、発注準備、見積比較、移行・検収の統制、外部支援への相談時期を順に整理します。自社の制約に合う刷新方針と、比較可能な発注準備の進め方を判断できるようになります。

リプレイスは導入方式だけで決めず、現行調査、発注準備、移行・検収までを連続した意思決定として管理します。

01Sectionリプレイスはいつ着手するか：まず保守期限と業務影響を可視化する

着手の判断は、「新しいシステムを導入する」と決めることではありません。現行環境の制約と業務への影響を可視化し、構想策定・現行調査を開始する対象範囲を決めることから始めます。老朽化・複雑化した既存システムは事業変化への追随を難しくし得るため、IT資産の可視化と経営層を含む検討が重要です。詳しくは経済産業省「レガシーシステムモダン化委員会総括レポート」も参考になります。

リプレイス・更改・刷新・再構築・移行は「何を変えるか」で定義する

リプレイスや入れ替えは既存システムを別の仕組みに置き換えること、更改はハードウェアやOS、ミドルウェアなどの更新を指すことが多い表現です。刷新は業務・運用・統制まで見直す広い取り組み、再構築は要件やアーキテクチャを見直して作り直す取り組み、移行はデータや機能、処理を新環境へ移す工程を指します。

実際には複数の対応が重なります。用語で範囲を決めるのではなく、「維持する業務」「変える業務」「移すデータ」「切替順序」を明確にしてください。企画から運用・保守までを一続きのライフサイクルとして整理する考え方は、IPA「共通フレーム2013」でも示されています。

構想策定を始めるべき技術・業務・統制・組織のサイン

次のようなサインが複数ある場合は、全面刷新の可否とは別に現行調査を始める判断が必要です。

• 技術・契約：保守終了が近い、障害復旧が特定担当者に依存している、性能問題や改修影響を把握しにくい
• 業務・事業：組織・拠点の変更に追随できない、二重入力や手作業が増えている、データ統合や連携に制約がある
• 統制・運用：権限管理、監査、バックアップ、災害対策、運用手順に不足がある
• 組織：現行仕様を説明できる人材が不足し、部門間の優先順位や判断が停滞している

サインごとに、業務影響、保守期限や停止許容時間、暫定策、その責任者を記録します。たとえば保守終了日だけを追うのではなく、「繁忙期に停止した場合の影響」「切替までに許容できる暫定運用」をセットで確認することが重要です。

初動で決める対象範囲、責任者、期限、意思決定の場

初動では、全社の全機能を一度に調べる必要はありません。影響が大きい業務と期限が近い領域を対象に、業務・機能・データ・帳票・連携・権限・保守契約・障害履歴を確認します。

あわせて、経営スポンサー、業務責任者、情報システム側責任者を置き、対象範囲と決裁期限を確認する会議体を決めます。この段階の完了条件は全面刷新の決裁ではなく、調査対象、責任者、制約、次に比較する方式が合意されていることです。

02Section刷新方式は3軸で選ぶ：変更方針・稼働形態・切替方針を分ける

「何を変えるか」「どこで動かすか」「どう切り替えるか」を分けて検討すると、選択肢を不必要に狭めずに済みます。

同等更新、標準機能中心の移行、個別再構築、クラウド利用、段階導入を一列に並べると、選択肢を誤って狭めます。方式は「何を変えるか」「どこで動かし誰が担うか」「どう切り替えるか」の3軸で組み合わせます。

たとえば「標準機能中心の移行 × クラウドサービス × 段階導入」のように候補を記述します。クラウド化は変更方針や切替方針と排他的な選択肢ではありません。

第1軸：業務・アプリケーションをどこまで変えるか

同等更新は、保守期限への対応を優先し、現行の業務・帳票・連携を維持したい場合の候補です。ただし、例外処理や二重入力などの課題を温存する可能性があります。

標準機能中心の移行は、共通業務を標準化し、例外処理を統廃合できる場合に検討します。法令・統制・共通業務として説明できる領域は標準化候補です。一方、顧客価値や収益性、代替しにくい統制要件に直接関わる業務は、個別再構築を候補に含めます。

候補は必須業務、法令・統制要件、稼働期限で先に足切りし、その後に業務適合性、個別開発量、連携・データ移行、将来変更、継続運用負荷を比較します。

第2軸：どこで稼働させ、誰がどこまで運用責任を負うか

自社運用環境、クラウド基盤、クラウドサービスのいずれを使う場合でも、責任が一方に完全移転するわけではありません。クラウド利用では、設定、ID・権限、データ保護、アプリケーション運用などの責任が利用者側に残り得ます。AWS「責任共有モデル」を参考に、サービス構成、契約、統制要件に応じた役割分担を確認してください。

可用性、性能・拡張性、運用・保守性、移行性、セキュリティも横断して確認します。確認観点の整理にはIPA「非機能要求グレード2018」が役立ちます。

第3軸：一括切替・段階導入・並行運用をどう選ぶか

一括切替は旧新環境の併存期間を短くしやすい一方、切替日に問題が集中しやすい方法です。段階導入は業務、拠点、機能ごとに導入波を分け、学習と修正を次の波に反映できます。並行運用は照合の機会を得られますが、二重運用の負荷と差異管理が発生します。

切替方針は、停止許容時間、繁忙期、データ整合、現場の受入体制を踏まえて決めます。方式の組み合わせを要件や受入条件へ落とし込む際は、基幹システムの選定ポイントもあわせて確認してください。

03Section現行調査・要件・RFI/RFPで見積前提をそろえる

見積もりの精度は、依頼先の数よりも前提のそろえ方に左右されます。現場から集めた要望をそのまま並べるのではなく、現状、優先順位、受入条件、未決事項を結び付けて発注要件にします。

現行調査は4ブロックで記録する

調査対象は、業務・機能、データ・帳票、連携・権限、非機能・運用の4ブロックにまとめます。各ブロックで現状だけでなく、例外処理、障害時対応、保守上の制約、変更時に影響する周辺領域を記録してください。

要件は優先度・受入条件・決定責任者・期限をセットにする

要件は「必須」「重要」「希望」「将来検討」に分けます。必須かどうかは要望の強さではなく、業務継続、法令・統制、稼働可否への影響で決めます。

各要件には、背景、優先度、受入条件、決定責任者、決定期限、変更時の影響を付けます。受入条件は「必要」のような抽象表現ではなく、どの業務シナリオで、誰が、何を確認できれば受け入れられるかまで記載します。

RFI・RFP・見積依頼を準備度で使い分ける

方式の選択肢、実現可能性、概算条件を把握したい段階ではRFIを使います。対象範囲と要件を固め、同じ前提で具体的な提案・見積もりを比較する段階ではRFPを使います。調達準備におけるRFIやRFPの考え方は、デジタル庁「標準ガイドライン実践ガイドブック」でも確認できます。

RFPと見積依頼には、目的、対象範囲、制約、連携・移行、回答形式、評価方法に加え、見積前提・除外事項・発注側作業・責任分界・未決事項と決定期限を記載します。秘密保持、個人情報、契約条項は、対象データと取引条件に応じて法務・調達部門と確認してください。

04Section費用と期間は相場より先に比較構造をそろえる

基幹システムの費用と期間は、対象業務、利用規模、連携、データ品質、業務変更、切替方式、支援範囲、発注側作業によって変わります。公開情報だけでは、これらを同じ条件で比較しにくいため、一般的な総額相場や標準期間として扱うのは適切ではありません。

金額を比べる前に、対象範囲・費目・期間の起点と終点をそろえることが必要です。

3つの見積シナリオで対象範囲と除外事項を固定する

限定導入、主要業務刷新、全社再構築は金額区分ではなく、比較する範囲をそろえるためのシナリオです。同じ回答様式で見積もりを依頼します。

初期費用・継続費用・発注側別途負担を分ける

初期費用は、構想・要件・調達、製品・ライセンス・基盤、設計・設定・開発、連携・移行・テスト・教育・切替に分けます。継続費用は保守、運用、監視、問い合わせ、追加改修、利用規模増加時の費用、旧環境延長費を分けて確認します。業務レビュー、移行データの整備・照合、受入テスト、教育参加、並行運用、社内環境対応は、発注側の別途負担として扱います。

投資比較総額は、次のように整理します。

投資比較総額 ＝ 外部契約総額 ＋ 金額化する発注側別途負担 ＋ 旧環境延長費 ＋ 契約上の選択費目

開発データを見積もりの点検に使う場合も、開発種別、規模、業種、工程範囲、工数定義が自社案件と比較可能かを確認します。IPA「ソフトウェア開発分析データ集2022」は基幹システム刷新の総額相場を示す資料ではありません。費目分解や総保有コストの考え方は、基幹システム導入費用の考え方も参考にしてください。

稼働希望日から逆算し、条件が崩れたら再比較する

期間は「構想開始から本稼働判定まで」と「開発・構築開始から本稼働判定まで」を分け、安定化完了も別に管理します。本稼働希望日だけを固定し、要件合意、受入テスト、移行リハーサル、切替判定の完了条件が未定のまま比較しないことが重要です。

各案を、予算適合、稼働日適合、停止許容度、発注側負担について「適合・条件付き適合・不適合」で判定します。不適合や条件付き適合が残る場合は、対象範囲、導入波、標準化範囲、並行運用の可否を変え、同じ条件で再見積もりします。

05Section工程を意思決定ゲートで管理する：体制・成果物・進行条件

次工程へ進む条件と未決事項の管理を各ゲートに置くことで、工程の進行と意思決定を切り分けて統制できます。

リプレイスは工程をこなすだけでは統制できません。各工程で成果物、承認、次へ進む条件、未決事項の責任者と期限を置きます。

構想承認から方式決定まで：目的・範囲・優先順位を固める

構想承認では、なぜ変えるのか、どこまでを対象にするのか、何を優先するのかを合意します。方式決定では、その目的を踏まえ、標準化する領域、独自性を維持する領域、切替方針を判断します。

業務優先順位、業務変更、受入可否、最終的な投資判断は発注側が保持すべき事項です。外部支援を使う場合も、これらの判断を委ねるのではなく、比較材料や調査結果を整える作業として切り分けます。

要件合意から設計・開発進行まで：変更を統制する

要件合意の基準は、すべての論点が解消していることではありません。未決事項について、決定責任者、期限、影響範囲、今回対応か将来対応かを記録し、提案・見積もりの前提が統一されている状態を目指します。

設計・開発では、要求変更を変更台帳で管理し、費用、期限、テスト、移行への影響を承認前に確認します。兼任体制では、部門間の優先順位調整、要件レビュー、テストケース作成、移行照合、教育、決定期限の管理が不足しやすいため、担当を明確にします。

移行・切替判定から安定化まで：受入・運用開始を分けて判断する

移行開始の判定と本稼働の判定は分けます。本稼働前には、必須業務の受入テスト、移行データの照合、切替手順、切戻し条件、連絡網、未解決課題を確認します。移行計画、移行・稼働判定、総合テストを事前に確認する観点は、デジタル庁「標準ガイドライン群 改定のポイント（令和7年度）」も参考になります。

安定化では、業務効率、統制、データ活用、安定運用について、構想段階で定めたKPIを確認します。本稼働直後の数値と安定化後の数値を分けることで、切替完了と投資効果を混同しにくくなります。

06Section提案比較から移行・検収まで、契約前に確認すること

提案比較は価格順に並べる作業ではありません。提案が要件をどのように理解し、どの前提で実現するのかを確認し、後工程の受入・検収条件まで契約前に整理します。デジタル庁「標準ガイドライン解説書」も、要件理解、提案内容の具体性、要件との整合を評価観点として示しています。

必須条件で足切りし、重要項目は重み付けで比較する

最初に、必須業務・法令・統制要件、希望する稼働時期、データ移行・連携・帳票、セキュリティと運用責任分界、見積前提の透明性で足切りします。満たさない条件がある候補は、代替策と費用・日程への影響が文書化されない限り、総合評価へ進めません。

残った候補は、業務適合・標準化方針、連携・移行・データ品質、非機能・運用・責任分界、実行体制・変更管理・品質管理、費用・契約条件の透明性を重み付けして評価します。重み、評価者、決裁者は採点前に決め、候補ごとに変えません。

加重評価点 ＝ 評価軸ごとの5段階評価 × 各評価軸の重み の合計

採点には提案書、質問回答、デモ、見積内訳などの根拠を付けます。総合点が高くても、稼働日、移行、責任分界、発注側負担に重大な未解決事項がある場合は、別の決裁論点として扱います。

見積前提・除外事項・発注側作業・責任分界を横並びにする

候補間で比較すべきなのは外部契約総額だけではありません。構想・要件、製品・基盤、設定・開発、連携、移行、テスト、教育、切替、保守のどこまでを含むかをそろえます。

特に、データ整備・照合、受入テスト、教育参加、並行運用、社内環境対応などの発注側作業は、作業量、責任者、実施時期を明記します。責任分界は、利用サービス、構成、契約、法令・統制要件で変わるため、役割分担表を契約条件と照合します。

受入基準、移行照合、未解決課題、保守開始条件を契約前に確認する

受入基準は、必須要件ごとの合格条件、業務シナリオ、性能、権限、監査などを対象にします。移行照合では、件数、重要な金額・数量の集計値、欠損・重複、例外データ、対象外データの扱いを確認します。切替では、判定時刻、連絡網、代替運用、切戻し条件・権限・期限を合意します。

未解決課題は次の3区分に分けます。

• 重大な未達：必須業務、法令・統制、稼働可否、データ整合、セキュリティに影響する課題
• 軽微な課題：本稼働を妨げないが、期限と暫定回避策の管理が必要な課題
• 将来改善：保守または追加開発として扱い、今回の検収対象から外す理由を記録する課題

それぞれに業務影響、責任者、対応期限、費用負担、検収との関係を付けます。保守開始についても、検収の有無だけでなく、問い合わせ・障害受付、監視、権限管理、運用手順、引継ぎ成果物が開始可能な状態かを確認します。

07Section支援会社への相談はいつからか：準備度で依頼範囲を決める

RFP完成前でも、整理できていない論点に合わせて支援範囲を区切れば、相談の目的を明確にできます。

完成したRFPは、外部支援へ相談するための必須条件ではありません。社内で判断すべきことと、調査・比較・統制として外部へ切り出せることを分ければ、構想段階から相談の目的を定められます。

RFP完成前でも相談できる4つの局面

工程別意思決定ゲート表の「外部支援を切り出しやすい場面」を使うと、相談目的を整理できます。

1. 1現行資産や業務課題を説明できない場合は、構想整理や現行調査の設計を相談する
2. 2対象範囲と決裁者は決まったが方式を絞れない場合は、RFI、方式比較、概略ロードマップを相談する
3. 3要件はあるが見積前提がそろわない場合は、要件整理、RFP、評価基準の統一を相談する
4. 4移行・テスト・切替を統制する社内機能が不足する場合は、PMO、移行、テスト、教育、切替統制を作業単位で相談する

初回相談で共有する情報と、発注側が保持する判断

初回相談では、発注準備テンプレートにある「初回相談」の情報を使います。背景、対象範囲、期限、制約、現行環境、社内体制、未決事項、期待成果物を共有すれば、RFP前でも必要な支援範囲を検討できます。

一方で、業務課題の優先順位、業務変更の意思決定、受入可否、最終的な投資判断は発注側が保持します。依頼範囲の切り分けは、内製と外部委託の判断軸も参考にしてください。

相談先を比較する際に確認する支援範囲と契約条件

相談先を比較するときは、支援範囲が構想、調査、要件化、RFI/RFP、PMO、移行・テストのどこまでかを確認します。あわせて、主要担当の役割、成果物、レビュー方法、変更管理、見積前提、除外事項、発注側作業、責任分界を比較します。

保守期限と業務影響を可視化したうえで、方式、見積前提、工程ゲート、受入・検収条件を順に定め、必要な作業単位から外部支援を検討してください。リプレイスの進め方や依頼範囲の整理に支援が必要な場合は、サービス一覧をご確認ください。

RFP作成・ベンダー選定支援を探す

要件や見積前提をそろえ、比較可能な提案依頼へ進めたい場合は、RFP作成・ベンダー選定を支援できる会社を確認できます。

RFP作成・ベンダー選定支援1071社掲載

支援会社を探す