ホソカワです。
矢崎さん（firo@....jp）からコメントをいただきました。ありがとうござい
ます。私の返答も入れました。
--- ここから
> ・きれいなコードがいいのであれば、いつもきれいなコードを書きます。
> （refactoring）
[]
ここは原文が
If design is good,we'll make it part of everybody's daily
business(refactoring).
なので、
設計がいいのであれば（設計するということがいいのであれば、あるいは、設計
が大事であれば）、・・・・のほうがいいと思うのですが、いかがでしょうか？
[ホソカワ]
最初は私は「設計がいいのであれば…」と訳していましたが、refactoringとの関連
があまりピンとこなくて「きれいなコード…」と訳しました。でも、「設計が大事で
あれば…」は意味が通じますねーー「ちゃんと設計してからコードを書くことがいい
ことであれば」と言う事ですね。このくだりは次のように変更します。
・設計（ちゃんと設計してからコードを書くこと）が大事であれば、いつも設計し
ます。(refactoring)
>
> ・単純にすることがいいのであれば、機能を落とさない一番単純なシステムを作りま
> す。（the simplest thing that could possibly work）
[]
原文にある、current functionalityのcurrentの意味を明確に表したしたほうが
いいと思うのですが、いかがでしょうか？
[ホソカワ]
はい、そうですね。現在の機能を満たすベストなシステムを作ることが大事ですね。
また、simplicityは「単純」よりは「単純明解」が合っていると思いますので、ここ
は次のように変更します。
・単純明解にすることがいいのであれば、現在の機能を満たす一番単純明解なシステ
ムを作ります。（the simplest thing that could possibly work）
--- ここまで
と言う事で、解説をアップデートします。
---
Preface
======
XPは、曖昧で頻繁に変わる要求定義と格闘する小中規模チーム向けの軽いソフトウェ
ア開発の手法です。
Extremeとうたっているのは、プログラミングの常識と言われている事を全て極限ま
で引っ張って行っているからです。
・コードレビューがいいのであれば、いつもやります。（pair programming）
・テストがいいのであれば、いつもやります。（unit testing）ユーザーまでテスト
します。（functional testing）
・設計（ちゃんと設計してからコードを書くこと）が大事であれば、いつも設計し
ます。(refactoring)
・単純明解にすることがいいのであれば、現在の機能を満たす一番単純明解なシステ
ムを作ります。（the simplest thing that could possibly work）
・アーキテクチャーが大事であれば、アーキテクチャーをどんどん改善していきます。
（metaphor）
・統合テストが大事であれば、毎日何回も行います。（continous testing）
・短い開発サイクルがいいのであれば、めちゃくちゃ短くしますーー秒単位、分単位、
時間単位です。（the planning game）
XPを行うためには規律（discipline）正しく行動しなくてはなりません。例えば、テ
ストは必ず書かなくてはなりませんーー書いていないのであればそれはXPではありま
せん。
（時間に）余裕があったらどのようにプログラムするか？テストを書いたり、コード
をきれいにしたりするでしょう。ゆとりを持って行動することは誰もが願っているこ
と（humane）です。XPは、ゆとりを持ってプログラムを書けるかどうかの実験です。
---
それから、chapter 9 の解説を矢崎さんにしていただくことになりました。担当表
もアップデートします。
> タイトル （ページ数）担当者
>
> Foreword (2) パス！
>
> Preface (8) ホソカワ
>
> Section 1 The Problem
> Chapter 1 Risk: The Basic Problem (4) ホソカワ
> Chapter 2 A Development Episode (4) ホソカワ
> Chapter 3 Economics of Software Development (4) ホソカワ
> Chapter 4 Four Variables (6)
> Chapter 5 Cost of Change (6)
> Chapter 6 Learning to Drive (2)
> Chapter 7 Four Values (8)
> Chapter 8 Basic Principles (6)
> Chapter 9 Back to Basics (8) ＊矢崎＊
>
> Section 2 The Solution
> Chapter 10 Quick Overview (10)
> Chapter 11 How Could This Work? (8)
> Chapter 12 Management Strategy (6)
> Chapter 13 Facilities Strategy (4)
> Chapter 14 Splitting Business and Technical Responsibility (4)
> Chapter 15 Planning Game (12)
> Chapter 16 Development Strategy (6)
> Chapter 17 Design Strategy (12)
> Chapter 18 Testing Strategy (6)
>
> Section 3 Implementing XP
> Chapter 19 Adopting XP (2)
> Chapter 20 Retrofitting XP (6)
> Chapter 21 Lifecycle of an Ideal XP Project (8)
> Chapter 22 Roles for People (10)
> Chapter 23 20-80 Rule (2)
> Chapter 24 What Makes XP Hard (4)
> Chapter 25 When You Shouldn't Try XP (4)
> Chapter 26 XP at Work (6)
> Chapter 27 Conclusion (2)
以上。
--
Kaoru Hosokawa
khosokawa@....com