Yahoo! JAPAN

「リファクタリングが大事なのは分かってはいる。でも、タスクが山積みで手が回らない……」

多くのエンジニアが抱えるこのジレンマに、我々はどう向き合うべきか。

整えないまま積み上げるコードは、やがてどこかで限界を迎える。だが今は、生成AIがコードを書き、設計まで担いはじめた時代だ。「コードを整える」ことの意味そのものが、大きく揺らぎつつある。

こうした変化の渦中にある今、改めてリファクタリングの本質と向き合いたい。

そこで今回、AIスタートアップの創業や技術顧問の経験をもつエンジニア・安野貴博さんと、ケント・ベック著『Tidy First?』（オライリー・ジャパン）の訳者でアジャイルコーチとして数々の実績を持つ吉羽 龍太郎さんによる対談を実施。

現場と経営、テクノロジーと組織。

両者の視点から掘り下げた本対談は、リファクタリングを「手が回らないタスク」ではなく、プロダクトの持続性と組織の健全性を左右する「戦略」として捉え直す試みとなった。

安野貴博さん（@takahiroanno）

AIエンジニア、起業家、SF作家。1990年、東京生まれ。開成高校を卒業後、東京大学工学部システム創成学科へ進学。「AI戦略会議」で座長を務める松尾豊教授の研究室を卒業。外資系コンサルティング会社のボストン・コンサルティング・グループを経てAIスタートアップ企業を二社創業。デジタルを通じた社会システム変革に携わる。未踏スーパークリエータ。デジタル庁デジタル法制ワーキンググループ構成員。日本SF作家クラブ会員。2024年、東京都知事選に出馬、一般財団法人GovTech東京 アドバイザー就任、デジタル民主主義2030プロジェクト発足、AIを活用した双方向型のコミュニケーションを実践

株式会社アトラクタ
Founder兼CTO/アジャイルコーチ
吉羽 龍太郎さん（@ryuzee）

野村総合研究所、Amazon Web Servicesなどを経て現職。アジャイル開発、DevOps、組織開発を中心としたコンサルティングやトレーニングが専門。Scrum Alliance認定スクラムトレーナー。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）など、訳書に『ダイナミックリチーミング』『Tidy First?』『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）『チームトポロジー』（日本能率協会マネジメントセンター）『ジョイ・インク』（翔泳社）など多数

目次

「綺麗か」ではなく「続けられるか」リファクタリングは、将来の選択肢を増やす「特典」リファクタリングの投下タイミングは「PMF前後」で変わるAIの登場で、技術的負債はマクロへと向かう

「綺麗か」ではなく「続けられるか」

ーーなぜリファクタリングは後回しにされがちなのか、お二人のご見解を聞かせてください。

安野：そうですね… まず挙げられるのは、やっぱり「経営陣への説明の難しさ」でしょうか。

これまでの経験から言っても、「いったん開発ペースを緩めて、リファクタリングした方がいい」と提言する場合、経営陣の理解を得るにはそれなりの工夫が必要でした。

特に、私が以前いた会社はエンタープライズSaaSだったので、顧客からの交渉圧力が強く、機能実装を優先せざるを得ない局面が多々ありましたから、リファクタリングのタイミングを見極めるのは非常に難しかったです。

もちろん、経営陣も営業サイドも、なるべく開発に支障をきたさないよう配慮はしてくれていたんですが、それでも戦略的に優先すべき機能開発などがどうしても積み上がりがちで……。そのバランスをどう取るかについては、毎回頭を悩ませていましたね。

吉羽：僕もその悩み、非常によく分かります。

安野さんがおっしゃる通り、プロダクトは当然ながら収益を上げなければなりませんよね。じゃないと、顧客の課題解決はおろか、従業員に給料を払えないし、組織が存続できない。ですからプロダクトの立ち上げ期や成長期には、機能開発が優先されがちな状況になるのも無理もないと思います。

エンジニアだって、事業成長のために日々コードを書いてることは、百も承知のはず。営業から「これができれば新しい契約取れるんですが……」なんて言われれば、どうしても機能開発を優先させてしまう。こうしたケースは、よくあることだと思います。

