Index: [Article Count Order] [Thread]

Date:  Sun, 24 Sep 2000 12:51:25 +0900
From:  Shigeru Gougi <gougi2@....jp>
Subject:  [XP-jp:00930] Re: Config等について
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <200009240349.MAA03450@....jp>
In-Reply-To:  <011201c0255b$a9d58bd0$640aa8c0@....jp>
References:  <39CC53F6.84FCED1D@....jp> <011201c0255b$a9d58bd0$640aa8c0@....jp>
Posted:  Sun, 24 Sep 2000 12:49:47 +0900
X-Mail-Count: 00930

はじめまして、合木といいます。
とても興味を持たせていただきながら、購読させていただいています。

On Sat, 23 Sep 2000 21:43:12 +0900
"hasegawa" <hasegawa@....jp> wrote:
<SNIP/>
> で、何がいいたいかと言いますと、アプリケーションと部品の関係、
> そして再利用性ということなしに、こういったことを考えても
> 意味がないんじゃないかということです。
> 現在私が加わっているプロジェクトでも、コンフィグファイルから
> 読み込んだデータをグローバルデータに突っ込むだけのものや、
> ちゃんとプロセス間通信やDBアクセス用のモジュールに伝達する
> 仕組みを組み込んだものなど色々とあります。
> 
> 後者は、あくまで、部品、モジュール、ユニットなどと呼ばれるものの
> 再利用性を考慮して初めてそういった形になったものです。
> そうでなければ、どんなやり方も五十歩百歩に過ぎないと感じています。
> 今の所、私には皆さんのやられているものについて、全体像がよく見えず、
> 何が部品なのかも良くわかりません。
> #マップらしきものがないようですね。

マップは、メインストーリーとメタファーになるのかなと思っています。アーキテクチャーは
プログラミングを進めて、1イテレーションを終えたときに最初のものが出来上がると理解して
います。(間違っているかもしれませんので、率直なご指摘をお願いします。)

XPを最初に読んだ時に感じたのが、
「XPで示唆している考え方というのは、仕事ではない小規模なアプリケーション(またはツール)を
自分ひとりで閉じて作る時の作り方に似ているぞ」ということでした。メインとなるストーリをまず
実装して、そのあと問題解決しながら全体を作り上げて行くというスタイル。

対して「自分ひとりで閉じた仕事ではない小規模なアプリケーション(またはツール)」と比較した
のは、わたしが経験したことがある実際の仕事としてのシステムです。この場合は、こうあるべきと
いう全体像とシステムのあらゆる部分を実装、テスト、保守フェーズをでの活動を考えながら詳細な
個所までを完全に設計をする努力をし、そのあとで手分けして実装していくというスタイルです。

前者は、演繹的思考で、後者は、帰納的思考という感じでしょうか。
また、前者(つまりXP)は、メインストーリーとメタファーによりアーキテクチャーが具現化していき、
後者は、アーキテクチャーからシステムが具現化していくといってもよいのではないかと考えました。

そしてそのあとすぐ、
「どちらが良いかという議論」ではなく、ここでXPについて思ったのが(もしかすると長谷川さんが問題
提起されていることと近いのでないかと思うのですが)個人的な経験から言って、

ユーザのシステム利用イメージから想定するストーリ群の中から選ぶメインストーリーと、システムの
メタファーで作られるアーキテクチャーを最初のイテレーションでは良しとし、何回かイテレーション
されたあとで、例えば今回の長谷川さんの問題提起である再利用を目的とした部品化というのを考えな
かった場合、

「もしアーキテクチャーを見直す必要性を感じたときに、さて本当にアーキテクチャーをリファクタ
リングできるのかどうか?」 (つまり、会社全体がそのための勇気を持つことができるのかどうか?)

という疑問を持ちました。

ここで感じているのは、やるとしたら大変だなぞというリスクなのですが、DBベース設計をおろそかに
すると後から大変なことになるぞ、というリスクと同じ程度のリスクを感じます。もちろんこの感じ方
は、個人により差はあると思いますが、わたしはそういう風に感じました。

そして、もう一度読み直してきずいたのは、XPは、演繹的思考での開発をチームで行うための哲学とフ
レームワーク必要であり、その哲学はとってもシンプルで
    ・ やらないといけないと分かっているならばやらなくちゃいけない
    ・ やらなくていいのであれば、やらないといけないと思うまではやってはいけない
という事であると今は思っています。

したがって、個人的な見解としては、

   ・ 再利用性のある部品化を可能な限り目指すのか目指さないか、といったそういった議論は、最初
      にしておいた方が良いだろう。...........(A)

ということです。そして必要であればやるし、必要でなければやらないと決めてよいと今は思っています。

(A)のような最初に議論しておくべき開発方針(のようなもの)を決める検討項目には、恐らく共通の部分
と、個々のチームまたは企業、部署のスキルによって異なるその組織に依存した独自性のある部分として
存在していき、組織に依存した独自性のある部分によりその組織でやれることを表面化させ他の組織と差
別化していくものになるのではないかなと考えています。

--
 Shigeru Gougi  < gougi@....jp >  
 http://www.post.self.ne.jp/~gougi/