この本で前提としていることがあります。それはコードを通じて他の人とコミュニケーションをとることはプログラマにとって重要であるということです。自分が行いたい処理をただマシンへ指示するだけでは十分ではなく、自分以外の人が自分の書いたコードを見て何を読み取るかにまで配慮しなければなりません。プログラミングはマシンに対しての命令を考えるというよりは作家が文章を書くことに近いと言えます。なぜそうする必要があるかというと、プログラムの変更には最初にそれが書かれた時と比べて3倍から5倍以上の投資が行われるからです。プログラムを書いている間は常に他の人からどう読まれるかを意識しなければならないことが、このことから分かります。なぜならオリジナルのプログラムの作成に費やした時間と比較して何倍もの時間を人々はコードを読んで理解することに費やすことになるからです。
2. なぜそれらをパターンとして書き記そうと考えたのですか？
私がパターン形式で好きなところは、自分が行っていることがなぜそのように行われているのかについて話し合うきっかけを与えてくれるところです。多くのJavaのスタイルブックがあり、その中には優れたものもあります。そこには多くの経験を積んだプログラマが注意深く考えた、どのようにプログラムを書くべきかが記されています。私はそれらを読んでみましたが、それは「変数の名前はこのようにつけよ。コードは以下のように整えよ、...」のような一連の戒律のようなものでした。それら戒律はある状況下では行うに価するものです。しかし、それがうまく行かなかったとしたらそれは何故なのでしょうか？それはどういった背景をもった問題なのでしょうか？それを正しく行うためにはどんな局面で用いればよいのでしょうか？そして結果として得られるものは何でしょうか？私がその流儀に反する必要にせまられた場合、それでもそれら一連の戒律はうまく働いてくれるのでしょうか？ですから、それらとは異なる私個人のスタイルを本書ではとりました。人々がそういったスタイルに行き着く理由は、一緒に利用することでうまく働く一連の判断基準があるためです。それらのうちのひとつだけを取り出して使ってみても当然それはうまく働きません。パターン形式で書くとこういう感じになります。「どうやってフィールドに名前をつけますか？」うーん、そうですね。あなたが名前を付けようとしているソレはいったい何者でしょうか？読み手が変数名を見て興味をもつのは何でしょうか？名前付けの制約はありますか？また、それは十分に皆に知られた名前ですか？変数名の省略はさまざまな理由からうまい具合に働きません。それは何故でしょうか？長すぎる名前もうまく働きませんがそれは何故でしょうか？パターンとして書き出すことで、これら全てのことについて考える機会を得ました。変数の命名に関する私のルールはこんな感じです。シンプルな名前をつけること。それは計算の中でのその変数の役割を正しく言い表している必要があります。私が「変数はこのように命名すべきだ」とだけ言ったとします。誰かがこれを真似ることはできますが、私が注意している点に関して完全に同じ理解を得ることはできません。もっと大事なことはこのルールが正しくない状況のとき、彼らはルールの裏にある考えを理解していないため、いつがそのルールを破るべきときなのかが分からないのです。
3. 自分自身の考えを掘り下げて行くのはどんな気持ちでしたか？それらのルールを見つけ、そこに価値を見いだすのはどんな気持ちでしたか？それらを記してみた今どういう感想を持ちましたか？
それは多くの作業を必要としました。幸いなことに、よく似た内容のSmalltalkの本を書いた経験がありました。それは10年前に私が初めて書いた本です。これは非常に骨の折れる経験でした。私は自分が優れたSmalltalkerであると感じていましたし、スラスラと流れるようにプログラムすることができましたが、ある時、自分が行おうとしている行為が自分の知らないパターンである間は完全にキーボードを叩かないでみることにしました。
私はこれらのパターンを意識することなく利用することに慣れていたので、これは非常に大変な作業でした。まるで自分の手足が突然に自分のものでなくなったように感じました。それはこんな感じでした。コードを5文字書いたらパターンを書き、もう1文字書いたら次のパターンを書く。この作業には 2、3週間かかりました。たいへんな作業でしたが、これらパターンを発見したことにより以前よりスムースにプログラミングできるようになりました。
「この変数にはどんな名前をつけよう？」といった、心の中で頻繁に行っていた議論を行わなくなったためです。同じようなパターンについてはすでに考察済みでしたので、Implementation Patternsを書く中ではそのようなドグマティックな「プログラミングを停止してパターンを記述」のアプローチはとりませんでした。Smalltalkの制約はJavaの制約とは大きく異なります。ですから2つの言語間で大きく異なっているパターンが数多くあります。いくつかはほとんど同じですし、いくつかはかなり違いますが、私はさきほどの内省のプロセスをすでに行っていたので、「自分の足体験」のような思考を今回は行いませんでした。とはいえ、この思考方法が有用であることには変わりありません。自分が強く信じていたり、強い思い入れを持っているものの、そのやり方に対する根拠が乏しい場合に私はこの方法を行いました。たとえばブレース（括弧）などがそうです。本気でこの問題を掘り下げていくのは本当に大変です。ですから、Implementation Patternsではコードフォーマットについてはふれまぜんでした。Smalltalk Best Practice Patterns では取り扱ったにもかかわらずImplementation Patternsでは取り扱わなかった理由は、あるやり方が別のものより優れているという根拠が見いだせなかったためです。コードフォーマットはプログラムの可読性におおきなインパクトを与えると私自身が考えているにもかかわらずです。
4. Pythonのようにコンパイラが正しいコードフォーマットしか受け入れないようにするというのはどうでしょう？(Pythonは空白文字が構文に影響をあたえます) 難しいでしょうか？
新しい環境へ来て自分が慣れたものとは異なるスタイルのコードを読むことを人々は嫌う傾向があります。たしかに皆は数週間コンパイラをきらいになるでしょうが、いずれそれを受け入れて開発を行なっていきます。よい考えだと思いませんか?
空白文字が人間にとって重要ならば、コンパイラにとっても重要なのではないかというのはもっともな話です。コンパイラが空白文字を重要視しないのには技術的な理由があるのですが、それでもなお、空白文字に意味を持たせるというのは良い考えかもしれない思っています。ですからPythonの向かう空白文字へ意味を持たせるという方向性は十分に理にかなっていると思います。わたしがプログラミングを始めたころに習ったUclidという名前の古い言語があります。この言語はPythonと同じような方式を採用していて、それはとても理にかなっていました。しかし私は未だにどちらがいいのか決めかねています。職人としてのわたしは手っ取り早い自己表現のひとつとして自分自身でコードをフォーマットしたいと考えています。一方では、よくできたオートフォーマッタがある場合にはControl-Shift-Fひとつでコードを整形したいという気持ちもあります。
5. なぜパターンをパターンランゲージ形式で記述したのでしょうか？また、そうでないものはなぜパターンランゲージ形式で記述しなかったのでしょうか?
Implementation PatternsではSmalltalkパターンほどパターンランゲージを前面に押し出していません。Implementation Pattenrsでは「このような変数を作る必要がある場合はこちらのパターンへ」のようなパターン間の明示的なリンクはありません。パターン間のつながりは明白なのでわざわざ文章として記述する必要はないと私は考えています。ですから本書ではパターン間のつながりを明示しませんでした。技術的な見地からするとこれはパターンランゲージではないでしょうし、構文的にもパターンランゲージではありません。しかし、意味的には確かにパターンなのです。パターンは複数のパターンを組み合わせて使うことを想定しています。そして、使用されるコンテキストが変化した場合には、一連のパターン郡も同様に変化する必要があります。このことに関して本書を書く中で得た新しい気づきもありました。それは難しい問でもありました。私とエリック・ガンマは本書のアーリードラフトについて議論をかわしました。彼はこう言いました。「いい内容だと思うけど、わたしはフレームワークを開発しているので、この本のパターンのすべてを使うことは無いだろうね。フレームワークの作り方は通常の開発とは大きく異なっていて、自分が正しいと思えるまで行ったり来たりをくり返すんだ。フレームワーク開発は通常の開発とは大きく異なる制約を持つんだ。」そこで私はフレームワークに関する章を設けました。その章にはこう書かれています。本書の大半はアプリケーション開発を前提として書かれています。あなたがプログラムのどこかをリファクタリングしたくなった場合、通常のアプリケーション開発であれば、気になるところを簡単にリファクタリングして振る舞いを変更します。あなたは全てのボタンの押下時の振る舞いを再定義することもできます。たとえそれが大規模なアプリケーションだとしてもです。しかしそれがうまく行かない状況もあります。波及する変更のコストが大きくなってしまうようであれば、あなたは将来の柔軟性を確保するために、今、多少の複雑さへ時間を費やそうと思うはずです。フレームワークの場合は、アプリケーションでやっていた方法と同じようにフレームワークの利用者側の全てのコードを変更することはできないからです。ですからこの章では通常のアプリケーション開発の対局に位置するフレームワーク開発において、フレームワーク開発でのパターンが通常のパターンとはどのように異なるかを私の考え得る範囲内で示しました。
6. この本のパターンの中でいちばん重要なパターンは何でしょうか？
もっとも正統派なのはCompose Methodです。これはこんなパターンです。自分が行おうとしているロジックの意図をコードの読み手へ伝達するのにもっとも効率的な方法は、メソッドをより小さなメソッドから構成することです。大きく長いコードブロックを持たないようにすると同時に、メソッドの中の一行一行の抽象度を一定のレベルにそろえていきます。ですから、ビットシフト演算の次の行で大がかりなオブジェクトの生成のコードが突然出てくることはありません。そのようにコードの抽象度がバラバラだと書き手の意図をうまく伝えることができません。あなたが自分の手になじんだオブジェクト指向言語を使っている場合には、Compose Methodパターンに従ってメソッドを他のメソッドへと分割していくことで自動的に柔軟性の高いコードを、それも無料で手に入れることできます。あなたはCompose Methodを使ってコードを書かなければなりません。それは無料で手に入るにもかかわらず、それを使うだけで他の人が読んでも理解しやすいコードになるうえ、機能の拡張も容易となります。人々はあなたが書いたコードをより容易に変更できますしコードの重複をより容易に取り除くことができます。なぜかというと、ある処理X(エックス)を行うメソッドには2、3の命令しかないからです。短いメソッドは変更が簡単であることを前提とすると、数行の命令しかないメソッドは簡単に変更ができるはずです。これを推し進めると一行だけのメソッドに行き着きますが、一行しかないコードをさらにメソッドにする意味があるのだろうかとあなたは疑問をもつかも知れません。こうすることで、ここではこんな風に計算しよう、といった設計情報を増加させることができます。それら設計情報がコードの中のいたるところへ散らばってしまうと、いざ変更しようというとき、どこをどう修正すればいいかわからなってしまうでしょう。こういう理由で、この本の中心となるパターンはCompose Methodだと私は考えています。本書には他にも76のパターンがありますが、それらももちろん重要なパターンです。そうでなければこの本に載ることは無かったでしょう。しかしComposed Methodはパターンの中核となりうる、ただひとつのパターンのなのです。
7. 本書ではどのようなパターンの形式をとったのでしょうか。どういう手順でそれらを記述していったのでしょうか。それらについてお話いただけますか？
「パターンはこう在るべし」のような厳格なパターンの定義に対して私は魅力を感じなくなってきています。アレギザンダーのパターンがとても厳格なものであることは知っています。「ここはこのセクション、その次はドットを3つ打って、次のセクション...」こんな感じです。それらのパターンフォーマットが便利だとは私には思えませんでした。例えばパターンを書いていて、あるセクションに対して何も書くことがなかったとしたらどうすればいいでしょうか？フォーマットに従うために何かしらをでっちあげるようことはしたくありませんでした。ですから本書のパターンには自由形式のフォーマットを採用しました。「ad-hoc(アドホック)」という言葉は、ある特定の目的のために何かを作成することを意味します。本書でわたしはアドホックなスタイルに挑戦しました。それぞれのパターンはわたしが最善だと思う形式で書かれています。たとえば、あるパターンの中にそのパターンの変種が3つあった場合、それらを3つのパターンへと分割して新しい名前をつけました。そのパターンの変種が十分に小さい場合はオリジナルのパターンに残したままにしました。今回わたしが気をつけたことは、各パターンがパターンフォーマットの意図に沿うようにしたことです。たとえばこんな感じです。「ここにはパターンを理解してもらうための問題の背景を、ここには代わりに使えるパターンを、ここには決定に対して影響を及ぼす他の問題を。そしてここでは、このパターンで行うことを具体的に。」Composed Methodsが良い例となります。聞けばすぐに分かるでしょう。それはこんな感じです。他のメソッドからメソッドを構成するようにしてください。そしてメソッド内のステートメントを同じ抽象レベルにそろえてください。ここまでがパターンで行なうべきことを述べるパートです。本書のパターンではこのように「ここがあなたの行なうべきことです」ということが明確に示されます。これは、ただ抽象的な原則を語るだけとはまったく異なる、わたしにとってのパターンの美点のひとつです。パターンは行なうべきことをあなたに教えてくれます。もしも私が「あなたの意図を明確に伝えなさい」とだけ言ったとしたら、人々はさまざまな方法で自分の意図を明確に伝えようと試みるでしょう。そのうちの何人かは他の人達よりもうまくやれるかもしれません。そこにパターンを用いることで私は自分の発言に対して責任を持つことができます。「オーケー、あなたはKentに意図を伝えろと言ったけど、どう伝えればいい？」そうですね、Compose Methodはどうでしょう。これは自分の意図を伝えるための方法のひとつです。他にはGuard Clauseというのもあります。これも意図を伝えるための方法のひとつです。
8. XPはプラクティス指向な方法論ですよね。Implementation PatternsとXPとの関係についてお話を聞かせていただけますか？ またそれらをどう共存させていけば良いでしょうか？
たしかにXPは一見プラクティスを重視しているように見えるかもしれません。しかし実際のXPの椅子には「プラクティス、価値、原則」の3本の足があります。XPをうまくやっている人達はこれら3つの全てに注意をはらっているというのが私の考えです。少し前の話ですが、わたしはアジャイル開発指南の中でアジャイル開発は魔法ではないという話をしました。人々は次のような質問をしてきます。「どのようにアジャイル開発行えばいいでしょうか？」しかし、アジャイル開発とは「行う」ものではありません。それは「問題に対する姿勢」です。現実の世界と向き合うためのいくつかの個人的な価値感の集合なのです。今そこにある情報をオープンにしようとする意志であり、そのためにできることを積極的に行おうという自発性なのです。それこそがアジリティです。たしかにXPには多くのプラクティスがあります。しかし、それらはアジリティによってもたらされたものです。私にとってはアジリティこそがスタート地点であり、そのスタート地点となるのが問題に対する姿勢なのです。もしいくつものプラクティスを頭で理解した誰かがそのプラクティスを実際に行ってみたとします。アジャイルな心を持たずに形だけのアジャイル開発を始めることはできますが、それは最悪な結果に終わるでしょう。そのような人がアジャイル開発を行ったばあい自分の本心に従った行動をとろうとしてしまうため、結果としてアジャイルとの不協和音を奏でることになるからです。
9. アジャイルにふるまうためには自分自身がアジャイルでなけらばならないとのことですが、アジャイルな心を持っていなければアジャイルにふるまうことはできないのでしょうか？
あくまでも私見です。私が心の内側に閉じこもっていたとき、現実の世界で起こっていることから目を背けていたとき、自分の頭の中で築いた空想の「物事の道理」が正しいものだと考えていたとき、わたしはアジャイルではありませんでした。当時のわたしは現在の自分自身とまったく同じスキルを持っていました。同じようにプログラミングできましたし、パターンも同じように知っていて、同じツールも持っていました。しかし、現実世界で何が起こっているかを語ってくれる他所の人達とのつながりを持っていませんでした。それでは本当にアジャイルであることはできません。
10. 人々がアジャイルを学ぶとき、たいていの場合はアジャイル開発のやり方を教わるだけだと思います。彼らが自分自身の考え方を変えることは本当に有り得ないのでしょうか？
私は言いたいのはこういうことです。アジャイル開発の教育としてプラクティスのみを教えるのは手軽な方法です。しかし実際は思ったほど簡単ではありません。TDDを覚え、継続的インテグレーションを習い、JUnitの使い方をマスターし、朝会の3つの質問を言えるようになれば立派なアジャイル開発者になれるかというと、そんなことはおそらくないでしょう。それは現実に即していないからです。パワーポイントを使ってアジャイル開発とはどのようなものかを説明するのは簡単にできるでしょう。そんなに深く考える必要はありません。本当にむずかしいのはそれを真剣な顔をして発表することです。なぜなら、すぐに、その方法ではうまくいかないというフィードバックを数多く得ることになるからです。椅子の 3 つの足は全てがそろっている必要があります。そうでなければその椅子は倒れてしまいます。プログラムをうまく書けるようになるにつれて、どうすればよりプログラムうまく書けるようになるのかを知りたくなるものです。「Implementation Patterns」などは、そのようなニーズにマッチします。この中にはあなたが本当に身につけることのできるスキルが記してあります。それはパターン形式である必要はありませんが、自分のプログラミングスタイルをパターンとして理解することはアジャイルへ至るためにとても重要です。なぜならアジャイルであるためには、優れた技術者である必要はありませんが、必要十分な技術は持っている必要があるからです。あわせて、あなたはアジリティとの一貫性を持つ価値体系を理解しなければなりません。それは「コミュニケーション、シンプルさ、フィードバック、勇気、尊敬」で、これらはXPより持ってきたものです。アジャイルであることと調和させることによりこれら価値体系はより良いものとなります。また、原則に従うためには、自分たちに合ったプラクティスがひとつもない時はすぐに元のやり方に戻ってこう言います。
「プラクティスはひとつも私達に合いませんでしたが、XPの原則に従うならば、こうやればいいはずです。さあ、やりましょう。」
椅子の3つの足が揃ったとき、あなたは本当にアジャイルであることができます。
守破離とは以下のようなものだと私は考えています。ルールにただ従う、次にルールを破る、そしてルールを越える。それは人の学習の過程に対するナイーブで単純化しすぎた見方です。守破離の良さはその尺度のわかりやすさにあります。「私のレベルはどこでしょうか」や「そのレベルのことはすべて理解できます」のように言うことができます。しかし、人々の学習のしかたはそのようなものではないと私は考えます。東洋の武道でさえもそのような学習の仕方ではありません。私は自分の息子が空手を習うのを見てきましたが、そのような教わり方では全くありませんでした。たしかに空手にも従うべき型はあります。しかし彼らは早いうちからスパーリングを始めます。スパーリング中の彼らは完全に即興・いきあたりばったりですが、あれやこれやを完璧にマスターするまでは何も教えない、というのは空手の習得方法ではないのでしょう。そこにはいくつもの複雑に絡み合ったサイクルがあると私は考えます。私自身のプログラミングのプラクティスでいえば、ただルールに従う時もありますし、あえてルールを破る時もあります。ルールなんて気にせずに、ただただプログラミングする時もあります。 そこには、「自分はまだルールを破る時期じゃない」といった考えはありません。そういう理由から、プラクティスだけを教えるというのは簡略化しすぎたアジャイルの教え方だと私は考えます。確かに、そこには異なる学び方もあると思います。自分では何もせずに、きれいに並べられた「価値」と「原則」を欲しがる人達もいます。自分で経験することを避けようとする人達の手助けをしてきた立場からの考えなのですが、経験することはとても価値があることです。しかし違う考えの人もいます。彼らは守るだけでいいルールを欲しがります。彼ら命令されることを望んでいるのです。「理由はよく分からないけど、山の上にいる偉い人から教わったルールに従っていると良いプログラマになれるよ。」わたしが教える側の立場としてそういう状況にいたならば、自分達の行っているプラクティスの意義と重要性を理解できるよう彼らを手助けします。さきほどの質問を聞いてこんなことを想像しました。今から2年後にだれかがウェブ上にこんな投稿をするのです。「わたしは1000人のプログラマにImplementation Patternsを教えてきました。わたしは彼らに77個のルールだけを教えました。興味を持って戻ってきたその中の一部の生徒に対してだけは、これらのパターンの理論的な背景について説明しました。」私はソフトウェア工学に対する私自身の貢献を誇らしく思うのと同時に、そんなことは止めてくれ！と思うことでしょう。あなたが理解したいと思う事柄を真に習得するためには、自分が行なっていることを様々な観点から理解する必要があると考えています。また、そのことについて誰かと語り合う習慣を早い段階で身につけるとともに、それを行い続けていく必要があります。
12. パターンは最初どのようにして受け入れられていったのか聞かせていただけますか？
いいですよ。わたしがオレゴン大学の学生だったときです。一年生でお金も無かった私は大学内の書店で「時を越えた建築の道」に偶然出会いました。その本を買う余裕がなかった私はそれを書店で立ち読みすることにしました。書店に寄っては１、２章読んで本棚に戻す、別の日にまた来てさらに何章か読むといった感じでした。こうして私はアレグザンダーのスタイルに慣れ親しんでいきましたし、実を言うと「これがあなたの守るべきルールです」というスタイルに魅了されていました。もしそこにあるのがルールのみであったなら、私にできることはそれに従う事だけだったでしょう。そして私は自分の行っていることに自信を持てなくなっていたでしょう。それが実際にはうまくいかなくても、わたしはそれに従うしかないのですから。テクトロニクス社へ入社した私はウォード・カニンガムと一緒に働くことになりました。私達ふたりはアレグザンダーの仕事に影響を受けていました。私達はパターンについてや、どうやったらそれをソフトウェア開発に適用できるか話し合いました。多くの人々がそのことについて話し合っていましたが、実際に何かを行っている人はだれもいませんでした。そこで、私達はパターンを使った実験をはじめることにしました。最初に書いたパターンはユーザーインターフェースデザインに関するものでした。アレギザンダーのメッセージの大きな部分を占め、そして現在は完全に失われてしまったものがあります。彼は、先鋭的で大きな影響を社会へと及ぼす宣言を打ち立てました。実際にその建築物を利用する人こそが、自身をとりまく環境を自分が納得のいくかたちで作り出すことが可能だというものです。それは建築家へお願いしておけば自分達は何もしなくても彼らがうまくやってくれるという今までの考え方とは大きく異なります。パターンのオリジナルである「時を越えた建築の道」では、農夫による時を越えた農作業小屋の建て方を例としてあげています。農夫が小屋を建てるとします。彼は小屋を設計し、それを建て、そしてそれは彼の作業場所としてとてもうまく機能します。それがうまくいく理由のひとつは、彼は彼自身の生活・仕事を熟知していたことです。また、100年、時には1000年にもわたる農作業小屋建築の歴史から得られた、何がうまくいくのか、どんなものに価値があるのかという知識を彼がもっていることもその理由のひとつでしょう。ですから、あなた自身で小屋を設計するだけで、必要な機能を完璧に満たす設備が手に入り、その場所では実に快適に作業を行うことができるのです。
アレギザンダーの宣言は、天上に住む賢いアーキテクトが人々のために図面を書いてやり、出来上がった設計図を持って下界へと降りて来る、そんな現在の状況とは大きく異なるものです。そのような社会的なシフトがソフトウェアエンジニアリングの世界でも行われるべきだと私は考えます。誰よりも自分達は賢いと思っているプログラマが、完成した設計書を持って登場するのを私は見たことがあります。彼らは自分達が入念なヒアリングを元に綿密な設計を行ったのだからこの設計は完璧であると主張して、その設計に対して不満を述べることが許されない他のメンバーへそれを手渡します。しかし、それら設計は彼らの脳内のファンタジーでしかありません。ただのガラクタも同然のものです。パターンのそのような側面が完全に失われてしまったという事実は、私にとってのパターンの悲しい側面です。パターンは専門用語から構成されるただの知識レイヤのひとつとなってしまいました。そればかりか、パターンはソフトウェアを必要とする人々とそれを実際に作る人々とを隔てる障壁となることさえあります。私はそれを非常に恥ずべき事だと考えますし、そのような状況を打破したいと考えています。そうすることにより人々は、自分達の利用するシステムについてのより深い理解を得ることができます。
天気やマイクロソフトに対してと同様に、誰もがこのことに関して不平不満を口にします。誰もがマイクロソフトへの不満を口にしますが、誰も何も行うことができません。外的な要因による制約がなくなってあなたが好きなソフトウェアを使えるようになれば問題は解決するのでしょうか？実はLinuxもまた別の問題を抱えています。それはこう言っています。「これはオープンソースですから、あなたが変更したいと思えばそうすることができます。」とは言うものの、自分の開発領域の中でLinuxのソースを変更する機会が果たしてあるでしょうか？それはエリート主義のアクティビティへと変わってしまいました。そこではちょっとした変更ができるようになるまでに長い見習い期間を必要とするうえ、自分以外の人たちに利用してもらえるような変更ができるようになるまでには、さらに長い見習い期間が必要となります。わたしはコンピュータを使った活動が広まって欲しいと思っています。プログラミングの経験とプログラミングを通して得られるパワーをもっと多くの人達へ届けたいと思っています。それは大変な仕事だとは思いますが。
13. パターン記述の現状についてどう考えていますか？ 人々はうまくやっているでしょうか、それとも間違った方向へ進んでいるでしょうか？
パターンはただのテクニックではありますが、パターンの書き手からすると、それはあなたの心の中にある重要なものです。あなたが何かを行うとき、それを実現するには様々な方法があることを意識していますか？また、そのような意識を持つように心がけていますか？他人よりも多くの知識を得るように努力していますか？自分が信じていることや、普段から気をつけていることについて誰かと語り合っていますか?これらのことは「私はこんなことに注意しています」といったものよりも重用にもかかわらず、意見として述べることは非常に難しいということを私は発見しました。なぜなら誰かがその点に関してあなたと意見が事なる場合、それはあなた自身が否定されたことになるからです。わたしが何かに対するルールを示したとします。たとえばEclipseアプリケーションパターンがあったとして、私がEclipseに興味がない場合･･･、いや、これは本当のことではないので悪い例ですね。では、ここにEJBの使い方に関するルールがあったとします。もし私がEJBに関するルールを述べただけで、わたしがEJBに対して何の思い入れも持たないとしたら、それはパターンとしては間違った方向性です。「それは正しいEJBの使い方じゃない」誰かにそう言われたとしても私は痛くもかゆくもありません。「そうかもしれないね。わたしは気にしないけど」と答えることでしょう。しかし、私が「プログラミングは本当に重要だ」と言った場合、それが本当でなかったらどうしようと私は考えます。そのことに対する不安から居ても立ってもいられなくなって私はプログラミングに関するパターンを書きます。自分が関心をもっていることに対してのパターンを書くとき、そのパターンはより有用なものとなるのです。これが私の考えていることです。