システムのモダナイゼーションの選定ポイント/選び方/種類

システムのモダナイゼーションを検討し始めると、リホストで様子を見るべきか、思い切ってリビルドに踏み切るべきか、判断材料が定まらずに検討が長引くことがあります。対象システムの重要度と現状の技術的負債の大きさを軸に、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つのアプローチから最適な組み合わせを選び取る進め方が、システムのモダナイゼーションの選び方の基本です。

本記事では、着手前に整理すべき自社の課題、5つのアプローチを評価軸で選び分ける考え方、対象領域の優先順位の付け方、自動変換ツールや開発パートナーの選定、PoCと移行判定の進め方を解説します。これから対象システムと手法の組み合わせを検討する担当者の方が、比較検討の土台を具体的に組み立てられる内容です。

モダナイゼーション着手前に整理すべき自社システムの課題

最初に行うべきは、手法を選ぶことではなく、対象システムのどこに問題が集中しているかを特定することです。保守コストの高さ、改修リードタイムの長さ、技術者確保の難しさ、性能や可用性の限界のうち、何が最も深刻かによって、優先すべきアプローチは変わります。

現状の保守運用費のうち、レガシーシステムにどれだけの予算が割かれているか、IT予算全体に対する比率を確認します。IPA「DXレポート」が指摘するように、多くの企業でIT予算の8〜9割以上がレガシーシステムの維持管理費に消費されているとされており、この比率が高いほど、新しい取り組みへ投資する余力が乏しくなっている可能性があります。あわせて、直近の改修案件で影響範囲の調査にどれだけの工数がかかったかを振り返ると、技術的負債の大きさを具体的に把握できます。

特定の言語や環境に精通した技術者が退職した場合に、保守を引き継げる体制があるかを確認します。仕様書が実態と一致しているか、コードを読み解ける人が一人に限られていないかは、リファクタリングやリビルドの緊急度を判断する材料になります。属人化が進んでいるほど、現状維持のリスクは大きいと考えられます。

性能や可用性の限界も見落とせない診断項目です。処理件数やアクセス数が当初の設計を上回り、夜間バッチが翌営業日の開始時刻に食い込むようになっていないか、障害発生時の復旧にどれだけの時間がかかっているかを確認します。これらの兆候が複数当てはまる場合は、単発の改修では解決しない構造的な課題である可能性が高く、モダナイゼーションの優先度を上げて検討すべきサインになります。

5つのアプローチ(5R)を評価軸で選び分ける方法

リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースは、期間・費用・効果の大きさがそれぞれ異なります。目的と制約条件に応じて、どの軸を重視するかを明確にしたうえで手法を選びます。

リホストは既存のコードやデータ構造を変更しないため、数か月程度と最も短期間で完了できる可能性があります。サポート終了(EOS)への対応など、期限が迫っている場合に適した選択肢です。リプラットフォームはOSやデータベースのマネージドサービス化を伴うため目安として4〜10か月程度、ビジネスロジックの内部構造まで整理するリファクタリングは8〜18か月程度、既存資産を廃棄して作り直すリビルドは12〜30か月以上と、対象領域を絞らない限り長期化しやすくなります。リプレースは自社開発が不要な分、期間を短縮しやすい一方、Fit to Standardのための社内調整やデータクレンジングに想定以上の時間がかかることがあります。

リホストは短期間で着手できる分、コード内部の技術的負債やアーキテクチャの制約は温存されるため、抜本的な保守性向上効果は限定的です。反対にリビルドは、柔軟性・拡張性・耐障害性を最大化できる可能性がある一方、初期投資と期間が最大になり、Kubernetesなど新しい運用基盤を扱えるスキルが組織になければ、稼働後に運用が破綻するリスクも高まります。効果の大きさだけでなく、自社が運用しきれる複雑さかどうかも選定の重要な軸になります。

リプラットフォームとリファクタリングは、この両極の中間に位置づけられます。リプラットフォームはデータベースのマネージドサービス化などによって運用負荷を一定程度下げられますが、アプリケーションの内部設計そのものは変わらないため、将来的な機能拡張のしやすさまでは改善しません。リファクタリングは内部構造を整理する分、リプラットフォームより保守性の向上効果は大きくなりますが、既存の挙動を壊さないための回帰テスト設計に相応の期間を要します。中間的な手法を選ぶ際は、どの効果を優先し、どの効果を次のフェーズに先送りするかを事前に合意しておくと、後戻りが少なくなります。