ーーそもそも、リファクタリングにまつわる問題の本質はどこにあるのでしょうか？

吉羽：結局は「それって持続できますか？」っていう、その一点に尽きると思うんです。

少なくとも僕が見てきた中では、「コードは常に綺麗に保たないといけない」とか「どんなプロダクトのどんなフェーズでもリファクタリングに時間割くべきだ」とか、そういう原理原則だけを振りかざすエンジニアには出会ったことがないですね。

むしろ「こんなやり方をずっと続けていると、いつか破綻してしまうんじゃないか？」という、漠然とした不安のようなものを抱えている。それが、現場のエンジニアたちのリアルな問題意識なんだと思います。

安野：実際のところ、リファクタリングと機能開発のバランスがうまくいっていると自負しているような会社さんって、存在するんですかね？

吉羽：「うちは完璧にやれてる」って会社は、僕の知る限りでは聞いたことないですね。

どの会社も多かれ少なかれ課題を感じているものですし、安野さんがおっしゃったように、現実と折り合いをつけながらなんとか凌いでいるというのが、正直なところだと思いますよ。

仮に「うちのコードは完璧にリファクタリングされていて、完璧な設計です」っていう会社があったとしても、「それって、プロダクトが売れてビジネスもうまくいってます？」っていう前提とセットじゃないと、あんまり意味がないというのが個人的な感覚です。

安野：なるほど。スタートアップから急激に大きくなった会社って、おしなべて「つぎはぎ」だらけのプロダクトが増えると思うんですが、これについてもいくつか捉え方があるかな、と。

「つぎはぎだらけだけど、ものすごい出力をしたからこそ、ここまで急成長できたんだ」っていう考えと「もうちょっとリファクタリングが行き届いていれば、今の比じゃないくらい成長余地はあった」という捉え方です。

一概には言えないと思いますが、吉羽さんはどちらが正解だと思われますか？

吉羽：どちらかというと「うちはレガシーコードを残しつつも、ガンガン出力したからこそ成長できた」という話を耳にすることが多い印象です。

とはいえ、僕らは「生き残った会社の話」しか聞けないので、正直、結果論なんだろうなとは思います。

とにかくプロダクトの売上を優先しなければならない状態なら、機能開発に集中するしかありません。でも安野さんがいた会社のように、エンタープライズのお客さんがたくさんついてくるようになれば、いずれ「成長を優先させるフェーズ」と「成長を持続させるっていうフェーズ」に切り替えるタイミングがくるはず。

その見極めを誤ったり、過去のやり方に固執したりして大事故につながる。そんなイメージですね。

リファクタリングは、将来の選択肢を増やす「特典」

安野：でも、リファクタリングの重要性が分かっていても、実際にはなかなか進まないケースって多いですよね。吉羽さんは「リファクタリングが必要な局面なのに、現場がなかなか踏み出せない」って状況、見たことありますか？

吉羽：僕はあまり遭遇したことないですが「ここを直すと別の場所が壊れるかも知れない」といった、あまりにもコードベースがひどい状態だと、精神的負荷がむちゃくちゃ大きいので、リファクタリングを避けたくなることはあるでしょうね。

他にも「動いている部分には一切触らず、新しいことをするときは似たようなものを量産する」ような考えがまかり通っている組織だと、リファクタリングに時間を割こうとは思わないでしょう。

ひどいコードベースが温存されたままなら、コードを読み解くだけでも大変でしょうから、どうしても出力は落ちてしまいます。やる気が削がれることはあっても、高まることはなさそうなので、いずれもっといい環境を求めて転職しそうですよね。

安野：確かに、コードベースの悪さがもたらすエンジニアの精神衛生って、めちゃくちゃ大きな問題ですよね。個人的には、以前から「エンジニアの精神衛生を改善するためのリファクタリング」というのは、考え方の一つとしてアリかなって思ってます。

実際に、他の経営メンバーにリファクタリングの必要性を説明するとき、「これはエンジニアの福利厚生施策でもあり、採用費用の削減にもつながる施策でもある」と話して理解を得たことがありました。

