『エクストリームプログラミング』を読んで～空間を設計する力を取り戻す

読書メモ。2025年34冊目。
『エクストリームプログラミング』を読んでの感想となります。（2025/5/30記載）

本の概要
動機
感想
忘れたくないメモ
副読資料
後日談

本の概要

アジャイル開発とは何だったのか、その原点を再考する新訳
優れた技術力と良好な人間関係をもってしてソフトウェア開発を成功に導く、ケント・ベックによるXP（エクストリームプログラミング）のすべてを集約した名著 "Extreme Programming Explained: Embrace Change" の新訳版。アジャイル開発の原点を知る、必読の一冊です。

引用：

www.ohmsha.co.jp

動機

10年前に読んで以来ずっと本書の断片が頭に残っている。
今年『Tidy First?』や開発生産性カンファレンス2025でケント・ベック熱が高まっている。
XP祭りのプロポーザルも出したく10年ぶりの再読！！

感想

10年ぶりの再読でした。

10年前の自分は30代を迎えて2社目に転職したばかりでした。
当時は受託企業でも稼働する工程が限定された商流が深いところで働いていたため、書籍に登場する多くのプラクティスが遠い世界のことのように感じたことを覚えています。

10年ぶりに再読し、ケントベックの思想の魅力が古びておらず、そのプラクティスの価値の多くも現在にも通じることに驚きます。
特に、チームや組織での協力の重要性が多くのページが説明されていることに驚きました。
ペアプログラミングやテスト駆動開発だけでなく、透明性のあるコミュニケーションによってチームが活性化するという考え方は、もっと早く理解しておきたかったとも感じました。

時代の変化により、いくつかの状況は今と異なる部分もありますが、それでもなお、ケント・ベックの開発に対する誠実な姿勢には、今も多くの学びがあります。
また、10年も待たず定期的に読み返したい。

忘れたくないメモ

■XPとは

XPとは、自分たちのできることをオープンにして、それを実行に移すことだ。そして、そのことを他の人にも認めたり、期待したりすることだ。「自分は頭がいいんだから、ひとりで上を目指せばいい」などという未熟な思い込みを克服することだ。もっと広い世界で成熟した場所を見つけることだ。ビジネスや仕事も含めたコミュニティーのなかで、自分の居場所を見つけることだ。自己超越のプロセスのことだ。そのプロセスのなかで、開発者として最善を尽くすことだ。ビジネスのためになる優れたコードを書くことだ。

こうしたマインドを常に持っていたい。

■全力を尽くし、明確に情報を伝える

他人の予測はコントロールできない。だが、プロジェクトについて自分が知っていることを伝えることはできる。そうすれば、他人の予測と現実が一致する可能性が出てくる。この教訓を学んだとき、私の期日に対する恐怖は消え去った。私の仕事は他人の予測を「管理」することではない。それは私以外の人の仕事だ。私の仕事は全力を尽くし、明確に情報を伝えることである。

DevOpsの考え方にも共通すると感じました。
明確に情報を伝えることで相手に情報が伝わる。相手に情報が伝わることによって新しい解釈が生まれる。
新しい解釈が生まれることによって、改善された方針が生まれる。改善された方針がよりよい未来をつくる。
言い辛いことも、言語化しづらいことも、全力を尽くし、明確に情報を伝えることが重要。

■効果のある新しい習慣を選ぶ

XPとは、効果のない技術的/社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。
◇ XPとは、自分が今日やるべきことを十分に理解することである。
◇ XPとは、明日をよりよくしようとすることである。
◇ XPとは、チームのゴールに貢献した自分を評価することである。
◇ XPとは、ソフトウェア開発で人間としての欲求を満たすことである。

今となっては当たり前に聞こえてしまうけど、10年前は難しいと思ったことでした。
それは仕事と自分自身の距離感に起因すると思っています。

■本当に重要なのはチームや組織の一員としてどのように振る舞うか

「トラブルに巻き込まれる原因は、何かを知らないことではない。よく知らないのに、知っていると勘違いすることである」。
ソフトウェア開発の「勘違い」のなかで、私が最も大きな問題だと思うのは、個人の行動に集中してしまうことだ。本当に重要なのは、個人としてではなく、チームや組織の一員としてどのように振る舞うかである。

