リファクタリングってどこまでやるべきなんだろう。
あるプロジェクトで、久しぶりにこの問いと正面から向き合うことになりました。動いているコードを「もっときれいに」したい衝動と、「今はそこじゃない」という声。どちらも正しくて、どちらも間違っている気がする。
正解がないからこそ、悩ましい。でも最近、この問いの前提そのものが変わってきているのではないか、と感じています。
安全に倒した結果、別の危険が生まれる
既存の機能を壊さないように開発を重ねていくと、コードの複雑度が上がり、逆に保守しにくくなる。これは多くのプロジェクトで起きていることだと思います。
既存コードに触れず、横に新しい分岐を足す。汎用化せずに似たようなコードをコピペする。「とりあえず動く」条件分岐をどんどん追加する。
短期的には安全です。でも積み重なると誰も全体を把握できなくなり、結果として「触ると何が起きるかわからない」状態になる。本末転倒ですよね。
これは昔からある話です。技術的負債という言葉で語られてきた問題でもあります。
初期は負債を積む、でもいつ返すのか
とはいえ、初期の開発では機能のリリースを優先してコードの品質が後回しになるのは、ある意味で自然なことです。最終的な形がまだ見えていないわけですから。
問題は、その負債を返すタイミングをどう見極めるか。
プロダクトが安定期に入ったとき。バグ修正に異常に時間がかかるようになったとき。チームに余裕ができたとき。いくつかの「潮目」はあります。
ただ、「いつか時間ができたらやる」は永遠に来ない。どこかで意思決定として「今やる」と決める必要がある。でもそれは、プロダクトが軌道に乗って初めて許される贅沢でもある。
この問いに対して、私自身は「今の目的に対して十分か」を基準にするのが現実的だと考えてきました。でも、最近この基準自体が揺らいでいます。
AI時代の技術的負債は性質が違う
特に最近だと、AIネイティブで開発を進めていった結果、いつのまにか管理できないコードが生まれている、という現象が起きています。
従来の負債とは性質が違う部分があります。
理解を伴わないコードが増える。人間が一行ずつ書いたコードは、少なくとも書いた本人は理解しています。でもAIに生成させると「動いたからOK」で、なぜそう書かれたかを誰も把握していない。
一貫性がない。同じプロジェクト内でスタイルや設計パターンがバラバラになる。AIは文脈を毎回リセットしがちです。
過剰に複雑なコードが生まれやすい。AIは「正しく動く」ことは得意ですが、「シンプルに保つ」意識が弱い。エッジケースを聞くたびに条件分岐が増えていく。
これを「理解の負債」と呼んでみました。書くコストが下がった分、読んで理解するコストの比重が上がっている、と。
でも、本当にそうなのか
ところが、ここで前提が崩れ始めます。
実は最近、コードを読んで理解しようということをあまりやっていないんです。AIに読んでもらって、そのコードの概要を教えてもらっている。細かく知りたいときはその仕様を聞くようにしている。
実際、人にとっては理解しにくいコードであっても、AIの方が早く確実に情報を紐解いてくれる。
だとすると、「理解の負債」というのはどのくらい重いものなのか。正直、よくわからなくなってきました。
AIに聞けば済む、で回らなくなる瞬間
もちろん、すべてがうまくいくわけではありません。
AIに不具合の指摘をして、問題箇所の特定をしてもらって改善してもらう。でも何度も何度もやっても根本原因の特定までたどり着かない。デバッグ用のコードが無作為に仕込まれて、結局問題解決しない。
こういうとき、イラッとします。
あの現象、独特のストレスがあるんですよね。人間のデバッグなら、たとえ時間がかかっても「ここは違った、次はこっちを疑おう」と絞り込んでいく感覚がある。でもAIは同じようなところをぐるぐる回ったり、「とりあえずログ入れてみました」を繰り返したりする。
試行錯誤しているようで、実は何も学習していない。そしてコードだけが汚れていく。
リファクタリングは「誰のため」なのか
ここで最初の問いに戻ります。
結局、リファクタリングが必要なのは変わらない。ただ、その目的が変わってきているのではないか。
昔は「人間にとっての可読性」が前提でした。変数名がわかりやすいとか、関数が短いとか。全部「人が読むから」という理由だった。
でも今、AIが十分に正確にコードを解釈できるなら、その前提が崩れる。
AIのためのリファクタリング。
スコープを小さく保つ。AIが一度に把握できる範囲を超えると精度が落ちる。
依存関係を明確にする。暗黙の結合が多いと、AIが影響範囲を見誤る。
状態を減らす。グローバルな状態や副作用が多いと、AIは追跡できなくなる。
テストを増やす。AIが変更を加えたときに、壊れたかどうかを即座に判定できる。
これって昔から言われている「良い設計」の原則と重なるんですが、理由が変わっています。「人間が読みやすいから」ではなく「AIが正確に扱えるから」になっている。
人間とAIで最適解は違うのか
ただ、ここで新しい問いが生まれます。
人間は「流れ」で理解します。上から下に読んでいって、ストーリーとして頭に入れる。だから途中で別ファイルに飛ばされると文脈が途切れる。
でもAIにとっては、関数が呼ばれたら定義を見に行くコストがほぼゼロです。分割されていても困らない。むしろ一つの塊が大きいと、どこが本質でどこが枝葉か区別しにくくなる。
共通化についても同じです。人間が「共通化しすぎ」を嫌がるのは、影響範囲が見えなくなるから。でもAIは参照箇所を列挙するのは得意です。
つまり、人間とAIで最適な設計が違う可能性がある。
これからはAIにとっての読みやすさを優先すべきか
人間がコードを読む機会自体が減っていくのなら。読むときもAIに説明させればいいのなら。
だったら、コードそのものは「AIが正確に扱える形」に最適化しておいて、人間向けの説明は必要になったときに生成すればいい。
これは割り切った判断です。でも、筋は通っている気もします。
ドキュメントを書くのと似た話かもしれません。コードとドキュメントを二重管理するより、コードを正として、ドキュメントは都度生成する方が合理的。この流れはすでにあります。
でも、正解がわからない
正直に言うと、確立した答えはありません。
AIにとって扱いやすいコードの「正解」が、まだ誰もわかっていない。今の感覚で分割や抽象化を進めても、実はそれがベストじゃない可能性があります。
あと、AIの世代が変わったら最適解も変わるかもしれない。今のモデルに合わせて最適化したコードが、次のモデルでは逆に扱いにくい、とか。
でも、正解がわからないから何もしない、だといつまでも進まない。
今あるAIにとって扱いやすい形にしておいて、変わったらまたAIに直させればいい。人間が保守するよりは変更コストが低いはず。そう考えることもできます。
残る問い
リファクタリングの基準は「AIがデバッグで迷走しない粒度」になるのか。
人間にとっての可読性は、本当に二の次でいいのか。
そもそも「良いコード」の定義は、これから書き換わっていくのか。
私自身、まだ答えが見えていません。
ただ一つ言えるのは、「誰のための可読性か」を問い直す時期に来ているということ。そして、その答えは現場で試行錯誤する中からしか出てこない、ということです。
あなたは、誰のためにコードを書いていますか？
参考書籍
リファクタリングの具体的な手法を学びたい方には、こちらの書籍がおすすめです。「5行ルール」という明確な基準を使って、コードを段階的に改善していく実践的なアプローチが紹介されています。
[📦 商品リンク: moshimo-book-5line-refactoring]