対象試験と出題頻度
リファクタリングは、基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア保守やアジャイル開発の文脈で頻繁に登場し、「外部の振る舞いを変えない」という大原則を理解しているかが問われます。デバッグや性能改善との違いを正確に区別できるかが得点の分かれ目です。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「リファクタリングって、結局バグ修正と何が違うの？」と混乱しがちです。
リファクタリング（Refactoring）とは、一言で言うと
「外部から見た動作を変えずに、プログラムの内部構造を整理して保守性を高める作業」
のことです。
イメージとしては、「部屋の模様替え」です。
家具の配置を変えても、その部屋が「寝室」であることや、ベッド・机といった役割は変わりません。住み心地（=メンテナンスのしやすさ）が良くなるだけです。
リファクタリングも同じで、ユーザーから見た機能や入出力結果は一切変えず、コードの中身だけを読みやすく・直しやすく整える作業です。
📊 リファクタリングの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Refactoring |
| 提唱者 | Martin Fowler（書籍『Refactoring』1999年） |
| 主な目的 | 保守性・可読性・拡張性の向上 |
| 大原則 | 外部から見た振る舞いを変えない |
| 関連工程 | ソフトウェア保守、アジャイル開発、TDD |
解説
ソフトウェアは作って終わりではなく、長い年月をかけて機能追加・修正が繰り返されます。
その過程でコードはどんどん複雑化し、「動いているけれど誰も触りたくない」状態（=技術的負債）に陥ります。
この負債を放置すると、ちょっとした修正にも莫大な時間がかかるようになります。そこで、機能を変えずに内部だけを綺麗にしておく作業が必要になります。これがリファクタリングが生まれた背景です。
「動作を変えない」を保証する仕組み
リファクタリングの大原則は「外部から見た振る舞いを変えない」ことです。
これを担保するのがテストコードの存在です。
事前に十分なテストを用意し、改修の前後で同じテストが全て通ることを確認することで、「整理しただけで壊していない」ことを保証します。
テストがない状態で構造を変えるのは、リファクタリングではなく単なる書き換えです。
🔄 リファクタリングのサイクル
▲ 「緑のまま少しずつ整える」のがリファクタリングの鉄則
代表的な手法（リファクタリングカタログ）
Martin Fowlerの書籍では具体的な手法がカタログ化されています。試験で頻出のものを中心に押さえれば十分です。
| 手法名 | 内容 |
|---|---|
| メソッドの抽出 （Extract Method） |
長い処理の一部を別メソッドとして切り出し、名前を付けて意図を明確にする |
| 変数名の変更 （Rename Variable） |
「a」「tmp」のような曖昧な変数名を、目的が分かる名前に置き換える |
| 重複コードの除去 （Remove Duplication） |
複数箇所に同じコードがある場合、共通メソッドに統合する |
| マジックナンバーの定数化 | コード中に直書きされた数値（例：0.08）を、意味のある定数（例：TAX_RATE）に置き換える |
コード例：メソッドの抽出
もっとも代表的な「メソッドの抽出」を見てみましょう。動作は変わらず、読みやすさだけが上がります。
❌ Before（読みにくい）
void printInvoice(Order o) {
// ❶ ヘッダ表示
System.out.println("=== 請求書 ===");
System.out.println("顧客: " + o.name);
// ❷ 合計計算（中身が見える）
double total = 0;
for (Item i : o.items) {
total += i.price * i.qty;
}
total *= 1.10;
System.out.println("合計: " + total);
}
👀 1つの関数に「ヘッダ表示」「合計計算」「税率掛け」「出力」が全部混ざっている。
📏 メソッドが長く、何をしているか一行ずつ追わないと分からない。
❓ 1.10 という数字の意味が読み取れない（マジックナンバー）。
✅ After（意図が明確）
void printInvoice(Order o) {
printHeader(o);
double total = calcTotal(o);
System.out.println("合計: " + total);
}
double calcTotal(Order o) {
double sum = 0;
for (Item i : o.items) sum += i.price * i.qty;
return sum * 1.10;
}
✨ メソッド名が「目次」の役割を果たし、メイン処理を読むだけで全体像が掴める。
🔧 合計計算ロジックが calcTotal に独立し、単体テストがしやすい。
♻️ 他の場所でも calcTotal を再利用できる。
🔍 何がどう「読みやすく」なったのか
| 観点 | Before | After |
|---|---|---|
| 関数の長さ | 10行（処理が混在） | 4行（メイン）+ 補助関数 |
| 処理の意図 | コメントを読まないと分からない | 関数名そのものが意図を語る |
| テストのしやすさ | 合計計算だけを検証できない | calcTotal単体でテスト可能 |
| 再利用性 | 他の画面で使うにはコピペが必要 | 関数を呼び出すだけで済む |
| 修正時の影響範囲 | 税率を変えるとメイン関数を触る必要 | calcTotalだけ修正すればOK |
▲ 出力結果は完全に同じ。違うのは「人間にとっての分かりやすさ」と「将来の修正コスト」
紛らわしい用語との違い
試験ではリファクタリングと混同しやすい用語が選択肢に並びます。
「何を変えるか／変えないか」で整理するのが近道です。
| 用語 | 外部の動作 | 内部の構造 | 主な目的 |
|---|---|---|---|
| リファクタリング | 変えない | 変える | 保守性・可読性の向上 |
| デバッグ | 変える（誤りを正す） | 必要に応じて | バグの修正 |
| チューニング | 変えない（速くなる） | 変える | 性能の改善 |
| リバースエンジニアリング | — | 解析する | 既存ソフトの仕様を逆算する |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 リファクタリングの核心を3行で
・外部の振る舞いを変えずに、内部のコード構造を整理する作業
・目的は保守性・可読性の向上で、機能追加や性能改善ではない
・テストコードで「動作が変わっていない」ことを保証しながら少しずつ進める
試験ではこう出る！
リファクタリングは、FE・APの午前問題でほぼ毎年のように出題される定番テーマです。問われ方はシンプルで、「リファクタリングの説明として正しいものを選べ」という形式が大半を占めます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問47 |
リファクタリングの説明として適切なものを選ぶ問題。 | ・「外部仕様を変更せずに内部構造を改善」が正解 ・性能改善・機能追加・バグ修正がひっかけ |
| AP H29春 午前 問46 |
アジャイル開発における作業の説明として、リファクタリングを問う問題。 | ・「動作を変えずに保守性を高める」が正解 ・ペアプログラミング・継続的インテグレーションの説明が混在 |
| AP R元秋 午前 問46 |
XP（エクストリームプログラミング）のプラクティスとしてのリファクタリング。 | ・XPの12のプラクティスの一つ ・テスト駆動開発（TDD）とセットで覚える |
| FE R4年 科目A 問47 |
ソフトウェア保守における作業の分類問題。 | ・予防保守の一環として位置づけられる ・是正保守（バグ修正）との区別が必要 |
📝 IPA試験での出題パターン
パターン1：「リファクタリングの説明を選べ」
4択のうち正解は必ず「外部仕様（外部から見た動作）を変えずに、内部構造を改善する」という記述。ひっかけは「処理速度を上げる」（チューニング）、「機能を追加する」（機能拡張）、「バグを修正する」（デバッグ）の3パターンが定番。「動作を変えない」という記述があるかどうかが見分けの軸になります。
パターン2：「アジャイル/XPの文脈での出題」
テスト駆動開発（TDD）やXPのプラクティスとセットで問われる形式。「テストが通る状態を維持しながら、コードを継続的に整理する」のがアジャイル流のリファクタリングです。CI（継続的インテグレーション）と並ぶXPの定番プラクティスとして覚えておきましょう。
ここだけは確実に押さえてください。「動作は変えない／中身は変える」この一行を覚えれば、午前問題のリファクタリング問題は8割方落としません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における「リファクタリング」の説明として、最も適切なものはどれでしょうか？
- A. プログラムの実行速度やメモリ使用量を改善するために、アルゴリズムやデータ構造を見直す作業。
- B. プログラムの外部から見た動作を変えずに、内部の構造を整理して保守性や可読性を高める作業。
- C. 既存のソフトウェアを解析して、設計書や仕様書などの上位ドキュメントを復元する作業。
正解と解説を見る
正解：B
解説：
選択肢Bが正解です。リファクタリングは「外部仕様を変えずに内部構造のみを改善する」のが定義そのものであり、目的は保守性・可読性・拡張性の向上です。
選択肢Aはチューニング（性能改善）の説明です。実行速度やメモリ効率という「非機能要件」を向上させる作業であり、コード構造の整理を主目的とするリファクタリングとは別物です。選択肢Cはリバースエンジニアリングの説明です。既存の成果物から上位ドキュメントを復元する作業であり、コードを書き換えるリファクタリングとは方向性が異なります。
よくある質問（FAQ）
Q. リファクタリングはいつやるのが正解ですか？
理想は「機能追加の直前」と「機能追加の直後」です。直前に整理しておくと新機能を追加しやすくなり、直後に整理すると追加で乱れた構造を綺麗に保てます。XPでは「コードの嫌な臭い（Code Smell）に気づいたらすぐ」が原則とされます。逆に、リリース直前や納期直前の大規模な改修は事故のもとなので避けるのが鉄則です。
Q. テストコードがないシステムでもリファクタリングはできますか？
原則としてはお勧めしません。動作が変わらないことを保証する手段がないため、知らないうちにバグを作り込むリスクが高いからです。レガシーコードを扱う場合は、まず「特性化テスト（Characterization Test）」と呼ばれる現状の挙動を固定するテストを書いてから、少しずつ整理するのが定石です。Michael Feathersの『レガシーコード改善ガイド』がこの分野の定番書です。
Q. リファクタリングと「ソフトウェア保守」はどう関係しますか？
ソフトウェア保守は「是正保守」「適応保守」「完全化保守」「予防保守」の4種類に分類されます（ISO/IEC 14764）。リファクタリングはこのうち、将来の問題発生を未然に防ぐ「予防保守」または、保守性そのものを高める「完全化保守」に位置づけられます。バグ修正である「是正保守」とは目的が異なる点が試験での頻出ポイントです。
Q. IDEのリネーム機能や自動整形もリファクタリングに含まれますか？
含まれます。IntelliJ IDEAやVisual Studio、EclipseなどのIDEには「Refactor」メニューが用意されており、変数名の一括変更、メソッドの抽出、クラスの移動などを安全に実行できます。手作業より失敗が少なく、現代のリファクタリングはこうした自動化ツールが前提です。ただし、自動整形（フォーマッタ）はインデントやスペースを揃えるだけで構造を変えないので、厳密にはリファクタリングではなく単なる「整形」と区別されます。
