システム更改に着手するとき、まず明確にすべきなのは「何を更改の対象とし、どの機能を見直すのか」という対象範囲の整理です。保守期限切れやEOL、ハードウェアの更新、契約満了といった契機で始まる更改では、現行システムをそっくりそのまま載せ替えればよいわけではありません。すべてを一律の手法で置き換えると、コストもリスクも膨らみます。対象範囲を見極め、領域ごとに適切な手法を選ぶことが、更改の効率と安全性を大きく左右します。
本記事では、システム更改で見直すべき機能・対象範囲を体系的に整理し、AWSが提唱する7Rをはじめとする手法を、それぞれの特徴・費用・期間・適したケースとともに解説します。基幹機能や周辺機能、データ、インフラといった対象範囲ごとに、現状踏襲すべき部分と見直すべき部分をどう切り分けるかという実務的な視点も示します。システム更改の全体像や基礎をあらためて押さえたい方は、システム更改の完全ガイド もあわせてご覧いただくと、本記事の手法選びがより立体的に理解できます。
▼全体ガイドの記事
・システム更改の完全ガイド
システム更改で見直すべき対象範囲の全体像
システム更改の対象範囲は、大きくインフラ層・アプリケーション層・データ層・周辺連携の四つに分けて捉えると整理しやすくなります。更改の契機がハードウェアの保守期限なのか、ソフトウェアのEOLなのか、契約満了なのかによって、優先的に見直すべき層が変わります。まずは対象範囲を層ごとに棚卸しすることが出発点です。
インフラ・アプリ・データ・連携の四層で対象を捉える
インフラ層は、サーバーやストレージ、ネットワーク機器、OSやミドルウェアといった基盤を指します。ハードウェアの保守期限切れやOSのEOLが契機となる更改では、この層が最優先の対象です。アプリケーション層は、業務ロジックを担うプログラム本体で、開発言語の保守終了や仕様の属人化が見直しの引き金になります。
データ層は、業務データを蓄積するデータベースやファイルで、更改時には移行の正確性が最重要となります。周辺連携は、他システムや外部サービスとのインターフェースを指し、更改によって接続仕様が変わると影響範囲が広がります。これら四層を切り分けて棚卸しすることで、どこに保守期限のリスクがあり、どこを優先的に更改すべきかが明確になります。
重要なのは、すべての層を同じ手法・同じタイミングで更改する必要はないという点です。保守期限が迫るインフラ層だけを先に更改し、安定しているアプリケーション層はそのまま載せ替える、といった層ごとの判断が現実的です。対象範囲を四層で捉えることで、更改の優先順位とスコープを冷静に設計できます。
現状踏襲する機能と見直す機能の切り分け
更改で必ず判断を迫られるのが、現状をそのまま踏襲する機能と、この機会に見直す機能の切り分けです。長年使われてきた機能の中には、すでに業務で使われていない不要機能や、複雑化して保守コストを押し上げている機能が紛れています。すべてを無条件に載せ替えると、不要な複雑さまで新基盤へ持ち込んでしまいます。
切り分けの基準は、その機能が現在の業務でどれだけ使われ、どれだけの価値を生んでいるかです。利用頻度が高く業務に不可欠な機能は現状踏襲し、使われていない機能は思い切って廃止（リタイア）の候補とします。一方、保守コストが高くトラブルの温床になっている機能は、更改を機に作り直す対象に位置づけます。この見極めが、更改の費用とリスクを大きく左右します。
切り分けを正確に行うには、現行機能の利用状況を可視化することが欠かせません。実際のログや利用部門へのヒアリングを通じて、機能ごとの利用実態を把握します。「念のため残す」という判断を繰り返すと、結局すべてを引き継ぐことになり、更改の効果が薄れます。見直すべき機能を勇気を持って選別することが、更改を価値ある投資に変える鍵です。
更改手法の一覧：7Rとその使い分け
更改の対象範囲を整理したら、次は領域ごとにどの手法で置き換えるかを選びます。代表的なフレームワークが、AWSの提唱する7R（Rehost、Relocate、Replatform、Repurchase、Refactor、Retire、Retain）です。これに加え、IPAによる4分類（リビルド、リライト、リホスト、ハードウェア更改）も実務でよく参照されます。それぞれの手法が向くケースを整理します。
7Rそれぞれの特徴と適用ケース
7Rは更改の選択肢を網羅的に整理したフレームワークです。Rehost（リホスト）はアプリケーションを変えずに別基盤へ載せ替える手法で、いわゆる「リフト＆シフト」に当たります。保守期限切れのハードウェアからクラウドへ移すケースに向き、改修が最小で済みます。Relocate（リロケート）は仮想環境ごと移設する手法で、構成を保ったまま基盤だけを変えます。
Replatform（リプラットフォーム）は、基盤を変える際にデータベースやミドルウェアの一部を最適化する手法です。Repurchase（リパーチェス）は、自社開発を市販パッケージやSaaSへ置き換える選択肢で、保守負担の大きい独自システムからの脱却に向きます。Refactor（リファクター）はコードを作り直す手法で、コストと期間はかかりますが、根本的な刷新が可能です。
残るRetire（リタイア）は不要となった機能やシステムの廃止、Retain（リテイン）は現状維持を指します。更改では「すべてを移す」のではなく、リタイアやリテインも積極的な選択肢として扱うことが重要です。対象範囲ごとに、改修の少ないリホストから根本的なリファクターまで、コストとリスクのバランスを見て手法を選び分けます。
手法別の費用・期間の目安
手法を選ぶ際は、費用と期間の目安を押さえておくと判断しやすくなります。改修を最小限に抑えるクラウド移行型（リホスト等）は、数百万円から1,000万円台の規模で、3〜6ヶ月程度が一つの目安です。基盤を変えるだけで業務ロジックには手を入れないため、比較的短期かつ低コストで済みます。保守期限が迫る中で素早く脱却したい場合に有効です。
一方、コードから作り直す再構築型（リビルド等）は、2,000万円から数千万円規模となり、期間も12〜18ヶ月以上に及びます。根本的に刷新できる反面、コストとリスクは大きくなります。単一業務システムの更改は概ね3,000万〜1.5億円、基幹に複数の周辺システムが絡む中〜大規模な更改では1.5億〜5億円が目安とされ、SI費が全体の6〜7割を占める傾向があります。
これらの目安は、対象範囲のどこにどの手法を適用するかで大きく変動します。すべてをリビルドすれば費用も期間も膨らみますが、安定領域はリホスト、不要機能はリタイアと使い分ければ、全体のコストを抑えられます。手法ごとの費用・期間を踏まえ、対象範囲に応じた最適な組み合わせを設計することが、更改の費用対効果を高める要点です。
単一手法に頼らないポートフォリオアプローチ
システム全体に単一の手法を当てはめるのではなく、対象範囲ごとに最適な手法を組み合わせる「ポートフォリオアプローチ」が、現実的な更改の進め方です。保守期限が迫る部分はリホストで素早く退避し、保守コストの高い独自機能はリパーチェスでパッケージへ置き換え、使われていない機能はリタイアする。こうした使い分けが全体最適につながります。
領域ごとに手法を組み合わせる理由
システムは、安定して長年使われている領域と、頻繁に変更が入る領域、すでに陳腐化した領域が混在しています。これらをすべて同じ手法で更改するのは非効率です。安定領域までリビルドすれば無駄なコストがかかり、逆に陳腐化した領域をリホストで延命すれば負債を引き継ぐことになります。領域の性質に応じて手法を変えることが合理的なのです。
ポートフォリオアプローチの実践では、先に整理した四層と機能の切り分けが土台となります。各領域について、保守期限の切迫度、利用頻度、保守コスト、改修ニーズを評価し、リホストからリビルドまでの手法を割り当てていきます。この設計図があれば、更改全体のコストと期間を見通しやすくなり、優先度の高い領域から段階的に着手できます。
手法を組み合わせることで、リスクの分散も図れます。すべてを一括で作り直すビッグバン型は失敗時の影響が甚大ですが、領域ごとに手法とタイミングを分ければ、問題が起きても影響を局所化できます。対象範囲の見極めと手法の使い分けは、更改を止めずに安全に進めるための実務的な要となります。
見直し対象を絞り込むための評価軸
対象範囲と手法を整理しても、限られた予算と期間の中ですべてを一度に更改することは現実的ではありません。そこで必要になるのが、どの機能・領域を優先的に見直すかを判断する評価軸です。保守期限の切迫度、利用頻度、保守コスト、ビジネス上の重要度という観点から、対象を絞り込んでいきます。
保守期限の切迫度とリスクで優先度を測る
第一の評価軸は、保守期限の切迫度です。ハードウェアの保守終了やOS・ミドルウェアのEOLが目前に迫っている領域は、放置すれば障害発生時に復旧できないリスクを抱えます。そのため、期限が近い領域ほど更改の優先度は高くなります。各構成要素の保守終了時期を一覧化し、期限から逆算してスケジュールを引くことが、現実的な計画の出発点となります。
あわせて、障害が起きたときの業務影響の大きさも評価します。同じ保守切れでも、停止すれば全社の業務が止まる基幹領域と、影響が限定的な補助的領域とでは、優先度が異なります。切迫度と影響度を掛け合わせて評価することで、限られたリソースをリスクの高い領域へ集中させる判断ができます。やみくもに古いものから順に更改するのではなく、リスクの大きさで優先順位を付けることが肝心です。
この評価軸に沿って優先度を整理すれば、更改を一度に行わず、複数年にわたる中期計画として段階的に進める道筋が描けます。先に整理した四層の棚卸しと機能の切り分け、7Rによる手法選択、ポートフォリオアプローチを、この優先度の評価軸と組み合わせることで、対象範囲・手法・順序という三つの設計が一つにつながります。
保守コストと利用価値で見直し範囲を判断する
第二の評価軸は、保守コストと利用価値のバランスです。維持に高いコストがかかっているのに、生み出している価値が小さい機能は、更改で統廃合や廃止を検討すべき筆頭候補です。逆に、コストは低く価値が高い機能は、無理に手を入れず現状踏襲（リテイン）とするのが合理的です。コストと価値の二軸でマッピングすることで、見直すべき範囲が浮かび上がります。
利用価値の評価には、実際の利用頻度や業務上の重要度を用います。ログ分析で「ほとんど使われていない機能」が見つかれば、それは更改の対象から外し、廃止する判断ができます。「念のため残す」を繰り返すと、不要な複雑さを新基盤へ持ち込み、保守コストを再び押し上げてしまいます。データに基づいて利用価値を見極めることが、対象範囲を適切に絞り込む鍵です。
こうした評価軸を用いた絞り込みは、更改の費用対効果を直接高めます。すべてを一律に移すのではなく、リスクが高くコスト効率の悪い領域から優先的に手を入れることで、限られた投資で最大の効果を引き出せます。対象範囲の見極めは、更改という守りの投資を、戦略的な意思決定へと変える出発点なのです。
なお、これらの評価軸は一度きりの判断で終わらせず、定期的に見直すことが望まれます。システムの利用状況や保守期限は時間とともに変化し、昨年は優先度が低かった領域が、保守終了の接近によって今年は最優先になることもあります。更改対象の評価を継続的に更新し、中期計画へ反映させていくことで、場当たり的な対応を避け、計画的な更改を実現できます。対象範囲の可視化と評価を運用に組み込むことが、システム全体を健全に保つ鍵となります。
まとめ
本記事では、システム更改で見直すべき機能・対象範囲について、インフラ・アプリ・データ・連携の四層で捉える視点と、現状踏襲する機能と見直す機能の切り分けを整理しました。そのうえで、AWSの7RやIPAの4分類といった更改手法を、それぞれの特徴・適用ケース・費用と期間の目安とともに解説し、領域ごとに手法を組み合わせるポートフォリオアプローチの重要性を示しました。
システム更改で押さえるべきは、すべてを一律に載せ替えるのではなく、対象範囲を層と機能で棚卸しし、保守期限の切迫度や利用頻度に応じて手法を使い分けることです。リホストで素早く退避すべき領域、リビルドで作り直すべき領域、リタイアすべき不要機能を見極めることで、コストとリスクのバランスが取れた更改が実現します。自社の更改を検討する際は、まず対象範囲の可視化から始め、領域ごとに最適な手法を割り当てる設計を進めていただければ幸いです。
株式会社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を創業。