逆に，いきなりエディタで「ソースコード」を書き始める人も，当然頭の中では設計を行っているでしょう．ソースコードを読めばクラス階層なども見て取れるわけですから，ソースコードを設計ドキュメントと見なすことも(ちょっと苦しいかもしれませんが)可能です．納品ドキュメントとして各種ダイアグラムが必要ならば，ソースコードから逆生成することだって可能なはずです．

実際「じゅん for Java」プロジェクトではRational Roseを使って，納品ドキュメントの一部としてオブジェクト図をソースコードから逆生成しました．「じゅん for Java」プロジェクトは「じゅん for Smalltalk」をJavaに移植するプロジェクトです．クラス構成やメソッドのインタフェースは，両者で統一することが基本方針となっています．「じゅん for Java」プロジェクトの場合，「じゅん for Smalltalk」のソースコードこそが設計ドキュメントだったわけです．

ＸＰの場合，１２の実践項目のうち，"Metaphor(隠喩)","Testing(テスト)","Refactoring(？？？)"において設計を行っていると考えることができるでしょう．Metaphorはシステムの全体構成をあらわしているわけですし，テストケースの作成はＡＰＩの設計に他なりません．Refactoringなんて，システム構成の再設計そのものです．

変化を受け入れよう

Kent Beckは "Extreme Programming Explained" の中で，昔母親から車の運転を習った時に言われた"Driving is not about getting the
 

"Extreme Programming Explained"の副題として"Embrace Change(変化を受け入れよう)"が書かれています．仕様は変わるものです．スケジュールも変わるものです．プロジェクトのメンバや方針も変わるものです．それを当たり前のこととして受け入れ，変化に備えましょう．いくら仕様をきっちり決めても，それが変わらないことを前提に開発を進めるのはリスクが大きすぎます．

変化を受け入れるためには，変化のコストが高くてはいけません．実際，１２の実践項目の多くが，変化のコストを下げ，ひいてはリスクを減らすためのものになっています．"The Planning Game"や"Small Releases"，"Simple Design"，"On-site Customer"は仕様や設計の変更のコストを下げるためのものですし，"Testing"や"Pair Programming"，"Continuous Integration"，"Coding Standard"はプログラミングレベルでの変化のコストを下げるためのものになっています．さらに，"Pair Programming"や"Collective Ownership"はプロジェクトチームの変化のコストを下げるためのものであると見ることができるでしょう．

開発手法としてのＸＰについては賛否が分かれるところでしょう．実際，ＸＰは小規模なチームでのソフトウェア開発のためのものだと言われていますし，自分が行うプロジェクトにすべての実践項目をそのまま適用するというわけには行きません．しかしＸＰが原則としている「人間らしく，楽しくプログラミングしましょう」という基本方針は，どんなプロジェクトであっても適用可能です．

最後に，"Extreme Programming Explained" の結びの言葉を紹介しておきましょう．
変化に対する備えを諦めることが，逆説的に，すべての変化に備えることになる．何も予期しなければ，何が起こっても驚くことはないだろう．