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