Booklog - レガシーコードからの脱却 ソフトウェアの寿命を延ばし価値を高める 9 つのプラクティス

はじめに、まで。 本書の言うレガシーは、修正・拡張といった作業が難しいコード。その性質はソフトウェア業界に膨大な損失を生んでいる。 本書はそんな業界を良くしたい気持ちで、 9 つのプラクティスを示す。プラクティスから高品質で運用可能性が高いプログラムを作る術を学ぶ事ができるとするのが本書の主張。 これ買った頃は誰も変えたくないけど事業の中核で動き続けてるレガシーコードと共に暮らしてた。でも個人的には新陳代謝みたいな徐々に置き換わるイメージを持ち出してた頃でもあったのと、そのレガシーコードがカネを稼いでいる事実もあり、脱却はなんかピンと来ないなと感じててそのまま積んでた。 今改めて読むことで当時の気持ちを振り返りたい。現職は単純にデッドコードが極端に多いが誰も触れない遺物はそうないから、 AI Agents とタッグを組んで力業で調査分析からの強行突破＆責任をとるのがヒトの仕事も出来るので、その点踏まえ本書当時との考えの変化も見て取れるかな。 あんまり方法論推しだと興ざめするので中庸で臨む。

2026-09-18, read count: 1, page: i ~ xxviii, pages read: 28

1 章。開発プロジェクト・開発組織を疲弊させるのはヒトの問題でない。レガシーコードが組織を学習性無力に陥れる問題であると本書は主張する。 本書のレガシーコードの定義はテストも書けないようなものを指す。 レガシーコードが生まれるのは機能のライフサイクルを終えたあと。 ウォーターフォールの問題点の指摘。最後の統合までフィードバックを得られない。各工程が仕事になる。制御できないものの進捗と見積。素人ビジネス。ソフトウェアの作り方を間違っている。 率直な感想、 1 章は恐らくアイスブレイクで、気を引きやすい所謂だめなコード・だめなプロジェクトの悪口満載にしてるんだと思う。よって得る点何もないなと思って退屈だった。 今時は多少の無理はあれど E2E test を書くこともできるからそこまで太刀打ちできないコードはないから、初手 unit test にせず外堀から埋める作戦が使えるけど、本書はそこまで書いてないのかな。 私見では、そういう遺物を改善なり出来ないのは開発者が責任を取れない/取らない状況に問題があるので、コードが悪いという結論は枝葉に過ぎない印象だが、本書がこの先どのように展開していくのか気になるな。 現時点での評価は、初～中級者向けで、既に CI/CD 導入したりシステムを新陳代謝させるために苦心しているヒト達は多分読者として対象外な気がするな。

2026-09-19, read count: 1, page: 1 ~ 20, pages read: 20

2 章。スタンディッシュグループの CHAOS レポート。その成功の定義の誤り。ただし業界の課題が解決されるまでの道のりが遠いことはという結論は正しい。 ウォーターフォールを始めとした不適切な開発プラクティスが、レガシーコードの発生に寄与し、プロジェクトの失敗がアメリカだけでも膨大な損失を毎年生んでいる。レガシーコードを生み出す開発者自身に解決の責任がある。 これ本書で触れられてる、バグには繁殖に最適な条件があるという話、レガシーコードにも同じことを言いたいんやろな。 この流れで次にアジャイル、その後 9 つのプラクティスに進むみたい。原著が 2010 年代の本だし対象層を考えるとこのよくある展開は妥当な展開かも知れんが、今のところ歯応えはあまりない。 本書ではじめに、プロジェクトの問題をヒトではなくレガシーコード側に寄せて説明していたが、レガシーコードの繁殖に最適な条件を考えると、それは結局ヒトの問題だろう。 本書が面白くなるかはそこまで踏み込めるか次第な気がする。まだ諦めずに読み進めてみる。

2026-09-20, read count: 1, page: 21 ~ 34, pages read: 14

