レガシーシステムのリニューアルは、アセスメントで現状を棚卸しし、要件定義で機能を仕分け、RFPで条件を揃えてベンダーを比べる順に進めます。この順で進めると、発注後の手戻りを抑えやすくなります。
各段階で決めることと用意する文書を、順に説明します。
▼全体ガイドの記事
・レガシーシステムリニューアルの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：現行UI・機能・業務フローの棚卸しと課題抽出
アセスメントは、リニューアルの出発点になる現状分析の工程です。客観的なデータと現場の声から、リニューアルが必要な理由をはっきりさせます。
発注側の担当者は、現行システムのUIや操作性、機能を棚卸しします。業務フローと外部連携も含め、課題を定量と定性の両面から整理します。この整理が曖昧なままだと、リニューアル後に「思っていたものと違う」事態になりがちです。
UI・機能の棚卸し：画面一覧と操作フローの可視化
画面と機能を別々に記録しておくと、操作上の課題や見直す機能を、後の要件定義へ引き継ぎやすくなります。
- 画面の可視化：現行システムの全画面を撮影し、画面遷移図にまとめたもの。
- 現状フロー：ユーザーの操作順と、各段階の手戻り・エラー・迂回操作の記録。
- 現場の声の収集：分かりにくいボタンや迷いやすい入力項目を、ヒアリングシートで集める。
- 機能の一覧化：実装済みの全機能を並べ、利用頻度・部署・業務上の重要度を添えた一覧。
- 機能の見直し：未利用・重複・外部ツールで代替された機能を確認する。
機能一覧をExcelやスプレッドシートで管理すると、後のMust/Want仕分けと連動させられ、作業の手間が減ります。
業務フローの課題抽出：定量データと現場ヒアリングの組み合わせ
業務フローの課題は、数値に表れる問題と現場の実感を組み合わせて捉えます。立場の違う人から情報を集めると、使いにくさや業務上のリスクも見えてきます。
- 定量情報：ログやサポートチケットを使い、エラーの多い機能や時間のかかる業務を見つける。
- 定性情報：業務担当者、管理者、ITリテラシーが低いユーザーに聞き取り、数値に出ない課題を集める。
- UI/UX・機能：操作性と視認性に加えて、不足機能と過剰機能の分類。
- 業務フロー・連携：二重入力、手作業、外部システムとのデータのつなぎ目の不備を整理する。
- セキュリティ/ガバナンス：これらとは別に、守りと統制に関わる課題を整理する。
課題をカテゴリごとに整理しておけば、要件定義へ渡す材料がそろいます。大企業では、Webガバナンスやセキュリティの要件が複雑になるため、情報システム、法務、コンプライアンスの各部門にも早い段階から加わってもらいます。
要件定義：リニューアル後のあるべき姿とMust/Want仕分け
要件定義では、アセスメントで見つけた課題を、リニューアル後にどう解決するかの形に置き換えます。今の問題だけでなく、3〜5年後のビジネス要件も踏まえて、あるべき姿を描きます。
要件定義・ディレクション費は、総予算の10〜30%が業界の相場とされています。この工程を省くと、発注後の手戻りで結果的に高くつくことが多いため、適切なリソースを確保しておくことが大切です。
要件のMust/Want仕分け：要件肥大化を防ぐ実務手法
要件定義で大事な作業の一つは、要件をMust（必須）とWant（希望）に仕分けることです。
要望を集めると機能要件が膨らみ、スコープが広がると、コスト超過・納期遅延・品質低下につながる場合があります。
Mustかどうかは、業務が成立するかを基準に判断します。
- Must：機能がなければ業務が成立しない要件。
- Want：「あると便利」「将来使うかもしれない」要件で、予算・納期に余裕がある場合に実装する。
- 合意と承認：一人で決めず、業務部門・経営層・IT部門で要件一覧を確認し、了承を得る。
- 必須の根拠：Mustの理由を、アセスメントの課題と結び付けて記録する。
関係者の合意を経ておけば、後になって必要な機能の有無を巡り、やり直しになる事態を防げます。また、Mustの根拠をアセスメントの課題と結び付けておくと、ベンダーへの説明やRFP作成の材料になります。
外部システム連携範囲の確定：失敗を防ぐ連携要件の定義
レガシーシステムの失敗事例では、外部システムとの連携範囲の確認不足が、主な原因の一つとして何度も挙げられています。特に、既存の連携をそのまま引き継げると思っていても、新システムと互換性がない場合があります。
- 連携先：基幹・在庫管理・CRM・外部APIなどのシステム名。
- 連携仕様：API、ファイルのやり取り、DB直結などの方式と、扱うデータ項目。
- 運用条件：連携のタイミングと、エラー時の対応方針。
大企業では、情報システム部門の管理外で事業部が独自に導入したSaaSが多数あることもあります。そのため、棚卸しで漏れなく把握しておく必要があります。
連携の範囲を要件定義の段階で確定しておくと、RFPでベンダーに正確な見積もりの根拠を示せます。
Webガバナンス・セキュリティ要件の定義：大企業特有の注意点
大企業では、Webガバナンスやセキュリティ要件が追加の論点になることがあります。これを後回しにすると、設計が終わったあとに大幅な仕様変更が生じるおそれがあります。
発注側は、関係部門と連携して、要件定義の段階で内容を確定させます。
- 権限と認証：誰がどの画面や機能にアクセスできるかを決め、シングルサインオンや多要素認証への対応も含める。
- データと監査：データ保持ポリシーと監査ログの要件。
- セキュリティ対応：TLS暗号化、脆弱性診断、ペネトレーションテスト、インシデント対応手順。
- 管理運用：CMS・管理画面の更新権限の分散と承認ワークフローの要否。
複数拠点やグループ会社にまたがるシステムでは、権限設計の複雑さがそのまま開発の難しさにつながります。そのため、要件定義の初期段階で範囲を決めておきます。
RFP（提案依頼書）の必須項目と作成のポイント
RFP（Request for Proposal：提案依頼書）は、実現してほしい内容と条件をベンダーに伝える文書です。要件定義の内容をRFPに反映させ、複数社に同じ条件で依頼すると、見積もりや提案を比べられます。
RFPの記載があいまいで、ベンダーごとに前提が違ってしまうと、提案を正確に比べられません。
RFPに必ず記載すべき必須項目：Why・What・条件の三本柱
RFPでは、リニューアルの背景、達成目標、発注条件をそろえて伝えます。予算の幅や納期を示すと、ベンダーの提案の精度が上がります。
- 現状の課題（Why）：アセスメントで見つけた問題点を端的に示す。
- 目的とKGI/KPI（What）：達成したい目標を数値で表したもの。
- 予算と納期（条件）：予算の幅と納期を提示する。
- その他の項目：対象範囲、現行システム概要、Must/Wantを含む要件一覧、提案依頼日程、評価基準、契約・知的財産権の考え方。
目標の例は、処理時間を現行比30%削減することや、問い合わせを月100件から60件に減らすことです。
予算を非公開にした場合、ベンダーは安全マージンを多めに含めて見積もる傾向があります。そのため、予算の目安は開示しておくことが推奨されます。
非機能要件の記載：UI品質・パフォーマンス・保守性の明文化
RFPで見落とされがちなのが非機能要件です。非機能要件は、機能そのものとは別に、システムがどの水準で動くかを定める項目です。解釈のばらつきを防ぐため、数値や基準をRFPに記載しておきます。
- 性能と可用性：レスポンスタイム、同時アクセス数、稼働率。
- UI品質：デザイン品質、操作性、社内デザインガイドラインへの準拠。
- アクセシビリティと端末：WCAGのAA水準への対応、モバイルファースト設計。
- 保守：修正や運用を続けるための体制。
特に、UI刷新では、デザイン品質や操作性の基準を言葉にしにくく、ベンダーごとの受け止め方が分かれやすい領域です。
具体的には、ページ表示速度3秒以内と、同時1,000ユーザーを想定した構成です。基準があいまいだと、発注後に想定とのずれが生まれがちです。
ベンダー評価の観点：提案内容の比較項目
複数の提案書が届いたら、評価基準に沿って比べて選びます。価格の安さだけで発注先を決めると、レガシーシステム刷新では失敗のリスクが高まります。
評価では、提案内容の質と実績に加えて、体制やコミュニケーション能力も見ます。さらに、保守を続けられるかまで含めて、総合的に判断します。
評価項目と重み付け：定量的なベンダー比較の方法
評価項目に重み付けをしたスコアリングシートを使うと、比較を定量的に行えます。項目ごとに5段階評価と重み係数を設定し、合計スコアで比べます。
- 提案と実績：課題理解度、類似案件の経験。
- 技術と体制：採用する技術の妥当性、管理体制、担当者のスキル。
- 説明と費用：提案説明の明確さ、価格の妥当性、見積根拠の透明性。
- 保守：運用を続けるための体制。
提案書だけでなく、提案説明会（プレゼンテーション）も行うことが推奨されます。提案書がよく練られていても、説明の場で理解の不足が分かったり、担当者のスキルが期待と違ったりすることがあるためです。
発注側は、不明な要件への対処や想定外の変更時の方針を質問し、ベンダーの問題解決の力を確かめます。
価格評価の落とし穴：初期費用だけで判断しないための注意点
価格は、初期の開発費用だけでなくTCO（総保有コスト）で比べます。初期費用が安くても、保守・運用費が高かったり、追加要件の変更費用が高額になったりすることがあります。
- 初期費用の範囲：テスト費、移行費、ドキュメント費用などが含まれているか。
- 継続費用：月次・年次の運用保守費用とライセンス費用の変動要因。
- 追加費用：工数の積算根拠、技術のランニングコスト、追加要件発生時の単価。
見積もりの根拠の透明性も、大切な評価の観点です。根拠を説明できないベンダーは、プロジェクト中のコスト増も曖昧になりがちです。
費用の説明が明確かどうかも評価基準に含めておくと、発注後にコストを管理しやすくなります。
アセスメントから発注までのプロセス管理：失敗しないためのポイント
アセスメント、要件定義、RFP作成は、別々に切り離して進める工程ではありません。前の工程の成果物が次の工程の入力になる、一続きの流れです。
課題一覧、要件一覧、RFPを文書にまとめ、関係者の承認を得ておくことが、全体の品質を左右します。
アセスメント〜RFP発行までの標準的なスケジュールの目安
中規模（数千万円規模）のリニューアルでは、各工程の期間を次のように見込みます。ただし、規模によって期間は変わります。
- アセスメント：2〜4週間。
- 要件定義：4〜8週間。
- RFP作成・ベンダー選定：4〜8週間。
この3工程を合わせた3〜5か月程度のプリ・フェーズを確保すると、発注後の手戻りを最小限に抑えられます。期間を縮めようとする企業もありますが、仕様変更の追加費用が、この工程のコストを大幅に上回る場合が多いため、適切な期間の確保が推奨されます。
スケジュールを管理するには、各工程の完了基準をはっきりさせておくことが大切です。アセスメントは課題一覧、要件定義はMust/Want一覧の関係者承認を基準にし、RFPはベンダーへの配布を完了の条件にします。
特に要件定義の承認は、ある機能が要件に含まれていたかを後から巡るトラブルを防ぐ、重要な節目です。
内製・外部コンサル活用の判断基準：アセスメント〜RFPの担い手
社内の経験と工数を踏まえて、内製か外部委託かを判断します。経験豊富な情報システム部門があれば、内製できることもあります。
- 内製を検討する場合：システムリニューアルの経験が豊富な情報システム部門が社内にあること。
- 外部支援を検討する場合：経験が少ない、または業務担当者が使える工数に制約があること。
- 依頼する範囲：アセスメント・要件定義、RFP作成、ベンダー選定の中立的支援から選ぶ。
外部支援を使う場合も、業務担当者が主体となって参加します。要件定義には業務の知識が欠かせないため、コンサルタントは整理と文書化を進める役割を担います。
要件の判断は社内で行い、外部のコンサルタントに丸投げしない役割分担が望ましいです。
まとめ
アセスメント、要件定義、RFP作成の流れを、ここまで見てきました。アセスメントでは、UIや機能、業務フローを棚卸しして課題を抽出し、外部連携やセキュリティも対象に含めます。要件定義では、Must/Wantを分けて、連携範囲を確定させます。
RFPには、課題と目標を記載し、予算と納期、非機能要件も入れます。ベンダー評価では、価格だけでなく、提案の質、体制、TCOを合わせて見ます。こうした総合評価が、プロジェクトの成功の可能性を高めます。
プリ・フェーズは目安として3〜5か月、要件定義・ディレクション費は総予算の10〜30%相当を確保します。関係者が目的と要件に合意してから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を創業。