対象領域のビジネス価値とROIで優先順位を判断する

全システムを同じ手法で刷新する必要はありません。対象領域が自社の競争力にどれだけ直結しているかを軸に、投資規模と手法を使い分けることが、限られた予算を有効に使う考え方です。

新機能投入のスピードやスケーラビリティが事業競争力に直結する「コアシステム」領域では、リビルドのような抜本的な刷新に投資する価値があります。一方、総務・人事・会計などのバックオフィス業務や、他社と差別化しにくいコモディティ領域では、大規模な投資に見合うリターンを得にくく、SaaSやパッケージへのリプレースの方が投資対効果に優れることが一般的です。

対象領域が複数ある場合は、業務への影響が小さく、効果を測定しやすい領域から着手する優先順位づけが有効です。最初の対象で得られた知見や自動変換ツールの精度検証結果を、後続の対象へ生かせるため、着手順そのものがリスクコントロールの一部になります。

優先順位を決める際は、担当部門の意見だけに頼らず、実際の取引件数やアクセスログ、障害発生履歴といった定量データを併用します。声の大きい部門の要望を優先すると、実際には影響が限定的な領域から着手してしまい、対外的に説明しづらい優先順位になることがあります。経営層への説明責任を果たすうえでも、事業インパクトを数値で示せる形に整理しておくことが望ましいといえます。

自動変換ツール・自社開発・SIerの選び方

リファクタリングやリビルドを進める体制には、自動変換ツールを活用する方法、自社エンジニアが読み解いて再設計する方法、外部のSIerやベンダーに委託する方法があり、対象システムの特性によって適した組み合わせが変わります。

COBOLなど特定言語の資産を自動変換ツールでJavaなどへ書き直す手法は、既存のビジネスロジックを踏襲できるため、リビルドに比べて短期間・低コスト(場合によっては半分程度)で移行できるケースがあります。ただし、言語仕様の違いによる細かな不具合の対応が必要になるほか、非効率な業務プロセスそのものは引き継がれるため、抜本的な業務改善までは期待しにくい点に注意が必要です。

メインフレーム上のCOBOL資産に強みを持つ会社、クラウドネイティブな再設計を得意とする会社、業務要件の分析から伴走する会社など、支援会社によって強みは異なります。見積もり金額だけで比較するのではなく、類似規模・類似言語での実績、変換後のテスト体制、稼働後の保守体制まで含めて確認することが重要です。

体制を検討する際は、移行が完了した後の保守フェーズも視野に入れておく必要があります。移行プロジェクトの間だけ外部の専門家を確保できても、稼働後の恒常的な保守を誰が担うかが決まっていなければ、数年後に同じ属人化の課題が再発します。プロジェクト単位の契約なのか、稼働後の保守運用まで含めた契約なのかを、体制検討の初期段階で整理しておくことが望ましいといえます。

PoC・移行判定・機能等価性検証の進め方

システムのモダナイゼーションのPoCは、関係者の合意形成という側面と、新しい技術・手法で本当に業務が動くかを見極める技術検証という側面を併せ持ちます。段階を踏んで検証範囲を広げることが、移行判定の精度を高めます。

最初に現状システムの構造・依存関係・データモデルを可視化したうえで、影響範囲が限定的な業務領域を「パイロットプロジェクト」として選び、PoCを実施します。この段階で、リライト(自動変換)とリビルドのどちらが適しているかを見極める移行判定を行います。

自動変換ツールを一部のコードに適用し、変換率や処理速度、正確性をPoC環境で検証します。新システムが旧システムと同じ処理結果を返すかどうかを証明する「機能等価性(回帰検証)」は、モダナイゼーションのPoCで最も難易度が高い工程とされ、本番データを使った検証スクリプトの自動生成・実行を支援する機能を持つツールも登場しています。

PoCの後も、新旧システムを実データで一定期間並行稼働させ、本番相当の負荷下での挙動を確認する工程を設けます。ここでも、一括で切り替えるのではなく、影響の小さい範囲から段階的に本稼働へ移すインクリメンタル方式を徹底することが、納期とリスクのコントロールにつながります。

