Yard 編集部

💡

「Tidy First? ―個人で実践する経験主義的ソフトウェア設計 - FL#84」イベントレポート

公開

2025-03-13

文章量

約4574字

Yard 編集部

フォロー

Yardの編集部が、テック業界の最新トレンドや知見について発信します。

「Tidy First?」とは何か

エクストリームプログラミングの旗手・ケント・ベックが示す新たな視点

なぜ「?（クエスチョンマーク）」が付いているのか

“整頓”――リファクタリングのサブセットとしての小さなコード変更

整頓の例

コード構造と振る舞いを分ける――ソフトウェア設計の新しい捉え方

個人レベルの設計

いつ整頓すべき？「先か？後か？それとも…やらない？」をどう判断するか

1. 整頓しない

2. 後日に回す（Later）

3. 振る舞いの直後に整頓（After）

4. 振る舞いの前に整頓（Before）

経済学から見る整頓の価値――ディスカウントキャッシュフロー×オプション取引

全体を踏まえた感想

「いつ整頓するか」を問う意義――コード設計と振る舞い変更の緊張関係

最後に：大切なのは、自分の頭で考えること

全体を踏まえた感想

「いつ整頓するか」を“自分ごと”で考えるための一冊

イベントレポート

Insight

2025年3月6日、「Forkwell Library」シリーズの第84弾として開催されたオンラインイベント「Tidy First? ―個人で実践する経験主義的ソフトウェア設計」。エクストリームプログラミング（XP）の生みの親として名高いケント・ベック氏が著した本書の内容や背景について、本書の翻訳を手がけた一人である細澤あゆみ氏（株式会社アトラクタアジャイルコーチ）をお招きし、解説・Q&Aが行われました。

本レポートでは、「Tidy First?」の狙いである“小さなステップでのコード改善”をどのように実践し、なぜ「?（クエスチョンマーク）」が付いているのか――その狙いや背景、さらにはケント・ベックが本書で提示している「ソフトウェア設計＝構造変更」の捉え方や、「いつ整頓（tidying）を行うか」という難しい問いに対する判断基準を中心にまとめています。

「Tidy First?」とは何か

エクストリームプログラミングの旗手・ケント・ベックが示す新たな視点

『Tidy First?』（以下「タディファースト」）は、エクストリームプログラミング(XP)やテスト駆動開発(TDD)など、数々のプラクティスを世に広めてきたケント・ベック氏が「小さく安全にコードの整頓を行う手法」についてまとめた最新の書籍です。

元はベック氏のブログが発端

タディファーストは、もともとブログ記事として公開された内容をブラッシュアップしたもので、これまでケント・ベックが培ってきたXPやTDDの考え方をさらに発展させたものと言えます。

3冊シリーズの1冊目

本書は3部作の第1巻にあたり、範囲は「個人レベルで実践できるソフトウェア設計」に限定されています。後続では「Tidy Together?」など、複数人での大規模リファクタリングなどにも踏み込んでいく予定だそうです。

“Tidy”とは「整頓」のこと

本書でいうTidy（整頓）は、「リファクタリングのうち、特に小さな範囲（数分〜1時間）」に限定したもの。つまりごく短時間で安全に行えるものを指し、それをどう自分の開発フローに組み込み、いつ行うかを説いています。

なぜ「?（クエスチョンマーク）」が付いているのか

本のタイトルは「Tidy First?」ですが、この“?”が非常に大事な意味を持ちます。

リファクタリングすべきものがあっても、必ずしも即座に行う必要はない
“小さく整頓できるからといって、今やるの？後？やらない？”
それは状況やタイミングによって最適解が変わる

一般的な「リファクタリングしましょう」という話ではなく、「リファクタリングや整頓を《いつ》やるのか」「そもそも《やるべきか否か》」という点に着目しているのが、このタイトルのクエスチョンマークに象徴されています。

“整頓”――リファクタリングのサブセットとしての小さなコード変更

書籍では「整頓（tidying）」という言葉を使い、リファクタリングと区別しています。

整頓（tidying）

「振る舞いを変えずに、コードの構造だけを変える」
リファクタリングのサブセット
「数分から1時間」程度の小さいスケールで行う
いわば“赤ちゃんリファクタリング”、あるいは“ちいかわ”のようなイメージ

かつてから言われる「リファクタリング」とは同じ概念かもしれませんが、ケント・ベックは「リファクタリング」という言葉があまりにも乱用され、しばしば“動作を大きく壊しかねない変更”とも混同されるようになった現状を問題視。そこで本書ではあえて「整頓」という新しい呼び方を提示し、 “とにかく小さく安全な変更を積み重ねよう” と強調しているのです。

整頓の例

いくつか本書に登場する整頓の例を紹介すると、たとえば以下のようなものがあります。

“塊”ごとに空行を挿入

もっともシンプルな整頓。
たった数秒で完了し、コードがグッと読みやすくなる。

“デッドコード”を削除

使われていないコードは躊躇なく消す。
バージョン管理があるので後戻り可能。
「必要になるかもしれない」思い込みで放置せず、コードを読む人の時間を削らないことが大切。

