矢崎です。
Yutaka Kamiteさん wrote:
>
> > [Listening]
> > プログラマはビジネス・ピープルが関心を持っていることを何も知らない。
> >
> > そのことを考えると、プログラマとしてのあなたは、ビジネス・ピープルから聞
> >
> > くということが重要になる。Listeningは、ソフトウエア開発の基本的な
> > Activity
>
（略）
>
>
> これは好みの問題だと思うんですが、「聞く」という単語より「聴く」方が
> 訳としていいと思います。
>
> ＃聞くと聴くが現在の常識で区別されているかわかりませんが・・・
> ＃元雑誌の記者なもので気になったので
> ＃広辞苑を調べてみたら「聞く・聴く」と同じ扱いとした上で、最後に
> 「広く一般には聞を用い、注意深く耳を傾ける場合に聴くを使う」
> となっていました。（第５版）
>
>
> 手元のlongmanの英英辞典だと
> listen : to give attention in hearing
> となっています。注意深く聞く、となっています。
>
> hearのところでも、
> To hear is to experience with the ears; to listen is to hear with attention
> となっていて、hear は耳で物理的に聞くことのようです。
>
なるほど、私もそう思います。どうもありがとうございました。
以下に修正版をアップします。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
矢崎です。Section1のChapter９についての解説です。
間違い等ありましたら、ML上でどんどんご指摘いただければ幸いです。
[矢崎のコメント]
このChapterでは、システム開発の基本的なActivityとして、Coding、
Testing、Listening、Designingの４つをあげ、XP的な観点から、各
Activityを簡単に説明しています。
ここで基本的なという意味は、このChapterの最初に書いてある以下
の文からすると、これらのActivityを除くともはやシステム開発が成り
立たなくなる、絶対に行わなければならないもの、そのような意味で
しょうか？
p.43より引用
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
安定して予測可能なシステム開発を行うためには、行わなければな
らない全てのことを行いたいと思う。しかし、余分なことをする時間はな
い。開発の４つの基本的Activity（basic activities）は、coding、testing、
listening、designingである。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
”車の運転を学ぶこと(Lerning to Drive）”、４つのValue、両手いっぱ
いのPrincipleを学んできたので、もう、ソフトウエア開発のDiscipline
の開発をスタートさせるための準備はできている。まずはスコープを
決めるところから始めよう。システム開発には、４つの基本的な
Activityがある。それはCoding、Testing、Listening、Designingである。
[Coding]
それを行わなければ、もはや何事も行われなかったといわざるを得な
いという意味で、コーディングは基本的なActivityの１つである。あなた
が、コードを生成するダイアグラムを描いていようが、ブラウザを使って
タイプしていようが、いずれにしろ、あなたはコーディングしているのだ。
コードから次のことを得ることができる。
１）学習
学習する方法は、考えることである。そして、それがよい考えである
かどうかを見極めるために、テストすることである。コードはそれを行
うために、ベストな方法である。コードはそれが書いてあるとおりにし
か動かないので、レトリックや、学歴や、給料の多さには影響を受け
ない。コードが思ったように動かない場合は、それはコードのせいで
はなく、書いたあなたの問題である。
２）明確かつ簡潔なコミュニケーション
コードはまた、明確かつ簡潔なコミュニケーション手段になり得る。も
し、あなたがアイディアを持っていて、それを私に説明した場合、私は
それを聴いて、簡単に誤解してしまうかもしれない。しかし、私たちが
いっしょになって、そのアイディアをコード化したら、そのロジックの
中に、あなたのアイディアの正確な形を見ることができる。相手のコー
ドを見て、アイディアがわけばそれをまたコードで表す。これを繰り返す
ことで学習が促進される。
我々はソースコードを持たなければならないので、それをできる限り、ソ
フトウエアエンジニアリングの多くの目的のために、使うべきである。コー
ドは、戦術的な目的を表現する、アルゴリズムを記述する、将来の拡張お
よび縮小が可能な個所を示すといった、コミュニケーションの手段に使うこ
とができる。また、ソースコードはテストを表現することにも使用できる。そ
のテストでは、システムの操作を客観的にテストしたり、全てのレベルにお
けるシステムの有益な操作上の仕様を提供する。
[Testing]
私は、私が書いた全てのものについて、それをテストするまでは信用しな
い。テストは、私がほしいものに関して、そのインプリメントを無視して考え
ることを可能にする。そして、私がインプリメントしたと考えたものを本当に
インプリメントしたかどうかを教えてくれる。
自動化テストは、機能のテストに限定されない。パフォーマンスのテストな
ど、機能以外の部分についての自動化テストを書くこともできる。
テストはあなたが、いつプログラムを完了したかを教えてくれる。テストが
全て終わったら、プログラムを完了したことになる。逆にいえばテストが全
て終わらなければ、あなたはプログラムを完了したことにはならない。
ほとんどのソフトエアは、自動化テストを使って開発されていない。ならば、
Testingが基本的なActivityであるということについて、本当にそう言えるの
か疑問が生ずる。Testingが基本的なActivityであると言えるのは、以下の
２つの理由からである。１つは短期的な観点のもので、もう１つは長期的観
点のものである。
１）長期的な観点
長期的観点からの答えは、テストはプログラムの寿命を長く保つという
ことである（テストが実行され、また保守されていけばという前提つき
で）。長い間にわたり、システムの信頼度は高まりつづける。
２）短期的な観点
テストを持っていてプログラミングすることは、テストを持たない場合に比
べてより楽しいものである。それは、より自信を持って、コーディングする
ことができるようになるからである。ある機能を追加し、テストをし、結果
が正しければ、その都度自信も新たにして、次に進んでいくことができる。
プログラミングとテストをいっしょに行うほうが、プログラミングだけを行うよ
りも開発スピードは速くなる。一度、テストを習慣にしてしまえば、生産性に
関する違いにすぐに気づくだろう。生産性の向上は、デバッグに費やされる
時間の減少からもたらされる。バグを発見する時間が非常に短縮される。
テストには危険もある。正しくないテストは、悪しき楽観主義を生む。テスト
は全てうまく行くっているのだから、それでシステムがOKであると誤解して
しまうからだ。
テストには、Unit TestとFunctional Testの２種類がある。Unit Testは、プロ
グラマが、自分が作ったプログラムが思ったとおりに動くことを、自分自身で
確信するために行う。Functional Testは、顧客が、システム全体が期待どお
りに動くことを確信するために、顧客自身が書く（あるいは少なくとも仕様を
書く）ものである。
[Listening]
プログラマはビジネス・ピープルが関心を持っていることを何も知らない。
そのことを考えると、プログラマとしてのあなたは、ビジネス・ピープルから
聴くということが重要になる。Listeningは、ソフトウエア開発の基本的な
Activityの１つである。
Listeningは単に聴くという受動的な面だけでなく、能動的な面も持たなけれ
ばならない。プログラマが顧客へフィードバックすることがそれである。このフ
ィードバックは、顧客がビジネス上の問題をより理解できるのに役に立つ。
「お互いによく話を聴くべきだ。また顧客の話をよく聴くべきだ。」と言うだけ
では、あまり役にたたない。我々は、必要な事物が、必要な時に、必要な詳
細さで伝えあうことができるように、コミュニケーションを組み立てなければ
ならない。同時に、それは、役に立たないコミュニケーション、内容が本当に
理解される前のコミュニケーション、重要な部分がわかりにくくなるほどの詳
細すぎるコミュニケーションが、促進されないようになっていなければならな
い。
[Designing]
聴いて、テストを書き、テストを実行する、の繰り返しでは、うまくいかない。
始めはうまくいっていても、いずれは行き詰まる。次のテストを完了するには、
それまでのどこかを壊さなければならなくなる。テストが価値をもたらす以上
に、トラブルをまねいてしまうようになる。
これを避ける唯一の方法がDesigningである。Designingは、システムの中のロ
ジックをオーガナイズする構造を作ることである。よい設計は、以下の特徴を
持つ。
１）システムの１つの部分の変更が、常に他の部分の変更を要求する、そう
いうことがない。
２）システムのロジックのどの断片も、たった一ヵ所に記述されている。
３）ロジックを、それが扱っているデータの近くに置く。
４）システムの拡張を、たった１ヵ所の変更だけで可能にする。
悪い設計は、ちょうどこれらの反対である。以下のようなものである。
１）１つの概念的な変更が、システムの多くの部分の変更を要求する。
２）ロジックが重複せざるを得ないような設計である。
３）ある変更に対する影響がどこに波及するのかが明確でない。
４）現在の機能を壊すことなく、新しい機能を追加することができない。
また、複雑さは、悪い設計のもう１つの源である。説明のつかない複雑さがあ
れば、それは悪い設計である。
XPのDesigningは、他のソフトウエアプロセスのDesigningとは、大きくちがって
いる。Designingは、コーディングの最中にあるXPプログラマにとっては、毎日
の業務の一部である。また、Designingは、オプションではない。ソフトウエア
開発が効果的になるために、設計はまじめに考えられなければならない。
--
矢崎博英 firo@....jp