寺田＠東工大です．
リプライがちょっと遅れまして申し訳ありません．
平鍋さん：
> うまく解が求まらない場合のもう1つの脱出法は，(寺田さんはうさ
> ん臭く感じられるでしょうが)，間違った解に行きそうになった時
> に「勇気」を出して別の初期値(アーキテクチャ)からやり直すこ
> と，と XP では言っています．この勇気，ですが，天才の出現より
> も実現可能性が高いかもしれません．XP の公式では，
>
> communication + simplicity + feedback = courage
>
> です．左辺の3つがあって始めてこの「勇気」を決断できるので
> す．(このあたりは工学的ではありませんが，スピリットとしてこ
> うなのです!)
なるほどです．「勇気」は工学的ではないかもしれませんが，ソフトウェアの開発には
「人間」が占める割合は非常に大きそうですから，「スピリット」というのはとても重
要そうです．
＃ この世は全てがうさん臭いかも（笑）
> 先の，リファクタリングの局所解の話でいうと，あるところで，こ
> れ以上エネルギーが下がらず，周囲にはもう道がなさそうなとき，
> 「勇気」を出して，大規模な修正を含めた「ジャンプ」をする必要
> があります．この「ジャンプ」が，別の初期値(アーキテクチャ)の
> 採用にあたるのだと思います．
いいですねぇ！
こういうメタファには弱い（＝好き）ので，思わず納得してしまいます．
シミュレーテッド・アニーリング（SA）法みたいですね．
＃ といいつつ，SA は詳しくは知らないのですが・・・．
確か SA というのは，初期段階では「温度」を高く設定して系全体を高エネルギーな状
態にし，「ジャンプ」が発生しやすい状態にしておきます．そして，だんだんと「温度」
を下げていって，系が冷え切った時に落ち着いた系の状態が最適解，という手法だった
と思います．
XP を SA とのアナロジーで考えると，XP プロジェクトの初期段階ではチームの「温度」
を高く設定して，「勇気をもった大規模修正」をやりやすい状態にするといいのかもし
れないですね．そして，だんだん「温度」を下げていって，プロジェクトの終盤ではあ
まり大規模な修正はしないように落ち着かせる，と．
それにしても，最適化の手法というのは，問題に合った手法を選ぶのが当然です．同様
に，ソフトウェアの開発プロセスも開発対象に合わせたプロセスを選択する方が自然な
のかもしれません．むしろ，Webアプリケーションや組み込みプログラム，数値解析プ
ログラムを同列に扱う方がナンセンスなのだと思います．
例えば「機械」という分野を考えれば，重機の設計と家電機器の設計を同列に考える人
は多分いないと思います．しかし，ソフトウェアの分野では，すべて「ソフトウェア」
と一括りにされることが多いですね．将来的にはソフトウェアももっと細分化して考え
られるようになるのかもしれません．
モデリングが必要かどうかの議論も，結論は多分，開発対象によって違うんじゃないで
しょうか．そうだとすれば，対象としているモノが全然違う人同士が議論しても，イマ
イチ議論がかみ合わない場合が出てきそうですね．
＃ なんだか，どうでもいいことをごちゃごちゃと書いてしまいました．
それでは．