アプリケーションのモダナイゼーションの対象範囲と標準的な手法(リホスト/リプラットフォーム/リファクタリング等)の一覧について

アプリケーションのモダナイゼーションでは、インフラ・アプリケーション・データ・運用の4層から対象範囲を定めたうえで、機能ごとに移行の速さや刷新の必要性に合わせて7Rなどの手法を選びます。

手法選定の全体像は、アプリケーションのモダナイゼーションの完全ガイドもご覧ください。

▼全体ガイドの記事
・アプリケーションのモダナイゼーションの完全ガイド

アプリケーションのモダナイゼーションの対象範囲

近代化の対象をインフラ層、アプリケーション層、データ層、運用層の4層に分けた図。
課題のある層を見極めると、手法を選ぶ範囲が定まります。

手法を理解する前に、何を近代化の対象とするのかを整理しておきます。近代化の対象には、ソースコードのほかに、インフラ・アーキテクチャ・データ・運用も含まれます。

どの層に課題があるかによって選ぶべき手法が大きく変わるため、対象範囲を先に押さえておくことが大切です。

対象となる4つの層(インフラ・アプリ・データ・運用)

対象は、インフラ・アプリケーション・データ・運用の4層です。各層で近代化する範囲を定めることが、手法選定の出発点になります。

  • インフラ層:オンプレミスのサーバーやメインフレームを、クラウドへ移行する対象です。
  • アプリケーション層:ソースコードの構造、プログラミング言語、アーキテクチャの刷新。
  • データ層:データベースの移行と、必要に応じたデータモデルの再設計。
  • 運用層:CI/CDの整備と、監視・自動化の仕組みの導入。

データ層では、独自形式や古いDBへの依存が移行の難所になりがちです。そのため、アプリケーション層も含めて、課題のある層と手を入れる深さを見極めることが求められます。

ポートフォリオアプローチという考え方

ポートフォリオアプローチでは、システムを構成要素ごとに分類し、重要度や変更頻度に合わせて手法を割り当てます。

  • 変更が多い顧客向け機能:リファクタリングで作り変える選択肢があります。
  • 変更が少ない安定機能:刷新せず、リテインで維持する方法です。

すべてを一度にリビルドしようとすると、費用も期間も膨大になり、リスクも跳ね上がります。一方で、すべてを単純にリホストすると、レガシーな構造が温存され、クラウドの恩恵を十分に得られません。

そこで、資産を洗い出し、ビジネス上の重要度と技術的負債の大きさで分類したうえで、機能ごとに手法を割り当てます。このポートフォリオの設計こそが、アプリケーションのモダナイゼーションにおける対象範囲の本質です。

ポイント

対象範囲は、課題のある層と、機能ごとの重要度や変更頻度を組み合わせて決めます。手法は層ごとではなく機能ごとに割り当てる、と考えておくとよいでしょう。

標準的な手法の一覧:AWSの7R

AWSの7Rは、既存システムをクラウドへ移行・刷新する際の7つの手法です(出典:Amazon Web Services)。各手法の定義と使い分けを、次の見出しから順に見ていきます。

リホスト・リロケート・リプラットフォーム

これらは比較的軽量な移行手法で、変更の範囲とクラウド最適化の度合いが手法ごとに異なります。

  • リホスト(Rehost):アプリケーションをほぼ変更せずクラウドへ移す「リフト&シフト」で、費用の目安は数百万〜1,000万円台、期間は3〜6ヶ月です。
  • リロケート(Relocate):仮想化環境を、コンテナやハイパーバイザー単位で別のクラウド基盤へ移す方式です。
  • リプラットフォーム(Replatform):コードを大きく書き換えず、DBをマネージドサービスに置き換えるなど、一部だけを最適化します。

リパーチェス・リタイア・リテイン