吉羽：経営陣全員がエンジニアリングのバックグラウンドがあるとは限りませんから、彼らに伝わる言葉で説明をするのは非常に重要ですよね。

僕が去年訳したケント・ベック著『Tidy First?』（オライリー・ジャパン）では、金融をメタファーに「リファクタリングはオプションを増やすプレミアム」と表現していました。

つまり「将来、プロダクトがどうなっているかは分からないけれど、その選択肢はなるべく多い方がいいですよね。今の段階で多少お金を払っておけば、将来取り得る選択肢が広がりますよ」ということです。

安野：確かに、リファクタリングの意義を馴染み深い金融に例えられると、経営陣も「なるほど」と、なりやすそうです。

ビジネス界隈でも時折耳にする「技術的負債」という表現と同じかも知れないですね。レガシーなコードは借金と同じで、直ちに返さなくちゃいけないものではないものの、「金利がかさめば、やがてボディブローのように経営に悪影響を及ぼす」というイメージが直感的に伝わりますから。

吉羽：はい。ですから「今、プレミアムを払う価値がどれぐらいあるのか？」という見極めがとても重要なんですよね。

プロダクトが長く生き残る可能性が高ければ、プレミアムの価値は高まりますけど、生きるか死ぬかが分からない状況なら「今プレミアムを払うよりも、目先の開発に集中して稼ごう」って選択になるわけですし。

プロダクトのフェーズを抜きにして、問答無用で「リファクタリングすべき」というのはかなり危険な物言いだと思います。

リファクタリングの投下タイミングは「PMF前後」で変わる

ーー会社やプロダクトが「この状態なら必ずやるべき」といった、見極めのポイントはありますか？

吉羽：大前提として、リファクタリングは必ずしもゼロイチとは限りません。それこそ、急成長中で機能開発を優先しているケースでも、リファクタリングがまったくされてないわけではありません。

ーーと、いいますと？

吉羽：エンジニアの日々の営みのなかで、自然に行われるリファクタリングはたくさんあります。

例えば、先ほども引き合いに出したケント・ベックの言葉を借りると「ソースコードの文脈が変わるところで空行を1行入れる」「不要なコメントは削除する」などが代表的な取り組みです。

リファクタリングは特定フェーズで行う特別な施策とは限らないことは、知っておいてほしいですね。

安野：リファクタリングを怠ったからといって、いきなりノックアウトされるわけではなく、実際はちょっとずつ選択肢が減っていき、いつの間にか身動きが取れなくなっていく……なんだか「ゆでガエル」みたいなイメージですよね（笑）

吉羽：分かります（笑）

技術的負債が溜まるに従って開発スピードが落ちていきますし、そこから抜け出すには、すさまじい量のソースコードを書き換えなきゃならなくなり、投資判断がさらに難しくなる。まさに「ゆでガエル」ですね。

安野：とはいえ、一つポイントがあるとすれば「プロダクトがPMF（*）を達成したタイミング」じゃないですかね。

プロダクトがいつピボットするか分からないPMF前の状態でコードを整えるのは、ビジネスモデルが変わった場合に無駄な投資になりかねません。その一方、 PMF後であればその不確実性はかなり下がるので、判断しやすくなります。

(*)「Product Market Fit (プロダクト マーケット フィット)」の略。顧客のニーズを満たす製品を、適切な市場で展開し、受け入れられている状態の意

ーースタートアップではなく、すでに実績のあるビッグテックの場合だと事情は変わりますか？

安野：どうなんでしょう。僕はビッグテックの事情にそこまで詳しくないので、ここはぜひ吉羽さんのご意見を聞いてみたいです。

例えば、1990年代の終わりから2000年代初頭にかけて生まれた「老舗」インターネットサービスだとどうでしょう？ 「確かに儲かってはいるんだけれど、大きくなりすぎて抜本的なリファクタリングがしづらい」会社もありそうですが。

吉羽：プロダクトが成長する余地があるかどうかで判断することになるんでしょうね。「稼げるだけ稼いだら、後はシュリンクするだけなので安定運用すればいい」という選択もあるかも知れません。

