ITパスポート 令和5年度 問39：development_managementに関する問題

答えは c「リバースエンジニアリング」 です。

ふつうは『設計図→完成品』の順で作ります。でも今回は逆で、設計図（仕様書）がなくなったので、完成品（プログラム）を調べて設計図を作り直したんです。

この『完成品から逆向きにたどって中身や設計を明らかにする』ことをリバースエンジニアリングといいます。リバース＝『逆』という意味。

👉 覚え方：リバース＝『逆』。できあがったものから逆に設計図を作る！

ほかの選択肢：a コードレビュー＝書いたコードをみんなで点検／b デザインレビュー＝設計を点検／d リファクタリング＝動きを変えずに中身をきれいに書き直す。

なぜこれが正解か

正解は c。リバースエンジニアリングは、完成した製品やソースコードを解析して、その仕様・設計・構造を明らかにする手法。通常の『設計→実装』とは逆方向のアプローチで、本問の『仕様書がないのでソースコードから仕様書を作成する』がまさにこれにあたる。

各選択肢の解説

• a コードレビュー：作成したソースコードを他者が検証し、不具合や品質問題を発見する活動。
• b デザインレビュー：設計工程の成果物（設計書）を関係者で評価・検証する活動。
• d リファクタリング：外部から見た動作（機能）を変えずに、内部のコード構造を整理・改善すること。

覚え方・ひっかけ注意

『リバース＝逆＝完成品から設計をたどる』。逆に、既存仕様から新システムを再構築するのが『リエンジニアリング』。dリファクタリングは『動作を変えず中身を整える』で目的が異なる点に注意。

理論的背景

リバースエンジニアリング（Reverse Engineering）は、完成した製品・システム・プログラムを対象として解析を行い、その設計情報・仕様・動作原理・内部構造を導き出す技術的アプローチの総称である。通常のエンジニアリングが「要件→設計→実装→製品」という順方向であるのに対し、逆方向に「製品→実装の解析→設計の復元→仕様の明確化」と進む点がReverseの語義に対応する。

ソフトウェアエンジニアリングの文脈でリバースエンジニアリングが特に重要となるのはレガシーシステム（老朽化した既存システム）の保守・移行場面である。1970〜90年代に開発されたCOBOL・PL/I・アセンブラで記述されたシステムは、開発当時の担当者がすでに退職しており、設計書・仕様書も失われているケースが多い。このようなシステムの機能理解・改修・最新環境への移行には、ソースコードやバイナリを解析して仕様を復元するリバースエンジニアリングが唯一の手段となる場合がある。

解析の手法には、ソースコードから構造・依存関係を解析する「静的解析」（構文解析・制御フロー解析・データフロー解析）と、実際に実行しながら動作を観察する「動態解析」（デバッガ・プロファイラ・実行トレース）の2種類がある。現代では静的解析ツール（SonarQube・Understand・Structure101など）が自動化を支援している。

実務での使われ方

リバースエンジニアリングの主な実務用途は以下の通り。（1）レガシーシステムの保守・移行：前述の通り失われた仕様の復元。（2）セキュリティ脆弱性の分析：マルウェアの動作解析（バイナリリバースエンジニアリング）や、自社製品の脆弱性調査。（3）相互運用性の確保：他社製品と自社製品の連携に必要なプロトコル・インターフェースの理解。（4）競合製品の分析：競合他社の製品の機能・設計思想の把握（法的制約に注意が必要）。

法的側面として、他社製品のリバースエンジニアリングはソフトウェアのEULA（使用許諾契約）でしばしば禁止されており、不正競争防止法・著作権法の観点からも制限される場合がある。一方、EU・日本・米国の法制度では「相互運用性の確保」を目的とした解析は一定範囲で許容されており、その境界の解釈は法務上の重要課題である。セキュリティ研究・バグバウンティ（脆弱性報奨制度）への応用では、法的グレーゾーンの整理が研究者・企業双方にとって重要になっている。

試験での位置づけ

ITパスポートの開発技術・ソフトウェア保守分野では、リバースエンジニアリング・リファクタリング・リエンジニアリング・コードレビュー・デザインレビューという関連用語群の定義と区別が繰り返し出題される。本問のように「この操作は何と呼ぶか」という定義問題の他、「XはどのYに分類されるか」という上位概念への分類問題も出る。

ソフトウェア保守の4分類（JIS X 0161準拠）も合わせて押さえておくと有効である。①是正保守（バグ修正）、②適応保守（環境変化への対応）、③完全化保守（機能追加・性能改善）、④予防保守（リファクタリング・ドキュメント整備）の4分類は、保守作業の目的で整理するとリバースエンジニアリングが「④予防保守の前段階としての仕様復元」として機能することが理解できる。

選択肢の発展補足

コードレビュー（a）：開発者が作成したソースコードを他のエンジニアが検証し、バグ・設計上の問題・コーディング規約違反を事前に発見する品質管理活動。ペアプログラミング・プルリクエストレビュー（GitHub/GitLab）・フォーマルインスペクション（ファガン法）などの形態がある。対象は「書いたコード」であり、完成品から仕様を導き出す方向性（リバース）とは正反対。

デザインレビュー（b）：システム設計段階で設計書・アーキテクチャを関係者（開発者・QA・セキュリティ担当・要件担当など）で検証し、設計上の問題を上流で発見・修正する活動。DFR（Design For Reliability）・DFM（Design For Manufacturability）などの枠組みで行われる。設計書を前提として進める点でリバースエンジニアリングとは方向が逆。

リファクタリング（d）：外部から観察できる機能・振る舞いを変えずに、内部コード構造（可読性・保守性・拡張性）を改善する活動。マーチン・ファウラーの著書「Refactoring」（1999年）で体系化。テストコードによる振る舞いの固定が前提。仕様書の作成ではなく「既存コードの品質改善」が目的であり、新しい情報の発見を目指すリバースエンジニアリングとは根本的に異なる。