情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#3R#역공학#재공학#재구조화#레거시#133회
最終更新 · 2026-09-30

ソフトウェア保守の3R（Reverse Engineering · Restructuring · Reengineering）

1. 概要

A. 定義

老朽化・複雑化したソフトウェアの保守性（maintainability）を高め、総所有コスト（TCO）を削減するために、既存システムを分析（リバースエンジニアリング）・改善（リストラクチャリング）・再構築（リエンジニアリング）する三つの代表的手法を総称する概念（3R）である。

3Rは互いに独立した別個の手法というよりも、「分析 → 改善 → 再構築」へと連なる一つの連続線（spectrum）の上に置かれた活動群である。リバースエンジニアリングが「このシステムが何を、どのように作られたのかを理解する」段階であるとすれば、リストラクチャリングは「理解したものを機能はそのままにより良く整理する」段階であり、リエンジニアリングは前の二つを含めて「作り直す」段階である。したがって三つの手法のうちリエンジニアリングが最も包括的であり、リバースエンジニアリングとリストラクチャリングを自らの部分工程（sub-process）として包み込む関係にあることをまず理解しないと、概念の階層が乱れてしまう。

この概念が一つにまとめて扱われる理由は、実務でレガシーに手を入れる際、この三つの活動がほぼ常に一緒に登場するからである。文書のないシステムはまずリバースエンジニアリングで構造を復元しなければならず、復元された構造はたいてい手を入れる箇所が多いのでリストラクチャリングが後に続き、プラットフォームまで変えなければならないならリエンジニアリングへと拡張される。すなわち3Rは、レガシー近代化という一つの目標に向けた強度（intensity）のスペクトルとして見ることができる — 最も軽い介入がリバースエンジニアリング、中間がリストラクチャリング、最も重い介入がリエンジニアリングである。

B. 登場背景および必要性

長く運用されたレガシー（legacy）システムは、担当人材が幾度も交代し設計文書が失われることで、システムの構造を完全に知る者が組織から消える状況に至る。ここに機能追加・緊急修正が長期間累積すると、コードの結合度（coupling）が高まり凝集度（cohesion）が下がり、いわゆる技術的負債（technical debt）が複利のように膨らむ。この状態では一行の修正すら予期せぬ副作用（ripple effect）を引き起こし、変更一件あたり回帰誤りを検証するコストが指数関数的に増加する。実際、ソフトウェアのライフサイクル総コストの相当部分（通常は半分以上と引用される）が開発以後の保守段階で発生するという点は、この問題の重さをよく示している。

とはいえシステム全体を取り払って新規開発（rewrite）へ進むと、数年間コードの中にのみ暗黙的に蓄積された業務ルール（ドメイン知識）が失われ、新旧システム並行運用に伴う危険とコストが非常に大きくなる。大規模な再作成プロジェクトがしばしば失敗したり日程を大きく超過したりする理由がここにある。3Rはこの二つの極端（放置 vs 全面再作成）の間で、既存資産を最大限再活用しながら危険とコストを制御可能な水準に下げる折衷案を提供する。今日、オンプレミスのレガシーをクラウド・マイクロサービス（MSA）へ移すレガシー近代化（Legacy Modernization）の流れの中で、3Rはその中核的な実行手段として再び注目されている。

C. 特徴

3Rの第一の特徴は資産再活用性である。 三つの手法いずれも最初から作り直すのではなく既存のコード・データ・業務ルールを最大限に生かして使うので、検証済みのドメイン知識を保存しながら改善を成し遂げる。 第二の特徴は機能等価性の保存を前提とするという点で、リバースエンジニアリング・リストラクチャリングは見かけの機能をまったく変えず、リエンジニアリングも既存機能の保存を検証したうえでのみ向上を加える。 第三の特徴は連続的スペクトルであるという点である — リバースエンジニアリング・リストラクチャリング・リエンジニアリングは介入強度が次第に大きくなる段階であり、問題の性格に合わせて必要な強度だけを選択または組み合わせて適用する。

2. 3Rの全体構造と区分基準