説明変数を導入

複雑な式を簡潔な変数にまとめるなど、既存ロジックを少しだけ整理。
振る舞いを変える前に、まず理解しやすいように整える。

どれも「日常的に私たちがリファクタリングとしてやっているあの作業」が思い浮かぶのではないでしょうか。ケント・ベックはこれらを積極的に「整頓」と呼び、頻繁に・こまめに入れることでコード全体を常に良い状態に保とうと説いています。

コード構造と振る舞いを分ける――ソフトウェア設計の新しい捉え方

本書では、ソフトウェアの構造と振る舞いはまったく別物だという視点が強調されています。

振る舞い

新機能の開発やバグ修正など、外部から見える動きを変えること。
ビジネス価値や売上につながる“稼ぎ頭”。

構造

いわゆるアーキテクチャや内部の整理など。
ユーザーからは直接見えないが、将来の改変コストに大きく影響する“土台づくり”。

これまでは「設計」といえば図面を引いたり大きく変更するイメージが強かったかもしれませんが、ケント・ベック曰く「ソフトウェア設計＝構造変更」と捉え、しかも実装まで含めて取り組むべきと主張します。

個人レベルの設計

ケント・ベックが本書で扱う範囲は「個人が行うソフトウェア設計」にとどまります。

チーム単位での大規模リファクタリングは次巻「Tidy Together?」で扱う予定
まずは1人ひとりが小さく安全に整頓を積み重ねられるようになることが大切

いつ整頓すべき？「先か？後か？それとも…やらない？」をどう判断するか

本書でいちばん難しく、かつ重要なのが「整頓をいつするのか」というテーマです。ケント・ベックは4つの選択を挙げています。

Never：整頓しない
Before：振る舞い変更の前に整頓
After：振る舞い変更の直後に整頓
Later：振る舞い変更を終えたもっとあと（後日）で整頓

それぞれ以下のような判断材料があるとされます。

1. 整頓しない

“そのコードを二度と変更しない”のが確定しているなら、整頓のコストはムダ
例：完全リプレイス対象で今後一切手が入らないシステム

2. 後日に回す（Later）

変更箇所が多い場合に、小分けしてやるほうが全体的に楽
「いま急いで作業するより、後日余裕あるときに…」という場合
必ずやらないわけではなく、いつかやるという決断

3. 振る舞いの直後に整頓（After）

実際に新機能などを実装してみて、「やっぱり整頓しておいたほうがこの先楽だ」とわかったら直後にやる
コストが今なら小さい（リビルドする大変さが増さない）ならAfterが合理的

4. 振る舞いの前に整頓（Before）

コストが明らかに安く済み、かつ後々の変更に大きく役立つと判明しているなら、先にやったほうがよい
コードを先に整頓することで、新機能追加に伴うストレス・リスクが大幅に下がる

経済学から見る整頓の価値――ディスカウントキャッシュフロー×オプション取引

本書第3部では、“なぜ”整頓するかを経済学的なアプローチで論じています。ここは非常に読み応えがあり、一見難解に思える部分ですが、著者は以下2つの概念を強調。

ディスカウントキャッシュフロー (DCF)

「将来のお金」は現在価値に割り引いて考えよう
遅いタイミングで得られる収益は、リスクや投資期間のコストを考慮すると現時点では小さく評価される
つまり「明日の1ドルより今日の1ドル」が大事

オプション取引（オプショナルティ）

“決断を後回しにできる”オプションを得られること自体に価値がある
ソフトウェアでは「柔軟なコード構造」により、将来の変更に素早く対応できる（＝高いオプション価値）
不確実性の高い未来で、最適なタイミングを待って変更を行うメリットは大きい

この2つは「整頓の時期選択」において一種の綱引き関係にあると言えます。

DCFからは「今すぐ稼げる振る舞いを優先したほうがいい」（整頓は後でいい）という示唆
オプション取引の考え方からは「将来の変更をスピーディにできる土台こそ価値がある」（整頓は今やったほうがオプション価値を得られる）

つまり、どちらをどの程度重視するかが本書の核となる主張であり、安易に「今すぐ整頓すべきだ！」と断定するわけでも「後回しにしろ！」というわけでもない。状況ごとに両者を天秤にかけ、決断をするにはどうすればいいかが本書で詳述されているのです。

全体を踏まえた感想

「いつ整頓するか」を問う意義――コード設計と振る舞い変更の緊張関係

「リファクタリング」という言葉が広まりすぎたことで、振る舞い変更と構造変更が混同され、大規模なコード破壊につながりがち……そうした現状へのアンチテーゼとして、ケント・ベックは 個人レベルでの“小さな整頓” を丁寧に積み上げ、状況に応じて「ビフォー／アフター／レイター／ネバー」を判断しようと提案しています。

その根底には「プログラムの内部構造を変えるのは、将来の変化に対する投資」という経済的視点がある。まるで金融のオプション取引をイメージしながら、「必要なときにすぐ対応できる」利点をどう捉え、どう費用対効果を測るか――この考え方は、アジャイル開発やXPで言われる「継続的設計・決断の先送り」と強く通じ合っています。