並行稼働の期間は、対象システムの重要度に応じて長さを調整します。決算処理や基幹の取引処理のように誤りが許されない領域では、月次・四半期といった業務サイクルを一巡させてから完全移行に踏み切る慎重さが求められます。反対に、周辺的な業務システムであれば、並行稼働の期間を短く設定し、得られた知見を次の対象へ早く展開する判断も選択肢になります。

スケジュールとリスクの見積もり方

見積もりの精度を高めるには、ベンダーへの支払額だけでなく、社内工数や並行稼働のコスト、教育研修費まで含めた実質的な総費用で検討する必要があります。

限定的な範囲のマイクロサービス化を伴うリビルドでは、ベンダーへの支払額が2,000万〜8,000万円程度、主要サブシステム全体を対象にする場合は3,000万円〜2億円程度になることがあります。ただし、これはベンダーへの支払額に過ぎず、社内担当者の工数、並行稼働期間中の二重運用コスト、運用担当者の教育研修費などを含めると、実質的な総費用はベンダー見積もりの1.3〜1.5倍程度を見込んでおくと、後からの予算超過を防ぎやすくなります。

大規模なグローバルERP刷新においても、価値のまとまりごとに分割して段階移行する「トランシェ方式」を採用し、大規模な移行でありながら約12か月で本稼働にこぎつけた事例があります。一方、数千万ステップ規模のCOBOL資産を自動変換ツールでJavaへ書き換えた事例では、規模の大きさから完了までに4年半を要しています。自社の対象規模がどちらに近いかを踏まえてスケジュールを見積もることが重要です。

両事例に共通するのは、規模の大きさに関わらず、対象を意味のあるまとまりに分割してから着手している点です。分割の単位を業務価値や依存関係で区切れば、途中で優先順位を見直す必要が生じても、他の分割済みの領域への影響を抑えられます。逆に分割の単位が曖昧なまま着手すると、進捗の可視化自体が難しくなり、経営層への状況報告のたびに説明の手間が増える結果になりがちです。

システムのモダナイゼーション導入前に確認しておきたいポイント

手法選定の途中で判断に迷いやすい論点を整理します。

対象システム全体を一つの手法で統一する必要はありません。コア業務はリビルド、周辺のバックオフィス業務はリプレース、といったように、領域ごとに異なるアプローチを組み合わせる進め方が一般的です。

特定ベンダーの自動変換ツールに強く依存すると、将来の追加改修や別ツールへの切り替えが難しくなることがあります。変換後のコードが標準的な形式で保守できるか、ドキュメントとして残るかを契約前に確認しておくと安心です。

依存度を下げる工夫としては、変換後のコードレビューを自社エンジニアも交えて行い、変換ロジックの考え方を理解しておくことが挙げられます。ツール任せで受け取るだけでなく、なぜそのように変換されたのかを把握しておけば、次回以降の改修や、将来別のパートナーへ引き継ぐ際にも対応しやすくなります。

クラウドへ移行しただけでコストが自動的に下がるわけではありません。オンプレミス時代の構成をそのまま引き継ぐと、期待した削減効果が得られないことがあるため、稼働前からFinOpsや性能監視の設計を組み込み、稼働後も継続的にリソースを見直す体制を計画に含めます。

まとめ

システムのモダナイゼーションの選定では、保守コスト・変更リスク・技術者への依存度から自社の課題を特定し、対象領域のビジネス価値に応じてリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースを組み合わせることが基本になります。期間と費用の見積もりは、ベンダー支払額だけでなく社内工数まで含めた実質総費用で行い、PoCでは移行判定と機能等価性の検証まで一気通貫で確認することが重要です。

リビルドが理想に見えても、運用体制が追いつかなければ稼働後に破綻するリスクがあります。反対にリホストだけで終わらせると、技術的負債が温存されたままになります。自社が扱いきれる複雑さと、解決したい課題の大きさのバランスを取ることが、選定の本質です。

自動変換ツールやクラウドサービスにどのような選択肢があるかは、システムのモダナイゼーションのパッケージ・クラウド製品一覧で紹介しています。既製のツールやSaaSでは吸収しきれない業務ロジックの分析や、段階移行を前提にした個別設計が必要な場合、riplaはフルスクラッチ開発の立場から、現状システムの分析からアーキテクチャ設計、既存システムとの連携までを支援しています。

株式会社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を創業。