3Rを正確に使うには、三つの手法が抽象度（level of abstraction）の上でどのように移動するかで区分するのが最も明快である。ソフトウェアは要求 → 設計・仕様 → 実装（コード）という抽象化の階段を持つが、各手法はこの階段の上で互いに異なる方向へ動く。

flowchart LR
  L["レガシーSW(コード・成果物)"] --> RE["Reverse Engineering(RE)"]
  RE --> RS["Restructuring(RS)"]
  RS --> RN["Reengineering(RN)"]
  RN --> N["近代化されたSW"]
  RE -. "上位仕様の復元" .-> SPEC["設計・仕様"]
  SPEC -. "順工学で再実装" .-> RN

リバースエンジニアリングは実装（コード）から設計・仕様という上位概念へ遡るボトムアップ（bottom-up）活動である。 コードを読んでその中に含まれるデータ構造・制御フロー・業務ルールを図表や仕様として蘇らせることが目的であり、システムの見かけ上の動作はまったく変えない。 文書のないレガシーを扱う際に必ず経なければならない「理解の出発点」であり、後に続くすべての改善の正確さを決める。

リストラクチャリングは抽象度を移さず同じ階層の中で表現（representation）だけを改善する活動である。 たとえばコード層にとどまってスパゲッティコードをモジュールに分けたり、データ層にとどまって正規化が崩れたスキーマを整えたりする具合である。 見かけの機能は同一に保ちつつ内部品質だけを引き上げることが核心なので、その効果は即時の機能ではなく以後の変更コストの削減として現れる。

リエンジニアリングはリバースエンジニアリングで上位仕様を復元したのち、その仕様を改善し再び順工学（forward engineering）で実装まで下りてくる「ボトムアップ → トップダウン」の往復活動である。 三つの手法のうち唯一、見かけの機能・品質・プラットフォームまで変えることができ、それだけ範囲と危険が大きい。 したがってリエンジニアリングは「なぜ今再構築すべきか」に対するビジネス上の正当化が先行しなければならない最も重い介入である。

手法 主目的 見かけの機能変化 抽象度の移動方向 代表的成果物
リバースエンジニアリング 設計・仕様の抽出（理解） なし 上向き（コード→設計） 復元された設計図・データモデル
リストラクチャリング 構造・可読性・複雑度の改善 なし 同一水準 改善されたコード・スキーマ
リエンジニアリング 再構築・品質・プラットフォーム向上 ありうる 上向き→下向き（往復） 再構築されたシステム

表に見るように三つの手法を分ける二つの軸は、「見かけの機能を変えるか」と「抽象化の階段の上でどこへ移動するか」である。この二つの問いに答えれば、どの状況でどの手法を使うべきかが自然に決まる。

3. 各手法の深い理解

A. リバースエンジニアリング

リバースエンジニアリングはソースコード・実行バイナリ・データベース・画面など、すでに作られた成果物から設計と仕様を抽出・復元する活動である。本来、製造業で完成品を分解して設計を突き止めていた概念をソフトウェアに持ち込んだもので、核心は「作ること」ではなく「理解すること」にある。したがってリバースエンジニアリングはシステムの動作を決して変えず、ひたすら知識を蘇らせることに集中する。

リバースエンジニアリングの対象は大きくコードの観点とデータの観点に分かれる。コードの観点では制御フローグラフ・呼び出し関係・クラス図を復元し、データの観点では物理スキーマから論理データモデル（ERD）を蘇らせる。実務では静的分析（コードを実行せず構造を分析）と動的分析（実行ログ・プロファイリングで実際の流れを観察）を併用して正確さを高める。たとえば20年前のCOBOL基幹系システムを扱う際、静的分析だけでは実際にどの分岐が生きているのか分かりにくいので、運用ログに基づく動的分析で「デッドコード（dead code）」を識別する。

リバースエンジニアリングが重要な理由は、レガシー近代化の成否が「どれだけ正確に理解したか」に左右されるからである。理解が不十分なら後に続くリストラクチャリング・リエンジニアリングが誤った前提の上に築かれ、元の機能を損なう。近年は大規模言語モデル（LLM）ベースのコード要約・説明ツールがリバースエンジニアリングの理解速度を大きく引き上げているが、自動復元の結果には誤りが混じりうるので、必ず人の検証が伴わなければならない。

