塚本さん，こんにちは．石井です．
> 「現在の」を額面通りに考えすぎると勝手が良くないケースもありそうです。
> 例えばこんなケースを想定してみて下さい。
>
> 現在の初号機: 1 [CPU/ボード]
> 次期の二号機: 1..4 [CPU/ボード]
>
> 次期への移行コストを考えると、ボード 対 CPU の関連は最初から「1:多」に
> モデリングされるケースもあると思います。初号機についてはCPU側の多重度
> 1..m に制約 {m=1} がついて test suite も 1 CPU 用に限定されますけど。
次期開発がある，といっておきながら結局なかったというのはよくある話
ですが・・（笑）．
塚本さんは，XPを導入すれば，変更コストのカーブがほとんどフラットな開発
プロセスになると信じてますか？
僕自身はこれは自分で実践しない限りわからないと思っています．だからXP
について懐疑的なところもあるし，非常に期待している部分もあって微妙なん
ですよ，正直いって．
もしこれが成り立つのなら，初号機の仕様できちんと動くものをしっかり作って
例えば半年後次期開発が来たときにRefactoringを行ってもあまり問題では
ないと思うのです．
でもPair ProgrammingやCollective Ownershipなどがどれぐらいの威力なの
か見極めることができせんしね・・（というわけで，答えになってないですね
^^;;）．
> MVC にしても、フレームワークとして提供されているものを「使う」ぶんには
> MVC なしの実装をスクラッチで書くよりもむしろ、アプリケーションコードは
> シンプルになり得ると思います。
そうですね，フレームワークのことは考慮にいれてませんでした．
申し訳ありません．
> 話は変わりますが、「シンプル」と「拡張性」の両立というと、XP が OCP
> (Open-Closed Principle) とどのように協調できるかにも興味があるのですが、
> そのあたりはいかがでしょう?
うっ，これを僕に聞いてくるということは僕のホームページをご覧になったん
ですか？^^;;．
XPの場合，OCPもデザインパターンと同じく到達点の一つと考えています．
仕様が複雑になってきて対応していたらいつのまにかOCPを満たすような
設計になっていた，という．