こんにちは、ユーザベースの野口です。2019年7月にユーザベースに入社して以来、一貫してエクストリームプログラミング（eXtreme Programming、以降XP）に取り組んでいます。
この記事を書くに当たって、改めてMartin Fowlerの『リファクタリング（第2版）』を読んだところ、「リファクタリングとは何か」「どのように行うのか」といったことは、ほとんど全て本書に書かれていることに気付きました。
一方で、開発の現場でリファクタリングをどのように位置付け、実践し、機能させるかという観点から考えると、本書を読んだだけでは見えにくい側面もあります。
この記事では、XPを全面的に実践するユーザベースという組織でリファクタリングがどのように機能しているのか、詳しくお伝えしていきます。
2026年7月現在、AIエージェントの普及によって、人間がコードを書くのではなく、AIに書いてもらうことも当たり前になりつつあります。そんな時代に、リファクタリングはどのような意味を持つのか。この記事では、その視点も探求します。
- リファクタリングの定義：外部から見た振る舞いを保ったまま、内部構造を変更する
- リファクタリングの本質：知識をコードベースに落とし込む
- ユーザベースでの実践：XPがリファクタリングを「当然の取り組み」にする
- XPの5つの価値：リファクタリングが表現するチームのバリュー
- AI時代にも、「リファクタリングする（動詞）」ことは重要であり続ける
- おわりに
- 合わせて読みたい：XPを実践するユーザベースの取り組み
リファクタリングの定義：外部から見た振る舞いを保ったまま、内部構造を変更する
まずは、リファクタリングの定義を確認することから始めましょう。
リファクタリング（名詞） 外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。
（中略）
リファクタリングする（動詞） 一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。
（Martin Fowler『リファクタリング（第2版）』オーム社、2019年、p.45）
これがリファクタリングの定義です。一つひとつのリファクタリング（名詞）は比較的小さなステップで、そのリファクタリング（名詞）を連続的に適用していくことでリファクタリングする（動詞）ことができる、ということが分かります。
ただ一つのリファクタリング（名詞）を適用することも、リファクタリングする（動詞）ことだと言えますし、リファクタリング（名詞）を複数適用していくことで、より大きな対象をリファクタリングする（動詞）こともできるということです。
このように、Martin Fowlerによるリファクタリングの定義は、「名詞」と「動詞」という切り分けによって、リファクタリングの「小さく安全な変更を積み上げる」という性質をうまく説明しています。
ここから先の文章では、冗長さを避けるため、「名詞」と「動詞」を厳密に使い分けることはしません。「スケールの大小によらず、外部から見た振る舞いを保ったまま内部構造を変更するのがリファクタリング」という要点を押さえていただければと思います。
リファクタリングの本質：知識をコードベースに落とし込む
ところで、皆さんの開発現場ではいつ、どのようにリファクタリングしていますか？ 「常に行っている」という方もいれば、「リファクタリングのチケット（あるいはストーリーや、プロダクトバックログアイテムなど）を作って、独立したタスクとして行っている」という方もいるのではないかと思います。
『リファクタリング』では、原則としてリファクタリングは常に行うものとしています。
リファクタリングはプログラミングと不可分の作業です。if文を書くためにわざわざ専用の時間を設けないのと同じです。ほとんどのリファクタリングは、何か別のことをしている最中に行われます。
（Martin Fowler『リファクタリング（第2版）』オーム社、2019年、p.53）
ただし、特別の必要があればまとめて行うことがあってもよいとしています。
計画されたリファクタリングが常に悪いと言っているわけではありません。開発チームがリファクタリングをこれまで軽視してきた場合は、コードベースを新機能追加に適したかたちに手直しするために、まとまった時間の確保が必要になることもあるでしょう。
（Martin Fowler『リファクタリング（第2版）』オーム社、2019年、p.53）
ではユーザベースではどうしているかというと、リファクタリング専用のストーリー*1を作ることはせず、「ユーザー価値を届けるためのストーリーに取り組む中で、常に行い続ける」ということを徹底しています。それが、XPという実践全体の中でもっとも自然なかたちだと考えているからです。
XPでは、常にフィードバックを得ながら、変化に適応し続けていくことを目指します。リファクタリングも例外ではありません。私たちは、リファクタリングを独立した開発フェーズやタスクとして捉えるのではなく、「ソースコードにおいて、変化に適応し続けていく過程」と捉えています。
では、コードが変化に適応するとは、どういうことでしょうか。
変化に対応するとき、私たちは何かを学びます。新しい機能（ストーリー）に取り組めば、そこで実現したいこと（要求）を深く考え、ドメインエキスパートとの対話から新しいドメイン知識を得ます。テストを書き、振る舞いを実装すれば、ユーザーの要求とコードとの適合について新たな見方が生まれます。変化からは、知識が得られるのです。
ここで言うコードとは、ただの「動くプログラム」のことではありません。コードは、その時点での設計（チームの理解）を表現したものです。変化に直面すると、「今時点での最新の理解」と「コードが表現している理解」との間にはズレが生じます。このズレは、チームの生産性に悪影響を及ぼします。
リファクタリングとは、このズレを埋める取り組みです。変化から得た知識を用いて、コードとして表現された設計を更新し続けるのです。つまり、リファクタリングとは「知識をコードベースに落とし込む実践」である、と言えます。その目的は、「チームの生産性を高く保ち続けること」です。
逆に「リファクタリングしてはいけないタイミング」があることにも触れておきましょう。それは「振る舞いの変更の真っ最中」です。*2
一つの機能（ストーリー）が完成するまでリファクタリングできないという意味ではありません。どんなに小さな単位でもいいので、リファクタリング対象の振る舞いが、意図通りに動作していると確認できているタイミングでのみ行いましょう、という意味です。別の言い方をすると、コンパイルやテストが通っていない状態ではリファクタリングしないということです。*3
この実践の具体例が、テスト駆動開発です。テスト駆動開発では、一つひとつのテストが通ったタイミングでリファクタリングを行います。Red（テストが失敗している状態）からGreen（テストが通った状態）へ進む短いサイクルの一つひとつが小さな学びを生み、Greenになった瞬間こそが、その学びを設計へ反映できる安定したタイミングだからです。
私たちは、そのように開発の過程で生まれる最新の知識を、日々リファクタリングによってコードベースに落とし込んでいるのです。
ユーザベースでの実践：XPがリファクタリングを「当然の取り組み」にする
リファクタリングは、ある程度独立したプラクティスとして行うこともできますが、XPのさまざまなプラクティスの網の目の中でこそ輝きを増します。
ここからは、例として以下のプラクティスとリファクタリングとの関わりについて掘り下げていきます。これらのプラクティスには、大きく分けて「リファクタリングをためらう理由をなくすもの」と「リファクタリングを推進するもの」があります。この点に注目しながら、それぞれの役割を見ていきましょう。
- テストファーストプログラミング（自動テスト / テスト駆動開発）
- 継続的インテグレーション
- ペアプログラミング
- コードの共有
テストファーストプログラミング（自動テスト / テスト駆動開発）
まず、リファクタリングに自動テストは欠かせません。『リファクタリング』でも明記されています。
リファクタリングは価値のあるツールですが、単体で成り立つものではありません。なんらかの誤りは必ずあり、それらを指摘してくれる堅牢なテストスイートが、適切なリファクタリングには必要です。
（Martin Fowler『リファクタリング（第2版）』オーム社、2019年、p.89）
テストファーストプログラミングは、リファクタリングに必要な自動テストが揃っている状態を導きます。さらに一歩進んで、私たちは前節でも触れたテスト駆動開発を全面的に取り入れています。*4リファクタリングはテスト駆動開発の構成要素の一つとなっています。いわゆるRed、Green、Refactorのサイクルです。テスト駆動開発ではこのサイクルをとても小さく繰り返していきます。*5
私が普段開発しているときには、数分に1回以上の頻度で自然にリファクタリングの機会が訪れます。
継続的インテグレーション
継続的インテグレーションでは、変更をため込まず、小さな変更を継続的にメインラインに統合していきます。そのため、安心してリファクタリングに取り組むことができます。
チームメンバーそれぞれが行ったリファクタリングが短時間で統合されることで、自分の変更が他のメンバーの変更と互いに競合していないことやシステムの振る舞い全体が壊れていないことが保証されるからです。もし壊れた場合にも気付けるので、問題をすぐに修正できます。
ペアプログラミング
ペアプログラミングも、リファクタリング開始の「嗅覚」を養うことに大きな役割を果たします。認知や思考、経験の異なる2人のプログラマが「リファクタリングした方がいいのではないか？」ということに注意を払い続けるからです。
私自身、ペアの相手に「リファクタリングしましょう！」と声をかけることが頻繁にあります。その場で得られた新たな知識を、すぐにコードベースへ反映したいからです。
ユニットテストや、E2Eテストが通ったあとに。新しいストーリーの開発を始める、最初の一歩として。時には、実装を始めてみたけれど、思いのほか変更が困難であることに気付き、「一度もとに戻して、先にリファクタリングしませんか？」と声をかけることもあります。
テストが通った後にリファクタリングすることの必要性は、テスト駆動開発の定義にも組み込まれていることもあり、経験の浅いエンジニアであっても比較的気付きやすいです。
しかし、ストーリーの開発を「始める」タイミングや、少しやりかけたあとに「戻って」リファクタリングする、といった判断の有効性は、経験豊富なエンジニアと一緒にペアプログラミングに取り組んでこそ、早く学べるのではないかと思います。
コードの共有
コードの共有は大前提です。ユーザベースでは「リファクタリングの許可を求める」ことはありません。前に述べたように、「新たに得た知識をコードベースに落とし込み、変化に適応し続ける」ための当然の実践だからです。
この節全体を通じて示したように、XPを実践しているとリファクタリングをためらう理由がなく（自動テスト、継続的インテグレーション、コードの共有）、リファクタリングを推進する力も働きます（テスト駆動開発、ペアプログラミング）。
これらが揃うことによって、リファクタリングはユーザベースにおける当然の取り組みとなり、開発の推進力となっているのだと思います。
補足として、XPのプラクティスではありませんが、ユーザベースで毎週金曜日に開催される「テックフォーラム」という場の役割にも触れておきます。
テックフォーラムはフリーテーマなのですが、ここでは、クリーンアーキテクチャやドメイン駆動設計のような「リファクタリングした結果、どのようなコードになっていると望ましいのか」に関する発表もあれば、テスト駆動開発やParallel Changeといった「リファクタリングを支える技術」についての発表もあります。このフォーラムが、組織全体のリファクタリング文化の推進に役立っています。
その効果は、日々のペアプログラミングの現場で発揮されます。「あのとき〇〇さんが話していたようなPortの単位にするといいと思うから……」とか、「ここではあのとき私が話したParallel Changeが使えるよ」とかいうふうに、文脈を共有した状態で会話ができるのです。
XPの5つの価値：リファクタリングが表現するチームのバリュー
リファクタリングはXPの他のプラクティスと支え合っているだけでなく、XPの価値とも深く結びついています。
私たちプロダクトチームは、チームとしてのバリューを5つ掲げており、それはXPの価値と同じ「コミュニケーション」「フィードバック」「リスペクト」「シンプルさ（シンプリシティ）」「勇気」です。*6
どのプラクティスもそうですが、リファクタリングもまた、それらの価値を表現する方法の一つと考えて日々取り組んでいます。ここからは、そうした実践の中で発見した、リファクタリングとXPの価値との関係性についてお伝えしていきます。
シンプリシティとフィードバック：シンプルだから、変えられる。変えられるから、シンプルにできる
まず、シンプリシティについて考えてみましょう。
シンプリシティはソフトウェア開発のさまざまな側面に関係がありますが、リファクタリングの文脈ではシンプルな設計に着目することになります。ここでは、Kent Beckが提唱する「シンプルな設計のルール」が参考になるでしょう。*7
- シンプルな設計のルール
- テストをパスさせる
- 意図を明らかにする
- 重複を排除する
- 要素を最小限にする
このようなシンプルな設計を実現したいものです。しかし、「リファクタリングがない世界」を想像してみると、その世界ではこのようにシンプルに設計することは簡単ではなくなります。将来発生しうるさまざまな変更の可能性に「備える」必要が出てくるからです。
日常的にリファクタリングを行うものであるという合意があれば、「今分かっていること」をもとに、安心して素直に「シンプルな設計のルール」にのっとったコードを書くことができます。
例えば、2つ目のルールは「意図を明らかにする」ですが、将来「意図」が加わったり、変更されたりしたとすれば、それを「明らかにする」かたちへとリファクタリングされるだろうと期待できるからです。
他方、もし「将来、リファクタリングが行われることはないだろう」と予想していれば、必ずしもシンプルなコードですませるわけにはいかなくなります。将来リファクタリングを行わなくても耐えられる、変更許容性の高そうな（ただし、現時点の要求に対しては過剰な）設計を採用したくなるでしょう。
例えば、リファクタリングが行われないだろうと想定した上で「意図を明らかにする」ルールを守ろうとすれば、将来の「意図」までを包含できるような抽象度の高い設計を行いたくなるかもしれません。
しかし将来は不確実です。その事前投資が功を奏する可能性もありますが、結局そのコードを変更することは少なく、ほとんど無駄に終わるかもしれません。さらに悪いケースとして、将来必要となる変更がもともと予想していたものと異なるケースが考えられます。その場合、過剰な設計がかえって変更の邪魔をしてしまうことにもなりかねません。
チームのみんなが、将来にわたって最もシンプルなコードへとリファクタリングし続ける。この共通認識があってこそ、安心して「今、シンプルなコードを書く」ことができる。そして、シンプルなコードは変更の容易なコードでもあるため、「リファクタリングし続ける」という約束自体を守りやすくします。
リファクタリングは、このような「シンプリシティの好循環」を作り出します。
さらに言えば、「リファクタリングし続けることによって、シンプルな設計を実現し続ける」という実践は、フィードバックを最大限に活用することでもあります。
ソフトウェア開発では、あらゆる側面からフィードバックが得られます。設計するに当たって、既存コードは読み取りやすいか。テストを書くに当たって、無理なくテストが書けるか。リリースされたコード（プロダクト）をユーザーが使った結果生じる、新たな要求やドメイン知識。これら全てのフィードバックが、リファクタリングによってコードベースに還元されます。コードを書き、動かし、得られた知識をコードに戻すのです。
将来を推測して備え過ぎることなく、コードをシンプルに保つ。この実践があってこそ、将来生じるフィードバックをリファクタリングによって容易に取り入れ、シンプルに保ち続けることができます。シンプリシティという価値とフィードバックという価値もまた、好循環の関係にあるのです。*8
コミュニケーションとリスペクト：過去と現在の知識を統合する
「シンプルに保つ」ということは、実はコミュニケーションとリスペクトの実践でもあります。
ユーザベースでは、3カ月周期で各チームのメンバー数名が他のチームに移動する「チームシャッフル」を実践しています。その影響もあり、「いま変更しようとしているコードは、もともと自分が書いたものではない」という状況が頻繁に生じます。こういうとき、皆さんならどう考え、行動するでしょうか？
何度か触れているように、リファクタリングとは「知識をコードベースに落とし込む実践」です。この見方から考えてみると、2つのことに気付きます。まず、今の自分は、今取り組んでいる要求（ストーリー）やその背景についての知識を持っていること。そして、これから変更しようとしている対象のコードや、それが書かれた背景についての知識は持っていないことです。
こんなとき、ユーザベースのエンジニアは、コミュニケーションの価値を体現すべく、過去にそのコードを書いた人（または、そのコードを書いたチームにいた人）と話をしに行きます。過去の知識と、現在の知識を統合し、統合された知識をもとにリファクタリングに取り組むのです。
コードをリファクタリングしたくなったら（過去に書かれたコードと、現在の知識とが調和していない状態）、そのコードを書いた人やチームと話す。経験上、結果はだいたい半々です。「当時はそこまで考えていなかった、だから今したいようにしてもらえばいいですよ」という返事が半分。そして、「ああ、それはね、これこれこういう理由があってそうなっているんですよ」という返事が半分です。
前者のケースでは、結果的には「現在の知識」があればリファクタリングするには十分だった、ということになります。しかし、後者のケースでコミュニケーションを取り損ねると、過去には分かっていたはずの知識がこぼれ落ちた「不完全な知識」をコードベースに埋め込んでしまうリスクがあります。だから、コミュニケーションが重要なのです。
また、過去のコード、そしてそれを書いた人との対話においては、リスペクトが欠かせません。目の前のコードは、今自分が向き合っている要求を実現するに当たって、必ずしも変更しやすいかたちになっていないかもしれません。しかしそれが示すのは、そのコードを書いた人が手を抜いていたとか、その人の能力が不足していたとかいったことでは決してありません。あくまで、過去時点の要求に誠実に向き合って、シンプルに実装した結果だと考えます。
過去時点の要求をシンプルに実装することで、過去時点のビジネスニーズを満たし、さらには（過去時点での推測のみにもとづく過剰な複雑性を埋め込まないことで）現在時点の要求に合わせてリファクタリングできる発展可能性を残してくれているのです。
だから、たとえ今の自分から見て奇妙なコードや設計に見えたとしても、いきなり「こうなっているのはおかしいのでは？」といったコミュニケーションを取ることはしません。純粋な質問として「どういう背景でこうなっているの？」といった聞き方をします。
今現在コードをシンプルに保つことは、将来そのコードを変更する人へのリスペクトであるとも言えます。つまり、将来そのコードを訪れる人が、（自分やチームに対して）コミュニケーションを取り、将来時点に存在する全ての知識を使って適切にリファクタリングしてくれると信じられるからこそ、現在時点の実装をシンプルに保てるわけです。
逆に、将来生じうる変更を推測し、将来の機能追加に備えるための複雑な設計をすることは、ある意味ではリスペクトが不足しているという言い方さえできるかもしれません。将来の人が将来時点の（最新の）知識で適切に設計する能力よりも、現在の自分が将来を推測して設計する能力の方を高く見積もっていることになるからです。
もちろん、将来の予測可能性や時間軸、組織内の人員構成などによって、どこまでを予測・推測するのが適切かは変動します。それでも、シンプリシティの実現のためには、「将来このコードを変更する人は、適切にリファクタリングしてくれるはずだ」というリスペクトの視点を忘れないことが重要だと私は考えています。
このリスペクトは、過去と現在の間で双方向につながるものです。
今度は逆に、現在時点から過去を眺め返してみましょう。過去の誰かが、現在の私をリスペクトして、過去時点において最善のシンプルなコードを残してくれた。であれば、現在の私が現在時点で最善のコードへとリファクタリングするために、過去にコードを書いた人としっかりとコミュニケーションを取ることは、その人へリスペクトを返すことでもあります。
小さな「勇気」：少しだけ、正しい方を選び続ける
最後の価値は「勇気」です。リファクタリングは、小さな勇気を発揮し続けることだと言えるでしょう。
ここまで読んでくれた方の中には、「自分はまだ経験の浅いエンジニアだから、先輩が書いたコードをいきなりリファクタリングするなんて恐れ多い」といったことを感じた方もいるかもしれません。
もしそう感じているなら、リファクタリングのことを大きく捉え過ぎているかもしれません。変数名を変えたり、空行の位置を動かしたりすることも立派なリファクタリングです。そして、どんなに優秀なエンジニアでも、将来的な変更を完全に見通すことはできません。今回あなたが行う変更によって、既存の変数の意味が微妙に変わったり、コードブロックのバランスが変化したり、といったことはきっとあるはずです。
それは決して悪いことではなく、変化の必然的な帰結として、新たな知識が生じているだけです。そういったことに敏感になり、現在時点でより適切なかたちへとリファクタリングすること。それこそが、変化に適応し続けていくXP（を含む、アジャイルソフトウェア開発）の実践における「少し怖いけど、正しいこと」です。
リファクタリングをすると、同じ機能を実現するのに、リファクタリングをしない場合よりも時間がかかってしまうのではないかと感じる方もいるでしょうか。
常にリファクタリングを行い続けていれば、個々の機能追加は比較的小規模なコード変更で実現できる場合が多くなるはずです。そして、ただ動けばよしとするのではなく、現時点の知識を十分反映したかたちへと（少しだけ）リファクタリングしておく。その繰り返しによって、チーム全体の生産性を高く保ち続けられるはずです。
また、開発を始める前に、あるいは開発を進めながら行うリファクタリングは、その開発自体の効率を上げる効果があるはずです。つまり、リファクタリングすると時間がかかるのではなく、リファクタリングしないと時間がかかるのです。*9
とはいえ、ある程度経験を積まないと、その確信は得られないでしょう。小さなステップですばやくリファクタリングする技術を習得するまでは、実地でリファクタリングを適用しながら習得するためにかかる時間が、リファクタリングの効果によって得られる時間を（短期的に）上回ってしまうこともあるかもしれません。
それでも、一度試してみる価値はあります。
リファクタリングは特別な活動ではありません。変数名を変える、重複を取り除く、責務を少し整理する。そうした小さな改善を積み重ねることで、コードベースは変化に適応し続けられるようになります。そして、その効果を実感できるようになれば、リファクタリングしないことの方が怖くなる場面が増えていくかもしれません。*10
AI時代にも、「リファクタリングする（動詞）」ことは重要であり続ける
現代では、コードを人間が直接書くのではなく、人間が指示を出し、AIエージェントがコードを書くことも一般的になってきています。そのような環境において、この記事で紹介してきたリファクタリングの原則はどのような意味を持つのでしょうか。「AIエージェントの時代にリファクタリングが持つ意味」を考えていきます。
まず、AIエージェントの時代に、リファクタリングは不要なのでしょうか。答えは「No」です。ソフトウェア開発が継続的な活動であり、新たなビジネスの要求という「知識」がその都度生まれ続ける限り、リファクタリングは必要不可欠だからです。
この記事で繰り返し示してきたとおり、リファクタリングは「知識をコードベースに落とし込む実践」です。そして、ソフトウェア開発は継続的な活動です。AIエージェントにたった一度だけ指示をして、永久に動作し続けるソフトウェアが完成することはもちろんありません。これからも、変化し続けるビジネスの要求に応じて、継続的にソフトウェアを変化させていくことが求められるでしょう。新たなビジネスの要求（という知識）は、その時点でしか手に入りません。だからこそ、それをコードベースに落とし込む活動が、その都度必要になるのです。
では、その「落とし込む」活動とは、具体的に何を指すのでしょうか。ここで改めて、リファクタリングの定義を確認します。
リファクタリング（名詞） 外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。
（中略）
リファクタリングする（動詞） 一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。
（Martin Fowler『リファクタリング（第2版）』オーム社、2019年、p.45）
新たな知識をコードベースに落とし込むためには、少なくとも、この定義における「リファクタリングする（動詞）」ことが必要になります。それが人間ではなくAIエージェントによって行われるとしても、依然として必要です。
リファクタリングは「外部から見たときの振る舞いを保つ」活動です。したがって、ソフトウェアの「外部から見た振る舞い」がいつ、どのように変更されても構わない（つまり、互換性は必要ない）という世界が訪れない限りは、この主張は有効でしょう。逆に言うと、そのようなソフトウェアに対しては、リファクタリングは不要です。それはAIエージェントを利用するか否かに直接は関係ありません。*11
ここから先は、AIエージェントの進化を踏まえた私自身の考察です。未来についての予測も含まれます。
小さな一つひとつのリファクタリング、Martin Fowlerの定義における「リファクタリング（名詞）」は、どこまで残るでしょうか。
これは、残るとしても、多くの部分をAIエージェントが代行することになる可能性があります。実際、AIエージェントは既に、関数やクラスを適切な単位に分けたり、適切な名前をつけ直したりといったことを、一つひとつ細かく指示しなくてもある程度行ってくれるようになっています。ユーザーである私たちが見るのはその結果であって、一つひとつのプロセスではありません。
では、「AIエージェントがこれからさらに進化したとしても残るであろうこと」という強い主張をどこまで具体的に行えるでしょうか。少し「勇気」を出して、それを試みようと思います。
まず「リファクタリングが機能するメカニズムと環境」は残るでしょう。振る舞いの変更と構造の変更を分けること。小さく、検証可能な単位で変更し、成否を継続的に検証すること。変更に失敗した場合には簡単にもとに戻せること、などです。『リファクタリング』で説明されているメカニズムや、これまでにも自動テストや継続的インテグレーションによって実現していた環境です。
また、XPの5つの価値についての議論もかなりの部分が有効だと思います。
AIエージェントにも将来的なビジネス要求の変化を見通すことはできません。仮にできたとしても、非効率です。*12ゆえに、シンプルな設計を保ち、リファクタリングによってフィードバックを反映し続けることは変わらず有効でしょう。
コミュニケーションの議論からは、「知識のありか」についてのヒントが得られます。つまり、リファクタリングを人間が行うにせよ、AIエージェントが行うにせよ、過去と現在の知識を統合する必要性は変わらないということです。
AIエージェントは知識が豊富であるがゆえに、将来を仮定した自信過剰な設計を行う場合もあります。その場合には、この記事で議論したような「将来（の誰か）へのリスペクト」を教えることも有効でしょう。最新の知識でリファクタリングし続けることが前提だから、将来を推測した過剰な設計は行わなくていい、ということです。
AIエージェントが仕事を片付けてくれるなら、リファクタリングに関してこまごまと面倒を見る必要はないのではないか、とも考えられるかもしれません。しかし、現時点ではまだそうなっているとは言えそうになく、また（いつ）そうなるかも分かりません。
そのため、リファクタリングはAIエージェント時代にも変わらず有効であると仮定し、AIエージェントによるリファクタリングに投資する勇気もまた必要となります。リファクタリングの初心者には小さなリファクタリングから始めることをおすすめしましたが、ここでも同じことが言えるでしょう。
これらの環境や価値・原則を担保し、活用していくことが、AIエージェント時代にリファクタリングを効果的に行い続けていくために重要だと私は考えます。
具体的には、継続的なテスト・統合用の環境を用意すること、そして価値や原則をAGENTS.mdやCLAUDE.md、スキルなどを通じてAIエージェントに伝えた上で、過去の設計判断に関する背景知識を（リファクタリングに役立つ粒度で）コンテキストとして利用できるようにすることが求められるでしょう。
いずれにせよ、これまで継続的なリファクタリングによって育ててきた「知識を埋め込んだコードベース」は、人間にとってもAIエージェントにとっても、これからも変わらず重要であり続けるはずです。
おわりに
この記事では、XPを全面的に実践するユーザベースでのリファクタリングへの取り組みについて、プラクティスと価値の両面から紹介し、AIエージェント時代に変わるものと変わらないものについて考えてきました。
リファクタリングを「知識をコードベースに落とし込む実践」と捉え、それをXPの実践の中で当たり前に続けていく。この考え方は、AIエージェント時代にも変わらない原則だと私は考えています。
ユーザベースでは、組織全体でリファクタリングを当たり前のものとして取り組んできましたが、今改めて、その価値はあった、と感じています。この記事で紹介してきたような原則を、程度の差こそあれ、みなが実践を通じて体得しているからです。
AIエージェント時代に、リファクタリングは変わる。でも、なくならない。
未来がどうなるかは分かりませんが、現時点では、自らリファクタリングを実践して獲得した原則への感覚は、AIエージェントに仕事を任せる上でも有用だと思います。
この記事を読んでくださった皆さんが、リファクタリングについて何か新しい視点を得ることができていれば幸いです。願わくば、何か取り入れられそうな部分を見つけて、自分でも実践してみていただければと思います。
編集・制作：はてな編集部
*1:ユーザベースではストーリー（ユーザーストーリー）を仕事の単位としています。
*2:このことを、Kent Beckの書籍『Tidy First?』では「振る舞いの変更と構造の変更を分ける」と表現しています。『Tidy First?』はリファクタリングのサブセットとしての「整頓」について書かれた本で、短くて読みやすく、おすすめです。
*3:というより、定義によれば「行えない」と言った方が正しいかもしれません。外部から見た振る舞いを保てないからです。
*4:テスト駆動開発はXPのプラクティスではありませんが、テストファーストプログラミングとインクリメンタルな設計という2つのプラクティスをより具体的なワークフローに落とし込んだものと言えるのではないかと思います。Kent Beckも書籍『エクストリームプログラミング』で、書籍『テスト駆動開発』を「テストファーストプログラミングとインクリメンタルな設計の入門書」と紹介しています。（引用はKent Beck『エクストリームプログラミング』オーム社、2015年、p.166より）
*5:テスト駆動開発について詳しく知りたい場合は、Kent Beckの書籍『テスト駆動開発』はもちろんですが、t-wadaさんの翻訳記事「テスト駆動開発の定義」もおすすめです。
*6:価値とバリューという2つの言葉が出てきましたが、同じものと捉えていただければ結構です。英語での表現はいずれも同じ「Values」です。他に「価値基準」と訳されることもありますが、この記事では書籍『エクストリームプログラミング』での訳語に従って「価値」としました。
*7:この「シンプルな設計のルール」については色々なバリエーションがありますが、この記事ではMartin Fowlerによる簡潔な表現を採用しています。日本語訳は「ケント・ベックの設計のルール」です。
*8:これは、Kent Beckが『Tidy First?』で「経験主義的ソフトウェア設計」と表現しているアイデアを、XPの価値の観点から説明したものと言えるかと思います。
*9:この考え方は、Kent BeckのXでのポストに簡潔に示されています。また、Ron Jeffriesの記事も参考になるでしょう。
*10:「（今後）変更されないコード」の品質、特に変更容易性はビジネスに影響しません。そのため、場合によっては「あえてリファクタリングしないこと」を選択すべき場面というのもあります。この記事ではこれ以上詳しく触れませんが、その場合には「リファクタリングしない勇気」が求められるでしょう。
*11:AIエージェントの台頭が、世の中におけるそのようなソフトウェア、例えば作り捨て、使い捨てに近いソフトウェアの割合を増やす可能性はあると思います。
*12:分かってからすればいいことを、がんばって予測する必要がないからです。
- 野口光太郎（のぐち・こうたろう） @enk_enk
- 株式会社ユーザベース ソフトウェアエンジニア / 『アジャイルリーダーシップ』翻訳チームメンバー。SIer、パッケージソフト企業を経て2019年にユーザベースに入社。Speedaの開発・運用に取り組みながら、日々エクストリームプログラミングを探求している。