安野：確かに、安定運用フェーズに入ったら、ほぼセキュリティのアップデート以外は触らないというのはあり得るでしょうね。

あともう一つ、やっぱり難しいなと思っているのが、リファクタリングが将来の選択肢を買うことだとしても、何から何へ変えるべきかを決めるのって悩ましいですよね。その見立ての難しさは、まさに「アート」だと思います。

同じプロダクトに携わっているエンジニア同士でも見解が違うこともあるし、その辺りについてはどうお考えですか？

吉羽：そうですね……難しいポイントですよね。

一つ言えるのは、一般的な傾向として、ソースコードの変更って特定ファイルに集中しがちですよね。だとすると、めったに触らないコードを綺麗にするより、よく触るコードをリファクタリングするほうがメリットがあるのは明らか。

もちろん、きちんと分析した上で判断すべきではあるんですが、「よく触るけど、扱いづらいところから手を入れましょう」というのが、僕からのアドバイスですね。

安野：確かに。それならめちゃくちゃクリアに判断できますね。

吉羽：そうですね。例えばですが、Gitのログを見て「どのファイルにどれぐらいの変更が入ってるか」メトリクスを取って「このあたりのファイル群は匂いますね」と、おおよその当たりをつけてから取り組むといいと思います。

エンジニアの善意がコードを複雑にする？ “改良したい欲”に駆られる前に知りたい「コーディングの鉄則」とはhttps://type.jp/et/feature/26789/

AIの登場で、技術的負債はマクロへと向かう

ーー開発現場にも生成AIがどんどん入ってきています。AIが一定のルールに基づいて自律的に行うなど、リファクタリングを仕組み化することは可能なのでしょうか？

吉羽：この点については安野さんに補足していただけると助かりますが、現在、急速に仕組み化が進んでいる領域と言えるのではないでしょうか。

すでに「こういうプロダクトをつくりたい」と具体的に指示を出せば、設計からコード出力までできますし「この設計とこの設計で迷っているんだけど、どっちがいい？」と聞けば、答えを返してくれる時代です。

静的解析で不適切なコードをあぶり出すだけで、いまやAIが文脈まで踏まえてレビューしてくれるので、リファクタリングの質も大きく変わっていくと思います。

安野：おっしゃる通りだと思いますが、一方で課題も感じています。

AIアシストによるコーディングもそうですが、自律型AIソフトウエアエンジニアを標榜する「Devin」のようなツールも出てきており、ソースコードの詳細を把握していなくても、ものすごい行数のコードをあっという間に生成できるようになりました。

これは非常に便利だと思う反面、裏を返せば、人類がこれまで経験したことのないスピードで負債が積み上がる可能性は否定できません。

いずれ、AIに指示を出すだけでプログラミングが完了する「バイブコーディング」ならぬ「バイブリファクタリング」が求められるようになるかも知れませんが、どこまで実現できるかは未知数。今後どうなっていくのか、非常に面白いテーマですね。

吉羽：ちょっと前までは、メンテナンス不能なコードは「現場の力量があまりにも低いがゆえに生まれてしまう」という認識がありました。ただ、生成AIによるコーディングが普及すると、「目に余るようなコード」は物理的に書けなくなるというか……。

そう考えると、AIの登場によってまた別の問題が浮上してくるのはあり得そうな展開ですよね。経験豊富なエンジニアからすれば「違和感がある」けど、ジュニアにとっては「どこが悪いのか分からない」コードが量産されることになりそうじゃないですか？

安野：同感ですね。ミクロな「よくないコード」は減る一方で、例えば「なんでこのファイルに書かなくてこっちに書いたの？」とか「ロジックが想定したものと全然違うんだけど」とか、マクロな負債が猛スピードで溜まっていくイメージがあります。

「技術的負債の矛先が、コードレベルから設計レベルに向く」とでも言ったらいいんでしょうか。なので当面は、シニアエンジニアの目利き力がとても重要な開発資源になりそうですね。

