レガシーシステムリニューアルのアセスメント/要件定義/RFPについて

レガシーシステムのリニューアルを検討している企業にとって、最初の壁は「何から手を付ければよいか分からない」という状況です。現行システムの課題は漠然と感じていても、それを整理してベンダーに正確に伝え、適切な提案を引き出すためのプロセスが確立していないケースが多く見られます。アセスメント・要件定義・RFPという三つのステップを正しく踏まなければ、発注後に大規模な手戻りが発生し、コストと時間を無駄にするリスクが高まります。

本記事では、レガシーシステムのリニューアルにおける「アセスメント（現状分析）→要件定義→RFP（提案依頼書）作成」という一連の流れを、実務レベルで解説します。プロジェクト全体の進め方や体制についてはレガシーシステムリニューアルの完全ガイドをあわせてご参照ください。本記事では特にRFPの必須項目・ベンダー評価観点・要件定義での仕分け手法に焦点を当てて掘り下げます。

▼全体ガイドの記事
・レガシーシステムリニューアルの完全ガイド

アセスメント：現行UI・機能・業務フローの棚卸しと課題抽出

アセスメントとは、リニューアルの起点となる現状分析フェーズです。「なぜリニューアルが必要なのか」を客観的なデータと現場の声から明確にし、要件定義以降の作業の根拠を作る作業です。ここを曖昧にしたままプロジェクトを進めると、リニューアル後に「思っていたものと違う」という事態が起きやすくなります。現行システムのUI・操作性・機能・業務フロー・外部連携の全域を棚卸しし、課題を定量・定性の両面で整理することが求められます。

現行システムのUI棚卸しでは、まず全画面のスクリーンショットと画面遷移図を作成します。ユーザーが実際にどの順番で操作しているかを「現状フロー」として文書化し、各ステップで発生している手戻り・エラー・迂回操作を記録します。「ここのボタンが分かりにくい」「この入力項目が何を指すのか毎回迷う」といった現場の声は、リニューアル要件の根拠になるため、ヒアリングシートを使って体系的に収集することが重要です。

機能の棚卸しでは、現行システムに実装されている全機能をリスト化し、利用頻度・利用部署・業務上の重要度を記録します。「使われていない機能」「重複している機能」「外部ツールで代替されてしまっている機能」を洗い出すことで、リニューアル時の機能スコープを合理的に絞り込めます。機能一覧はExcelやスプレッドシートで管理し、後のMust/Want仕分けと連動できる形にしておくと作業効率が上がります。

業務フローの課題抽出では、定量データと定性情報を組み合わせるアプローチが有効です。定量面では、システムのログデータやサポートチケットの傾向から「どの機能でエラーが多いか」「どの業務で時間がかかっているか」を数値で把握します。定性面では、業務担当者・管理者・ITリテラシーが低いユーザーといった複数の立場からヒアリングを実施し、数値に表れない使いにくさや業務上のリスクを収集します。

課題はカテゴリ別に整理しておくと要件定義フェーズへの引き継ぎがスムーズになります。具体的には「UI/UX課題（操作性・視認性）」「機能課題（不足機能・過剰機能）」「業務フロー課題（二重入力・手作業）」「連携課題（外部システムとのデータ連携不備）」「セキュリティ/ガバナンス課題」といった分類が実務では使いやすいカテゴリです。大企業のリニューアル案件では、Webガバナンスやセキュリティ要件が複雑になるため、情報システム部門・法務・コンプライアンス部門も早期にアセスメントに参加させることが重要です。

要件定義：リニューアル後のあるべき姿とMust/Want仕分け

要件定義フェーズでは、アセスメントで明らかになった課題を「リニューアル後にどう解決するか」という形に変換します。単に「今の問題を直す」だけでなく、3〜5年後のビジネス要件も踏まえた「あるべき姿」を描くことが重要です。要件定義・ディレクション費は総予算の10〜30%が業界の相場とされており、このフェーズを削ると発注後の手戻りで結果的に高くつくことが多いため、適切なリソースを確保することが求められます。