B. リストラクチャリング

リストラクチャリングは外部から見える機能・動作をそのまま保ちつつ内部のコード・構造・表現だけを改善する活動である。目的は可読性・モジュール性を高め循環的複雑度（cyclomatic complexity）と重複を下げ、以後の変更をより容易かつ安全にすることにある。「今すぐ新しい機能を与えること」ではなく「今後の変更コストを下げること」がリストラクチャリングの価値なので、その効果は即時の売上ではなく保守生産性として現れる。

リストラクチャリングの典型的な作業には、長い関数を意味単位に分割すること、重複ロジックを共通モジュールへ抽出すること、深くネストした条件文を平坦化すること、マジックナンバーを定数化することなどがある。データ面では非正規化で絡んだテーブルを正規化したり参照整合性制約を復元したりする作業がここに該当する。重要な前提はリストラクチャリング前後で見かけの動作が完全に同じでなければならないという点であり、それを保証する安全装置が回帰テストである。テストの不足したレガシーではリストラクチャリングに先立って特性化テスト（characterization test）をまず確保し、現在の動作を「固定」してから手を入れるのが定石である。

リストラクチャリングはしばしばリファクタリングと混同されるが、両者は階層が異なる。リストラクチャリングはコード・データ・アーキテクチャを包括する広い概念であり、リファクタリングはそのうちソースコード水準で小さな単位で反復適用する実践技法である。たとえば大型銀行システムで「決済モジュールを階層構造に再編する」ことはリストラクチャリングであり、その過程で個々の関数を分割し名前を変えることはリファクタリングである。

C. リエンジニアリング

リエンジニアリングはリバースエンジニアリング + 改善 + 順工学を一つに結合してシステムを再構築する最も包括的な活動である。まずリバースエンジニアリングで既存システムの設計と業務ルールを復元し、復元された仕様から欠陥・重複・古い設計を除去して改善したのち、改善された仕様をもとに新しいプラットフォーム・言語・アーキテクチャに合わせて順工学で再実装する。この過程で見かけの機能が向上したりプラットフォームがまるごと変わったりしうる点が、リストラクチャリングと決定的に異なる。

リエンジニアリングの強みは、蓄積されたドメイン知識を保存しながらもシステムを根本的に改善できる点にある。たとえばメインフレームのCOBOL基幹系をJavaベースのWebシステムへ移すプロジェクトは、画面とデータを最初から想像し直すのではなく既存の業務ルールをリバースエンジニアリングで確保したうえでそのルールを新しいプラットフォームに再実装するリエンジニアリングの典型である。こうすれば「何を計算すべきか」という検証済みの知識を保ちながら技術スタックだけを近代化できる。

ただしリエンジニアリングは三つの手法のうち範囲と危険が最も大きいので、何をどこまで変えるかについての明確な目標設定と段階的移行戦略が必須である。よく使われる方式はシステムを一度に置き換えるビッグバン（big-bang）ではなく、機能単位で新規システムへ漸進移管しながら旧システムの前段に中継層を置くストラングラーフィグ（Strangler Fig）パターンである。この方式は移管中もサービスを止めず、問題が生じれば当該機能だけをロールバックできるので危険を大きく下げる。

4. リエンジニアリングのプロセスと関連概念

リエンジニアリングが三つの手法をどのように一つの流れへ織り込むかは、次のプロセス図で見ることができる。

flowchart TD
  A["分析・リバース(現行構造・業務ルール復元)"] --> B["改善・リストラクチャ(設計欠陥・重複除去)"]
  B --> C["変換・順工学(新プラットフォーム再実装)"]
  C --> D["テスト・移行(回帰検証・並行運用)"]
  D --> E["運用反映・安定化"]
  D -. "機能不一致の発見" .-> A