吉羽：全くもって同意です。ただ、今後はどうなんですかね。AIを使いまくることで、ジュニアからシニアにステップアップするキャリアパスが消えてしまうんじゃないか、という懸念も感じてて。

AIを使ってコードを生成するうちにシニアになる未来があるのか、はたまた別の取り組みが必要になるのか。そこはまだ分からないというのが、今の正直な気持ちです。

安野：これまでの経緯を踏まえると、シニアの目利き力もAIに任せられる時代がきそうな気がしますが、どうでしょう？

必要なタイミングでパパッとプロダクトをつくって、仕様が変わったらゼロからバイブコーディングし直すことが当たり前になったら、人材育成や組織作りを、根本から見直さないといけないと思うのですが。

吉羽：そうですね。ユーザーインタビューを重ねて、いけそうだと確信を得てから開発に着手するのでなく、AIにコードをバンバン生成させて、市場にぶつけてから検証を重ねて改善する手法が当たり前になったら、自ずと人材育成や組織のあり方も変わるでしょうね。

僕の専門であるスクラムやアジャイルにしても、「1週間ごとに期間を区切って開発するのが本当に正しいのか？」という疑問が生まれてもおかしくない。それこそ「もっと別の高速なやり方を採るべき」という話になるかもしれないし。

いずれにしても、大きなパラダイムシフトが起こる可能性があるのは確かですね。

安野：「今月はDevin3人で開発を賄うけど、来月は繁忙期だからDevinを300人に拡張する」みたいな、今までにないレベルでエンジニアリソースがスケーリングできるようになったら、AIと人間のベストバランスはどう考えるべきなんですかね……。

現時点で答えを持っているわけではないのですが、まさにパラダイムシフトが起こりはじめた過渡期ならではの大きな課題だと思っています。

ーーAIがリファクタリングを支援するようになる中で、エンジニア自身のスキルや心構えとして、リファクタリングにどう向き合っていくべきだとお考えですか？

吉羽：AIの力でリファクタリングにかかる労力は減りますが、プロダクトが成長する過程でプロダクトの方向性が変わることはよくあることですし、リファクタリングがゼロにはなることはありません。

ただし、AIによってリファクタリングの敷居は間違いなく下がります。まとまったリファクタリングを避ける意味でも、あまり気負わず、日常業務の延長で見直しを進めればいいと思います。

「ボーイスカウト・ルール」(*)ってありますけど、それくらいのイメージで大丈夫です。

(*)「自分のいた場所は、そこを出て行く時、来た時よりもきれいにしなければならない」という、ボーイ・スカウトの考え方

安野：リファクタリング一つをとっても、AIにどこまで任せるべきか、明確な線引きはまだ難しい状況です。

だからこそ、変化に即応できるよう、日頃から新しい技術や手法をリサーチしたり、実際に試してみたりすることは、非常に投資対効果の高い取り組みだと思います。ぜひ積極的に行ってほしいですね。

吉羽：そういう意味では、マネジメント層の方々は、現場が日々の開発業務に追われすぎないよう、チームビルディングやスケジューリングに努めるべきでしょう。

将来のための改善や学習の時間が取れない状態が続くと、場当たり的な対応が増え「焼畑農業」のような状態に陥り、プロダクトの持続可能性が損なわれかねません。

エンジニアの向上心や主体性を信じて、業務時間内でコードをリファクタリングしたり、最新のメソッドやツールを試したりできる余裕を作るよう、努力してほしいですね。

安野：これほど大きなパラダイムシフトに立ち会える機会は、そう滅多にありません。

社会人やプログラマーとしての経験が浅くても、AI活用のスキルや知識という面では、シニアエンジニアにも勝るチャンスが大いにある。若いエンジニアの皆さんは、まさに今が頑張り時ですね。

吉羽：先日、OpenAIがMCP（Model Context Protocol）をサポートすると発表し、エンジニア界隈で随分と話題になりましたが、今後もAIでできることは増え、開発はさらに便利になっていくはずです。

この変化の波に乗り、恐れずにどんどん新しいことにチャレンジしてほしいですね。

取材・文／武田敏則　編集／今中康達（編集部）