LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

何度も改修を重ねた既存システムが読みにくくなり、次の機能を加えるたびに時間がかかる。外から加わる業務委託エンジニアに作りを整えてもらいたいが、動いている仕組みを壊されないか心配だ——。こうした悩みは、長く使っているシステムを抱える開発の現場で起こりがちです。既存システムのリファクタリングとは、利用者から見た動きを変えずに、プログラムの中の作りを読みやすく直しやすい形へ整えることを指します。

動きが変わらない作業なので、頼む範囲と確かめ方を先に決めておかないと、終わった後に何が良くなったのかが分かりません。本記事では、開発の現場を預かるマネージャーに向けて、IPA（情報処理推進機構）の2つの資料をもとに、範囲の決め方、壊していないことを確かめるテスト、機能追加と組み合わせる手順、受け取るものを整理します。

既存システムのリファクタリングとは

IPAが2013年に公表した「アジャイル型開発におけるプラクティス活用事例調査 ガイド編」は、アジャイル型開発を実践している企業への調査をもとに、開発の現場で使われる手法や活動を整理した資料です。この中でリファクタリングは、外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるようにソフトウェアの内部構造を変えることとされています。^*1

手を入れる対象として、同ガイドは重複したコード、長過ぎるメソッド、巨大なクラス、多すぎる引数、わかりにくいコメントや不要なコメントを挙げています。^*1 既存システムでは、長年の改修で同じ処理が何か所にも書かれていたり、1つの処理が長く膨らんでいたりすることがあります。

機能追加や不具合の修正とは目的が違います。機能追加は利用者から見える動きを増やし、不具合の修正は誤った動きを正しい動きに直します。リファクタリングは動きを変えないことが前提で、この違いを最初に共有しておくと、「ついでに直した」動きの変化が混ざるのを防げます。

業務委託で頼むと後回しになる理由

同ガイドの調査では、リファクタリングは全体の69%の事例で使われていました。契約の形で分けると、自社開発では78%だったのに対し、受託開発では54%にとどまっています。^*1 ガイドはこの差について、受託開発ではリファクタリングの工数を確保しにくいことが原因と推測しています。

発注する側から見ると、リファクタリングは成果が見えにくい作業です。ガイドは、顧客からは「新しい機能を追加しないで、既存の機能をいじっているだけ」と捉えられてしまうと書いています。動きが変わらないので、終わった後に画面を見ても何が良くなったのかは分かりません。そのため、機能の追加やバグへの対応と並べると、優先順位が下がりやすくなります。

もう一つは、作業の大きさが読みにくいことです。ガイドの事例では、小さな単位のリファクタリングは日々の開発の工数で補えた一方、大きなリファクタリングは計画に入っておらず、工数を捻出できずに調整が必要になりました。^*1 業務委託では、何をどこまで直すのかを頼む側が先に決めておく必要があります。

頼む範囲の決め方

範囲は、システム全体ではなく、目的を決めて絞り込みます。IPAの「先進的な設計・検証技術の適用事例報告書 2015年度版」には、版を重ねるパッケージソフトウェアの開発でリファクタリングに取り組んだ事例が載っています。この事例では、機能追加の見込みが高いものから優先度を上げ、目的と範囲を限定してリファクタリングを実施しました。^*2

優先する箇所の手がかりとして、アジャイルのガイドは、バグの発生は特定の場所に集中することが多く、そのポイントを絞って徹底的にリファクタリングすると効果が高いとしています。全体にテストコードが書かれていなくても、絞った箇所にだけテストを書くことに効果があるとも述べています。障害の記録から、修正が繰り返されている処理を書き出すと候補を挙げやすくなります。

大きなリファクタリングが要るときは、新しい機能の追加量、リファクタリングをしない場合の潜在的なリスク、対応の工数などを含めて、プロダクトオーナー（何を先に作るかを決める人）と検討するとしています。業務委託エンジニアに頼む場合、この判断は発注する側が担います。次の表の項目を書き出してから頼むと、見積もりの前提がそろいます。

工数の見込み方には、ガイドが紹介した事例が参考になります。リファクタリングをしないまま開発を進めて保守に苦労した経験を持つ顧客企業が、全体の工数の15%をリファクタリングの工数として見積もるよう依頼し、工数を確保して実施できたというものです。^*1 比率は1つの事例のものですが、機能の作業とは別に時間を見込む考え方は、業務委託でも使えます。

壊さないための確認テスト

動きを変えていないことは、テストで確かめます。アジャイルのガイドは、リファクタリングには堅実なテストの存在が欠かせないとし、リファクタリングの前と後で、自動化された回帰テスト（変更していない部分が壊れていないかを確かめるテスト）や受入テストの結果が変わらないことを確かめなければならない、としています。^*1

適用事例報告書の事例では、ソースプログラムの構造に依存しないテスト仕様とテストコードを用意し、リファクタリングのたびにそれを使って影響の範囲を確かめていました。^*2 構造に依存しないテストとは、関数の分け方や名前ではなく、入力と出力の組み合わせで書いたテストのことです。中の作りに合わせて書いたテストは、作りを変えると一緒に書き直しが要り、確かめるための物差しになりません。

既存システムでは、テストコードがほとんど無いことも珍しくありません。その場合は、手を入れる前に、今の動きを記録するテストを書く作業を最初に頼みます。書く範囲は、前の節で絞った対象に合わせます。ガイドの調査では、自動化された回帰テストは全体の65%の事例で使われており、ガイドは早くから自動化に取り組むのが望ましいとしています。^*1

