ITパスポート 令和3年度 問48:プロジェクトマネジメントに関する問題
既存のプログラムを,外側から見たソフトウェアの動きを変えずに内部構造を改善する活動として,最も適切なものはどれか。
- aテスト駆動開発
- bペアプログラミング
- cリバースエンジニアリング
- dリファクタリング正答
AI解説(初心者・標準・上級)
理解度に合わせて3レベルの解説を無料で読めます。
答えは d「リファクタリング」 です。
外から見た動きはそのままで、中身(プログラムの作り)だけをきれいに整理し直すことです。
部屋でたとえると、置いてある物は同じだけど、引き出しの中を整理して取り出しやすくする感じ。見た目(使い勝手)は変わらないけど、中はスッキリ。
👉 覚え方:リファクタリング=「動きは同じ、中身だけお片付け」。
ほかの選択肢:a テスト駆動開発=先にテストを作ってから作る進め方/b ペアプログラミング=2人1組でコードを書く方法/c リバースエンジニアリング=完成品を分解して仕組みを調べること。
なぜこれが正解か
正解は d。リファクタリングは、プログラムの外部から見た振る舞い(仕様・出力)を変えずに、内部構造をより理解しやすく保守しやすい形に改善する活動。可読性向上・重複削除・将来の機能追加の容易化が目的。
各選択肢の解説
- a テスト駆動開発(TDD):実装前にテストコードを書き、テストを通すよう実装を進める開発手法。
- b ペアプログラミング:2人1組で1台のPCを使い、運転者と確認者を交代しながら開発する手法。
- c リバースエンジニアリング:既存の製品やプログラムを解析して、設計や仕様などの情報を取り出すこと。
覚え方・ひっかけ注意
「動きを変えずに内部だけ改善」=リファクタリング、と本問のキーワードで即断。cのリバースエンジニアリングは“分解して調べる”であり改善ではない点が引っかけ。a・b・dはいずれもアジャイル(XP)で使われる実践だが、本問が問うのは内部改善活動なのでd。
理論的背景
「リファクタリング」という概念を体系化したのは Martin Fowler で、1999年の著書『Refactoring: Improving the Design of Existing Code』において「外部的振る舞いを保ちながら内部構造を改善する規律ある手法」と定義した。重要なのは「振る舞いの保存」を条件とする点であり、これを担保するのが自動テストスイートだ。リファクタリングの主なカタログには次のようなものがある。
- メソッドの抽出(Extract Method): 長いメソッドを目的別に分割し可読性を向上
- 重複コードの除去(Remove Duplication): DRY 原則(Don't Repeat Yourself)の適用
- 不適切な名前の変更(Rename): 意図を正確に表す命名への統一
- 巨大クラスの分割(Extract Class): 単一責任原則(SRP)への適合
- マジックナンバーの定数化: 読み手に意図を伝えるための可読性改善
これらを適用するたびにテストを実行し、「グリーン(全パス)」を確認しながら小さなステップで進めるのが安全なリファクタリング手順である。
実務での使われ方
リファクタリングを怠ると「技術的負債(technical debt)」が蓄積し、機能追加コストが指数的に増大する。Ward Cunningham が提唱したこの概念では、設計上の妥協を借金に見立て、放置するほど利子(保守コスト)が膨らむことを示す。実務では CI/CD(継続的インテグレーション / 継続的デリバリー)パイプラインのなかに静的解析ツール(SonarQube・ESLint・Checkstyle)や複雑度指標(循環的複雑度 McCabe)を組み込み、品質劣化を自動検出してリファクタリングのタイミングを判断する。アジャイル開発ではスプリントごとに「完了の定義(Definition of Done)」にリファクタリングを含めることで、技術的負債の積み増しを防ぐのが標準的実践だ。
試験での位置づけ
ITパスポートではアジャイル・XP(エクストリームプログラミング)のプラクティスとして、TDD(テスト駆動開発)・ペアプログラミング・リファクタリング・継続的インテグレーション・小さなリリースの五つがセットで問われることが多い。リファクタリングはこの文脈で「内部品質を維持する活動」として位置づけられる。基本情報技術者では、ソフトウェア保守の分類──是正保守(バグ修正)・適応保守(環境変化への対応)・完全化保守(機能追加)・予防保守(品質向上目的のリファクタリング)──との対応も問われる。リファクタリングは「予防保守」に分類される点は上位資格で必須知識だ。
選択肢の発展補足
選択肢 a「テスト駆動開発(TDD)」 は実装前にテストコードを書き、テストが通るように実装するサイクル(Red → Green → Refactor)。リファクタリングとは対象物が異なるが、TDD のサイクルの第三段階がリファクタリングであるため深い関連がある。TDD なしのリファクタリングは振る舞い保証が弱くなる。
選択肢 b「ペアプログラミング」 は2名が1台の PC を共有し、「ドライバー(コードを書く)」と「ナビゲーター(レビューする)」を交互に担う手法。コードレビューの即時化と知識共有が目的で、書いた直後にナビゲーターがリファクタリング候補を指摘できる相乗効果がある。
選択肢 c「リバースエンジニアリング」 は既存システムのバイナリや動作を解析して設計情報・仕様を逆算する手法。レガシー資産の移行・再設計に用いられる。回復した設計情報を基に作り直す全工程を「リエンジニアリング」と呼ぶ。なお他社製品を解析して機能を模倣する行為は、ソフトウェア使用許諾契約のリバースエンジニアリング禁止条項や著作権法に抵触するリスクがある点も法務知識として押さえておきたい。
出典:IPA(情報処理推進機構)公式 ITパスポート試験 令和3年度 問48/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。