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