一方でガイドは、自動化は「壊れていないこと」を確かめる目的でしかないとし、自動化できない領域のテストも実施するよう求めています。画面の表示や帳票のレイアウトのように自動化しにくい部分は、手で確かめる項目として一覧に残し、誰がいつ確かめるかを決めておきます。

機能追加と組み合わせる手順

既存システムのリファクタリングは、機能追加とあわせて頼むことが多いでしょう。適用事例報告書の事例では、リファクタリングを機能追加のときと、アーキテクチャ（システムの全体の構成）を変えるときに実施していました。機能追加のときの手順は、次の図の5段階です。^*2

この手順の要点は、構造を直す段階と機能を足す段階を分けていることです。2と4を同時に進めると、テストが落ちたときに、原因が構造の変更なのか機能の追加なのかを切り分けにくくなります。変更の記録（コミット）も段階ごとに分けてもらいます。

事例では、テストを設計する段階で入出力の条件をはっきりさせながらテスト仕様とテストコードを作り、後のバグ対応の再検証やリファクタリングに使い回していました。機能追加のたびにテストが社内に残っていけば、次にリファクタリングを頼むときに1の段階を短くできます。

作りを大きく変えるときの進め方

アーキテクチャを変えるような大きなリファクタリングでは、事例は手順を変えています。従来機能を保証するテストを用意するところは同じですが、従来のソースは残したまま、別のソースでアーキテクチャを追加します。用意したテストと機能追加分のテストを流すことを繰り返し、旧機能と新機能が同等のレベルになったところで置き換えています。^*2

古い作りを残したまま新しい作りを並べて育てるので、途中で問題が見つかっても、本番で動いている側には手が入りません。業務委託エンジニアに頼む場合は、「同等」と判断する条件を先に決めておきます。どのテストがすべて通ったら置き換えるのか、置き換えを決めるのは誰か、置き換えた後に古いソースをいつ消すのかを、作業の計画に書いておきます。

期間が長くなりやすい点にも注意が要ります。契約を月ごとに更新する場合は、毎月「どこまで同等になったか」を報告してもらう形にすると、途中で担当が替わっても続きから進めやすくなります。

受け取るものと確かめ方

受け取るものの1つ目は、直したソースコードとあわせたテストコードとテスト仕様です。事例では、リファクタリングのときにソースプログラムだけでなく、テストコード（テスト仕様）もリファクタリングの対象にしていました。^*2 テストを社内に残しておけば、次に別の業務委託エンジニアが入ったときも、同じ物差しで動きを確かめられます。

2つ目は、変更の前と後のテスト結果です。同じテストを同じ環境で流し、結果が変わっていないことを記録で受け取ります。事例では、リファクタリングによってテストパターンが12から5に減った例を示しつつ、必要十分なテストパターンを考えているので品質上の問題はないとしています。^*2 テストの数が減ったときは、減らした理由の説明もあわせて受け取ります。

3つ目は、中の作りが良くなったかどうかの見方です。アジャイルのガイドは、リファクタリングを実施していても、内部構造の改善につながっているかどうかは定かでない場合もあるとしています。ガイドの事例の1つは、静的解析ツール（プログラムを動かさずに調べる道具）でルールを決め、スコアが低ければリファクタリングするようにしていました。^*1 前と後で同じ道具の結果を並べてもらうと、成果を社内に説明しやすくなります。

終わらせ方も決めておきます。テストがすべて通り、前後の結果と差分の説明がそろったら完了、のように受け入れの条件を書いておくと、どこで作業を止めるかで迷いにくくなります。

外部に委託するときに確認しておきたい点

業務委託エンジニアを探す前に、前の表の項目を書き出しておきます。とくに「変えない動き」と「確かめ方」が決まっていれば、求める経験がはっきりします。テストコードを書いた経験や、他人が書いたコードを読み解いて直した経験は、面談で具体的に聞けます。

既存システムに機能を加える追加開発の受け渡しは業務委託エンジニアの既存システム追加開発、受け渡しの3つの場面で整理しています。

仕様書が古く、今の動きが文書から分からない場合はレガシーの仕様書が古いときに引き継げる形へ直す4つの手順も参考になります。

まとめ：リファクタリングで確かめておきたい3つの点

業務委託エンジニアに既存システムのリファクタリングを頼むうえで、確かめておきたい点は3つに整理できます。第一に、目的を決めて対象を絞り、変えない動きと工数を書き出してから頼むこと。第二に、手を入れる前に今の動きを確かめるテストを用意し、構造を直す段階と機能を足す段階を分けること。第三に、テストコードと前後のテスト結果も受け取ることです。この3点を踏まえておけば、「中を直してもらったはずが、気づかないうちに計算の結果が変わっていた」という事態を避けやすくなります。テストを書きながら既存のコードを直せる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「アジャイル型開発におけるプラクティス活用事例調査 調査報告書 ～ガイド編～」（PDF）（https://www.ipa.go.jp/archive/files/000026849.pdf）。出典：独立行政法人情報処理推進機構、2013年（平成25年）3月19日。3.2.2「自動化された回帰テスト」、3.2.8「リファクタリング」、3.5.4「リファクタリングができない」を参照（確認日2026年10月6日）（2026年10月確認）
2. *2　参考：IPA「先進的な設計・検証技術の適用事例報告書 2015年度版」PARTⅢ 検証事例 15-B-9（PDF）（https://www.ipa.go.jp/archive/files/000049407.pdf）。出典：独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター。「パッケージソフトウェア開発プロセス改善による品質向上と生産性向上」の3.1(3)（顧客視点での設計）、3.3（リファクタリングの方法・例・実施トリガ）を参照（確認日2026年10月6日）（2026年10月確認）

Tweet