属人性の問題。個人ではなくチームで成果をあげる重要性。
つい最近までこの言葉を理解できていなかったと思います。

■ドキュメントと会話でのコミュニケーション

大量のドキュメントはコミュニケーションを目的としたものだが、会話も同じ目的を持っている。では、どちらがより効果的なのだろうか？その答えは、文脈によって決まる部分もあれば、原則によって決まる部分もある。この場合は、人間の基本的な欲求である「つながり」が会話によって満たされること、その他の条件が等しければ、会話のほうが好ましいコミュニケーション方法であることが、人間性の原則によって示されている。ドキュメントによるコミュニケーションは本質的にムダが多い。多くの人に情報は伝わるかもしれないが、コミュニケーションは一方向である。会話であれば、明確化、迅速なフィードバック、一緒にブレインストーミングするなど、ドキュメントではできないことが可能になる。ドキュメントによるコミュニケーションは、事実として受け止められるか、真っ向から否定されるかのいずれかになりやすい。いずれにしてもコミュニケーションの増加にはつながらない。

Slackやチケットでのコミュニケーションがこのような形に陥らないことを気を付けたい。
少なくとも仕様書や設計書でのコミュニケーションでは不十分だと感じました。
ドキュメントベースのやり取りはコミュニケーションの増加に繋がらない。

■質とスピード

品質を犠牲にするのは、効果的なコントロール方法ではない。品質は制御変数ではない。低品質を受け入れることで、プロジェクトが速くなることはない。高品質を要求することで、プロジェクトが遅くなることもない。むしろ品質を高めることで、デリバリーが高速になることが多い。品質基準を下げてしまうと、デリバリーが遅くなり、予測できなくなってしまう。

10年前ぐらいに読んでいたはずなのに、質とスピードをちゃんと捉え始めたのは最近の気がしています。
開発に対する主体性の問題かもしれないと思います。

■スコープリープ

プログラミングに夢中になって我を忘れてしまうと、「念のため」に余計なコードを追加しがちである。プログラムのあるべき姿を明確に客観的に記述すれば、本来のコーディングに集中できる。どうしてもコードを追加したいなら、手元の作業を終えたあとに別のテストを書くようにしよう。

今数年ぶりの実装をしていて、改めて難しい処理の実装にあたると、難しさを解消することに目が行ってしまい、当初目的を見失いがちであることを実感しています。
何を作るべきかを先に定義することは効果的。

■計画が表す人間関係の状態

共有された計画の状態は、その計画によって影響を受ける人たちの人間関係の状態を示すヒントになる。たとえば、現実離れした計画は、不明確で不安定な人間関係を表している。お互いの合意の上に成り立っており、現実の変化を反映して調整された計画は、リスペクトに満ちた相互に重要な人間関係を表している。

全力を尽くし、明確に情報を伝えることと同じように、チームや組織でコミュニケーションが取れているかという話と理解しました。
プロダクト開発をする人間は、敵対関係ではなく同じ方向を向くことができる協力関係を作れることが重要と思います。

■生活に最も大きな影響を受ける人の手のなかに、空間を設計する力を取り戻す

アレグザンダーは、建築家の自己中心的な関心事は、施主の関心事と一致していないと指摘している。建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、重要な情報を見逃している。それは、施主がどのように生活したいかという情報だ。アレグザンダーの夢は、生活に最も大きな影響を受ける人の手のなかに、空間を設計する力を取り戻すことだった。

アレグザンダーのビジョンには、建築家の役割も残されている。あらゆるプロジェクトには、うんざりするほどありきたりな問題もあるが、そのプロジェクトに特有の問題もある。いきいきとした空間を設計する鍵は、その空間を使う人の好みや社会的な人間関係を深く理解して、建築家の技術に対する深い理解と結び付けることである。この2つの観点を組み合わせ、どちらかを優位にすることなくうまく調和させることができれば、人間の欲求を満たしながら、雨を遮断できる空間の設計と建設が可能となる。

ものを作る人間とそれに対する希求との関係・距離感の話と理解しました。
プロダクト・エンジニアリングに対する先見性とも解釈できると思います。