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

答えは a です。

リファクタリングとは「外から見える動きは変えずに、中身（プログラムの作り）をきれいに整理し直す」ことです。部屋の使い方は同じまま、引き出しの中を整理整頓するイメージです。

👉 覚え方：「リファクタリング＝動きはそのまま、中身をお片づけ」。

ほかの選択肢：

• b 動きを調べて仕様を明らかにする→リバースエンジニアリングのこと。
• c 不具合を直して仕様どおりに動かす→バグ修正のこと。
• d 新しい機能を加える→機能追加のこと。

機能は変えず内部だけ改善する a が正解です。

なぜこれが正解か

正解は a。リファクタリングとは、ソフトウェアの外部から見た機能・振る舞い（仕様）を変えずに、内部構造を改善すること。可読性・保守性を高め、将来の変更を容易にするのが目的で、機能追加やバグ修正そのものではない。

各選択肢の解説

• a 正しい：機能仕様を変えず内部構造を改善＝リファクタリングの定義。
• b 誤り：動作を解析して仕様を明らかにする＝リバースエンジニアリング。
• c 誤り：不具合を修正し仕様どおり動かす＝バグ修正（デバッグ）。
• d 誤り：新しい機能を加える＝機能追加（保守の中の完全化保守）。

覚え方・ひっかけ注意

キーワードは 「機能（外部仕様）は変えない・中身だけ直す」。「内部構造の改善」という語があればリファクタリング。bのリバースエンジニアリング、cのバグ修正、dの機能追加はいずれも“何かを変える/明らかにする”操作で、リファクタリングと対比して覚える。

理論的背景

リファクタリングはマーチン・ファウラー（Martin Fowler）が著書「Refactoring: Improving the Design of Existing Code」（1999年・2018年第2版）で体系化した概念であり、「外部から観察できるふるまいを変えることなく、内部構造を改善する」という明確な定義を持つ。"外部から観察できるふるまい"とは、関数・メソッドが受け取る入力に対して返す出力・副作用・例外のすべてを指し、これらを不変に保ちながら内部のコード品質（可読性・保守性・凝集度・結合度・複雑度など）を向上させる。

リファクタリングが技術的負債（Technical Debt）の返済手段として位置づけられる背景には、ソフトウェアの経年劣化という現象がある。当初は整理されていたコードも、機能追加・緊急修正・担当者交代・仕様変更を繰り返すうちに「腐敗（Rot）」していく。「スパゲッティコード」「神クラス（God Class）」「マジックナンバー」「重複コード」「長すぎるメソッド」などのコードスメル（Code Smell）が蓄積すると、変更に要するコストが指数的に増大し、バグ混入リスクが高まる。リファクタリングはこの劣化を定期的に修正するメンテナンス活動として、継続的な実施が推奨される。

実務での使われ方

リファクタリングの前提として自動テスト（ユニットテスト）の整備が不可欠とされる。テストコードによって現行の外部ふるまいを「固定」し、リファクタリング中に誤ってふるまいを変えていないことをテスト実行によって即座に確認できる仕組みが必要である。テストのない状態でのリファクタリングは「盲目的な改変」であり、技術的負債の返済どころか新たなバグを生む危険がある。

アジャイル開発・TDD（Test Driven Development）では「Red（失敗するテストを書く）→Green（テストを通るコードを最小限で書く）→Refactor（コードを整理する）」というサイクルを短い周期で繰り返す。CI/CDパイプラインへの統合により、コードの変更ごとに自動テストが実行され、リファクタリングによる回帰（既存機能の劣化）を継続的に防止する。

代表的なリファクタリング手法として、メソッドの抽出（長すぎるメソッドを意図が明確な短いメソッドに分割）・変数のインライン化・条件の分解（複雑な条件式を読みやすい形に整理）・クラスの抽出（過大なクラスを適切な単位に分割）・依存性の注入（テスタビリティ向上のための構造変更）などがある。IDEの多くはリファクタリング操作（変数名の一括変更・メソッド抽出など）を安全に自動実行する機能を提供している。

試験での位置づけ

ITパスポートの開発技術・ソフトウェア保守分野では、リファクタリングと類似・関連する用語（リバースエンジニアリング・リエンジニアリング・コードレビュー・バグ修正・機能追加）の違いを問う問題が安定して出題される。本問の正解の鍵は「機能仕様を変えずに」という文言であり、この条件に合致する唯一の選択肢がリファクタリング（a）である。

ソフトウェア保守の4分類（JIS X 0161）との対応も重要な発展知識である。リファクタリングは予防保守（Preventive Maintenance）に分類される（内部品質の改善により将来の修正コストを下げることが目的）。是正保守（バグ修正）・適応保守（環境変化対応）・完全化保守（機能追加・性能向上）とリファクタリングの位置づけを組み合わせて理解すると、保守分野の問題全体への対応力が向上する。基本情報技術者試験ではアジャイル開発プラクティスとしてのリファクタリングの役割、コードメトリクス（循環的複雑度・クラス結合度）との関係まで問われる。

選択肢の発展補足

選択肢b（ソフトウェアの動作を解析して仕様を明らかにする）＝リバースエンジニアリング：既存の成果物から設計・仕様情報を導き出す逆方向の解析活動。レガシーシステムの仕様書復元に使われる。「明らかにする」という新しい情報発見のプロセスであり、「不変を保つ」リファクタリングとは方向が逆。

選択肢c（不具合を修正し仕様どおりに動かす）＝バグ修正（是正保守）：テストで発見した欠陥を修正し、要件どおりの正しい動作を実現する活動。バグ修正は外部ふるまいを（正しい仕様に向けて）変える活動であり、ふるまいを「変えない」リファクタリングとは正反対の目的を持つ。

選択肢d（新しい機能を加える）＝機能追加（完全化保守）：利用者の要望や事業要件を受けてソフトウェアの機能セットを拡張する活動。外部ふるまいを積極的に拡張する点でリファクタリングと対照的。機能追加と同じ変更セットの中にリファクタリングが混在すると「ふるまいの変化がバグなのかリファクタリングの意図した変更なのか」が不明確になるため、機能追加とリファクタリングを別のコミット・PRに分けて管理することがプロフェッショナルな開発実践の標準とされている。