レガシーシステムのリニューアル範囲は、画面・機能・外部連携・データ移行・非機能要件に分けて見直します。各項目をMust（必須）とWant（あれば嬉しい）に仕分けると、開発の途中で起きる手戻りを減らせます。
全体の流れはレガシーシステムリニューアルの完全ガイドもご覧ください。
▼全体ガイドの記事
・レガシーシステムリニューアルの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
リニューアルのスコープ定義の重要性
スコープ定義は、投資対効果と現場の納得感を両立させる出発点です。現場のヒアリング後に要望を整理せずすべて取り込むと、要件が膨らみます。その結果、プロジェクトが途中で立ち往生するおそれがあります。
一方、コア機能だけに絞りすぎると、リリース後も使い勝手が改善されず、現場の反発を招くことがあります。また、スコープ定義の失敗は、リニューアルプロジェクトの失敗要因として常に上位に挙がります。
スコープ肥大化が引き起こす典型的な失敗パターン
要望を整理しないまま設計に進むと、見積もりが膨らみ、予算を超えることがあります。さらに機能追加や変更が続くと、設計の整合性が崩れ、テスト工数も増えます。
途中でスコープカットが起きると、現場の期待を裏切り、リリース後の定着率も下がります。こうした悪循環は、要件定義の段階でMustとWantを仕分けておくと防げます。
Must/Want仕分けによるスコープ絞り込みの考え方
Mustは、リニューアル後も業務を成立させるために欠かせない機能です。日常業務の維持、法令・規制対応、セキュリティ上の必須対応がこれに当たります。
Wantは、業務効率や利便性を高めるものの、なくても業務は回る機能です。仕分けには業務部門のキーパーソンも加わり、経営判断が必要な項目は早めに上げます。
Wantの項目は、Phase2以降の追加開発候補としてバックログに残すと、将来の拡張計画を立てやすくなります。
画面・UI/UXと操作フローの見直し範囲
画面の古さや複雑な操作は、レガシーシステムで特に目につく課題です。20年以上前の画面は情報量が多く、メニュー階層も深いため、新しいメンバーが操作を覚えるのに時間がかかります。
リニューアルでは、見た目の刷新にとどまらず、操作フロー全体を現在の業務ニーズに合わせて設計し直すことが求められます。
画面棚卸しとスクリーン数の整理
まず現行システムの全画面リストを作り、利用頻度・利用者数・業務上の重要度の3軸で評価します。
画面棚卸しシートには、次の情報を記録します。
- 現行画面名：棚卸しの対象を特定するための名称。
- 利用状況：利用頻度、利用者数、課題。
- リニューアル方針：刷新・統合・廃止・現行維持から選ぶ方針。
利用者がほとんどいない画面や、機能が重複する画面は廃止・統合候補です。一方で、毎日使うメイン業務画面では、操作ステップ数を減らすことを優先します。
レスポンシブ対応とモバイルアクセス要件の定義
業務システムでも、スマートフォンやタブレットからのアクセスが全体の60〜70%を超えるケースが増えています。PC前提の固定幅レイアウトでは、モバイル利用が事実上難しくなります。
モバイルで使えるようにする画面と機能は、スコープに明記しておきます。全画面をレスポンシブ化するか、外出先で使う照会・承認系だけに絞るかは、業務フローを見て判断します。
機能カテゴリ別の見直しポイントと優先度判断
業務システムの機能は5つのカテゴリに分けられ、カテゴリごとに見直し方や優先度が異なるため、分けて見ていくと漏れを減らせます。検索・照会と登録・更新では、見直す内容が大きく異なります。残りの3つは、後の2つの節で詳しく見ていきます。
- 帳票・出力、通知・アラート：次の「検索・帳票・通知機能の現代化」で扱う項目。
- 権限管理：「権限管理・認証機能の刷新ポイント」で扱う項目。
検索・帳票・通知機能の現代化
検索機能は、レガシーシステムで最も不満が出やすい領域です。複数条件検索の使いにくさ、検索結果の遅さ、条件を保存できない点が典型的な課題です。このため、条件指定や結果表示、検索条件の保存を見直します。
帳票と通知は、業務部門と相談しながら範囲を決めます。通知は、外部連携コストも踏まえて優先度を決めます。
- 検索：キーワード入力部分のUI改善と、お気に入り保存・最近の検索履歴の検討。
- 帳票：現行フォーマットを維持するか、PDFに加えてExcelやCSVも出力するかの判断。
- 通知：メール、ブラウザ表示、Slack/Teams連携のニーズの確認。
権限管理・認証機能の刷新ポイント
ロールがなくIDごとに権限を設定していたり、退職者のアカウントが残ったりする状態は、権限管理の見直し対象です。認証・権限では、次の導入範囲を検討します。
- 権限管理：ロールベースアクセス制御（RBAC）と、入退職時の付与・剥奪フローを含むアカウントライフサイクル管理の範囲。
- 認証：シングルサインオン（SSO）やMFAの方針。情報セキュリティ要件のため、経営判断が必要で、早期の決定が求められます。
権限設計は、システム設計の根幹に関わります。したがって、後からスコープに加えると手戻りが大きくなります。
廃止すべき不要機能の洗い出し方
長年運用したシステムには機能が積み重なり、業務フローが変わっても削除されないものが出てきます。誰も使っていないのに、廃止が不安で残している機能もあります。
廃止候補は、利用実績データの有無で探し方が変わります。
- ログがある場合：利用実績がゼロか極めて少ない画面・機能を抽出する方法で、最も客観的です。
- 実績データがない場合：業務部門へのアンケートで、利用状況と廃止可否を確かめる手段。
廃止できれば、開発・テスト・保守のコスト削減に直結します。そのため、廃止候補は積極的に洗い出します。
外部システム連携の対象範囲の把握
外部連携の確認不足は、リニューアルの大きな失敗要因です。基幹システム、CRM、会計システムとのデータ連携は、対象システムの設計に直接影響します。決済基盤やWMSとの連携も同様です。
仕様確認を後回しにすると、必要なデータを連携で取得できないことや、連携先のAPI仕様が変わっていたことが、設計後に分かります。その結果、手戻りが発生します。
連携システムの棚卸しと優先度判断
連携の全体像を把握するため、相手システムごとに一覧を作ります。一覧には、方向やデータ、頻度に加え、次の観点も書き込みます。
- 連携方式：バッチ、リアルタイム、APIのいずれかの確認。
- データ形式：CSV、XML、JSONのどれかの選択。
- 連携タイミング：日次、時次、イベント駆動のどれかの把握。
連携仕様を変えるか現行を踏襲するかは、連携先の担当者と合意したうえでスコープを決めます。新しいAPIやデータ形式への変更は工数が増えるため、優先度と費用対効果を見ながら判断します。
リニューアルを機に連携設計を見直すべきポイント
現行がFTP/CSVによるファイル連携なら、API連携への移行をスコープに含めることで将来の拡張性が高まります。ただし、連携先もAPI対応が必要となり、担当者との調整コストが発生します。
連携を増やす場合は、連携先ごとに今回の対象に含めるかを明記します。スコープ外の連携は、将来フェーズのバックログで管理します。
連携の追加は後からでも比較的対応しやすいため、初期範囲は現行連携の維持を基本に絞ると安全です。
データ移行範囲の設計と落とし穴
データ移行は工数を読みづらく、品質がビジネスに直接影響する領域です。新システムの利用開始日に正しいデータを揃えるには、移行設計からツール開発、リハーサル、本番移行までの工程が必要です。
特に、対象範囲が曖昧なまま進めると、開発終盤に移行ツールが間に合わないおそれがあります。
移行対象データの選定と期間の考え方
移行データは、マスタ、トランザクション、添付ファイル・ドキュメントに分けて検討します。種別ごとに移行方針を決めます。
- マスタデータ：顧客・商品・組織・ユーザーなどは、原則としてすべて移行。
- トランザクション：移行する年数を、業務要件と移行コストのバランスで決める。
- 添付ファイル：移行するか、旧システムで参照を続けるかの判断。
たとえば、直近3〜5年分のトランザクションを移行し、それ以前のデータは旧システムに参照閲覧用として残す折衷案もよく採用されます。
添付ファイルは件数・容量が大きく、移行コストも高くなりがちなため、早めに方針を決めます。
データ品質の事前確認と移行リハーサルの重要性
長年運用したデータには、表記ゆれ、重複レコード、未使用マスタが混在しがちです。移行前のデータクレンジング工数を見積もりに含めないと、リハーサル時にエラーが増え、予定が崩れるおそれがあります。
移行リハーサルは、本番切替の1〜2ヶ月前に少なくとも1回、できれば2回行います。リハーサルを重ねることで、移行ツールのバグやデータ品質の問題を早く見つけられます。
データ移行は、プロジェクト全体の品質とスケジュールを左右する重要工程です。そのため、要件定義の段階から計画に組み込んでおきます。
非機能要件(表示速度・セキュリティ・アクセシビリティ)の見直し
非機能要件は後回しにされやすい一方で、ユーザー体験と運用コストに直結します。そのため、機能要件が中心になりがちな要件定義の段階で、非機能要件も同時に整理しておきます。
速度、セキュリティ、アクセシビリティの目標は、数値で定めておきます。基準がなければ、開発後に達成できたかどうかを確かめられません。
表示速度の目標設定と改善インパクト
Googleの調査では、ページの読み込み時間が1秒から3秒になると、直帰率が32%増加します。業務システムでも、処理待ちが多いと従業員の生産性や満足度が下がります。
性能目標の例としては、主要画面の初期表示を3秒以内、検索結果の表示を2秒以内とすることが挙げられます。そのうえで、開発・テストの工程で計測する仕組みも設けておきます。
ボトルネックがデータベース設計にある場合は、アーキテクチャの見直しが必要になります。このため、技術調査は早い段階で行います。
セキュリティ・アクセシビリティ要件のスコープへの組み込み方
セキュリティでは、脆弱性対応の基準（OWASP Top10への対応等）と、HTTPS必須などの通信暗号化を確かめます。さらに、個人情報の暗号化・マスキングや、監査ログの取得範囲も対象に含めます。
顧客向けシステムでは、アクセシビリティも特に重要になります。JIS X 8341-3（WCAG準拠）の対応レベルを、要件として定めておきます。
開発完了後にセキュリティやアクセシビリティの対応を追加すると、大規模な修正になりうるため、設計前に範囲を確定しておきます。必要な場合は、専門コンサルタントを要件定義の段階から加えます。
リニューアルスコープ定義チェックリストの活用
画面・機能・外部連携・データ移行・非機能要件を網羅したチェックリストを作っておくと、キックオフ時の確認漏れを防げます。各項目を『確認済み』『スコープ内』『スコープ外』『次フェーズ候補』の4状態で管理すると、共通認識を作りやすくなります。
スコープ定義チェックリストの主要項目
スコープの抜けを防ぐため、領域ごとの確認範囲を並べて見ていきます。データ移行後の旧システムの扱いも、あわせて確かめておきます。
- 画面・UI/UX：全画面リストの作成と利用頻度の評価、廃止・統合候補の合意、モバイル対応範囲の確認。
- 機能：検索、帳票、通知、権限管理、廃止機能。
- 外部連携：連携一覧、仕様変更の有無、連携先との合意。
- データ移行：対象種別、移行期間、クレンジング、リハーサル。
- 非機能要件：表示速度・セキュリティ・アクセシビリティの目標と基準。
最初から設けるスコープ変更管理の仕組み
スコープが確定した後も、プロジェクトの途中で変更要求は発生します。そこで、意思決定の前に変更内容と影響範囲を評価する手順を設けます。評価では、工数やコスト、スケジュールへの影響も見ておきます。
変更管理がないまま要求を受け入れると、スコープクリープが起き、プロジェクトが収束しなくなります。そのため、意思決定権者をあらかじめ明確にし、現場で安易に仕様が追加されるのを防ぎます。
まとめ
レガシーシステムのスコープ定義では、画面・機能から非機能要件までの範囲を整理します。そのうえでMustとWantで優先順位を決め、チェックリストで確認漏れを防ぎます。
要件定義で対象範囲を確定すると、開発中の手戻りを抑えやすくなります。不要な機能の廃止も含めて現行機能を洗い出し、関係者どうしで共通認識を持つことが大切です。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。