要件定義で最も重要な作業のひとつが、要件をMust（必須）とWant（希望）に仕分けることです。関係者から要望を集めると、際限なく機能要件が膨らむ「要件肥大化」が起きやすく、スコープが広がることでコスト超過・納期遅延・品質低下を招きます。仕分けの基準は「この機能がなければ業務が成立しない」かどうかで判断するのが原則です。「あると便利」「将来使うかもしれない」はWantに分類し、予算・納期に余裕がある場合にのみ実装対象とします。

仕分けは一人の担当者が決めるのではなく、業務部門・経営層・IT部門の合意形成を経ることが重要です。MustとWantを記載した要件一覧を作成し、関係者レビューを経て承認を得るプロセスを設けることで、後から「この機能は絶対に必要だった」という巻き戻しを防げます。また、Mustに分類した要件についても「なぜ必須なのか」の根拠をアセスメントの課題と紐づけて記録しておくと、ベンダーへの説明やRFP作成の際に説得力が増します。

レガシーシステムリニューアルの失敗事例を分析すると、外部システムとの連携範囲の確認不足が主因のひとつとして繰り返し登場します。基幹システム・在庫管理システム・CRM・外部APIとの連携仕様は、リニューアル要件定義の段階で必ず確認し、スコープを明確に定義する必要があります。「既存の連携はそのまま引き継げる」と思い込んでいたが、実際には新システムの仕様と互換性がなかったというケースは珍しくありません。

連携要件の定義では、連携先システム名・連携方式（API/ファイル連携/DB直結）・データ項目・連携タイミング・エラー時の対応方針を一覧化します。特に大企業では、情報システム部門が管理するシステム以外に事業部独自で導入したSaaSが多数存在するケースがあり、棚卸しの段階でこれらを漏れなく把握することが重要です。連携範囲を要件定義で確定しておくことで、RFP段階でベンダーに正確な見積もり根拠を提供できます。

大企業のシステムリニューアルでは、Webガバナンスやセキュリティに関する要件が追加の論点として浮上することが多くあります。アクセス権限の管理方針（誰がどの画面・機能にアクセスできるか）・認証方式（シングルサインオン対応・多要素認証）・データ保持ポリシー・監査ログの要件は、情報システム部門やコンプライアンス部門と連携して要件定義の段階で確定させます。これらを後回しにすると、設計工程に入ってから大幅な仕様変更が生じるリスクがあります。

セキュリティ要件としては、通信の暗号化（TLS対応）・脆弱性診断の実施方針・ペネトレーションテストの有無・インシデント対応手順なども要件定義に含めることが推奨されます。ガバナンス面では、CMS・管理画面の更新権限をどう分散させるか、承認ワークフローが必要かどうかも要件として明文化します。特に複数拠点・グループ会社にまたがるシステムでは、権限設計の複雑さがプロジェクトの難易度に直結するため、要件定義の初期段階でスコープを決めておくことが重要です。

RFP（提案依頼書）の必須項目と作成のポイント

RFP（Request for Proposal：提案依頼書）は、ベンダーに対して「何を・なぜ・どのような条件で実現してほしいか」を伝える文書です。要件定義で明確にした内容をRFPに落とし込み、複数のベンダーに同条件で提案を依頼することで、見積もりの比較・ベンダー評価が可能になります。RFPの質が低いと、ベンダーによって前提が異なる提案が集まり、正確な比較ができなくなります。

RFPに必ず盛り込むべき必須項目は、大きく「現状の課題（Why）」「目的とKGI/KPI（What）」「予算と納期（条件）」の三つです。「現状の課題（Why）」では、アセスメントで抽出した課題を端的に記載し、ベンダーがリニューアルの背景を理解できるようにします。「目的とKGI/KPI（What）」では、リニューアルで何を達成したいのかを数値目標で示します。例えば「オペレーション処理時間を現行比30%削減」「問い合わせ件数を月100件から60件に削減」といった形で、ベンダーが提案の方向性を定めやすい目標を明記します。

