はじめに
ここ数年、既存システムの改善やリファクタリングに向き合う機会が増えてきた。
筆者がエンジニアになって最初に勤めた会社の時の話にはなるが、とあるサービスの料金計算ロジックに小さな仕様変更を入れるタスクを担当したことがある。
仕様としては「割引条件を1つ追加するだけ」のはずだったが、実際に触るコードは2,000行オーバーのクラスで、if文とフラグとコメントが何年分も積み重なっていた。
- どこに手を入れるのが正解なのかが一目ではわからない
- テストも乏しく、影響範囲の見通しも悪い
- ちゃんと分割して整理し直したいが、工数の割に合わない。
結局そのときは、既存の条件分岐の枝にさらにif文を差し込み、「本当は分割したい」というTODOコメントだけを残してマージした。
動作としては正しいが、技術的負債を利息付きで積み増したような、何とも言えない後味が残った。
このときに感じていたモヤモヤを言語化すると、だいたい次の二つになる。
- 設計をきれいにしたいが、どこから手をつければよいかわからない
- 大掃除レベルのリファクタリングをする余裕はないが、モヤモヤはある
今回手に取ったのは、Kent Beckの『Tidy First? ― 個人で実践する経験主義的ソフトウェア設計』という本。
オライリーから出ている比較的薄い技術書だが、コードの「片付け方」と「片付けるタイミング」にかなり焦点を当てた本になっている。
この記事では、本の内容を網羅的に紹介することは目的とせず、「Tidy First?」を読んで、自分の開発スタイルやチームでの仕事の進め方をどう変えたいと思ったか、という観点で整理してみることにする。
「Tidy First?」はどんな本か
本の構成
本の構成はおおまかに次の3部に分かれている。
- Part I: Tidyings（片付けのパターン集）
- Part II: Managing（いつ／どこまで片付けるかのマネジメント）
- Part III: Theory（設計を支える理論・経済性の話）
全体としてコンパクトな分量で、「読み切って終わり」というよりは、「必要なときに特定の章だけ読み返す」タイプの本になっていると感じた。
「Tidying」と「Refactoring」の違い
本書のキーコンセプトはタイトルどおり「Tidy（片付け）」。著者は、tidyingを「リファクタリングの部分集合」と位置づけている。
自分なりに整理すると、次のような関係になる。
- リファクタリング
- 振る舞いを変えずに構造を変える、広い概念
- 場合によっては大規模・高リスクにもなりうる
- Tidying（片付け）
- 「誰も文句を言えないレベルの、小さくて無害な構造変更」
- 1 ステップが小さい／安全／レビューしやすい
- 日々の開発の合間に差し込める
この「誰も文句を言えないレベル」という線引きが重要である。著者は「どう片付けるか」だけでなく、「どこまでをtidyingと呼び、それ以上を大掛かりなリファクタリングとみなすか」を意識的に区別しようとしている。
Part I: 小さな「片付け」たち
Part I では、具体的なtidyingのテクニックがいくつか紹介される。その中から、印象に残ったものだけピックアップする。
Guard Clauses（ガード節）
深いネストを避けるために、関数冒頭で「何もしないケース」を早期 return するパターンである。
if (!user) {
return;
}
if (!user.isActive()) {
return;
}
// 本題の処理
テクニック自体は目新しいものではない。
しかし本書では、これを「読み手のストレスを減らすための片付け」として扱っている点が特徴的。
条件が複雑な処理ほど、「ここでは何も行われない」ケースを先に片付けてしまうことで、コアロジックがすっきり見えるようになる。
Dead Code（死んだコードの削除）
使われていないコードを削除するだけの話に見えるが、著者は削除そのものが価値を持つ行為だと強調している。
- いつか使うかもしれない
- 一応、残しておきたい
といった心理とどう折り合いをつけるかについて、後半の「オプション価値」の話とも絡めて議論している。
単に「不要なコードは消せ」と叫んでいるわけではない。
Reading Order / Cohesion Order（読む順番と凝集）
関数やメソッドの並び順を「読みやすい順」に揃える、似た責務のコードを近くにまとめる、といった、ごく地味な整理もtidyingとして扱われる。
差分としては「順番が変わっただけ」のコミットになるが、読み手にとっては「どこから読めばよいか」が一目でわかるようになり、理解コストが下がる。
「処理を理解する順番」と「コードが並んでいる順番」を一致させようとする姿勢は、日常的にやっていることをうまく言語化してくれる。
Explaining Variables / Extract Helper
複雑な式を説明用の変数に切り出したり、長い関数の一部を小さなヘルパー関数に抽出したりするパターンも、tidyingの代表例として挙げられる。
ここで強調されるのは、「未来の自分やチームメイトに向けた説明を、まずコードの構造で表現せよ」という姿勢。
コメントを書く前に、変数名や関数分割でどこまで説明できるかを考える、というスタンスに近い。
Part II: いつ片付けるのか問題
個人的に一番おもしろいと感じたのが Part II。
ここでは、tidyingと振る舞い変更（新機能追加やバグ修正）をどう組み合わせるかに多くのページが割かれていた。
Separate Tidying（片付けと変更を分ける）
片付けだけのコミット／PR と、振る舞い変更を含むコミット／PR を意図的に分けることを推奨している。
- 「読み順を整えただけ」「変数名を改善しただけ」といったtidying専用のコミット
- 機能追加やバグ修正といった振る舞い変更のコミット
これを分離しておくと、レビューもロールバックも格段にやりやすくなる。
よくある「リファクタと機能追加が1つのPRに混ざっていて辛い」という状況に対する、ひとつの具体的な方法。
Chaining（片付けの芋づる効果）
著者は「片付けはポテトチップスのようなものだ」と表現している。
理由は、1つtidyingをすると、次に直したくなる場所が次々と見えてくるから。
問題は「どこで止めるか」。
- 1 ステップのサイズを小さく保つ
- 1 つの PR に含めるtidyingの数を意識する
- チームのレビューサイクルやCIの速度と釣り合う範囲にとどめる
といった視点で、「やりすぎ」を制御することを推奨している。
実務に持ち込むと、「このついでリファクタは別PRに逃がすべきか」という判断を言語化する助けになる。
First / After / Later / Never
Part II の終盤では、片付けのタイミングを次の4パターンに分類。
- Tidy First
片付けを先にやることで、その後の変更が大幅に楽になるケース - Tidy After
まず振る舞い変更で価値を出し、その後に片付けるケース - Tidy Later
今はやらないが、余裕ができたときに検討する候補として残すケース - Tidy Never
コストに見合わないため、永続的にやらないと決めるケース
タイトルは「Tidy First?」だが、「常に最初に片付けよ」という主張ではない。
むしろ「いつ片付けるかを意識して選べ」というメッセージが強い。
Part III: 設計は“要素同士の関係づけ”であり経済活動
Part III では、話が一段抽象的になる。ここは好みが分かれる部分かもしれないが、個人的には一番「設計の本らしい」パートだと感じた。
「ソフトウェア設計」とは何か
著者は、ソフトウェア設計を「要素同士をうまく役立つように関係づけること」と定義している。
ここでの「要素」は、クラスや関数だけでなく、モジュール、サービス、時にはチームメンバーそのものまで含む広い概念として扱われる。
- 要素同士がどう結びついているか（結合）
- 要素の中身がどれくらい一体感を持っているか（凝集）
これらを調整する行為が設計であり、tidyingはその小さな一歩である、という位置づけ。
結合がソフトウェアのコストを決める
本書では、結合（coupling）がソフトウェアのコストを決める、というメッセージが繰り返し強調される。
- 結合が強いと、1 箇所の変更が多くのモジュールに波及し、変更コストが跳ね上がる
- 結合が弱く、凝集が高いと、変更は局所に閉じ、予測しやすいコストで済む
多くのtidyingは、この「結合を弱める」「責務を整理する」ためのものとして説明されている。
その延長線上に、より大きな設計変更やアーキテクチャ変更が位置づけられる。
時間価値とオプション（経済性の話）
金融の世界で出てくる「お金の時間価値」や「オプション」という概念を、ソフトウェア設計に持ち込んでいる点も特徴的である。
- 今日の1時間と、半年後の1時間の価値は同じではない
- 今tidyingに時間を投じることは、将来の変更コストを下げる「オプション」を買う行為とも捉えられる
- 逆に、今はビジネス価値の高い変更を優先し、tidyingは後回しにする判断もありうる
このように、tidyingの是非を「きれい／きたない」という感情だけでなく、「時間価値」と「オプション価値」という経済的な軸でも眺めようとする姿勢が、この Part の核。
読んでみて良かった点・気になった点
良かった点
-
「いつ片付けるか」が言語化されている
普段なんとなくやっていた「ついでリファクタ」を、「First / After / Later / Never」という枠組みで説明できるようになる点が良い。
議論の単位が揃うことで、チーム内での合意形成もしやすくなりそうだと感じる。 -
人間の感情やチーム事情を前提にしている
個人のこだわりよりも「チームが安心して変更できる状態」を優先するバランス感覚が全体にある。
理想的なアーキテクチャ論ではなく、「人間が協調してコードを育てていくための考え方」として読める点がよい。 -
薄くて読み返しやすい
各章が短く、エッセイ集のような構成であるため、「特定のtidyingだけ読み直して明日の仕事に1つ取り入れる」といった使い方がしやすいのが良い。
気になった点・向き不向き
-
テクニック自体は目新しくないものも多い
Guard ClausesやDead Code削除などは、多くの開発者が既に実践している内容。
そのため、「新しいテクニック集」として期待すると物足りなさを感じる可能性はある。 -
理論パートは好みが分かれそう
経済性やオプションの話が刺さる人には非常におもしろいが、ここに興味が湧かない読者にとっては、急に抽象度が上がったように感じられるかも?。
明日からの開発をどう変えるか
本を読んだうえで、実務に取り入れたいと思ったポイントを、具体的な行動レベルで挙げてみる。
-
「Tidy: ...」専用コミット／PR を積極的に切る
- 読み順の整理、変数名の改善、ヘルパー抽出などは、機能変更と別コミットに分ける
- レビューする側に「これは振る舞いに影響しないtidyingである」と明示する
-
タスク開始前の 5〜10 分だけ Tidy First を試す
- 対象ファイルの中で、明らかに読みづらい箇所を 1 箇所だけ片付けてから本題に入る
- やりすぎを防ぐため、「1 PR あたり 1〜2 個まで」など、自分なりの制限を設ける
-
レビューコメントで「Tidy Later」を明示する
- 「ここは気になるが、今回の本質ではないので Tidy Later で」と書いておく
- そうすることで議論の発散を防ぎつつ、後で着手するオプションを残すことができる
-
チームで「First / After / Later / Never」の語彙を共有する
- 「この案件は Tidy After のほうがよさそう」といった会話ができるようになると、設計やリファクタリングの相談がしやすくなる
- 「全部 Tidy First したい人」と「常に Tidy Never にしたい人」の衝突も、少しは緩和できるかもしれない
まとめ
「Tidy First?」は、最新技術を紹介する本ではなく、既に存在するコードベースと毎日格闘している開発者に向けた、「片付け方の本」。
- Part I は、小さなtidyingのパターン集
- Part II は、tidyingと振る舞い変更の組み合わせ方／タイミングの話
- Part III は、それらを支える設計論・経済性の話
という構成で、リファクタリングの HOW だけでなく、WHENとWHYにも光を当てている点が特徴的。
既存コードにモヤモヤしつつも、大掛かりなリファクタリングには踏み切れない、という状況にある人にとっては、「小さく始めて、どこで止めるかを決める」ためのよいガイドになる本だと思う。