長年使い続けてきた基幹システムの刷新、いわゆるモダナイゼーションを検討する際、プロジェクトの成否を最初に左右するのが「アセスメント（現状分析）」と「要件定義」、そしてベンダーへ提示する「RFP（提案依頼書）」の質です。新規システムをゼロから作るのとは異なり、モダナイゼーションは既に動いている既存システムを刷新する取り組みであるため、現行の仕様を正確に把握できていなければ要件を固めることすらできません。経済産業省が指摘する「2025年の崖」では、レガシーシステムを放置した場合に年間最大12兆円もの経済損失が生じるリスクが警告されており、刷新は多くの企業にとって待ったなしの経営課題となっています。
一方で、刷新プロジェクトが頓挫する大きな原因は、現行システムの仕様書が失われていたり、長年の改修でブラックボックス化していたりして、要件定義が不十分なまま発注に進んでしまうことにあります。本記事では、モダナイゼーションのアセスメント・要件定義・RFP作成に絞り込み、資産の棚卸しの進め方、RFPに盛り込むべき項目、そして失敗しないベンダー選定の評価観点までを実務目線で整理します。刷新全体の流れや前提を体系的に押さえたい方は、あわせてモダナイゼーションの完全ガイドもご覧ください。本記事はその完全ガイドの内容を発注実務に落とし込み、RFPに何をどの粒度で書くべきかを掘り下げる位置づけです。
▼全体ガイドの記事
・モダナイゼーションの完全ガイド
モダナイゼーションにおけるアセスメント（現状分析・AS-IS可視化）の重要性
モダナイゼーションを成功させるうえで、最初の関門となるのがアセスメント、すなわち現状分析です。刷新の対象となる既存システムが、どのような構成で、どんな機能を持ち、他システムとどう連携しているのかを正確に把握できなければ、移行後の姿を設計することはできません。新規開発と決定的に異なるのは、すでに業務が回っている資産を扱う点にあります。現行の挙動を取りこぼせば、刷新後に「以前は動いていた処理が動かない」という事態を招きます。ここでは、刷新の出発点となる資産の棚卸しとAS-IS可視化の進め方を整理します。
仕様書欠如とブラックボックス化が刷新を阻む理由
刷新プロジェクトが失敗に陥る最大の原因の一つは、現行システムの仕様書が存在しない、あるいは実態と乖離していることです。長年にわたる度重なる改修の結果、当初の設計書が更新されないまま放置され、「実際にコードが何をしているのか」を誰も正確に説明できない状態に陥っているケースは少なくありません。これがいわゆるブラックボックス化です。担当者の退職や世代交代が重なると、暗黙知として引き継がれてきた仕様すら失われてしまいます。
この状態のまま要件定義に進むと、現行で実現されている処理の一部が刷新後の要件から抜け落ちます。その結果、移行後に業務が止まったり、データの不整合が発生したりといった重大なトラブルにつながります。日本情報システム・ユーザー協会（JUAS）の調査でも、約7割の企業が基幹システムのレガシー化を課題として挙げており、ブラックボックス化は決して特殊な問題ではありません。要件定義の前段で、現行システムを徹底的に可視化する工程が欠かせないのは、この抜け漏れを防ぐためです。
ブラックボックス化への対処は、刷新の難易度そのものを左右します。仕様が見えていれば、どの部分を残し、どの部分を作り替えるかを論理的に判断できます。逆に、見えないまま進めれば、移行方式の選定もリスク評価も推測に頼らざるを得ません。アセスメントの工程は、この「見えない部分を見える化する」ことに主眼を置く必要があります。
資産棚卸しとAS-IS可視化を支援するツール
現状分析の中核となるのが、アプリケーション資産の棚卸しです。具体的には、稼働しているプログラムの本数、画面や帳票の数、データベースのテーブル構成、外部システムとの連携インターフェースなどを網羅的に洗い出します。あわせて、どのプログラムがどのプログラムを呼び出しているかという依存関係や、複雑度の高い箇所を特定していきます。これらが整理されて初めて、刷新の対象範囲と工数の見積りが現実的なものになります。
こうした棚卸しを人手だけで進めるのは、規模が大きいシステムほど困難です。そこで活用されるのが、アプリケーション資産を機械的に解析して可視化するツールです。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を地図のように可視化し、どこにリスクが集中しているかを俯瞰できるようにする支援ツールです。こうしたツールを用いることで、目視では追い切れない巨大なソースコードの構造を客観的なデータとして把握できます。
ツールによる可視化は、刷新範囲の優先順位づけにも役立ちます。複雑度が高く依存関係が密集している箇所は、刷新のリスクとコストが集中するポイントです。可視化によってこうした「重い部分」を事前に特定できれば、段階移行の順序や移行方式を合理的に検討できます。アセスメントは単なる現状把握ではなく、その後の要件定義や移行計画の精度を高めるための土台となる工程だと捉えることが重要です。
棚卸し・要件定義フェーズの費用感
アセスメントから要件定義にかけての工程は、刷新の本体開発に入る前の準備段階にあたります。この段階だけを切り出して外部の専門会社に依頼する場合、業務の棚卸しと要件定義のみで200万〜500万円程度が一つの目安とされます。本体の刷新費用に比べれば一部分に見えるかもしれませんが、ここでの分析の質が後工程の見積り精度を決めるため、相応の投資が必要な工程です。
この費用を「もったいない」と考えて省略すると、後でより大きな代償を払うことになりがちです。現状分析が不十分なまま本体開発に進めば、途中で想定外の仕様が次々と判明し、追加要件や手戻りによってコストもスケジュールも膨らみます。アセスメントへの投資は、後工程のリスクを前倒しで潰すための保険と位置づけるのが適切です。RFPを出す前にこの段階を独立して進め、確かな現状理解のうえで発注に臨むことをお勧めします。
要件定義で固めるべき項目とRFPの書き方
アセスメントで現状が可視化できたら、次はその情報をもとに要件を固め、RFPに落とし込んでいきます。RFPは、ベンダー各社に同じ前提で提案を作ってもらうための共通の物差しです。記載が曖昧だと、各社の提案がバラバラの前提で作られ、横並びの比較ができなくなります。ここでは、モダナイゼーションのRFPに盛り込むべき具体的な項目と、その記載粒度について整理します。なお、本記事ではプロジェクト全体の進め方ではなく、あくまでRFPに何をどう書くかという発注実務に焦点を当てます。
RFPに盛り込むべき必須項目
モダナイゼーションのRFPでは、新規開発のRFPとは異なり「現状の正確な提示」が極めて重要になります。ベンダーは現行システムを知らない状態で提案を作るため、現状情報の解像度がそのまま提案の精度に直結するからです。RFPに盛り込むべき代表的な項目を整理すると、次のとおりです。
・現行システムの構成図（ハードウェア・ミドルウェア・連携先を含むシステム全体図）
・性能要件（応答時間、同時接続数、バッチ処理の許容時間など）
・移行後のKPI（刷新によって達成したい数値目標）
・対象範囲（刷新する機能と、現行のまま据え置く機能の線引き）
・移行方式（段階移行やストラングラーパターンなど想定する進め方）
・移行後の保守体制（運用フェーズで求めるサポート水準）
・スケジュール（マイルストーンと希望する完了時期）
・予算レンジ（投資可能な金額の幅）
これらをRFPに明記することで、ベンダー各社が同じ前提に立って提案を作成でき、見積りの比較可能性が担保されます。
とくに現行構成図と対象範囲は、モダナイゼーション特有の重要項目です。どこまでを刷新し、どこを現行のまま残すのかが曖昧だと、ベンダーごとにスコープの解釈が割れ、見積りが大きくぶれます。アセスメントで可視化した資産情報を、RFPの中で具体的な図表として提示することが、提案の質を引き上げる鍵となります。
移行方式とKPIを要件として明文化する
移行方式は、刷新のリスクとコストを大きく左右する要件です。一度にすべてを切り替えるビッグバン方式は、切替時の影響範囲が大きく、問題が起きたときの後戻りが難しいという特徴があります。これに対し、機能を分割して順次置き換えていく段階移行は、影響を局所化しながら進められるため、業務を止めにくいという利点があります。とくに、新旧システムを並行稼働させながら少しずつ機能を移していくストラングラーパターンは、リスクを抑えた刷新手法として広く想定されます。
RFPでは、自社が想定する移行方式を提示したうえで、その妥当性についてベンダーから提案を求めるとよいでしょう。発注側が方式を一方的に決め打ちするのではなく、現状分析の結果を踏まえて最適な方式を提案してもらう姿勢が、結果としてリスクの低い計画につながります。移行方式の記載粒度としては、「段階移行を希望し、各段階での並行稼働期間と切替の判断基準を提案に含めること」といった形で、ベンダーに検討してほしい論点まで踏み込んで書くことが望まれます。
あわせて重要なのが、移行後のKPIを要件として明文化することです。「処理時間を何割短縮したいのか」「運用にかかる人手をどの程度削減したいのか」といった数値目標を示すことで、刷新の成否を客観的に評価できるようになります。KPIが曖昧なまま発注すると、「動くものはできたが、期待した効果は得られなかった」という結果に陥りがちです。RFPの段階で達成したい数値を明示し、その達成方法を提案に含めてもらうことが、投資対効果を担保する要件定義の要点です。
失敗しないベンダー選定の評価観点
RFPを各社に提示し、提案が出そろったら、いよいよベンダーの選定です。モダナイゼーションは既存資産を扱う難度の高いプロジェクトであるため、価格や提案書の見栄えだけで選ぶのは危険です。重要なのは、刷新を確実に完遂できる実力を客観的な基準で見極めることです。ここでは、失敗しないベンダー選定のために押さえておきたい評価観点を整理します。あらかじめ評価項目を決めておくことで、各社を同じ物差しで比較できます。
ベンダー評価の5つのチェックポイント
モダナイゼーションのベンダーを評価する際は、次の5つのチェックポイントを軸にすると、客観的な判断がしやすくなります。それぞれの観点について、提案書や面談を通じて確認していきます。
(1) 同業界・同規模の刷新実績があるか。自社と近い業界や規模のシステムを刷新した経験があれば、固有の業務要件や落とし穴への理解が期待できます。
(2) 段階移行の設計力があるか。リスクを抑えた刷新には、機能をどう分割し、どの順序で移すかという設計力が不可欠です。
(3) ダウンタイム（切替時の停止時間）の見積り精度が高いか。停止時間を具体的に試算できるベンダーは、移行の段取りを現実的に描けている証拠です。
(4) 24時間365日の保守体制を備えているか。基幹システムは止まると業務に直結するため、運用フェーズのサポート水準が重要になります。
(5) ISO9001やISO27001などの品質・セキュリティ認証を取得しているか。第三者認証は、組織としての品質管理と情報セキュリティの裏づけになります。
これら5つの観点は、いずれも「提案の見栄え」では測れない実力を映し出すものです。とくに段階移行の設計力とダウンタイムの見積り精度は、モダナイゼーション特有の難所に直結するため、重点的に確認することをお勧めします。各観点に重みづけをして点数化すれば、複数社を定量的に比較できる選定シートが作れます。
客観基準で比較するための提案依頼の工夫
5つのチェックポイントを実際の選定で機能させるには、RFPの段階で各観点に関する情報をベンダーから引き出す問いを用意しておくことが有効です。たとえば実績については「直近3年以内の同規模刷新案件を、移行方式とともに提示してください」と求めれば、抽象的なアピールではなく具体的な事例で判断できます。ダウンタイムについても「切替時の想定停止時間と、その短縮のための工夫を提案に含めること」と指定すれば、見積りの精度を比較できます。
保守体制や認証についても同様に、「障害発生時の一次対応時間」「夜間休日の対応可否」「保有する認証の種類と取得年」などを定型の様式で回答してもらうと、各社を横並びで評価しやすくなります。回答の形式をそろえることが、客観的な比較の前提になります。提案書の自由記述だけに頼ると、各社が得意な部分だけをアピールし、肝心の弱点が見えにくくなってしまいます。
最終的な選定では、価格の安さだけで判断しないことが何より重要です。モダナイゼーションは、安価な提案に飛びついた結果、移行に失敗してかえって高くつくケースが後を絶ちません。5つのチェックポイントで一定の水準を満たしたうえで、総保有コストや刷新後の運用負荷まで含めて総合的に判断する姿勢が、失敗しないベンダー選定につながります。客観基準にもとづく評価が、刷新プロジェクトの第一歩を確かなものにします。
まとめ
本記事では、モダナイゼーションのアセスメント・要件定義・RFP作成に絞り込み、刷新を発注実務に落とし込む際の要点を整理してきました。まず、刷新失敗の大きな原因が現行システムの仕様書欠如やブラックボックス化にあることを踏まえ、資産の棚卸しとAS-IS可視化を徹底することの重要性を確認しました。富士通の「ソフトウェア地図」のような可視化ツールを活用し、棚卸し・要件定義フェーズに200万〜500万円程度の投資を惜しまないことが、後工程のリスクを前倒しで潰す鍵になります。
続いて、要件定義では現行構成図・性能要件・移行後のKPI・対象範囲・移行方式といった項目をRFPに具体的な粒度で書き込み、ベンダー各社が同じ前提で提案できるようにすることが重要だと述べました。さらにベンダー選定では、同業界・同規模の実績、段階移行の設計力、ダウンタイムの見積り精度、24時間365日の保守体制、ISO9001やISO27001などの認証という5つのチェックポイントを軸に、客観基準で各社を比較する姿勢が失敗を防ぎます。
2025年の崖が警告するように、レガシーシステムの刷新はもはや先送りできない経営課題です。だからこそ、焦って発注に走るのではなく、現状分析という土台を固めたうえで、質の高いRFPと客観的なベンダー評価をもって臨むことが、刷新成功への確実な近道となります。アセスメントから要件定義、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を創業。