システム更改は、現状分析、要件定義、RFP作成・評価の順に進めると、移行漏れや不具合を防げます。保守期限切れやEOLに追われると、早く新基盤へ移すことに意識が傾きがちです。
全体像はシステム更改の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
更改の起点となるアセスメント・現状分析
システム更改は、現行システムを正確に把握するアセスメントから始まります。仕様書の欠如やブラックボックス化は、要件定義が不十分になる大きな原因です。そのため、移行前に現行資産を棚卸しし、AS-IS（現状）を見える形にしておくことが欠かせません。
AS-IS可視化と資産棚卸しの進め方
AS-IS可視化では、現行システムの構成や機能、データ、連携先を洗い出します。長く運用されたシステムは、設計後も改修が重なり、仕様書と実態が食い違うことがあります。そのため、実態をつかむには、資料だけでなく、現場で使う人の声も欠かせません。
- 資料を照合：ソースコード、稼働ログ、運用手順書の内容を突き合わせます。
- 利用部門に聞く：ヒアリングで、実際の動作を確かめます。
- 可視化ツールを使う：複雑な資産を把握します。
可視化の手間を減らすツールもあります。たとえば、富士通の「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を示し、密結合で改修リスクが高い部分も地図のように可視化します。
資産規模が大きく依存関係が複雑なシステムほど、可視化ツールが棚卸しの精度と速度を高めます。さらに、資産棚卸しでは各機能の利用状況も把握して、未使用機能や重複処理を見つけます。
対象範囲を適切に絞るには、利用状況の確認も欠かせません。アセスメントのみの場合、要件定義や業務棚卸しは200万〜500万円が相場の一つです。
この投資は後工程の手戻りを防ぎ、更改全体のコストを抑える効果があります。そのため、移行に着手する前に、資産を棚卸しし、AS-IS（現状）を可視化しておきます。
移行後のTO-BE像と移行方針の決定
現状を把握したら、更改後に目指すTO-BE像を描きます。そのうえで、現行機能をそのまま再現する「現状踏襲」と、見直す部分を切り分けます。
- 維持と改善を分ける：移行スコープのぶれを防ぐための区分けです。
- 移行手法を選ぶ：対象範囲ごとに、リホストかリビルドかを決めます。
- 移行時期を決める：一括で移すか段階的に移すかを含めて、方針を固めます。
移行方針は、保守期限の切迫度、予算、許容できるダウンタイムを踏まえて定めます。
現状を把握する前に方針を先に決めると、移行時に前提が崩れて手戻りが生じます。このため、準備工程で現状と方針の両方を明確にしておくと、更改全体の確実性を高められます。
アセスメントとTO-BE定義を丁寧に行うことは、更改の進め方そのものを設計することにつながります。さらに、この方針がRFPの骨格となり、ベンダーへの要件の伝え方や見積もりの精度を高めます。
RFPに盛り込むべき更改特有の要件
アセスメントと要件定義の成果は、RFP（提案依頼書）に明記してベンダーへ提示します。更改では特に、現行システムとの整合や移行要件を厚く盛り込みます。
記載が曖昧だと、ベンダーごとに前提がばらつき、提案を比べにくくなります。そこで、移行の条件を具体的に伝え、提案の前提をそろえます。
現行構成図・性能要件・移行後KPIの明記
現行構成図は、アセスメントで可視化したインフラ・アプリ・データ・連携の全体像を示します。そのため、ベンダーは移行の難しさを見積もれます。
性能要件は、現行のレスポンスやバッチ処理時間を基準にして記します。そのうえで、更改後に維持または改善する水準を明確にします。
- 移行後KPI：保守費の削減目標や処理時間の短縮目標を定めます。
- データ移行：対象範囲と移行方式を記します。
- 停止と並行稼働：許容ダウンタイムと、新旧並行稼働の期間を示します。
目標が示されると、ベンダーは目標達成に向けた提案を行えます。さらに、RFPの項目がそろうほど、提案の精度と各社を横並びで比べる基準が高まります。
曖昧な要件では、安く見える提案が移行範囲を狭く想定しているケースがあります。そのため、具体的な記載が公正な比較と適切な選定の前提になります。
データ移行とダウンタイムの要件定義
現行と新システムのデータ構造を対応づけるデータマッピングは、更改の難所です。設計が不十分だと、データの欠損や不整合を招きます。
- 移行対象：移すデータの範囲を決めます。
- 変換要件：文字コードやフォーマットの変換条件を記します。
- 検証方法：移行後にデータを確かめる方法を定めます。
許容できるダウンタイムも定義します。とくに24時間稼働の業務では、停止できる時間帯が限られます。
停止できる時間帯と長さを示し、超える場合に新旧並行稼働で対応するかも要件に加えます。そうすると、現実的な移行計画を立てやすくなります。
データ移行とダウンタイムの要件は、更改の品質とリスクを左右します。新規開発にはない要件だからこそ、RFPで具体化して、移行時の混乱を防ぎます。
準備工程で要件まで踏み込むことが、「止めない更改」の第一歩です。ダウンタイムの見積もりは、ベンダー評価の場面でも見られます。
失敗しないベンダー選定の評価観点
RFPへの提案が集まったら、客観的な基準でベンダーを評価します。更改には移行リスクが伴うため、価格や開発力だけでは決められません。
安全に移行できる実績と体制を見極めます。複数の観点で定量的に評価すると、主観に頼らず選定の精度を高められます。
ベンダー評価の5つのチェックポイント
更改ベンダーは、次の5つの観点で評価します。移行を安全にやり切れる力を、それぞれの側面から確かめるためです。
- 同業界・同規模の更改実績：類似業務と規模の移行経験を確認します。
- 段階移行の設計力：機能単位で段階的に移す計画を評価します。
- ダウンタイムの見積もり：停止時間と短縮策の現実性を見ます。
- 24時間365日の保守体制：更改後の運用体制を確かめます。
- 品質・セキュリティ認証：ISO9001やISO27001の有無です。
類似案件の経験があれば、想定外の事態への対応力も期待できます。また、一括切り替えだけでなく、新旧を並行させて安全に移せる設計力も見ます。
停止時間を楽観的に見積もると、当日に予定を超えて業務へ影響するおそれがあります。そのため、見積もりの根拠を示せるかも、選定の場で確かめておきます。
認証は、管理体制を客観的に裏付けるものです。移行品質や情報の取り扱いへの安心にもつながります。そのうえで、5つの観点を評価表に整理して各社を採点すれば、価格に偏らず総合的に判断できます。
更改では、安さよりも「止めずに移し切れるか」が本質的な選定基準です。
要件定義からつなぐ移行計画とテスト設計
アセスメント、要件定義、ベンダー選定の成果を、移行計画とテスト設計につなげます。準備工程は要件定義で終わらず、安全な移行方法まで設計して実を結びます。この計画が、止めない移行の可否を左右します。
段階移行を前提とした移行計画の組み立て
要件定義で決めた範囲と手法を、移行順序と時期の具体的なスケジュールに落とし込みます。段階移行では機能ごとに新旧を並行稼働させるため、切り替えの順番や停止時間、戻し方まで段階ごとに決めておく必要があります。
- 機能単位で新旧を並行稼働させる、ストラングラーパターンを前提にします。
- RFPのダウンタイム要件に合わせて、停止できる時間帯に切り替えを割り当てます。
- 各段階の完了基準と、問題発生時に旧システムへ戻すための切り戻し手順を定めます。
- 並行稼働中のデータ整合性を保つため、正とするシステムや機能ごとに同期方法を設計します。
ビッグバン方式は基幹システムを一度に切り替えるため、リスクが高くなります。一方で、段階移行なら、不具合が起きても業務停止の長期化を避けられます。
要件定義で整理したデータ移行要件を、運用レベルの同期設計につなげることが、止めない移行の土台です。同期設計がないと、移行後にデータの食い違いが発覚します。
移行リハーサルとデータ検証のテスト設計
本番移行を模したリハーサルでは、実データに近い条件で移行を試します。このとき、所要時間、エラー、変換後のデータの正確性を事前に確かめます。
本番で初めて移行する形を避け、事前に手順を検証しておけば、切り替え当日のトラブルを減らせます。データ検証では、要件定義で決めたマッピングに沿って照合します。
- 件数と内容：移行前後のデータを両面から突合します。
- 重要項目：金額や数量は合計値で照合します。
- 個別データ：サンプルを抽出して照合します。
欠損や変換ミスは、こうした照合で見逃さないようにします。移行の失敗は、更改で典型的に起きる失敗要因です。そのため、検証を厚くすることがリスク低減につながります。
加えて、業務シナリオに基づくテストも必要です。利用部門が実際の手順で操作し、業務が想定どおり完結するかを確かめます。
システムが技術的に動いても、現場の業務が滞りなく回るとは限りません。そこで、正常系に加えて、月末や決算など負荷が高い時期の処理も試します。
また、エラーなど例外的なケースも試します。想定外の処理でつまずくと、業務が止まり、現場の信頼を損ねます。
準備工程で把握した現行業務を踏まえてテストの網羅性を高めると、稼働後の安定運用を支えます。アセスメントからテスト設計までを一貫してつなげると、要件定義の精度がテストの精度にも影響します。
まとめ
システム更改では、アセスメントで現状を可視化し、AS-ISを棚卸ししてTO-BE像を定めます。RFPには現行構成図と性能要件を明記します。このほか、KPI、データ移行、ダウンタイムの要件も記します。
ベンダーを5つの観点で評価し、要件を移行計画とテスト設計につなげます。準備工程の質が更改の成否を分けるため、現状分析から着手して手戻りを防ぎます。
現行システムを可視化し、要件を明文化して、客観的にベンダーを選ぶ流れが、「止めない更改」の基盤になります。自社の更改でも、現状分析から始めて、要件を書面にまとめたうえでベンダー選定に臨みます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。