リバースエンジニアリングは、既存の製品やシステムを観察、測定、分析し、その構造や働きを理解する活動です。
仕様から実装へ進む開発とは逆に、実装されたものから設計に関する情報を取り出します。
ChikofskyとCrossの1990年の論文は、既存システムを理解する活動と、それを変更して作り直す活動を区別しています。

分かったことと推測を分ける

仮に、設計資料が十分に残っていない自社の業務ソフトを更新するとします。
画面、プログラム、保存されるデータ、実行時の動きを調べ、入力から処理結果までを対応させます。
データがどこを通るかという観察と、なぜその設計を選んだかという推測は別の情報です。
挙動を再現できても、当初の意図をすべて復元できたとは限りません。

調査の前には、更新、保守、互換性の確認など、何の判断に使うかを決めます。
すべてを詳しく調べるより、変更が必要な部分と、その周辺への影響を重点的に把握します。
観察した版、環境、入力条件、結果を記録すると、別の担当者が確かめ直せます。
例外処理や障害時の動きは、通常の操作だけでは見えないため、確認できた範囲を明示します。

理解から変更へ進むとき

得られた情報は、構成図、データの対応、接続条件、試験の条件などへ整理します。
その後に構造を変えたり、別の技術で作り直したりする場合には、改めて要求と設計を検討します。
既存製品の動きには、必要な仕様だけでなく、不具合や過去の制約も含まれる可能性があります。
観察した挙動をすべて次の製品へ引き継ぐのではなく、維持する理由を確認します。

分析できることと、取り出したコード、図面、名称などを利用できることも区別します。
対象の入手方法、契約、権利、利用する地域の条件に応じて、実施する調査と成果物の利用範囲を確認します。
これは他社製品の模倣だけを指す用語ではなく、自社製品の保守や移行でも使う技術的な活動です。
目的と調査範囲を絞り、裏付けのある知識へ整理することが成果になります。

関連する記事:製品アーキテクチャ、知的財産、具現化設計。