第 3 章。ウォーターフォールを引きずったままの見かけ上のアジャイルではうまくいかない。 アジャイルのマネジメント手法はキャズムを超え広く知られるようになったが、技術的プラクティスはまだそう言えない。 ソフトウェア開発という複雑で多様な領域においては、技術と創造性の両方が必要であり、高い技術卓越性で以て臨む必要がある。 今更だが本書のいう「人」は、個性や特性などを指すっぽい。だからプロセスで改善できるとする。大規模開発ならそうなのかな。 わたしも再現性のためのプロセス設計や自動化の組み込みをする。ただソフトウェア開発は無個性なものだけではないと思う。変化し続けられる人を選ぶことが重要だと考える。 あと技能・創造性のくだりで右脳・左脳みたいなわかりやすい分類の話が出てきて解像度低いなと思った。 いずれも対象読者に合わせた単純化と思うが、あまり好きじゃないな。 本書に邦訳が 2019 年なので、その頃のわたしが読んでたらもっとポジティブに受け取れてたと思う。

2026-09-21, read count: 1, page: 35 ~ 44, pages read: 10

第 4 章。 9 つのプラクティス。 ソフトウェアは必ず変更が必要になる。そしてその内容を予測することはできない。よって簡単に変化対応できることが重要になる。 9 つのプラクティスはアジャイルの技術的プラクティス。プラクティスは専門家が経験から得た原則を個別に考えずに使えるよう汎用的に実装したもの。 9 つという数字は、ヒトが覚えられる上限と言われる 7 ± 2 という上限から。 プラクティスに正しく従うことでソフトウェアの内部品質を高める。正しくプラクティスを使うには、その背景を理解する必要がある。 プラクティスを実践し、継続的な学習を経てその背後の理論まで深く理解した頃には、ルールを超えた新境地に達する。守破離。 やっぱ本書は導入編みたい。まだ学習を始めたばかりで、レガシーと共存したり立ち向かうすべを持たない人に、基礎的な道具を与えるみたいな感じか。 ひとりで学び、ひとりで実践するのはたいして難しくないけど、本書が対象とする大規模開発でこれらのプラクティスをどのように組織的に実践するのかは気になるところやな。 その件に触れられてなかったら実践書としては不十分かも知れんね。 7 ± 2 という数字を一般的な記憶容量の上限として扱うのはかなり粗いし、9 個という構成に後付けした理由にも見える。

2026-09-22, read count: 1, page: 45 ~ 62, pages read: 18

第 5 章。どう作るかでなく何を作るか。プロダクトオーナー(PO)を置く。 PO は次に作るべき最も重要なものを決める。 それに基づき PO がストーリーを描き、受け入れ基準を定める。受け入れ基準はテストに落とし込む。あとは PO の心得や良いストーリーの書き方が載ってる。 本書で勧められている開発者と PO が別れてるのが好きじゃないから小規模開発してる身なので、大規模開発ならそうなんやろなという感想で読んでる。 非開発者を PO に置くのは開発者のバイアスを避ける利点もあろうが、どうにも開発者の当事者意識が薄くなりそうで好きじゃない。 それに加えて、非技術者の PO が技術的な選択肢や解決策の幅を無意識に狭めてしまう可能性もあるよな。役割分担するなら開発者とのかなり密な対話が必要だろう。 この調子であと 8 つのプラクティスも進むのかー。あまり心に響かずメモの解像度も低いが最後まで頑張って読み進めよう。

2026-09-23, read count: 1, page: 63 ~ 78, pages read: 16

第 6 章。小さなバッチで自分たちに最適な作業量で仕事するためのタイムボックス・スコープボックス。 大きなタスクを小さなタスクに分割し、短い期間でフィードバックを得る。小さなバッチで依存関係を極小化することでビルドと CI が迅速なフィードバックを可能になる。 小さなタスクはスケジュールの組み合わせで柔軟に調整できる。観測性の向上にもつながる。 あまり真面目に読んでない。小さなウソ、って例えは好きじゃないな。単にストレッチ目標だったり外れるかも知れない予測をウソと呼ぶのであれば、違和感がある。情緒的な要素が絡まない言葉を使うべき。 ローカルなら試行錯誤は速いほど良いけど、 CI は数分でも大して困らないと思う。逆に高速化のためにスコープを絞りすぎることが検査漏れのリスクにつながる。 AI 時代になってローカルがさほど高速でなくても並列で仕事回せるから気にならなくなった、というのもある。 でも AI に任せるにしてもバッチサイズが小さく要件がまとまってるのはすごく重要。そこだけは変化ないな。 PO のくだりもそうだったが、この章でもバッチサイズの縮小をどう組織に持ち込むかは全然書いてないようだった。 複数人での開発を前提とした文脈が多く、恐らく読者単身でのプラクティス導入が難しいのわかってるはずだと思うが、今後はその点に触れるのかな。

