（長谷川＠テクノポートです）
----- Original Message -----
送信者 : "Shigeru Gougi" <gougi2@....jp>
送信日時 : 2000年 9月 24日 日曜日 午後 12:51
> はじめまして、合木といいます。
> とても興味を持たせていただきながら、購読させていただいています。
こんにちは、合木さん。さっそくのフォローありがとうございます。
今までＲＯＭだけだったので、切り出しが難しく、
この後、どうすればいいのか悩んでいた次第です。
合木さんに言われて、少し整理できたようです。
初めてなのに、あのような唐突なメールはまずかったかと。
そこで、私が現在、XPをどのように捉えているか、述べておきます。
個人的には、ＸＰを以下の点で捉えています。
・必要性駆動原理（勝手につけた名前です(^^;)
・リファクタリング
・ペアプログラミング
＃これはあくまで個人的なもので、テストがないじゃないか、
＃といわれても、今の所、含めていないだけです。
必要性駆動原理はいいと思っています。
しかしそれは、余りにも独断的予見に基づいていることが多いからです。
＃経験を応用するのでなく、経験に拘束されていることも含め。
リファクタリングも基本的な道具であり、パターンの揺籠とさえ思っています。
ただしそれにはかなりの年季が必要だと思っていますが。
ペアプログラミングはぜひともやってみたいと思っています。
ただし、開発者に今までとは別の視点を導入するために。
＃と言いつつ、このような言い方は誤解を招くかもしれません。
で、結局は合木さんにまとめてもらったように、進め方のスタンスなんです。
＃何となくですが、ＸＰでするといつもいちからやり始めるしかないように感じます。
規模にもよりますが、設計過程によりホットスポットがフローズンスポットに
変質した時点で、それにあった部品や考え方を探すと思います。
確定した部分から徐々に攻めていくのが、通常なされているプロセスと考えています。
実際は、もう少し強烈な決定が働き、サーバーのＯＳは何々、
ＤＢはこれを使い、通信にはこのミドルウェアを使うなど。
更に、用途が決まるだけでも、ロギングやコンフィグなどは
詳細設計に着手できるかもしれません。
＃ここまで来ると必要性駆動原理に抵触するかもしれませんが。
もっとよくメールを読んでみないとわからないかもしれませんが、
どうも設計作業というものがよく見えないんです。
> > ＃マップらしきものがないようですね。
>
> マップは、メインストーリーとメタファーになるのかなと思っています。アーキテクチャーは
> プログラミングを進めて、１イテレーションを終えたときに最初のものが出来上がると理解して
> います。（間違っているかもしれませんので、率直なご指摘をお願いします。）
StoryCardですね。
実際には、こういった形態で要求が出てくるのでしょうか？
というのも、規定されるものに対する粒度に大きな差があると思うのですが。
＃たとえば、「メンバーの追加、削除」と「あるファイルに１行１名」。
ざっと簡単にラフ設計してみると、以下のようになるかと：
Ａ）メール受信-ディパッチ（メール配信、コントロール要求）
Ｂ）メール配信（メンバー配信、一時中止、ダイジェスト要求、サブジェクト変換）
Ｃ）コントロール要求(ダイジェスト要求、抽出要求；アドレス登録/削除)
Ｄ）アドレスプール(検索、追加、削除；ＭＬ名、ＭＬアドレス)
Ｅ）メールプール（検索、追加、削除）
ＡはＢかＣへディスパッチします。ＢとＣはＤとＥを利用します。
つまり、要求を部品に分割し、その部品の設計と実装、及び組み立てが
完了することをもって、要求を実現したとみなせるのではないでしょうか？
また、こうすると複数の人に作業を割り当てることができます。
そして、私が疑問に思うのは、こういった過程がＸＰでは
どのように取り扱えるかということです。
＃経験の集積をどのように扱うのかとも考えられます。
ここがクリアされると、必要性駆動原理、リファクタリング、
ペアプログラミングなどは上手く働くように思えます。
----------------------------------------------
## テクノポート：長谷川(hasegawa@....jp) ##
----------------------------------------------