刷新は、現状把握、要件定義、RFP、ベンダー評価の順に進めると、手戻りを抑えられます。多くの炎上は、技術力の不足より、現状把握や要件、選定基準の曖昧さが原因です。
現状分析、RFPの項目、評価基準の順に見ていきます。全体像はシステム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
刷新の成否を決めるアセスメント（現状分析）の重要性
システム刷新は、まず現行システムを正確に理解することから始まります。新しくしたい機能だけを並べると、既存業務との不整合が後から見つかり、追加開発で予算が膨らみます。
仕様書の欠如やブラックボックス化による要件定義の不足は、刷新失敗の大きな原因として繰り返し指摘されています。現状分析（AS-IS）は刷新の出発点で、アセスメントだけで200万〜500万円規模の費用がかかることもあります。一方で、現状分析への投資は後工程の手戻りを大幅に減らします。
とくに全社規模の刷新では、現状把握の対象を情報システム部門だけにとどめず、各業務部門の利用システムや独自運用も調べます。横断的に把握しなければ、刷新後に現場の実態とずれるおそれがあります。また、アセスメントは技術調査であると同時に、全社の業務実態を可視化する経営の取り組みです。
AS-IS可視化と資産棚卸しのやり方
現行システムの資産棚卸しでは、機能やデータに加えて、連携関係や支えている業務も洗い出します。複雑化したシステムでは労力がかかりますが、この作業を怠ると要件定義が机上の空論になります。
棚卸しでは、現行システムを4つの面から確認し、全体像をつかみます。
- 機能：現行システムに存在する機能
- データ：データの保持場所
- 連携：システム同士の連携関係
- 業務：各システムが支えている全社業務
可視化を支えるツールも登場しています。たとえば、富士通の「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化します。
このツールは、ブラックボックス化した部分や改修が集中する箇所も把握しやすくします。そのため、属人的な勘に頼らず、データを基に刷新の難所を特定できます。
棚卸しの結果は、現行構成図やデータ一覧、機能と業務の対応表として文書化します。これらは、後のRFPに添付する重要な資料です。加えて、アセスメントは、ベンダーに正確な見積もりを出してもらうための材料を揃える工程でもあります。
AS-ISとTO-BEのギャップの整理
現状（AS-IS）を可視化したあとは、刷新後のあるべき姿（TO-BE）を描き、その差分を整理します。このギャップが、刷新で実現すべき要件の中身です。
ギャップ分析では、要件と目標を具体化するために、次の取り組みを行います。
- 理想像を描く：何を残し、何を変え、何を新たに作るかを整理する
- 業務部門を交える：現場の不満と刷新後の希望を出し合う
- KPIを定める：刷新後に達成したい成果を数値にする
情報システム部門だけで要件を固めると、現場の実態とずれやすくなります。そのため、要件定義は全社で取り組む工程です。
KPIの例には、夜間バッチ処理時間の短縮や、二重入力をなくして月◯時間の作業を削減する目標があります。たとえば、ある製造業では、刷新により夜間バッチを8時間から90分へ短縮しました。さらに、同じ事例では保守費も年2,400万円から850万円へ削減しています。
RFPに盛り込むべき項目と書き方
アセスメントと要件定義が固まったら、内容をベンダーに示すRFP（提案依頼書）にまとめます。RFPの質は、提案と見積もりの質を直接左右します。
曖昧なRFPには曖昧な提案しか集まらず、「言った・言わない」のトラブルにもつながります。そこで、刷新のRFPに必ず盛り込みたい項目を押さえておきます。
現行構成図・性能要件・移行後KPIなどの必須項目
RFPには、見積もりと提案の前提となる項目を盛り込みます。
- 現行構成図：移行難易度を見積もる土台
- 性能要件：刷新後に満たす定量基準
- 移行後KPI：業務効率やコスト削減の目標
- 移行方式：一括か段階的か、許容する停止時間
現行構成図にはアセスメントの成果物を活用できます。図がないと、ベンダーは想定で見積もることになるため、後から追加費用が発生しやすくなります。
性能要件には、ピーク時の処理件数や応答時間、同時接続数などを記します。「現状と同等以上」では検証できないため、できるだけ数値で示します。移行後KPIも数値で記載すれば、ベンダーの提案を客観的に比べられます。
移行方式では、一度に全システムを切り替えるか、段階的に置き換えるかを示します。また、ダウンタイムの許容度も伝えます。とくに、事業を止められない業務では、新旧を並行稼働させながら段階的に移行する方式を求めると、提案の方向性が揃います。
データ移行・現新比較の要件
データ移行はトラブルが起きやすいため、RFPには対象範囲や方法、移行後の検証要件を記載します。検証では、現行と新システムの結果が一致するかを確認します。
移行要件では、次の観点を明らかにします。
- 対象と方法：移行するデータの範囲と移行方法
- 責任分担：自社とベンダーの担当範囲
- 検証方法：比較する項目と合格基準
データ移行を軽視したRFPは、刷新の終盤で深刻な手戻りを招きます。とくにパッケージ導入では、現行データの項目を新システムに対応づけるデータマッピングが複雑になることがあります。
対応関係を整理しないと、移行作業が泥沼化します。そのため、自社の業務知識を持つ担当者が移行に関与する体制も、RFPに明記します。
検証では、件数だけでなく、金額や日付の整合性、過去データの欠落も確認します。なかでも会計・在庫などの数値データは、小さなずれでも業務の混乱に直結します。
現行と新システムの突合は複数の観点で行い、その合格基準をRFPに示します。基準があれば、ベンダーは十分な工数を見込んで提案できます。
非機能要件とサポート範囲の記載
RFPでは機能要件に注目が集まりがちですが、非機能要件も同じくらい重要です。運用を左右する保守範囲も、あわせて記載します。
- 可用性：システムが止まらない度合い
- 安全性：セキュリティ、バックアップ、データ保全
- 拡張性：将来の拡張に関する要件
- 保守体制：障害対応や継続的な改修支援の範囲
非機能要件が曖昧だと、刷新後に想定した安定性が得られず、不満につながります。そのため、保守の窓口や対応時間も明確にします。
保守・サポートの条件は、長期的な運用コストに直結します。たとえば、全社の基幹システムでは、業務特性に照らして24時間365日の保守が必要かを判断します。
導入後の運用まで見据えた要件を示すことが、刷新したシステムを長く使い続ける前提になります。
失敗しないベンダー評価の客観的基準
提案が集まったら、次の観点からベンダーを客観的に評価します。価格だけで選ぶと、移行の難所を理解していないベンダーに発注してしまい、刷新が炎上するリスクが高まります。
ベンダー評価の5つのチェックポイント
評価の基準を5つに絞って比べると、判断のブレを抑えられます。
- 同業界・同規模の実績：刷新経験の有無
- 段階移行の設計力：段階的な移行を設計できるか
- 停止時間の見積もり：ダウンタイムの想定が現実的か
- 保守体制：24時間365日の保守に対応できるか
- 品質・安全認証：ISO9001やISO27001などの取得有無
同じ業界・規模の経験があるベンダーは、業務特有の落とし穴を把握しており、見積もり精度も高い傾向があります。また、全社を一度に切り替えず段階的に置き換えられるかは、刷新リスクを大きく左右する実力差です。
停止時間の見積もり、保守体制、品質・安全認証は、刷新後の安定運用を担保する観点です。停止時間の見積もりが楽観的すぎる場合、ベンダーが移行時のトラブルを軽く見ている可能性があります。さらに、保守体制や認証の有無は、刷新したシステムを長期的に安心して使い続けられるかを判断する材料にもなります。
5項目を評価表にして点数化すると、複数のベンダーを横並びで比較しやすくなります。
自社が主体となる体制づくり
ベンダー選定では、自社側の体制づくりも欠かせません。優れたベンダーを選んでも、要件や判断を丸投げすると、現場とずれた刷新になりやすくなります。
自社が判断を担うため、準備段階で次の役割を整えておきます。
- 刷新責任者：社内の刷新を主導する
- 業務部門の担当者：各部門の要件をまとめる
アセスメントから要件定義、RFP作成、ベンダー評価まで、自社が主体的に進めます。そうすることで、認識のずれを早く見つけ、刷新後も自社で改善を主導できます。
自社の体制づくりは、刷新全体の質を底上げします。一方で、丸投げを続けると、刷新後の保守も特定のベンダーに依存し続けることになります。
まとめ
ここまで、システム刷新のアセスメント、要件定義、RFPについて、準備段階の進め方を見てきました。準備は資産棚卸しとAS-IS可視化から始め、TO-BEとのギャップをもとに要件とKPIを定めます。
次に、構成図や性能要件、移行要件を含むRFPを作り、ベンダーの提案を求めます。そのうえで、同業界の実績や段階移行の設計力などを含む5つの基準で、ベンダーを客観的に評価します。自社が主体となる準備も欠かせません。
刷新の失敗の多くは、こうした準備段階の甘さに起因します。アセスメントには200万〜500万円かかることもあります。一方で、準備への投資は後工程の手戻りを防ぎ、刷新全体のコストを抑えます。
富士通の「ソフトウェア地図」のような可視化ツールも活用できます。自社の刷新を検討する際は、アセスメントと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を創業。