システムのモダナイゼーションは、現状分析、要件定義とRFP作成、ベンダー選定の順に進めると、刷新全体のリスクを抑えやすくなります。仕様書の紛失やブラックボックス化で現状把握や要件定義が不十分になると、刷新は失敗しやすくなります。
全体像はシステムのモダナイゼーションの完全ガイドもご覧ください。
▼全体ガイドの記事
・システムのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント（現状分析・AS-IS可視化）の進め方
モダナイゼーションの最初の工程は、刷新対象の現行システムを調べるアセスメントです。経済産業省のDXレポートも「2025年の崖」でレガシー資産の複雑化を指摘しており、まずは現状を把握することが出発点になります。
この工程では、現行システムが何を、どのように、どこまで担っているかを棚卸しし、AS-IS（現状の姿）を可視化します。要件定義・業務棚卸しのみの費用は、200万〜500万円が目安です。刷新全体からみれば小さな投資ですが、省くと後工程で何倍ものコストとして跳ね返るおそれがあります。
資産棚卸しと複雑度の可視化
アセスメントでは、アプリケーション資産と業務上の利用実態を確認します。棚卸しでは、各プログラムの利用業務と頻度、連携先を洗い出します。
- 依存関係の可視化：システム間のつながりを押さえる
- 利用状況の把握：現場へのヒアリングと利用ログ分析の組み合わせ
レガシー環境では棚卸しが難航しがちなので、支援ツールを使うのも一つの手です。たとえば富士通の「ソフトウェア地図」は、資産の複雑度や依存関係を可視化します。
人手では把握しきれない巨大なコード資産も、このツールを使えば構造を俯瞰しやすくなります。そのうえで、技術面の解析に加えて、現場への聞き取りで業務上の利用実態も確かめます。
プログラムが残っていても、ほとんど使われていない機能があります。一方で、一部の担当者しか知らない重要な処理が隠れている場合もあります。
棚卸しの結果は、廃止（リタイア）の判断にも直結します。使われていない機能や重複する処理を刷新の対象から外せば、そのぶん全体のスコープとコストを圧縮できます。
この工程では、「何を刷新し、何を捨て、何を残すか」というポートフォリオ判断の材料を集めます。技術と業務の両面から現状を捉えておくと、刷新後に必要な機能が抜け落ちて業務が回らなくなる事態を防げます。
AS-ISからTO-BEへのギャップ整理
現状を可視化したら、刷新後のTO-BE（あるべき姿）を描き、AS-ISとのギャップを整理します。現行業務をそのまま移すと、形骸化したルールや無駄な処理まで新システムに残ってしまいます。
- 改善の方向を定める：目指す業務の形を基準にした刷新内容
- 課題を分類する：業務上の課題とシステム上の課題の切り分け
- 優先順位を決める：事業インパクトの大きい領域からの着手順
イオングループは、RPA導入前に業務プロセス分析を徹底し、月700時間もの業務削減を実現しました。業務を現状どおりに再現せず、あるべき姿から考える姿勢が、効果を高めます。
たとえば「月次決算に時間がかかる」という業務課題の背後には、複数のシステムにデータが分散し、手作業で集計している問題が潜んでいることがあります。
業務課題とシステム課題を結びつけて考えると、刷新で何をどう改善するかが見えてきます。この整理は、経営層への説明や予算確保の根拠にもなります。
ギャップを整理すると、刷新の目的・スコープ・優先順位が明確になります。全課題を一度に解決しようとせず、事業への影響が大きい領域から段階的に進める方針を固めます。
アセスメントの成果は、次の要件定義とRFPの土台になります。現状を記録するだけでなく、刷新の目的と改善内容を組み立てる工程だからです。
要件定義とRFPに盛り込むべき項目
アセスメントで現状とあるべき姿をつかんだら、ベンダーに伝えるRFP（提案依頼書）を作成します。RFPの質が、ベンダー提案の質を左右します。
曖昧なRFPには、曖昧で高めの見積もりが返ってくることがあります。反対に、精緻なRFPであれば、比較しやすく精度の高い提案を集めやすくなります。
モダナイゼーションのRFPに必須となる項目は、次のとおりです。
RFPに必須の項目
RFPでは、現状・目標・移行の前提を明示します。次の項目をそろえておくと、提案の比較と、刷新後の効果検証に役立ちます。
- 現行システム：構成図に、システム間の連携とデータの流れを含める
- 目的と範囲：刷新の目的、対象システム、そして対象外の範囲
- 性能要件・KPI：処理時間、同時接続数、バッチ完了時刻に加え、保守費削減率や処理時間短縮などの移行後の目標
- 移行方針：段階移行か一括移行か、希望する方針
- データの前提：移行範囲とデータ品質の前提
移行後のKPIは特に見落とされがちです。たとえば「夜間バッチを8時間から2時間以内に」「保守費を年間で半減」のように定量的な目標を書いておけば、提案を客観的に比べられます。
定量目標は、刷新後に効果を検証する基準にもなります。
現行の構成図がないと、ベンダーは現状把握の費用を見積もりに含めざるを得ません。その場合、費用が膨らみ、提案の比較も難しくなります。
希望する移行方式も記載しておくと、ベンダーは同じ前提で提案を組み立てられます。たとえば「事業を止められないため、機能単位で段階的に移行したい」と前提を示せば、ベンダーは制約を踏まえた計画を提案できます。
反対に、方針を伝えないと各社が異なる前提で見積もるため、金額だけでは比べられません。自社の制約と優先順位を率直に共有するほど、提案の精度が高まります。
非機能要件と移行要件の明確化
既存業務を止められないモダナイゼーションでは、非機能要件と移行要件を具体化しておく必要があります。暗黙の前提を残したままだと、後の認識のずれやトラブルにつながります。
- 非機能要件：可用性、バックアップ・リカバリ、セキュリティ、性能の明文化
- データ移行：範囲、方式、許容できるダウンタイムの決定
- 運用保守：障害対応、機能改善、年間の保守費用の確認
非機能要件は、現行と同等以上の水準を目指して記載します。「現状と同じように動くはず」という前提に頼らず、必要な水準を共有します。
ERPなどのパッケージに置き換える場合、現行データを新システムの項目に対応づける「データマッピング」が複雑になりやすく、曖昧なままだと移行時に大きく遅延するおそれがあります。そこで、RFPで移行の難易度を共有し、ベンダーに移行計画とリハーサルの方針を求めると、リスクの低減につながります。
刷新後も運用は続きます。初期費用が安くても運用費が高いケースを見抜くため、保守・運用の体制と費用についても、ベンダーに回答してもらいます。
RFPは、要件を伝えるための文書であると同時に、提案を同じ条件で比べ、刷新の全期間にわたるコストとリスクを見通すための設計図でもあります。
失敗しないベンダー選定の評価基準
RFPへの提案は、客観的な基準で評価します。価格だけで選ぶと、移行リスクの見積もりが甘い提案や、後から追加費用が膨らむ提案を選ぶおそれがあります。そのため発注側は、実績や移行設計力などの複数の観点から、ベンダーを見極めます。
ベンダー評価の5つのチェックポイント
ベンダー評価は、次の5つのチェックポイントを軸にすると客観性を保てます。提案書の見栄えではなく、プロジェクトを最後までやり切れる力を見ます。
- 同業界・同規模の実績：該当する刷新経験の有無と中身
- 段階移行の設計力：新旧並行稼働を含む設計の中身
- 停止時間の見積もり：切り替え時のダウンタイムの想定
- 保守・運用体制：24時間365日の対応体制
- 品質・セキュリティ認証：ISO9001やISO27001などの保有状況
段階移行の設計力とダウンタイムの見積精度は、移行の失敗による業務停止を避けるうえで特に重要です。
提案ヒアリングでは、過去案件の移行時に起きたトラブルと対処方法を具体的に尋ねます。その回答から、ベンダーの実力を確かめられます。
ベンダー丸投げを避ける発注側の体制
ベンダー選定後に発注側が任せきりにすると、刷新は成功しにくくなります。要件の妥当性確認や移行計画のリスク検討も、発注側が担います。
- 要件を確認する：要件定義が妥当かどうかの判断
- 移行を検討する：計画のリスクをベンダーと詰めること
- 現場を巻き込む：業務部門による受け入れテストの主導
SAP導入では、ユーザー部門の参画不足が失敗要因として知られています。現場の関与が薄いままだと、刷新が頓挫するおそれがあります。
社内で主導できない場合は、発注側に立つ中立的なコンサルティングパートナーが有効です。そうしたパートナーが、アセスメントから移行までを一貫して支援する体制であれば、上流の精度と発注側の主体性を保ちやすくなります。
現場部門は、要件の妥当性確認や受け入れテストで評価者になります。実際に業務で使う現場だからこそ、要件やテスト結果を判断できます。
情報システム部門だけで進め、現場が完成間際になって初めて触れると、手戻りや不満につながります。そのため、アセスメントの段階から現場のキーパーソンを巻き込みます。
要件・RFP・テストの各段階で現場の意見を反映する仕組みが、刷新後も使われるシステムへの着地を支える鍵です。また、上流工程への投資は、刷新全体のリスクを下げる打ち手でもあります。
まとめ
システムのモダナイゼーションでは、アセスメント、要件定義とRFP、ベンダー選定の順に進めることで、刷新全体のリスクを抑えられます。
出発点のアセスメントでは、資産棚卸しと複雑度の可視化を通じて、刷新するもの、捨てるもの、残すものを見極めます。要件定義・業務棚卸しのみの費用は、200万〜500万円が目安です。
RFPには、現行構成図、性能要件、移行後のKPI、移行方式、データ移行範囲などを記載します。定量KPIと非機能・移行要件を明確にすると、提案の比較と効果検証に役立ちます。
発注側は、同業界・同規模の実績、段階移行の設計力、ダウンタイムの見積精度でベンダーを評価します。加えて、24時間365日の保守体制や、ISO9001やISO27001などの認証も見ます。
優れたベンダーを選んでも、発注側が任せきりでは成功しません。社内に主導体制を置くか、発注側に立って伴走するパートナーを用意します。
上流工程の精度が、刷新全体のリスクを左右します。そのため、経験豊富なパートナーと組み、アセスメントから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を創業。