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