矢崎です。Section１のChapter7 Four Valuesの解説です。
Section 1 The Problem
Chapter 7 Four Values
===========================================
ソフトウエア開発のプラクティスを作り上げる時に、本当に正しい
方向に向かって進んでいるのかどうかを判断するための基準が
必要である。XPでは、その基準としてValue（価値観）というものを
考える。それは以下の４つである。
・Communication
・Simplicity
・Feedback
・Courage（勇気）
[Communication]
第1のValueはCommunicationである。
プロジェクトで起こる問題は常に、コミュニケーションがうまくいっ
ていないという点に原因を求めることができる。プログラマ、顧客、
マネージャの間で、重要な仕様変更、要件の確認、進捗の状況の
把握などについて、コミュニケーションがうまくいかないことがある。
コミュニケーションがうまくいかないという問題は、偶然に起こるわ
けではない。罰則や無視などが行われるならば、人は自分に都合
の悪い情報や、伝えても無駄だと思える情報を伝えなくなる。
XPは、コミュニケーションなしでは実行できない多くのプラクティス
を利用することで、コミュニケーションが正しく行われることをねら
う。このようなプラクティスの例は、ユニット・テスト、ペア・プログラ
ミング、タスク見積などである。
XPにおいても、常に正しいコミュニケーションが実現できるわけで
はない。そのために、コーチ（という役割の人物）が、コミュニケー
ションがうまくいっていないところを発見して、問題を解決するよう
にする。
[Simplicity]
第2のValueはSimplicity（システムを単純明快にすること）である。
システムをSimpleにすることは容易ではない。
システムをSimpleにするために、XPは、今日必要なことだけを、単
純な方法で実現するというやり方をとる。将来的なニーズは、それ
が本当に必要になるまで開発しない。
[Feedback]
第3のValueはFeedbackである。
Feedbackは様々な時間の間隔で行われる。
・分や日の間隔で行うFeedback
・ユニット・テスト
・顧客が書いた新しいストーリーに対して、プログラマが立てた
見積
・プロジェクトの進捗
・週や月の間隔で行うFeedback
・ファンクショナル・テスト
・スケジュール
・イテレーションごとにリリースされるシステム
イテレーションごとにリリースされるシステムについては、１つの戦
略がある。それは、最も価値の高いストーリーをできるだけ早くリリ
ースしたほうがよいということである。そうすれば、プログラマは彼ら
が行った決定や開発プロセスのがどれくらい正しかったのかについ
て、具体的なFeedbackを早く手にいれることができる。
[Courage]
第4のValueはCourage（勇気）である。
Courageとは例えば次のようなことである。
１．途中まで問題なく進んでいたプロジェクトが、あるところから、
ファンクショナル・テストが通らなくなった。その原因は、アー
キテクチャに欠陥があるせいだとわかった。この場合の正しい
対処方法は、アーキテクチャの欠陥を修正せずに、だましだまし
やることではなくて、アーキテクチャを思い切って修正することで
ある（例えそのために余分な時間がかかっても）。
２．１日の終わりになっても、その日に書いてきたコードが正しく動
かなかった場合には、それを捨てて、次の日に、ゼロから始め
る。
３．１つの問題を解決するのに、複数の設計案がある場合、各設
計案につき、１日で書ける範囲のコードを書き、それらがどん
なものかを評価し、そして一番いい案を選択して、あらためて
正式なコードを書く（ゼロから）。
システムが複雑になりすぎた場合には、思いきった手をうつCourage
（勇気）が必要な場合もある。
上記4つのValueは、相互にサポートしあうものである。例えば、より
密にコミュニケーションを行えば、今何が必要で何が必要でないかが
より明らかになり、システムをよりSimpleに保てるようになる。
[The Values in Practice]
最後に、、４つのValueの下にあって、それらを支えるValueがある。
それはRespect、つまりチームメンバが互いに尊敬しあうことである。
===========================================
<矢崎のコメント>
SimplicityとはXPの重要概念の１つだと思いますが、私は以下のよう
に解釈しています（あくまでも私の独善的解釈です。ご意見お待ちし
ております）。
１．XPのSimplicityとは、今必要な機能だけを作り込む。しかもできる
だけ単純な構造で、ということである。
２．将来的なニーズは、それが本当に必要になった時に作り込む。こ
れは、これは結局使われない無駄な投資を防ぐ意味がある。また、
Simplicityの観点からは次のような効果がある。
(1)システムは機能が増えれば増えるだけ、必然的に複雑になる。
しかし、最初から１００の機能を作り込むよりも、１０からスタート
して、１０ずつ機能を作りこんでいくほうが、人間の理解が容易
になる。
(2)テストを作成する場合でも、１００の機能のテストを作るより、１０
の機能のテストを作り積み上げていくほうが簡単である。
３．テストを開発に先立って考えることはシステムをSimpleにする鍵で
ある。それは、システムを作る基準が、テストを通すための最も
Simpleなシステムを作るという点に考えを合わせていけるから。
４．機能を追加していけば、その都度少しずつシステムは複雑になる。
しかし、Refactoringは、これを緩和する、あるいは複雑さをゆりもど
す１つの方法である。
後、このChapterでは、Communicationにおけるペア・プログラミング
というプラクティスが好きです。また、Feedbackを短いサイクルで行う
べし、それもテストという手段を使ってという点も、注目すべきところと
思います。
--
矢崎 博英 <firo@....jp>