マナビングITパスポート

リバースエンジニアリングとは?コードから仕様を復元する手法の見分け方

ITパスポート試験 令和5年度 問39 / ソフトウェア開発管理技術 › 開発プロセス・手法

過去問にチャレンジ

令和5年度 問39

運用中のソフトウェアの仕様書がないので,ソースコードを解析してプログラムの仕様書を作成した。この手法を何というか。

  1. ア

    コードレビュー

  2. イ

    デザインレビュー

  3. ウ

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

  4. エ

    リファクタリング

会話形式の解説

講師講師
今回は、仕様書がないソフトウェアについて、ソースコードを解析して仕様書を作る手法の名前を問う問題です。まず「何を材料にして、何を作ったか」に注目してください。
受験者受験者
材料はソースコードで、作ったのは仕様書です。ただ、選択肢にカタカナ語が並んでいて、どれも開発の現場で聞きそうなので迷います。
講師講師
ふつうの開発は、仕様を決めてから実装、つまりプログラムを書く作業に進みます。今回の作業はどちら向きに進んでいるでしょうか。
受験者受験者
コードから仕様に戻っているので、逆向きです。だから「リバース」が付いたリバースエンジニアリングでしょうか。
講師講師
そのとおりです。リバースエンジニアリングは、既存の製品やソフトウェアを解析して、構造・設計・仕様を明らかにする手法です。仕様書を失ったシステムの保守や、既存システムの調査・移行などで使われます。
受験者受験者
コードレビューもソースコードを詳しく読むので、近い気がしました。違いはどこですか。
講師講師
コードレビューは、書き上がったソースコードを作成者以外の人が確認して、不具合や規約違反、読みにくさを見つける活動です。目的は品質の確認で、コードから仕様書を作り出すことではありません。
受験者受験者
デザインレビューは設計を確認する活動ですよね。仕様書を作る話とつながりそうにも見えます。
講師講師
デザインレビューは、設計書や設計内容を確認して、問題点や要件との食い違いを見つける活動です。主にコーディングの前に行います。設計書があることが前提なので、コードしか残っていない今回の状況には当てはまりません。
受験者受験者
リファクタリングもリバースエンジニアリングと同じ「リ」で始まるので、私はよく混ざってしまいます。
講師講師
リファクタリングは、外から見た動作を変えずに、ソースコードの内部構造を改良する作業です。目的は読みやすさや保守性を高めることで、仕様を復元して文書にすることではありません。
受験者受験者
整理すると、二つのレビューは確認する活動、リファクタリングは改良する活動、リバースエンジニアリングは仕様を復元する活動、ということですね。
講師講師
よくまとまっています。補足すると、仕様や設計から実装へ進む通常の流れはフォワードエンジニアリングと呼ばれます。また、他社製品をリバースエンジニアリングする場合は、著作権や利用許諾による制約を受けることがあるので、権利関係の確認が必要です。「仕様を取り出す」のか「コードを整える」のかで区別すれば、リファクタリングとの取り違えは防げます。

まとめ

既存のソースコードを解析して仕様書を作る手法は、リバースエンジニアリングと呼ばれます。仕様から実装へ進む通常の開発(フォワードエンジニアリング)を逆向きにたどる点が特徴です。コードレビューはソースコードを、デザインレビューは設計書を対象にした品質確認の活動で、仕様を復元するものではありません。リファクタリングは動作を変えずにコードの内部構造を整える作業なので、「仕様を取り出す」リバースエンジニアリングとは区別しましょう。

解答・解説

正解はウです

この問題のテーマ

既にあるソースコードを解析して仕様書を作り直す手法の名前を問う問題です。あわせて、名前の似たレビューや改善活動との違いも問われています。

解き方の考え方

まず、問題文の作業が「何を材料にして、何を作ったか」を押さえます。材料はソースコードで、作ったものは仕様書です。通常の開発は仕様から実装へ進みますが、この作業はその逆向きに進んでいます。各選択肢について「確認する活動か」「改良する活動か」「復元する活動か」を考えると、復元にあたるものは一つだけだとわかります。

選択肢ごとの解説

  1. ×ア  コードレビュー
    アのコードレビューは、作成済みのソースコードを作成者以外の人が確認し、不具合や規約違反、読みにくさなどを見つける活動です。目的はコードの品質確認であり、コードから仕様書を作り出すことではありません。
  2. ×イ  デザインレビュー
    イのデザインレビューは、設計書や設計内容を確認し、問題点や要件との食い違いを見つける活動です。設計段階で、主にコーディングを始める前に行います。設計書があることが前提の評価なので、仕様書がなくコードしかない今回の状況には当てはまりません。
  3. ○ウ  リバースエンジニアリング
    ウのリバースエンジニアリングは、既存の製品やソフトウェアを解析して、構造・設計・仕様を明らかにする手法です。仕様書がないソフトウェアのソースコードを解析して仕様書を作る作業は、まさにこれにあたります。仕様書を失ったシステムの保守や、既存システムの調査・移行などで使われます。
  4. ×エ  リファクタリング
    エのリファクタリングは、外から見た動作を変えずに、ソースコードの内部構造を改良する作業です。目的は読みやすさや保守性を高めることで、仕様を復元したり文書にしたりすることではありません。

補足

「リ」で始まるリバースエンジニアリングとリファクタリングは混同しやすい組み合わせです。「仕様を取り出す」のか「コードを整える」のかで区別しましょう。また、仕様や設計から実装へ進む通常の流れはフォワードエンジニアリングと呼ばれます。他社製品をリバースエンジニアリングする場合は、著作権や利用許諾による制約を受けることがあるので、権利関係の確認が必要です。

POINT

  • リバースエンジニアリングは、既存のソフトウェアや製品を解析して、設計や仕様を明らかにする手法です。
  • 仕様から実装へ進む通常の開発の流れを、逆向きにたどる点が特徴です。
  • コードレビューはソースコードを、デザインレビューは設計書を対象にした品質確認の活動です。
  • リファクタリングは、動作を変えずにコードの内部構造を整える作業です。

※出典:令和5年度 ITパスポート試験 問39