「予算と納期」については、発注者側が「予算を明かすと足元を見られる」と考えて非公開にするケースがありますが、予算レンジと納期を示した方がベンダーの提案精度は上がります。予算が非公開の場合、ベンダーは安全マージンを多めに乗せた見積もりを出す傾向があるため、合理的なRFP運営のためには予算の目安を開示することが推奨されます。その他の必須項目としては、「対象範囲（スコープ）」「現行システムの概要」「要件一覧（Must/Want含む）」「提案依頼スケジュール」「評価基準」「契約・知的財産権の考え方」が挙げられます。

RFPで見落とされがちな項目が非機能要件です。非機能要件とは、機能そのものではなく「どの水準で動作するか」を定義するもので、レスポンスタイム・同時アクセス数・可用性（稼働率）・UI品質基準・アクセシビリティ対応レベル・保守体制などが含まれます。UIリニューアル案件では特に「デザイン品質」「操作性の基準」を言語化することが難しく、ベンダーによって解釈がばらつきやすい領域です。

UI品質基準の例としては、「社内で定めたデザインガイドラインへの準拠」「WCAGのAA水準のアクセシビリティ対応」「モバイルファースト設計（スマートフォン表示の最適化）」などを明記します。パフォーマンス要件としては、「ページ表示速度3秒以内」「同時1,000ユーザーのアクセスを想定」といった具体的な数値をRFPに記載することで、ベンダーがインフラ構成を適切に提案できます。非機能要件の記載が不十分だと、発注後に「想定と違う」という認識のずれが生じやすくなります。

ベンダー評価の観点：提案内容の何を比較するか

RFPへの回答として複数のベンダーから提案書が届いたら、評価基準に沿って比較選定を行います。「価格が安いベンダーに発注する」というシンプルな判断は、レガシーシステムリニューアルにおいては失敗リスクが高い選択です。提案内容の質・実績・体制・コミュニケーション能力・保守継続性を含めた総合評価が求められます。

ベンダー評価を定量化するには、評価項目ごとに重み付けを設定したスコアリングシートを使う手法が一般的です。主な評価項目としては、「提案内容の課題理解度（RFPの意図を正確に読み取っているか）」「実績・類似案件の経験」「技術力・採用技術の妥当性」「プロジェクト管理体制・担当者のスキル」「コミュニケーション品質（提案説明の明確さ）」「価格の妥当性・見積根拠の透明性」「保守・運用体制」が挙げられます。それぞれに5段階評価と重み係数を設定し、合計スコアで比較します。

評価の際には、提案書の内容だけでなく「提案説明会（プレゼンテーション）」を実施することが推奨されます。提案書は洗練されていても、実際のコミュニケーションで理解不足が露呈するケースや、担当者のスキルレベルが期待と異なるケースがあります。プレゼンテーションでは「要件定義で不明確な点をどのように対処するか」「想定外の要件変更が発生した場合の対応方針」なども質問し、ベンダーの問題解決能力を確認することが重要です。

ベンダー評価で価格を比較する際には、初期開発費用だけでなくTCO（総保有コスト）で判断することが重要です。初期費用が安くても、保守・運用費用が高い、または追加要件が発生するたびに高額な変更費用が請求されるケースがあります。見積書の内訳を確認し、「初期費用に含まれていない費用（テスト・移行費・ドキュメント費用など）」「月次・年次の運用保守費用」「ライセンス費用の変動要因」を明確にして比較することが求められます。

また、見積根拠の透明性も重要な評価ポイントです。「なぜこの工数・単価になるのか」を説明できないベンダーは、プロジェクト中にコスト増の説明も曖昧になりがちです。工数の積算根拠・使用技術のランニングコスト・追加要件が発生した場合の単価など、費用に関するコミュニケーションが明確かどうかを評価基準に含めることで、発注後のコスト管理がしやすくなります。