自社開発を維持する必要があるか、利用状況はどうかによって、乗り換え・廃止・現状維持のいずれかを選びます。

  • リパーチェス(Repurchase):自社開発システムを廃止し、SaaSやパッケージ製品へ乗り換えます。
  • リタイア(Retire):使われていない、または役割を終えたシステムを廃止し、不要な資産を整理する方式です。
  • リテイン(Retain):刷新せずに現状を維持する選択で、安定稼働し変更が不要な機能を残す場合に使います。

会計や人事などの汎用業務では、市販製品へ乗り換えることで保守の負担を減らせる場合があります。7Rには「作る」だけでなく「やめる」「残す」の判断も含まれます。そのため、資産を洗い出して各機能の必要性を見極めます。

ポイント

手法は、移行の速さ、クラウドの利点を取り入れる度合い、事業上の重要度で選びます。汎用業務は乗り換えや廃止を、保守の負担が大きい機能は作り直しを候補にするとよいでしょう。

アプリ層の作り変え:リファクタリングとリアーキテクト

クラウドネイティブ化に関わる要素として、独立サービス、環境差異の抑制、CI/CDによる継続的なリリースを並べた図。
機能の分割と環境・リリースの整備が構造の見直しを支えます。

7Rの中で、アプリケーション層を最も抜本的に近代化するのが「リファクタリング/リアーキテクト(Refactor)」です。これは、クラウドの能力を最大限に引き出すために、アプリケーションの構造そのものを作り変える手法です。

費用も期間もかかります。ただし、得られる効果は最大で、DX文脈で「クラウドネイティブ化」と呼ばれる取り組みの中核を担います。アプリケーションの構造そのものに手を入れる手法なので、中身まで掘り下げて理解したうえで選ぶことが大切です。

モノリスからマイクロサービスへの分割

モノリスでは、機能が一つのプログラムに密結合しているため、小さな改修でもシステム全体への影響を確認しなければなりません。リアーキテクトでは、業務機能ごとに独立したサービスへ分割します。

マイクロサービス化すると、次のような運用が可能になります。

  • 個別の開発・デプロイ・スケール:特定の機能だけを改修したり、負荷の高い機能だけを増強したりできます。
  • 変更への対応:新機能のリリースリードタイムを短縮し、ビジネスの変化に対応しやすくなります。

マイクロサービス化には、設計上の留意点もあります。特に、分割しすぎるとサービス間の連携が複雑になります。そのため、業務の境界(ドメイン)に沿って粒度を決め、ストラングラーパターンで一部の機能から段階的に切り出します。

コンテナ化とクラウドネイティブ化

コンテナ化は、アプリケーションと実行環境をまとめてパッケージ化する方法です。DockerやKubernetesなどが使われます。

  • 環境差異を抑える:開発環境と本番環境をそろえ、「自分の環境では動いたのに本番で動かない」という問題を防ぎます。
  • 需要に応じて拡張する:負荷に応じたスケールアウトやリソースの増減が容易になります。

マネージドサービスやサーバーレス技術を組み合わせると、インフラ運用の手間を減らせます。また、クラウドネイティブ化では、保守費の削減に加えて、CI/CDによる継続的なリリースや障害時の自動復旧も可能になります。

単なるクラウド移行との違いは、アプリケーションと運用の構造まで見直す点にあります。

ポイント

リファクタリングは費用も期間もかかるため、変更の多い中核機能に絞って検討するとよいでしょう。分割の粒度は業務の境界に沿って決め、コンテナ化は環境差異を抑える目的で併せて考えます。

手法ごとの費用・期間と選び方の指針

クラウド移行型の数百万〜1,000万円台・3〜6ヶ月程度と、再構築型の2,000万〜数千万円規模・12〜18ヶ月以上を左右に比較した図。
再構築型は費用・期間ともに大きな投資目安です。

手法の優劣は一律には決まりません。目的・予算・リスク許容度を踏まえて、機能ごとに選ぶことになります。

クラウド移行型と再構築型の費用・期間目安