2026-09-24, read count: 1, page: 79 ~ 104, pages read: 26

第 7 章。継続的インテグレーションで常に自動で統合が検証された状態を保ち、継続デリバリーでいつでも本番にリリース可能な状態を維持する。 ビルドスクリプトも DB スキーマもバージョン管理することがリリースを安定化する。 長寿命のブランチを避け、フィーチャーフラグを採用し、リリース直前の統合がはらむリスクを低減する。 現代では一般的なことが書かれていると思う。邦訳の 2019 年にいた組織ではまちまちだったので当時はまだ広まりきってなかったのかな。現在も CI/CD 採用できてないところはあろうけど。 フィーチャーフラグの良さもわかるが、運用やコードの複雑化をはらむ点は注意が必要だと思う。そして本書は入門書なためか古さゆえかその点に触れていない。 それ自身がレガシー化のきっかけになりうる点に言及してないのは良くない。

2026-09-25, read count: 1, page: 105 ~ 118, pages read: 14

第 8 章。協力しあう。 その方法として、ペアプログラミング、バディプログラミング、スウォーミング、モブ。 スパイクのような未知に取り組む場合は事前にタイムボックスの中で疑問・ゴール・目的を定めておく。 ペアプロをしても、チーム全体へコードの理解を共有する意味で、コードレビューはなくすべきでない。 同様にレトロスペクティブも、フォーマルな形でなくて良いので、必要。 集合知の活用と、偶発的な創造性の促進という点で、複数人でのプログラミングの利点があることは理解している。 でも同時に、創造性や独立した仮説形成には、個人で集中し自由に考える時間も必要な点をわたしは他の本から学んでいるので、ペアプロのようなプラクティス一辺倒では不十分だという認識。 実際のところペアプロ・モブプロしかしないような開発組織もあるようだけど、均質化された思考というのは存外脆いので、バランスなんやろなと雑に考えてる。 実際に AI Agents もコンテキストを共有し過ぎない方が精度が高まるからなあ。

2026-09-26, read count: 1, page: 119 ~ 140, pages read: 22

第 9 章。 CLEAN なコード。命名はブおじさん等に倣って。 Cohesive(凝集性), Loosely Coupled(疎結合), Encapsulated(カプセル化), Assertive(断定的), Nonredundant(非冗長)。コードの品質がベロシティ向上につながる。 品質に着目するのは良いとして、本章で技術的負債に触れてる内容は違和感あった。 元来は学習によって生じた現在の理解とコードとの差分を負債になぞらえたもので、後には将来価値との交換として意図的に負う債務まで意味が拡張されたものだと思う。単に急ぐために雑にする手抜きと一括りにするのは違うんじゃないかな。 世の中に広まるうちに手抜きが含まれ拡張された後の認識で書かれてるのかな。序文がウォード・カニンガムなのに。 負債自体は悪でなく手段で、適切に管理されるべきものだと思う。 負債を単純に悪とみなすのは、負債という比喩の重要な部分を落としている。

2026-09-27, read count: 1, page: 141 ~ 160, pages read: 20

第 10 章。テスト駆動開発(TDD)などについて。テストの種類、受け入れテスト = 顧客テスト、ユニットテスト = 開発者のテスト、それ以外のテスト = QA テスト。 開発者のテストは QA の検証の代わりにはならない。 E2E test の観点のようなテストはユニットテストにはできない。ユニットテストは振る舞いの仕様とコードが期待通り動くことの検証の役割がある。 TDD は素早いフィードバックが得られ、リファクタリングをサポートする(動作保証するのだからそりゃそうだ)。 これはその通りな良く知られた話だった。わたしは新規で書く機能などはテストファーストであまり書かないけど、リファクタリングのためにテストはつけるようにする。レガシーコードでテストがないなら先にテストを書いてからやる。 AI 時代では AI 自身にテストを書かせるのも有効だが、彼ら抜けがあるから考慮漏れがないかは別の AI Agents に検査させたり最終的にヒトが見たり大変なのよな。