アセスメントから発注までのプロセス管理：失敗しないためのポイント

アセスメント・要件定義・RFP作成という一連のプロセスは、それぞれが独立したフェーズではなく、前フェーズの成果物が次フェーズの入力になる連続した流れです。各フェーズの成果物（課題一覧・要件一覧・RFP）をきちんと文書化し、関係者間で承認を取ることが、プロジェクト全体の品質を左右します。

規模感によって異なりますが、中規模（数千万円規模）のレガシーシステムリニューアルでは、アセスメントに2〜4週間、要件定義に4〜8週間、RFP作成・ベンダー選定に4〜8週間を目安とするのが一般的です。合計で3〜5か月程度のプリ・フェーズを設けることで、発注後の手戻りを最小化できます。この期間を「無駄」と感じて短縮しようとする企業もありますが、発注後の仕様変更による追加費用は、アセスメント・要件定義コストを大幅に超えるケースが多いため、適切な時間を確保することが推奨されます。

スケジュール管理では、各フェーズの完了基準を明確にしておくことが重要です。「アセスメント完了＝課題一覧の関係者承認」「要件定義完了＝Must/Want一覧の経営層承認」「RFP完了＝ベンダーへのRFP配布」といった形で、完了を承認行為と紐づけることで、曖昧なまま次フェーズに進むことを防げます。特に要件定義の承認は、後から「あの機能は要件定義に含まれていたはずだ」というトラブルを防ぐために重要なマイルストーンとなります。

アセスメント・要件定義・RFP作成を内部リソースで対応するか、外部コンサルタントに委託するかは、社内の経験値と工数によって判断します。システムリニューアルの経験が豊富な情報システム部門がある企業では、内製対応が可能なケースもあります。一方、リニューアル案件の経験が少ない企業や、業務担当者がプロジェクトに割ける工数に制約がある場合は、外部のDXコンサルタントやITコンサルタントに支援を依頼することで、プロセスの品質を高めることができます。

外部コンサルタントに依頼する範囲は「アセスメントと要件定義の支援」「RFP作成支援」「ベンダー選定の中立的支援」など、部分的な活用も有効です。重要なのは、外部コンサルタントに丸投げするのではなく、社内の業務担当者が主体となってプロジェクトに参画することです。要件定義は業務の深い知識なしには作れないため、コンサルタントは「プロセスの整理と文書化のファシリテーター」として活用し、要件の判断は必ず社内で行うという役割分担が望ましいです。

まとめ

本記事では、レガシーシステムリニューアルにおけるアセスメント・要件定義・RFP作成の実務について解説しました。アセスメントでは現行UI・機能・業務フロー・外部連携・セキュリティ要件を体系的に棚卸しして課題を抽出し、要件定義ではMust/Want仕分けによる要件肥大化の防止と外部連携スコープの確定が核心となります。RFPでは「現状の課題（Why）」「目的とKGI/KPI（What）」「予算と納期（条件）」の三本柱を明記し、非機能要件も盛り込んだ上でベンダーに提示することが、適切な提案を引き出すための条件です。ベンダー評価では価格だけでなく提案品質・体制・TCOを総合的に評価することが、プロジェクト成功の確率を高めます。

アセスメント〜RFP発行までのプリ・フェーズに適切な時間（目安3〜5か月）とリソース（総予算の10〜30%相当）を投資することが、発注後の手戻りを防ぎ、レガシーシステムリニューアルを成功に導く最も確実な道筋です。「要件定義を急いだために、後から大規模な仕様変更が必要になった」という失敗パターンは、このフェーズへの適切な投資によって大幅に回避できます。リニューアルの目的と要件を関係者全員で合意した上でRFPを発行し、透明性の高いベンダー選定を行うことで、期待通りの成果物を適切なコストで実現できます。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。