リエンジニアリングはまず分析・リバースエンジニアリングで既存システムの構造と業務ルールを復元し、改善・リストラクチャリングで設計欠陥と重複を除去し、変換・順工学で新しいプラットフォーム・構造に合わせて再実装したのち、テスト・移行で既存機能が保存されたかを検証し運用に反映する。 この流れで最も重要な統制点は最後のテスト段階である。 再構築以後も元の機能が同一に動作することを回帰テスト（regression test）で必ず確認しなければならず、機能不一致が発見されれば分析段階へ戻る反復構造を持つ。 実務では新旧システムに同じ入力を与えて出力を比較する並行運用（parallel run）でこの検証を大規模に行い、計算結果が最小単位まで一致したときに初めて旧システムを廃棄する。

3Rは隣接概念としばしば混同されるので関係を整理しておく必要がある。特に順工学・マイグレーション・リファクタリングが3Rのどこに位置するかを知れば概念が明快になる。

概念 説明 3Rとの関係
Forward Engineering(順工学) 仕様 → 設計 → 実装の順方向開発 リエンジニアリングの最後の工程
Migration(移植) プラットフォーム・言語・DBを別環境へ移す リエンジニアリングの一形態・部分
Refactoring(リファクタリング) 外部動作を保ちつつ内部構造を改善 リストラクチャリングをコード単位で実践

リファクタリングはリストラクチャリングの概念をソースコード水準で小さな単位で反復適用する実践技法であり、マイグレーションはリエンジニアリングの過程で対象環境（プラットフォーム・言語・DB）を変える特殊事例と見ることができる。したがって「マイグレーションした」という言葉はおおむねリエンジニアリングの一部を遂行したという意味であり、「リファクタリングした」という言葉はリストラクチャリングを局所的に実践したという意味になる。

このように隣接概念を3Rの座標の上に位置づければ実務の対話の混乱を減らせる。 現場で「リエンジニアリング」と「リライト（rewrite）」が入り混じって使われる場合が多いが、リライトは既存資産を捨てて最初から作るものなので、資産再活用を前提とする3Rとは志向が異なる。 技術士は提案・設計文書でこれらの用語を正確に区別して使うことで、プロジェクトの範囲・危険・コストに対する利害関係者の期待を最初から整合させなければならない。

5. 手法選択の基準と適用事例

三つの手法のうち何を適用するかは流行ではなく問題の性格と目標で判断しなければならない。 「構造を誰も知らない」が問題ならリバースエンジニアリングが先であり、「構造は分かるが手を入れるのが怖い」が問題ならリストラクチャリングであり、「プラットフォーム自体が寿命を終えた」が問題ならリエンジニアリングが答えになる。 すなわち診断なしにいきなりリエンジニアリングへ飛び込むのは、病の原因を知らずに大手術を敢行するのと同じである。

判断を助けるには三つの信号を見る。 第一は変更頻度で、頻繁に変わるモジュールほどリストラクチャリング・リエンジニアリングの投資回収が早い。 第二は欠陥密度で、特定のモジュールに障害が集中するなら、その部分が優先的な改善対象である。 第三は人材の理解度で、誰も理解できない領域はリバースエンジニアリングで知識をまず復元しなければならない。 この三つの信号がすべて高いモジュールが3R投資優先順位の最前列に置かれる。

具体例として、ある流通社の精算バッチが毎月締めのたびに数時間ずつ遅延し、担当者が退職して誰もロジックを説明できない状況を想定しよう。 このときいきなり再作成に着手すれば検証されていない精算ルールが失われる危険が大きい。 正しい順序はまずリバースエンジニアリングでバッチの計算ルールとデータフローを復元して仕様として残し、特性化テストで現在の算出値を固定したのち、ボトルネックとなる反復照会ロジックをリストラクチャリングし、必要ならバッチエンジン自体をリエンジニアリングで置き換えることである。 このように段階を踏めば「月次締め遅延数時間」という見かけ上の症状の背後にある根本原因を安全に除去できる。

もう一つの事例として、特定の言語・ランタイムのサポート終了（End of Support）が迫ったシステムはセキュリティパッチが途絶えるので、リエンジニアリングが事実上強制される。 この場合は機能改善よりも「等価機能をサポートされるプラットフォームで再現する」ことが第一目標となり、ここでもリバースエンジニアリングで確保した仕様と回帰テストが移行の安全弁の役割を果たす。 結局、三つの手法は状況に応じて単独でも組み合わせても使われるが、共通して「理解 → 検証 → 改善」の順序を守らなければ失敗しない。