2026-09-28, read count: 1, page: 161 ~ 180, pages read: 20

第 11 章。 TDD の続き。テストの活用方法。より細かい内容には触れているものの、実質 10 章と同じテーマ。テストの書き方的な話。一意性や書き順など。 レッド/グリーン/リファクタの節でテストのテストについては触れ、カバレッジ 100% 派な点からもテスト品質を重視しているのはわかる。 わたしも世間の「カバレッジ 8 割に落ち着く論」好きじゃなくて可能な限り 100% を目指すので、その点は共感できる。 けど、テストのバグ自体をどう防ぐかに言及してないように見える(読み飛ばしてたらｽﾏｿ)。カバレッジ 100% だけでは仕様を満たしている事にならない。実行範囲の指標で仕様適合性の指標じゃないから。 実際のところ example-based testing に property-based testing や mutation testing 等の別系統の検証を重ねて誤りを検出するしかない。 この辺まで踏み込まないのは、本書が入門的なプラクティスの紹介に射程を絞っているからかもな。

2026-09-29, read count: 1, page: 181 ~ 204, pages read: 24

第 12 章。テストコードが揃ってからコード設計を洗練させるみたいな話。ただし、最初に必ず行うべき重要な設計まで後回しにする、という意味ではない点に注意。 また、最初に過剰設計をしないというのは YAGNI と同じ。 これも TDD の続きと考えて良い気がするな。変更しても壊れない保証があることを前提としている点で。 わざわざこれを 1 つのプラクティスに並べるくらいには、コードを正しく意図された状態に保つことを重視してるんやろうな。 とはいえ、始めから効率の悪いコードを書かなくても、頭の中で選ぶべきアルゴリズムやデータ型や設計が定まってるなら、それでスパッと書いて良いと思うけどな。 当然その後の見直しでの改善を期待してこのプラクティスはあるのだろうけど、読み間違えられる可能性はあるよな。

2026-09-30, read count: 1, page: 205 ~ 220, pages read: 16

第 13 章。レガシーコードのリファクタリングについて。 変更が必要なレガシーコードを保守せず、技術的負債を抱えると、開発コストの増加という利子を払うことになる。資産への投資として定期的な保守が必要。 リファクタリングのテクニック。ピンニングテスト、依存性の注入、ストラングラーパターン、抽象化によるブランチなど。あとリファクタリングは勉強になって良いぞという話。 個人的な感覚でも、保守もひっくるめた開発が一番難しくて面白い。リファクタリングだけが保守じゃないから、もっと広い意味での保守してくのが大事だと思う。 巷ではスタートアップであることを理由に保守が放置気味なことも普通にあるが、短期的な合理性と、中長期的に見た先送り・問題回避のトレードオフやな。 ランウェイが尽きるかも知れないときに保守とか言ってられるかというのはあると思うが、ランウェイが伸びてもサービスが死んだら意味がない。 保守を放置して熟成が進むほど課題の解決も段違いに難しくなるし、結局は適切に保守せざるを得ない。

2026-10-01, read count: 1, page: 221 ~ 240, pages read: 20

第 14 章。レガシーコードからの学び。プラクティスの実践と、その先にある原則の理解、そして変化の体現。 きょうはアレルギーきつく話半分しか読めてないが、本書のプラクティスは、多分、制御可能性の確保がキーなんやろな。 誰のための機能か宣言して目的に沿うよう制御、小さなサイズで制御可能な範囲で物を作る、TDD は検証可能性の制御、という具合に。 この本質的な部分は AI が爆発的にコードを量産する時代でも変わらない。 本書のプラクティスを実践し続け、その背景にある原則まで理解できれば、わたしが見出した制御可能性のような共通項を、その先に見るんやろな。 本書はこれで終わり。わたし自身は本書から得るものなかったけど、自分の内省を促す程度には効果はあった。入門者には課題として本書を与えるくらいは良いかもな。 ただ参考文献が 3 頁しかなくて薄いのが残念なので、本書を渡す入門者には他にもアジャイルに限らず古典を読むよう勧めたいところ。

2026-10-02, read count: 1, page: 241 ~ 271, pages read: 31