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