6. 深化：クラウド近代化戦略との連携および最新動向

3Rは近年クラウド移行の議論と出会い、より広い実行戦略へと拡張された。クラウドマイグレーションで広く引用される6R/7Rフレームワーク（Rehost・Replatform・Refactor・Rearchitect・Rebuild・Replace、およびRetain・Retireを加えた拡張）は事実上「レガシーをどれだけ深く手を入れるか」のスペクトルであり、このうちRefactor・Rearchitect・Rebuildが3Rのリストラクチャリング・リエンジニアリングと直接接する。たとえばサーバだけをクラウドへ移すRehost（lift-and-shift）は3Rをほとんど使わないが、アプリケーション構造をコンテナ・MSAに合わせて再編するRearchitectはリバースエンジニアリング・リストラクチャリング・リエンジニアリングをすべて動員する。

実務適用事例として、国内外の金融・公共機関の次世代システム構築は大半がメインフレーム基幹系のリエンジニアリングプロジェクトである。数百万行規模のCOBOL資産をJava・クラウドへ移しながら、自動変換ツールで一次コードを生成したのち人が業務ルールを検証・訂正する方式が標準化されている。このとき並行運用期間に新旧システムの計算結果がウォン（₩）単位まで一致するかを突合（reconciliation）することが移行成功の関門となる。

最も注目すべき最新動向はAIベースのコード分析・自動変換の拡散である。LLMベースのツールはリバースエンジニアリング段階で見慣れないコードの意図を要約し、リストラクチャリング段階でリファクタリング候補を提案し、変換段階でレガシー言語を現代言語へ移す下書きを作ってくれる。これにより人がコードを読んで理解するのにかかる時間が大きく減るのは明確な利点である。ただし自動変換の結果には微妙な意味の誤りや幻覚（hallucination）が混じりうるので、テストに基づく検証と人の最終確認を必ず経てこそ品質を担保できる。技術士の観点ではAIを「理解・下書き生成の加速器」として位置づけつつ、正確さの最終責任は依然として検証体系に置くという均衡が求められる。

7. 考慮事項および示唆点

技術士の観点から3Rの成否は結局「何を、なぜ、どこまで手を入れるか」の判断にかかっている。次の四つを戦略的に考慮しなければならない。

  • 対象の優先順位付け（トレードオフ）：すべてのレガシーをリエンジニアリングできるわけではない。保守コスト・ビジネス重要度・技術的負債の水準・変更頻度を軸にポートフォリオを評価し、費用対効果の大きいシステムから手を入れなければならない。変更がほとんどなく安定したシステムはむしろRetain（維持）が合理的でありうる。
  • 機能保存の保証体系：3Rの最大の危険は再構築の過程で検証されていない業務ルールが失われることである。したがって特性化テストで現行動作を固定し、回帰テスト・並行運用・結果突合で機能等価性を立証する安全網を事前に構築しなければならない。
  • 漸進的移行戦略：ビッグバン移行は危険が大きいので、ストラングラーフィグパターンのように機能単位で漸進移管し問題時にロールバック可能な構造を選ぶのが望ましい。これはサービス連続性と危険統制を同時に達成する。
  • 近代化戦略およびAI活用との連携：3Rはクラウド・MSA移行（6R/7R）の実行エンジンであり、AIベースの分析・変換ツールでリバースエンジニアリング・変換の効率を大きく高められる。ただし自動化の結果は必ず検証を前提とし、ドメイン知識を知る人材の参加を維持してこそ近代化の品質と持続可能性が確保される。

一言まとめ: 3Rは*リバースエンジニアリング（設計抽出）・リストラクチャリング（構造改善）・リエンジニアリング（再構築）*へと連なるレガシー改善のスペクトルであり、抽象度の移動方向と機能変化の有無で区分され、対象の優先順位付け・回帰テストに基づく機能保存・漸進的移行を前提としてクラウド・MSA近代化（6R/7R）とAI自動化の中核的実行手段となる。