クラウド移行型と再構築型では、費用・期間の目安が異なります。

  • クラウド移行型:リホストやリプラットフォームは、数百万〜1,000万円台・3〜6ヶ月程度が目安です。
  • 再構築型:リファクタリングやリビルドは、2,000万〜数千万円規模・12〜18ヶ月以上を見込みます。

システム規模で見ると、単一業務システムの刷新は3,000万〜1.5億円、基幹システムに複数の周辺システムを含む大規模な刷新は1.5億〜5億円が一般的な相場です。

費用の内訳では、SI費(システムインテグレーション費用)が全体の60〜75%を占める点も押さえておくとよいでしょう。

再構築型は初期投資が大きい分、保守費の削減や業務スピードの向上という形で、中長期的に回収していく性質の投資です。

目的別の手法選定フロー

移行速度やクラウド活用度、事業上の重要度に応じて手法を選びます。

  • 早くクラウドへ移し、保守の限界を回避する:リホストが第一候補です。
  • クラウドの利点を取り入れつつコストを抑える:リプラットフォームが向いています。
  • 汎用業務で独自開発を維持する意味が薄い:リパーチェス(SaaS化)が候補に入ります。
  • 中核機能に俊敏な改修と拡張性が必要:リファクタリング・リアーキテクトによるクラウドネイティブ化。

投資は、ビジネス上の重要度に応じて機能ごとに集中させます。手法の組み合わせに迷う場合は、対象範囲の診断から手法の割り当てまで支援できるパートナーに相談できます。

手法選定でもう1つ意識したいのが「段階性」です。リホストで先にクラウドへ移し、運用しながら課題を見極める方法があります。その後、本当に作り変える機能だけをリファクタリングする二段階の進め方も有効です。

これにより、初期投資を抑えつつクラウドの基盤を先に確保でき、その後の近代化を着実に進められます。

手法は一度選んで終わりにせず、システムの成熟度や事業の優先順位に応じて見直していきます。時間をかけて組み替えることで、過大な投資や手戻りを避けやすくなります。

また、どの手法を選ぶ場合でも、移行は段階的に進めることが鉄則です。リアーキテクトの場合も、全機能を一度に切り替えず、ストラングラーパターンで一部から新しい構造へ置き換えて、安定を確認しながら範囲を広げます。

手法の選定と移行の進め方は、セットで考える必要があります。優れた手法を選んでも移行の設計が雑であれば、その効果は十分に発揮されません。

自社にとって最適な手法の組み合わせと、それを安全に実現する移行ロードマップの両方を描くことが、モダナイゼーション成功の条件です。

ポイント

再構築型は初期投資が大きいため、目的・予算・リスク許容度を踏まえて手法を選びます。段階的に進めるかどうかも、あわせて先に決めておくとよいでしょう。

まとめ

アプリケーションのモダナイゼーションの対象範囲と標準的な手法を、一覧で整理しました。

対象範囲はインフラ・アプリケーション・データ・運用の4層に分かれ、機能ごとに最適な手法を割り当てる「ポートフォリオアプローチ」が基本になります。

標準的な手法として AWSの7Rを紹介し、各手法を解説しました。7Rには、リホスト、リロケート、リプラットフォームがあります。さらに、リパーチェス・リファクタリング・リタイア・リテインも含まれ、全体で7つの手法になります。

アプリケーション層では、リファクタリングとリアーキテクトを掘り下げました。モノリスのマイクロサービス化とコンテナ化によるクラウドネイティブ化が中核で、この取り組みは俊敏性と拡張性を高めます。

費用・期間はクラウド移行型で数百万〜1,000万円台・3〜6ヶ月、再構築型で2,000万円以上・12〜18ヶ月以上が目安です。

重要なのは、ビジネス上の重要度に応じて手法を使い分けることです。一律に最新化するよりも、機能ごとの判断が大切になります。

自社に最適な手法の組み合わせを設計したい方は、対象範囲の診断から支援できる専門パートナーへの相談から始めてみてください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。