こんにちは、合木です。
On Mon, 25 Sep 2000 16:15:25 +0900
"hasegawa" <hasegawa@....jp> wrote:
：
> もともとの動機は、おかしなところで躓いているんじゃないのかな、
> と感じたことでした。ＸＰには必要性駆動原理(YAGNI)があるのに
> なぜこんなところで悩むのかな？といういたって素朴な思いでした。
> あの時点では、分割するかしないは、ほぼ五十歩百歩問題だったと思います。
> それなら単純な方を選択することが、ＸＰとして当然じゃないのかな
> と考えたわけです。洞察としては、それにより分割時のリハーサルを
> することにもなると。
僕が思うのは、「そういった単純な判断をする」という了解または取り決め
が決まるのは、最初のその判断を迫られた時であると考えています。
つまり、「こう考えればいいのにどうしてそうしないの」という事がいくつ
か出て、それについて議論して組織の決め事が出来ていく事は何もおかしな
感じがせず、このMLでの先の出来事も大切なひとつの出来事と捉えていました。
> > > (A)のような最初に議論しておくべき開発方針（のようなもの）を決める検討項目には、恐らく共通の部分
> > > と、個々のチームまたは企業、部署のスキルによって異なるその組織に依存した独自性のある部分として
> > > 存在していき、組織に依存した独自性のある部分によりその組織でやれることを表面化させ他の組織と差
> > > 別化していくものになるのではないかなと考えています。
>
> 私は、一般的な層の上に、個別的な層を構築する、と読んでみました。
私は、XPは「一般的」という風に扱えないと感じています。
そのため、共通部分を別けて、組織ごとにその上への拡張が必要と考えています。
> > XPの共通部分をフレームワークとしてその上に、
> >
> > ・自分達の持っている（部品を含めた）リソースを生かせるような拡張
> > ・自分達の組織が持つ強みを生かせるような拡張
> > ・自分達の扱うドメインに合うような拡張
> >
> > をしていく必要があると個人的に考えることで理解し受け入れられる様になりました。
> > ＃ただ、まだ間違った理解をどこかでして、よからぬところにいってしまっている可能性も大です。^^
>
> これって、方法論＝フレームワークという図式ですか？
> 確かに、そう考えるとわかりやすいことがありそうですね。
自分達の方法論を作るためのフレームワークという図式です。
> > そして、この「どうするか？」と考えた問題とその解決策で開発規約や開発プロセスに関わること
> > は、次回の開発で生かそうと考えるのも自然だと思います。また、そういった問題解決をし自分達
> > の開発プロセスや開発規約として取り組むという事を繰り返すことで、自分達の開発方法論という
> > ものになっていくのではないかと考えています。
> >
> > また、一番最初にXPに取り組む時には、リエンジニアリングと同じように、今までのやり方をすて
> > ゼロから取り組むことが必要ではないかとも思っています。なぜなら、それをすることではじめて
> > 無駄のないプロセスと規約を作れるのではないかと考えるからです。
> > わたしは、そういった理解を今はしています。ただ、やっている中でどんどん変わって行くと思い
> > ます。それもまたXP的でいいような気がしています。^^
>
> 「ゼロから出発」もいいと思いますし、また私も長い期間そうしていました。
> ＃好き嫌いの問題かもしれませんが、カット＆ペーストプログラミングは
> ＃どうも我慢できないものを感じました。
> 前と同じにするのでなく、前より少しでも良いものを、という意思は、
> 大切だと思います。私の場合、部分的な安定構造というものにたどりついたので、
> そういうところではエネルギーを節約し、重要な問題に集中するというスタンスに
> なってしまっています。「ゼロから出発」は実践することによってのみ、
> その意義があるようですね。
実は、ゼロからというのをある会社のオブジェクト指向開発の導入のためのプロジェクト
でやっています。ペアプログラミングはせずに、チームで必要性駆動原理に基づいて、オ
ブジェクト指向開発をしながら、開発方法論を作くることをやっています。
ペアプログラミングをしなかったのは、焦ることはないと考えているからです。
オブジェクト指向開発になれたなと思った頃に、やってみた方がその効果もよくわかるの
でよいだろうという判断です。
１年経ってやっと、今まさにそのベースを作くり終え様としています。１年掛かったの
は、メンバ個々のスキル不足というわけではなく、そのプロジェクトに対してメンバの
一人一人が１００％関われず、１日約２時間〜３時間このプロジェクトに関わりながら
やっているという事が大きいでと考えています。１００％関われたならばもう少し早く
ベースを作れたと思っています。
その会社のメンバの人に怒られるかもしれませんが、本当に良いチームになるという
確証はまだありませんが、少なくても１年前と比べて、個々のメンバが成長している
事だけは確かです。
一番メンバが苦労したのが、問題を問題であると気づくようになってもらうことでした。
次にメンバが苦労したのが、議論の仕方、デザインレビューの仕方でした。
そして、上記２つの力をさらに高めるのがコミュニケーション能力でした。
問題を問題であるときずいたり、よいレビューができないと、必要性駆動原理が機能
しないので、メンバもチームも成長をしていかなくなりますし、開発プロセスや規約も
洗練していくことができません。
ここをどのようにするかが、ポイントだなと思いながら進めていました。
必要性駆動原理で進める力が個々のメンバまたはチームでついて来ると、設計もおのずと
力がついて来ると考えています。
ただ、これについてはもう少しやってみて結果を出して行かないと、強く主張できる様
なものではないと思っています。
--
Shigeru Gougi < gougi@....jp >
http://www.post.self.ne.jp/~gougi/