アプリケーションのモダナイゼーションを成功させられるかどうかは、開発に着手する前の「アセスメント・要件定義・RFP（提案依頼書）」の段階でほぼ決まると言っても過言ではありません。実際、刷新プロジェクトが炎上する最大の原因は、現行システムの仕様書欠如やブラックボックス化による「要件定義の不十分さ」だと指摘されています。古いシステムほど全体像を把握している人がおらず、いきなりベンダーに見積もりを依頼しても、精度の高い提案は返ってこないのです。
本記事では、アプリケーションのモダナイゼーションにおける「現状分析（アセスメント）→要件定義→RFP作成→ベンダー選定」という上流工程の進め方を、実務に沿って具体的に解説します。AS-IS可視化のためのツール活用、RFPに必ず盛り込むべき項目、失敗しないベンダー評価の客観的基準まで踏み込みます。刷新全体の流れを体系的に押さえたい方は、あわせてアプリケーションのモダナイゼーションの完全ガイドもご覧ください。発注前の準備を万全にし、刷新を成功へ導くための実践情報をお届けします。
▼全体ガイドの記事
・アプリケーションのモダナイゼーションの完全ガイド
アセスメント：現状分析（AS-IS可視化）の進め方
モダナイゼーションの上流工程は、必ず「アセスメント（現状分析）」から始まります。アセスメントとは、現行システムが「いま、どうなっているか」というAS-IS（現状）を徹底的に可視化する作業です。ここを飛ばして「あるべき姿（TO-BE）」だけを描いても、現状とのギャップが見えず、現実的な移行計画は立てられません。
資産棚卸しとブラックボックスの可視化
アセスメントの第一歩は、アプリケーション資産の棚卸しです。どのようなプログラムが、どれだけの規模で存在し、どの業務とどう連携しているのかを洗い出します。レガシーシステムでは、長年の改修でコードが複雑に絡み合い、仕様書も更新されていないことが多いため、この作業は想像以上に骨が折れます。担当者の記憶や口頭の知識に頼る属人的な状態（ブラックボックス化）を、客観的な資料へと変換していくことが目的です。
近年は、こうした可視化を支援するツールも登場しています。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や、プログラム間の依存関係を地図のように可視化するツールです（出典：富士通）。どの部分が特に複雑で、どこを変更すると影響が広範囲に及ぶのかを把握できるため、刷新の優先順位付けや手法選定の判断材料になります。こうしたツールを活用することで、人手だけでは見えなかった技術的負債の所在を客観的に特定できます。
資産棚卸しでは、各アプリケーションを「ビジネス上の重要度」と「技術的負債の大きさ」という2つの軸で評価し、マッピングしていく作業が有効です。重要度が高く負債も大きいシステムは最優先で刷新すべき対象となり、重要度が低く負債も小さいものは現状維持や廃止の候補になります。この評価を通じて、限られた予算と期間をどこに集中投下すべきかが明確になります。すべてを一律に近代化するのではなく、効果の大きい領域から手を付けるという優先順位付けが、アセスメントの実務的なゴールです。
アセスメント工程の費用・期間の目安
アセスメントと要件定義・業務棚卸しは、本格的な開発に着手する前の独立した工程として発注することが可能です。費用の目安は、要件定義・業務棚卸しのみで200万〜500万円程度です。一見すると安くない金額ですが、この工程を省略して見切り発車したために、後工程で数千万円規模の手戻りが発生するケースを考えれば、極めて費用対効果の高い投資といえます。
進め方としては、まずアセスメント工程のみを契約し、現状分析とTO-BEの方向性を固めたうえで、本開発のRFPを作成して別途ベンダーを選定する「2段階発注」が推奨されます。最初から大規模な開発契約を結んでしまうと、現状が見えていないまま見積もりが甘くなり、追加費用の温床になります。まず現状を見える化し、確かな根拠に基づいて本開発の要件を固める。この順序こそが、刷新失敗を避ける王道です。
アセスメントの成果物としては、現行システムの構成図、機能一覧、データ項目の棚卸し表、システム間連携の関係図、そして技術的負債の所在を示す課題リストが標準的です。これらは後続の要件定義やRFPの土台となるため、第三者が読んでも理解できる粒度でドキュメント化しておくことが重要です。属人的な口頭知識を、引き継ぎ可能な客観的資料へと変換することそのものが、アセスメント工程の最大の価値だといえます。
要件定義：TO-BEと移行要件の固め方
アセスメントで現状（AS-IS）が可視化できたら、次は「あるべき姿（TO-BE）」を定義し、現状からそこへ至る移行要件を固めます。モダナイゼーションの要件定義は、ゼロから新規開発する場合と異なり、「既存の何を残し、何を変え、何を捨てるか」という観点が中心になる点が特徴です。
残す機能・変える機能の仕分け
要件定義の核心は、現行機能の「仕分け」です。レガシーシステムには、現在も業務に不可欠な機能と、過去の経緯で残っているだけの形骸化した機能が混在しています。すべてをそのまま新システムへ移植しようとすると、不要な複雑さを引き継いでしまい、刷新の意味が薄れます。アセスメント結果をもとに、各機能を「必須で維持」「改善して移行」「廃止」の3つに仕分けることが重要です。
この仕分けには、業務部門（ユーザー部門）の参画が欠かせません。情報システム部門だけで判断すると、現場で本当に使われている機能を見誤るリスクがあるためです。逆に、ユーザー部門が「念のため全部残してほしい」と要求しすぎると、刷新効果が削がれます。両者が現状の利用実態データを共有しながら、業務に与える影響を基準に冷静に仕分けることが、スリムで効果的な新システムを生み出す鍵となります。
仕分けの精度を高めるには、機能の利用ログやアクセス頻度といった客観データを活用することが有効です。「使っているはず」という思い込みではなく、実際にどの機能がどれだけ使われているかを数値で確認すると、形骸化した機能や、特定の一部ユーザーしか使っていない機能が浮かび上がります。データに基づいて廃止候補を提示すれば、現場の合意も得やすくなります。要件定義は関係者の主観がぶつかりやすい工程だからこそ、客観的な事実を共通の土台に置くことが、円滑な合意形成と質の高い要件につながります。
非機能要件と移行KPIの定義
モダナイゼーションの要件定義では、機能要件以上に「非機能要件」と「移行後のKPI」を明確にすることが重要です。非機能要件とは、性能（処理速度・同時アクセス数）、可用性（稼働率の目標）、セキュリティ、拡張性といった、機能の裏側で品質を支える要件です。「夜間バッチを現状の半分の時間で完了させる」「ピーク時に同時アクセスが何件あっても応答する」といった具体的な目標値を定めます。
さらに、刷新によって何をどれだけ改善するのかを示す移行KPI（重要業績評価指標）を設定します。「保守費を3年で50%削減する」「リリースリードタイムを2週間から3日へ短縮する」といったKPIは、後のベンダー提案を評価する基準になると同時に、稟議を通すための投資対効果の根拠にもなります。曖昧な「使いやすくしたい」ではなく、測定可能な数値目標へ落とし込むことが、要件定義の質を決定づけます。
非機能要件の中でも、モダナイゼーションで特に注意すべきが「移行時の制約条件」です。たとえば、業務を止められる時間（許容ダウンタイム）が何時間あるのか、繁忙期を避けてどの時期に切り替えるべきか、新旧並行稼働の期間をどれだけ確保できるか、といった制約は、システムの作り方そのものを左右します。許容ダウンタイムが極めて短い業務であれば、無停止で切り替えられる方式を前提に設計する必要があり、その分だけ難易度と費用が上がります。こうした制約を要件定義で明文化しておかないと、開発が終盤に差しかかってから「この方式では止められる時間内に切り替えられない」といった致命的な問題が発覚しかねません。
RFP作成：盛り込むべき項目とベンダー評価基準
要件が固まったら、それをベンダーへ提示するRFP（提案依頼書）に落とし込みます。RFPは、複数のベンダーから同じ土俵で提案・見積もりを取り、客観的に比較するための文書です。RFPの精度が低いと、各社バラバラの前提で提案してくるため比較ができず、結局「印象」でベンダーを選ぶことになりかねません。盛り込むべき項目と評価基準を整理します。
RFPに必ず含めるべき項目
モダナイゼーションのRFPには、一般的なシステム開発のRFP項目に加え、刷新固有の情報を盛り込む必要があります。最低限含めるべきは次の項目です。
・プロジェクトの背景と目的（なぜ刷新するのか、2025年の崖などの課題認識）
・現行システムの構成図（アセスメントで可視化したAS-IS）
・残す／変える／捨てる機能の仕分け結果
・非機能要件（性能・可用性・セキュリティの目標値）
・移行後に達成したいKPI（保守費削減率・リードタイム短縮など）
とりわけモダナイゼーション特有の重要項目が「データ移行の方針」と「移行方式の希望」です。レガシーシステムからのデータ移行は最大の難所であり、どれだけのデータをどう移すのかを明示しなければ、ベンダーは見積もれません。また、ビッグバン移行ではなくストラングラーパターンによる段階移行を希望する旨をRFPに明記しておくことで、各社の移行設計力を提案段階で見極められます。現行構成図・性能要件・移行後KPIをそろえて提示することが、質の高い提案を引き出す前提条件です。
ベンダー評価の5つのチェックポイント
RFPへの提案を受けたら、客観的な基準でベンダーを評価します。モダナイゼーションのベンダー選定では、次の5つのチェックポイントが特に有効です。
1. 同業界・同規模のモダナイゼーション実績があるか
2. 段階移行（ストラングラーパターン）を設計できる力があるか
3. 移行時のダウンタイム（業務停止時間）を具体的に見積もれているか
4. 24時間365日の保守・運用体制を提供できるか
5. ISO9001（品質）・ISO27001（情報セキュリティ）等の認証を保有しているか
これらは、いずれも提案書や面談で客観的に確認できる項目です。特に「ダウンタイムの見積もり」は重要で、ここを曖昧にしか答えられないベンダーは、移行リスクへの認識が甘い可能性があります。安さだけで選ぶと、後の障害や追加費用で結局高くつきます。価格・実績・移行設計力・保守体制・品質認証を総合的に点数化し、複数社を横並びで比較することで、刷新を任せられる信頼性の高いパートナーを見極められます。自社にRFP作成やベンダー評価の経験が乏しい場合は、上流工程から伴走できる専門パートナーの支援を受けるのも有効な選択です。
評価の実務では、各チェックポイントに重み付けをして点数化する「評価マトリクス」を用意すると、選定の客観性と説明責任を両立できます。たとえば移行設計力やダウンタイム見積もりの精度には高い配点を置き、価格は一定以上の品質を満たした候補の中での比較材料にとどめる、といった設計です。さらに、提案内容だけでなく、提案にあたって各社がどれだけ自社の現状を深く理解しようとしたか、質疑のやり取りでどれだけ的確な指摘をしてきたか、といった姿勢も重要な判断材料になります。RFPへの提案は、ベンダーの実力と誠実さを見極める絶好の機会でもあるのです。
まとめ
本記事では、アプリケーションのモダナイゼーションにおける上流工程「アセスメント→要件定義→RFP→ベンダー選定」の進め方を解説しました。アセスメントでは、資産棚卸しとブラックボックスの可視化を行い、富士通の「ソフトウェア地図」のようなツールも活用しながらAS-ISを把握します（費用目安は要件定義・業務棚卸しのみで200万〜500万円）。要件定義では、残す・変える・捨てる機能の仕分けと、非機能要件・移行KPIの数値化が核心となります。
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を創業。