矢崎です。Section１のChapter５ Cost of Chageの解説です。
Section 1 The Problem
Chapter 5 Cost of Change
===========================================
ソフトウエア・エンジニアリングの広く行き渡っている仮定の１つに、
プログラムの変更コストは、時間が経つにつれて指数的に増加する、
というものがある。要件定義や分析時に発見すれば解決するのに１
ドルしかかからない問題でも、製品になった後で解決しようとすれば、
数千ドルかかるという具合だ。
しかし、この仮定はもはや正しくない。テクノロジーとプログラミング・
プラクティスのコンビネーションにより、時間が経っても変更コストが
指数的に増加するとは言えない状況を経験できるようになった。
K.Beck氏が実際に経験したように、今では非常に短時間に問題を解
決することができる（K.Beck氏が経験したのは、稼働中の生命保険
の契約管理システムで、問題の発見から解決までを３０分ほどで行っ
たものである）。
ソフトウエア開発のコミュニティは、変更コストを減少させるために、
莫大な資源を費やし、よりよい言語、よりよいDB技術、よりよいプロ
グラミング・プラクティス、よりよい環境やツール、新しい表記法を
生み出してきた。こうした投資が実を結び、変更コストが指数的に増
加するのではなく、もっとゆっくりと上昇するカーブを描き、最後に
は漸近線を描くようになったらどうなるだろう。これが、XPの前提の
1つである。
変更コストが時間が経ってもゆっくりとしか上昇しなければ、コストが
指数的に上昇するという仮定のもとで行ってきたやり方とはまったく
別のやり方で行うことができる。重要な決定は、できるだけ遅らせる
ことができる。明日必要になるかもしれないものは、本当にそうなる
かどうかわからないので、今必要なものだけをインプリメントする。設
計に新しいエレメントを追加するのは、そのエレメントが今のコードを
より単純明快にするか、あるいは次に書くコードが単純明快になると
きだけである。
変更コストを低く押さえるための鍵となる技術がオブジェクト指向で
ある。メッセージ・センディングが、変更の数多くの機会を安価に作
り出すための強力な方法である。また、オブジェクト・データベースは、
この柔軟性を、永続記憶の領域へともたらす。
製品化して数年たった後でさえもコードを簡単に修正できたという事
例から、以下のような、いくつかの要因を抽出できる。
・単純明快な設計
余分なエレメントがない設計。今は必要ないが、将来的に必要
になるかもしれないような余分なエレメントは含まない。
・自動化テスト
自動化テストを行えば、知らない間にシステムの既存のふるま
いを変更してしまったかどうかを見逃すことがない。
・設計を変更するために役立つ数多くのプラクティス
システムを変更するときに、心配しすぎることがなくなる。
変更コストの増加についての仮定が変化したことで、私達は、ソフト
ウエア開発に対するまったく別のアプローチをとることができる。こ
の新しいアプローチは、他のアプローチと同じように規律的である。
しかし、次元は異なる。旧来のアプローチは、開発の早期に大きな
決定を行い、後のほうでは小さな決定だけをすることを良しとする。
新しアプローチは、決定をすばやく行い、それをテストで検証する。
そして、その設計について、よりよい方法を学習した時に、設計を
改良していけるように準備しておくのである。
しかしながら、このようなアプローチを作り上げることは容易ではな
い。私たちは、よいソフトウエア開発に効果のあるものについての、
最も深いところの仮定を再検証しなければならないであろう。まず
は、私たちが行う他の全てのことをanchor(?)するであろう、１つの物
語から始めることとする。
（矢崎：：最後のAnchorって何て訳せばいいでしょう？）
（矢崎：：本当はホソカワさんがやるところでしたが、私が無理言って
やらせてもらいました。）
--
矢崎 博英 <firo@....jp>