リファクタリング（refactoring）

分類: マネジメント系ソフトウェア開発管理技術
出る試験: 基本情報応用情報
重要度: ★★★☆☆

外から見た動きを変えずに、ソースコードの構造を整理すること。機能を増やす作業とは分けて行う。

もう少し詳しい説明

リファクタリングは、外から見た動きを変えずに、ソースコードの構造を整理することです。

変えるものと変えないもの

	変わるか
ソースコードの構造	変わる
外から見た動き	変わらない
入力に対する出力	変わらない
機能の数	変わらない

他の作業との区別

作業	外から見た動き
リファクタリング	変わらない
機能の追加	増える
不具合の修正	変わる（正しくなる）
性能の改善	速さが変わる

同時に行わないところが決まりです。

混ぜると	起きること
整理と機能追加を同時に行う	動きが変わったとき、どちらが原因か分からない
整理と不具合の修正を同時に行う	テストが通らない理由が切り分けられない

整理の回と、機能を変える回を分けます。 整理だけの変更なら、テストの結果は変わらないはずだ、という形で確かめられます。

なぜ整理するのか

放っておくと	整理すると
同じ処理が何か所にも増える	1か所にまとまり、直すときに1回で済む
1つの処理が長くなり、読めなくなる	分かれて、読めるようになる
手を入れるたびに別の場所が壊れる	影響する範囲が狭くなる
新しい人が読めない	読んで分かる形になる

手を入れる速さが落ちていくことを防ぐための作業です。 機能が増えないので、すぐには効果が見えません。

よく行う整理

整理	中身
名前を分かる名前に変える	`a`、`tmp` のような名前を、中身を表す名前にする
長い処理を分ける	1つの処理を、意味のまとまりで分ける
重複をまとめる	同じ処理が複数あるところを1つにする
深い入れ子を浅くする	if の入れ子を減らす
使われていないものを消す	呼ばれない処理、使われない変数

安全に行うための前提

テストが無い状態で整理すると、動きが変わったことに気づけません。

手順	すること
1	先にテストを用意する（いまの動きを確かめられる状態にする）
2	小さく整理する
3	テストを実行して、結果が変わっていないことを確かめる
4	2と3を繰り返す

一度に大きく変えないところが要点です。 小さく変えて確かめる形にすると、動きが変わった時点が分かります。

変更のたびに自動でテストを動かす仕組み（継続的インテグレーション）があると、この確認が早く回ります。

進め方の中での置き場所

進め方	置き場所
アジャイル	各回の中に組み込む。機能の追加と同じ回に、別の作業として入れる
ウォーターフォール	工程の中に入れにくい。保守の段階で行うことが多い

繰り返して作る進め方では、整理を続けることが前提になります。 作って直すのを繰り返すと、構造が崩れていくためです。

時間が取れないとき

起きること	中身
整理を後回しにし続ける	手を入れる速さが下がっていく
その状態が積み上がる	技術的負債と呼ばれる状態になる

負債という言い方は、後で返す必要がある、という意味で使われています。 返さないままにすると、新しい機能を作る時間が、既存の部分の手当てに取られていきます。

一方で、

整理に時間をかけすぎると	中身
機能が進まない	外から見た成果が出ない
終わりが決まらない	どこまで整理するかの線が引きにくい

どこまで整理するかは、手を入れる予定があるかで決めるという考え方があります。これから触る部分を整理し、触らない部分はそのままにする形です。

試験ではこう出る

科目A（旧・午前）では、用語の意味が問われます。外から見た動きを変えない、という部分が答えの軸です。機能追加や不具合の修正と並べて、どれがリファクタリングかを選ぶ形が多くあります。

午後や応用情報（プロジェクトマネジメント、開発技術）では、作業の一覧の中に出てきます。この作業を入れる理由、整理の回を分ける理由、という読み取りになります。

ミニクイズ

リファクタリングの説明として、最も適切なものはどれか。

正解は 2番：外部から見た振る舞いを変えずに、ソースコードの内部構造を改善すること

リファクタリングは、外から見た動きを変えないまま、ソースコードの内部の構造を整えることです。機能の追加、不具合の修正、速さの改善は、いずれも外から見た動きや結果が変わる作業なので、リファクタリングとは分けて考えます。これらを同時に行うと、動きが変わった原因が構造の整理なのか別の変更なのか分からなくなります。

間違えた用語の復習リストを見る →

この分野をまとめて解く → システム開発とユーザーインタフェースのミニテスト（全40問）

最終更新：2026-11-09