Tidy First方法論：Kent BeckのAugmented Codingの解釈と適用
チョン・ドヒョン - ROBOCO首席コンサルタント
最近、私はClaude Codeを主な作業ツールとして使っています。Claude Codeが卓越した性能を見せる理由は、作業を即座に実行するのではなく、作業全体を体系的に計画したうえで、小さく明確なステップに分けて順に遂行するからです。
今日はこれに加えて、もう一つ有用な方法論を紹介したいと思います。TDD（Test Driven Development）の創始者として有名なKent Beckが自身のブログで提案した「Augmented Coding」というアプローチです。この方も用語作りに執着している様子を見ると、バイブコーディングという大きな流れに早々と便乗しようとしているようです。しかし私は、このアプローチがKent Beckがこれまでに書いた本——Tidy First?（ケント・ベック著）——の内容に基づいているため、勝手ながら「Tidy First方法論」と呼ぶことにしました。
TL;DR
- Tidy Firstは、構造的変化と振る舞いの変化を分離することで、AIとともにコーディングする際の複雑さを下げるアプローチです。
- まずコードを整理してテストで検証し、そのうえで機能の変更を入れてこそ、作業の流れが揺らぎません。
- Claude Codeのようなツールと併せて使えば、開発者がコードの品質と方向性に対する主導権を保ちやすくなります。
Augmented CodingとTidy Firstの核心
Kent Beckが語るAugmented Codingの核心は、コーディング作業を構造的変化（Structural Changes）と振る舞いの変化（Behavioral Changes）の二つに明確に分けることです。構造的変化とは、コードの動作を変えずに単にコードの位置を変えたり、名前を変更したり、メソッドを抽出したりする作業を指します。振る舞いの変化とは、実際にコードの機能を追加したり修正したりする作業です。
Beckは、この二つの変化が決して一つのコミット（commit）に混ざってはならないと強調します。特に、構造的変化を常に優先して処理し、それによってコードの複雑さを下げた状態で明確なテスト環境を維持したうえで、振る舞いの変化を導入すべきだと説明しています。
Kent Beckが示したルール
Kent Beckが実際にプロジェクトで使った「Tidy First」のルールは次のとおりです。
- 常にTDDサイクル（レッド→グリーン→リファクタリング）を厳格に守る。
- 最も単純な失敗するテストを先に書く。
- 最小限のコードでテストを通し、それ以上のことはしない。
- テストが通ったあとにのみリファクタリングする。
- 構造的変化と振る舞いの変化を分離し、コミットを明確に区別する。
- すべてのテストが通り、警告がなく、作業の論理的単位が明確なときにのみコミットする。
- コードの重複を徹底的に排除し、明確な名前と構造で意図を表現する。
- メソッドは小さく保ち、一つの責務だけを担わせる。
このような明確なルールを守りながらコーディングを進めれば、コードは複雑さと不要な機能追加を防ぎつつ、段階的に堅牢で理解しやすいものになっていきます。
Tidy Firstの実際の適用と利点
筆者がClaude Codeとともにこの「Tidy First方法論」を実際のプロジェクトに適用してみた結果、ほとんどのプロジェクトで非常に効果的に機能しました。構造的変化から始めてコードベースをきれいに保ったうえで振る舞いの変化を導入すれば、コードが複雑になって途中で道に迷うことが大幅に減ります。
Kent BeckがB+ Treeプロジェクトで明らかにしたように、AI（GenAI）が時として不要な機能を追加したり、コードが複雑になって開発速度が低下したりすることがあります。これを防ぐには、常にまず構造的な整理作業を行い、その作業がテストによって正確に検証されたあとにはじめて、次の機能的な変化を追加すべきです。
「Tidy First方法論」は、AIとともに作業する際に開発者がコードに対する主導権と明確さを維持できるようにしてくれ、コードの品質と複雑さを管理するうえで大きな助けになります。
この方法論は、みなさんのプロジェクトにもきっと効果的でしょう。ぜひ一度試してみることを強くおすすめします。