「リファクタリングが大事なのは分かってはいる。でも、タスクが山積みで手が回らない……」
多くのエンジニアが抱えるこのジレンマに、我々はどう向き合うべきか。
整えないまま積み上げるコードは、やがてどこかで限界を迎える。だが今は、生成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のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）『チームトポロジー』（日本能率協会マネジメントセンター）『ジョイ・インク』（翔泳社）など多数
ーーなぜリファクタリングは後回しにされがちなのか、お二人のご見解を聞かせてください。
安野：そうですね… まず挙げられるのは、やっぱり「経営陣への説明の難しさ」でしょうか。
これまでの経験から言っても、「いったん開発ペースを緩めて、リファクタリングした方がいい」と提言する場合、経営陣の理解を得るにはそれなりの工夫が必要でした。
特に、私が以前いた会社はエンタープライズSaaSだったので、顧客からの交渉圧力が強く、機能実装を優先せざるを得ない局面が多々ありましたから、リファクタリングのタイミングを見極めるのは非常に難しかったです。
もちろん、経営陣も営業サイドも、なるべく開発に支障をきたさないよう配慮はしてくれていたんですが、それでも戦略的に優先すべき機能開発などがどうしても積み上がりがちで……。そのバランスをどう取るかについては、毎回頭を悩ませていましたね。
吉羽：僕もその悩み、非常によく分かります。
安野さんがおっしゃる通り、プロダクトは当然ながら収益を上げなければなりませんよね。じゃないと、顧客の課題解決はおろか、従業員に給料を払えないし、組織が存続できない。ですからプロダクトの立ち上げ期や成長期には、機能開発が優先されがちな状況になるのも無理もないと思います。
エンジニアだって、事業成長のために日々コードを書いてることは、百も承知のはず。営業から「これができれば新しい契約取れるんですが……」なんて言われれば、どうしても機能開発を優先させてしまう。こうしたケースは、よくあることだと思います。
ーーそもそも、リファクタリングにまつわる問題の本質はどこにあるのでしょうか？
吉羽：結局は「それって持続できますか？」っていう、その一点に尽きると思うんです。
少なくとも僕が見てきた中では、「コードは常に綺麗に保たないといけない」とか「どんなプロダクトのどんなフェーズでもリファクタリングに時間割くべきだ」とか、そういう原理原則だけを振りかざすエンジニアには出会ったことがないですね。
むしろ「こんなやり方をずっと続けていると、いつか破綻してしまうんじゃないか？」という、漠然とした不安のようなものを抱えている。それが、現場のエンジニアたちのリアルな問題意識なんだと思います。
安野：実際のところ、リファクタリングと機能開発のバランスがうまくいっていると自負しているような会社さんって、存在するんですかね？
吉羽：「うちは完璧にやれてる」って会社は、僕の知る限りでは聞いたことないですね。
どの会社も多かれ少なかれ課題を感じているものですし、安野さんがおっしゃったように、現実と折り合いをつけながらなんとか凌いでいるというのが、正直なところだと思いますよ。
仮に「うちのコードは完璧にリファクタリングされていて、完璧な設計です」っていう会社があったとしても、「それって、プロダクトが売れてビジネスもうまくいってます？」っていう前提とセットじゃないと、あんまり意味がないというのが個人的な感覚です。
安野：なるほど。スタートアップから急激に大きくなった会社って、おしなべて「つぎはぎ」だらけのプロダクトが増えると思うんですが、これについてもいくつか捉え方があるかな、と。
「つぎはぎだらけだけど、ものすごい出力をしたからこそ、ここまで急成長できたんだ」っていう考えと「もうちょっとリファクタリングが行き届いていれば、今の比じゃないくらい成長余地はあった」という捉え方です。
一概には言えないと思いますが、吉羽さんはどちらが正解だと思われますか？
吉羽：どちらかというと「うちはレガシーコードを残しつつも、ガンガン出力したからこそ成長できた」という話を耳にすることが多い印象です。
とはいえ、僕らは「生き残った会社の話」しか聞けないので、正直、結果論なんだろうなとは思います。
とにかくプロダクトの売上を優先しなければならない状態なら、機能開発に集中するしかありません。でも安野さんがいた会社のように、エンタープライズのお客さんがたくさんついてくるようになれば、いずれ「成長を優先させるフェーズ」と「成長を持続させるっていうフェーズ」に切り替えるタイミングがくるはず。
その見極めを誤ったり、過去のやり方に固執したりして大事故につながる。そんなイメージですね。
安野：でも、リファクタリングの重要性が分かっていても、実際にはなかなか進まないケースって多いですよね。吉羽さんは「リファクタリングが必要な局面なのに、現場がなかなか踏み出せない」って状況、見たことありますか？
吉羽：僕はあまり遭遇したことないですが「ここを直すと別の場所が壊れるかも知れない」といった、あまりにもコードベースがひどい状態だと、精神的負荷がむちゃくちゃ大きいので、リファクタリングを避けたくなることはあるでしょうね。
他にも「動いている部分には一切触らず、新しいことをするときは似たようなものを量産する」ような考えがまかり通っている組織だと、リファクタリングに時間を割こうとは思わないでしょう。
ひどいコードベースが温存されたままなら、コードを読み解くだけでも大変でしょうから、どうしても出力は落ちてしまいます。やる気が削がれることはあっても、高まることはなさそうなので、いずれもっといい環境を求めて転職しそうですよね。
安野：確かに、コードベースの悪さがもたらすエンジニアの精神衛生って、めちゃくちゃ大きな問題ですよね。個人的には、以前から「エンジニアの精神衛生を改善するためのリファクタリング」というのは、考え方の一つとしてアリかなって思ってます。
実際に、他の経営メンバーにリファクタリングの必要性を説明するとき、「これはエンジニアの福利厚生施策でもあり、採用費用の削減にもつながる施策でもある」と話して理解を得たことがありました。
吉羽：経営陣全員がエンジニアリングのバックグラウンドがあるとは限りませんから、彼らに伝わる言葉で説明をするのは非常に重要ですよね。
僕が去年訳したケント・ベック著『Tidy First?』（オライリー・ジャパン）では、金融をメタファーに「リファクタリングはオプションを増やすプレミアム」と表現していました。
つまり「将来、プロダクトがどうなっているかは分からないけれど、その選択肢はなるべく多い方がいいですよね。今の段階で多少お金を払っておけば、将来取り得る選択肢が広がりますよ」ということです。
安野：確かに、リファクタリングの意義を馴染み深い金融に例えられると、経営陣も「なるほど」と、なりやすそうです。
ビジネス界隈でも時折耳にする「技術的負債」という表現と同じかも知れないですね。レガシーなコードは借金と同じで、直ちに返さなくちゃいけないものではないものの、「金利がかさめば、やがてボディブローのように経営に悪影響を及ぼす」というイメージが直感的に伝わりますから。
吉羽：はい。ですから「今、プレミアムを払う価値がどれぐらいあるのか？」という見極めがとても重要なんですよね。
プロダクトが長く生き残る可能性が高ければ、プレミアムの価値は高まりますけど、生きるか死ぬかが分からない状況なら「今プレミアムを払うよりも、目先の開発に集中して稼ごう」って選択になるわけですし。
プロダクトのフェーズを抜きにして、問答無用で「リファクタリングすべき」というのはかなり危険な物言いだと思います。
ITエンジニア向けスカウト転職サービス
に登録すると続きをお読みいただけます。会員登録後、画面が自動で更新されます。
取材・文／武田敏則 編集／今中康達（編集部）
タグ
