Document Actions

設計の終焉?

(原題: Is Design Dead?)

マーチン・ファウラー チーフサイエンティスト , ThoughtWorks エクストリーム・プログラミング(XP) をかじってみて、多くの人がこう感じただろう。XPは﹁ソフトウェア設計など消え失せろ﹂と言っているのではないか、と。というのもXPでは、多くの設計作業が﹁料金前払いのデカい設計("Big Up Front Design"﹂などとからかわれているばかりか、UML、柔軟なフレームワーク、そしてパターンまでもを含む設計技法が、ぞんざいな扱いを受けているか、完全に無視されているからだ。実際には、XPにもたくさんの設計作業が含まれている。しかしそれを、既存の設計プロセスとは違うやり方で行っているのだ。﹁進化的設計﹂という考え方がある。XPはこの考え方を、﹁進化﹂を実行可能な設計戦略へとに変換するプラクティス(実践)を用いることで、復興させたのだ。さらにXPは、新たな挑戦課題と新たな技能とを示している。設計者は、﹁シンプルな設計を行うにはどうしたらよいか﹂﹁リファクタリングを行ってきれいな設計を維持するにはどうしたらよいか﹂そして﹁進化的な方法でパターンを用いるにはどうしたらよいか﹂ということを学ばなくてはいけないからだ。 (この文章は XP 2000 会議での基調講演のために書かれた。またプロシーディングスにも掲載される。) ●計画的設計と進化的設計 ●できることを増やすXPの実践 ●単純さの価値について ●単純さとはいったい何か ●リファクタリングは YAGNI 原則に違反しているか？ ●パターンとXP ●アーキテクチャを育てる ●UML とXP ●メタファーについて ●おおきくなったら﹁アーキテクト﹂になりたいかい？ ●後からリファクタリングで追加することが難しいものについて ●設計は死んだのか？ ●謝辞 ●改訂履歴ソフトウェア開発でふつう当り前とされている多くの前提を、 Extreme Programming (XP)は疑問視している。そのなかでも最も論議を呼ぶものの一つは、XPが最初から設計作業に多くの努力を割くことを拒否して、より進化的なアプローチをよしとしている点である。XPの反対者とってこれは、ハッキングとして見下されている﹁書いて直せ (code and fix)﹂型開発への逆行に他ならない。XPの信奉者にとってこれは、 (UML などの)設計技法、設計原理、そしてパターンを拒否することだと理解されている。設計なんて気にするな、コードに耳を澄ましさえすれば、優れた設計が姿を現すはずだ、と。私自身は、この議論のちょうど真中に立っている。自分のキャリアの多くを、私はグラフィカルな設計言語 -- UML やその先行者たち -- とパターンとに捧げて来た。実際、 UML についてもパターンについても本を書いたことすらある。この私が、XPを受け入れると言うことはどういうことか？私が今までこういった内容について書いたことを、すべて悔い改めたということなのか？そんな保守反動的な考え方は、頭の中からきれいさっぱり追い出してしまったということなのか？ .... などといってみなさんを、ドラマのサスペンスのような緊張状態で宙吊りにしておこう、と思っているわけではない。短い答は "No" だ。そして長い答を、ここから先に書くことにしよう。

計画的設計と進化的設計

この論文において私は、設計のやり方に関する二つのスタイルについて、説明するつもりだ。おそらく最もよく見受けられるのが﹁進化的設計﹂だ。進化的設計とは、要はシステムの実装が進むにつれて、設計のほうも成長するということだ。設計もプログラミングの一環であり、プログラムが進化すれば設計も変化する。普通の使われ方では、進化的設計は﹁大失敗﹂という意味である。設計は、その場しのぎの戦術的な決定がたくさん集まったカタマリと成り果て、その一つ一つが、コードの変更を難しくしていまう。進化的設計など﹁設計﹂と呼べない、という議論もいろいろ可能だろうし、また普通はこれが貧弱な設計につながることもあきらかである。ケントが述べたように、長期にわたってソフトウェアの変更を苦労無く行うことを、可能にするものが設計だからだ。設計がダメになっていくにつれ、正しい変更を加えることも困難になっていく。いわばソフトウェアのエントロピー状態を見ているようなものだ。時間が経つにしたがい、設計のひどさは倍加して行く。変更が困難になるだけではない。バグがより発生しやすくなるとともに、バグを発見して安全に取り除くことがより困難になる。これこそが﹁書いて直せ﹂の悪夢だ。プロジェクトが進むにつれて、バグを取り除くコストが指数的に増加してしまうのだ。﹁計画的設計﹂はちょうどこれの反対であり、他の工学分野から得られた知見を含んでいる。犬小屋を建てようと思ったら、木材を集めて、大まかなカタチを作ってしまえばおしまいだ。しかしもし摩天楼を建てようと考えているなら、そんな方法は使えない -- 半分も作り上げる前に崩壊するだろう。私のワイフはボストンのダウンタウンにある設計事務所に勤めているが、だからまずは、そういった設計事務所で作られるような工業用の製図を描くところから手を付けるはずだ。建築設計の作業を通して私のワイフは、問題点を全て洗いだす。それは、数式に頼ることもあるが、多くは﹁建築基準﹂を用いることで行われる。建築基準とは、今までちゃんと建つものを作った時の経験(そしていくつかの基礎となる数学)に基づいた、構造物を設計するためのルールである。設計が完了したら設計事務所は、建造を行う他の会社にその設計を手渡してしまうことができる。ソフトウェアにおける計画的設計も、これと同様の過程を経る。設計者が先だって、全ての大きな問題点を考え抜く。彼らはソフトウェアを作っているのではなく設計しているので、コードを書く必要はない。だから設計者は、UML のようにコード詳細からはなれた設計技法を使って、より抽象的なレベルの仕事をすることが可能になる。設計が済んだら、作成のために別のグループ︵別の会社の場合もある︶に渡してしまえる。より大きなスケールでものを考えているので、設計者はソフトウェアエントロピーを引き起こすような一連の戦術的決定を回避できる。プログラマは設計の指示に従って、また設計に従う限りにおいて、きちんとしたシステムを作ることができる、というわけだ。計画的設計によるアプローチは、すでに70年代から存在していて、多くの人が使ってきた。﹁書いて直せ﹂の進化的設計より計画的設計のほうが良い面もたくさんあるだろう。しかし欠点もある。最初の欠点は﹁プログラミングの局面で対処しなくてはならない全ての問題を見通すことなど不可能だ﹂ということだ。であれば、設計から再考せざるをえないようなことにプログラミングの段階で出喰わしてしまうことは、必ず起きる。しかし、もしその時に設計者の仕事は終わっていて、彼らは既に他のプロジェクトに移っていたとしたらどうなるだろう？プログラマはごそごそとコードを書き加えるようになり、エントロピーが頭をもたげてくる。仮に設計者がまだいた場合でも、設計上の課題を整理して、図を書き直して、その上でコードを改変するのには時間がかかってしまう。普通は、より早くできるフィックスがあったり、時間的な制約も厳しかったりするものだ.. というわけで、エントロピーの︵再︶登場となる。さらに、設計者のカルチャーの問題もよくみられる。彼らは、技能と経験が豊富だから設計者に選ばれたのだろうが、自分自身は設計で忙しすぎて、コーディングをしている暇がない。しかし、ソフトウェア開発のツールやマテリアル類はどんどん変わっている。コーディングをしない人は、技術の絶え間ない流れに起きている変化を見逃すだけではなく、コーディングをする人に対する尊敬の念も、あわせて失ってしまうことだろう。建築の世界にも﹁施工者﹂と﹁設計者﹂との緊張関係は見られるが、ソフトウェアの世界のほうがより強烈である。建築とソフトウェアには重要な違いがあるからだ。建築業界では、設計する人の技能と施工する人の技能に関して、よりはっきりとした区分がある。しかしソフトウェアではこれがはっきりしないのだ。設計が中心となる環境で働こうとするプログラマは、高い技能、それも設計者が出して来る設計を批判的に見ることが出来るくらいに高い技能が必要とされるだろう。特に設計者が、日々変化する開発プラットフォームの現状にあまり詳しくない場合はなおさらそうである。これらの問題点はもちろん、その気になれば解決可能な問題である。おそらく、人間関係の緊張を和らげるような手を打つことができるかもしれない。おそらく、多くの問題に対処できる有能な設計者を手配したり、設計図の﹁書き直し﹂にも対応できるきちんとした開発プロセスを採用したりすることが可能だろう。それでもまだ別の問題がある。それは﹁変化する要求﹂という問題だ。変化する要求こそ、私が関わったソフトウェアプロジェクトで一番、頭の痛い問題である。変化する要求に対処する一つの方法は、柔軟性(flexibility)を設計に盛り込むことである。これにより、要求の変化に応じた変更が簡単にできるようにしておくのだ。しかしこれを行うには﹁どのような種類の変化が起きるのか﹂という洞察が必要になる。変化しやすい領域に対処できるよう、設計の側で準備しておくことはできるだろう。しかしこれだと、予見された変化に対する助けにはなるが、予見されなかった変化に対しては、助けにならない(どころか害悪になりかねない)。だから、要求を十分に咀嚼して、変化しやすい領域を切り分けなければならない。私の見たところ、これは非常に難しい。要求を十分に理解していないことが原因となって、これらの問題が起きることもある。だから多くの人は、設計を将来変更しないですむよう、よりよい要求を得るための﹁要求定義工学プロセス﹂をうちたてようとすることになる。しかしこの方向でも、解決をえることは出来ないだろう。予見されなかった要求変更の多くは、ビジネス上での変化によって引きおこされた。ビジネス上での変化は、どんなに要求定義プロセスを洗練させようとも防ぎようのないことだ。ここまでくると、計画的設計は不可能に思えて来る。実際、これは本当に大きな問題である。ただ私自身は、計画的設計が進化的設計よりもダメだと主張しようとは思っていない。進化的設計の大多数が﹁書いて直せ﹂方式で行われているからである。実際、私は計画的設計のほうが﹁書いて直せ﹂より望ましいと思う。しかし計画的設計の問題点にも気づいているからこそ、新しい方向を探ろうとしているのだ。

できることを増やすXPの実践

XPは多方面で論議を呼んでいる。焦点の一つは、XPが計画的設計よりも進化的設計を主導している点にある。見てきた通り、その場しのぎの決定とエントロピーの法則からいえば、進化的設計がうまくいくなんてことはあり得ないからだ。この議論を理解する上で基礎となるのが、﹁ソフトウェアの変更に関する曲線﹂の存在である。この変更曲線が述べるところによると、プロジェクトが進行するにつれて、変更を行うコストは指数的に増大する、のだそうだ。変更曲線はよく、﹁分析の段階では1ドルで済む変更が、製品の段階で直すとなると、何千ドルにもなる﹂などと表現される。分析フェーズなど持たないその場しのぎのプロセスしかなくても、多くのプロジェクトでうまくいっていることを考えるとこれは皮肉に聞こえるが、それでも、累乗効果の議論は生き残る。この指数関数的な変更曲線が意味するところは﹁進化的設計がまともに機能する余地などない﹂ということだ。さらにこれは﹁計画的設計は注意深く行わなくてはいけない﹂という意味にもなる。計画的設計におけるどんな間違いも、同じように、指数関数的な増幅を受けるからだ。 XPが措いている根本的な前提は﹁進化的設計がうまくいくように、変更曲線を平らに近づけていくことができるはずだ﹂ということである。この平坦化は、XPによって実現される(enabled)と同時に、XPによって利用もされている (exploited)。これはXPプラクティス同士の﹁結びつき﹂を構成している‥ つまり、この平坦になったカーブを﹁利用する﹂ようなXPプラクティスを、カーブを平坦に﹁近づける﹂XPプラクティスと切り離して行うことはできないのだ。XPをめぐる論争がよく起きる原因がここにある。多くの人は、﹁できることを増やす(enabling)﹂部分を理解しないままに、XPの﹁利用する﹂部分を批判する。その批判の多くは、彼ら自身の過去の経験から導かれたである。しかしそのとき彼らは、﹁出来ることを増やす﹂プラクティス(つまり﹁利用する﹂プラクティスの効果を保証する部分)を実践していなかったのだ。結果として彼らは火傷を負うことになり、XPを見ると、彼らの身を焦がしたあの炎を、また思い出してしまうのだ。﹁できることを増やす﹂プラクティスにもいくつかある。それらの中心に位置するのが﹁テスト作業﹂と﹁連続的インテグレーション﹂である。テスト作業がもたらす安全性なしには、XPの他の部分は不可能になってしまうだろう。連続的インテグレーションはチーム各人の歩調をあわせるために必要であり、これによって、あなたが変更を加えるときにも、他人の作業との統合で起きる心配をしなくてすむのである。これらのプラクティスを合わせて行うと、変更曲線に大きな影響を与えることが可能になる。ここ ThoughtWorks 社︵訳注‥ファウラー氏の現在の職場︶においても、このことが再確認された。テストと連続的インテグレーションを導入すると、開発作業に確かな改善が見られたのだ。これは明らかに、﹁大幅な改善を得るには、ＸＰの﹃全部の﹄プラクティスを実践する必要がある﹂というXPの主張を真剣に疑う上で十分であろう。リファクタリングにも同様の効果がある。XPが唱える秩序だったやり方でコードをリファクターする人は、よりいい加減な、その場限りの再構成をすることに比べると、効率が全然違うことに気づくだろう。これは Kent が私に正しくリファクターすることを教えてくれた時に、私自身が経験したことである。だって、それほど強烈な変化でなければ、リファクタリングに関する一冊の本を書き上げようとは思わなかっただろう。ジム・ハイスミス氏は、そのXPに関する優れた要約の中で、﹁天秤﹂の例を使っている。天秤の片側の皿には計画的設計が、そしてもう片側にはリファクタリングが置かれている。今までのアプローチでは計画的設計のほうに天秤が傾いていた。というのも、あとで心変わりすることは許されない、という前提があったからだ。変更にかかるコストが減っていけば、設計のうち、リファクタリングの形で後から行うことのできる分量は増えていく。計画的設計が完全になくなることはないが、二つの設計アプローチのバランスを取りながら進めていくことができる。リファクタリングを知る以前の私は、片手で設計をやっていたようなものだ。連続的インテグレーション、テスト、リファクタリングなどの﹁できることを増やす﹂プラクティスは、進化的設計を可能ならしめる新たな環境を提供してくれる。しかし、﹁どこでバランスを取るべきか﹂という問題は、まだ我々にもよくわかっていない。外野からの想像とは異なり、単にテスト、コード、リファクターだけでXPが出来るというわけではないのだ。設計を行う機会は、コーディングを始める際に産まれる。コーディングが全く行われていない時にもあるにはあるが、大多数の設計の機会は、イテレーションの最中、あるタスクのためのコーディングの前に発生する。しかしここで、新たに前払いの(up-front)設計とリファクタリングとの間にバランスを取らなくてはならないのだ。

単純さの価値について

XPのスローガンのうちで最高のものなにか。それは、﹁なんとか動いて、最も無駄のないものをやれ﹂("Do the Simplest Thing that Could Possibly Work")と﹁どうせ要らないって﹂("You Aren't Going to Need It":YAGNI として知られる)との二つだろう。両方とも、XPプラクティスの﹁単純な設計﹂を反映したものである。よく、YAGNI の述べるところは﹁明日にならないと必要とされない機能のために、追加のコードを今日書いてはいけない﹂ことだと説明される。これを聞いただけなら、簡単なことだと感じるだろう。YAGNIは﹁フレームワーク﹂﹁再利用可能なコンポーネント﹂﹁フレキシブルな設計﹂といった事柄に関連してくる。こういったもの作成は複雑であり、追加の設計を前払いで行うはめになる。しかしそのコストは、将来に回収されることが期待される。つまり、フレキシビリティを最初から組み込むことが、効果的なソフトウェア設計のカギである、と思われているわけだ。しかしXPの推奨によれば、その機能が最初に必要になるときに備えてフレキシブルなコンポーネントとフレームワークを書くようなことは、すべきでない。機能が必要とされるにしたがって、構造を発展させるべきなのだ。もしも今日、足し算はできるが掛け算は必要の無い Money クラスを欲しいと思ったら、私は足し算の機能だけ Money クラスにいれるだろう。仮に次のイテレーションで﹁かけ算が必要になる﹂とわかっていたとしても、またかけ算の実装のやり方もわかっていて、それもすぐ出来るだろうとわかっていたとしても、それでも、次のイテレーションにまわしてしまうのだ。こうする理由の一つは、経済的なものだ。将来必要になる機能のためだけの仕事をやるということは、今回のイテレーションで必要となる機能のための労力を失うということになる。﹁いま、なにをすべきか﹂をリリース計画が示している以上、将来のための何かを行うことは、顧客との開発に関する合意に背くことになる。今期のイテレーションにおけるストーリーが完了しなくなる、というリスクもある。そうでなかったとしてもなお、どの追加の仕事をやるべきかどうかを決めるのは顧客なのだ -- 掛け算なんかいらないよ、と言われるかもしれない。将来の仕事をやるべきでないというこの経済上の理由は、正しく実装できないかもしれないという危険によって、さらに大きなものとなる。この機能のふるまいはこうなる違い無い、と我々がどれだけ自信を抱いていたとしても、それでも間違える危険がある。なぜかと言えば、詳細な要求事項をまだ手にしていないからだ。間違った解決方法に最初からとり組むなんて、正しい解決方法に最初からとり組むことよりさらにムダだ。我々は後で正しかったとわかるより、間違っていたとわかることのほうが多いのだというのが、XP実践者の一般的な信念である︵ある感慨と共に、私もこの意見に賛成する︶。単純な設計を推奨する二番目の理由は、複雑な設計は﹁旅行の荷物は少なめに﹂という原則に反するからだ。複雑な設計は単純な設計より理解するのが困難だ。追加の複雑分だけ、システムに対する他のどんな変更の困難さも倍加する。これは、﹁複雑な設計﹂が追加された時期と、その設計が実際に必要とされた時期とのあいだのコストが、上昇するのだという意味である。多くの人にとって、今まで述べて来たこのアドバイスは馬鹿げたものに聞こえるだろう。そう考えるのは正しい。正しいというのは、通常の開発環境、つまり﹁できることを増やす﹂XPのプラクティスが行われていない環境のことを考えている場合に、正しいのだ。しかし、計画的設計と進化的設計のバランスが変化すれば︵そして変化した時に限って︶、YAGNI は素晴らしいプラクティスとなるのだ。まとめよう。将来のイテレーションになって初めて必要とされるような、新たな機能のための努力などしなくない。仮にタダでできるとしてもするつもりはない。なぜなら追加はタダだとしても、それは変更のためのコストを上げているからだ。しかしこのやり方でうまく立ち回れるのは、XPを使っているか、変更コストを抑えるまた別の技法を用いているときに限る、ということになる。

単純さとはいったい何か

というわけで、コードをなるべく単純にしたい、ということがわかった。これは、あえて主張するほど難しいことだとは思えない、誰だってややこしいものなど欲しくないからだ。しかし次には、﹁単純さとは何か？﹂という疑問がでてくることになる。 XPE の中で、ケントは単純なシステムの四つの基準を掲げている。重要度の順に並べると、以下のようになる。 ● 全てのテストを行う ●全ての意図が明確になっている ●ダブりがない ●クラスまたはメソッドの数が最小である﹁全てのテストを行う﹂はすごく単純な基準だ。﹁ダブりがない﹂も簡単である。とはいえこれを達成するには、多くの開発者がガイダンスを必要とするのだが。もっともややこしいのは﹁意図が明確になっている﹂である。これはいったい、何を指すのだろうか？ここでの根本的な価値基準は﹁コードの明晰さ﹂だ。XPは、読みやすいコードに高い価値を認める。XPで﹁賢いコード(clever code)﹂と言えば、ののしり言葉なのだ。とはいえ、ある人が﹁意図を明確にしたコード﹂と思ったものが、他人には﹁小利口さ(cleverness)﹂と見えることがある。これのよい実例を、ジョシュア・ケリーブスキ︵Josh Kerievsky︶氏がXP2000 論文において取り上げている。彼が注目したのはおそらく最も有名なXPコード、JUnit だ。 JUnit では、﹁並行処理の同期﹂とか﹁バッチ処理のコード﹂といったオプショナルな機能をテストケースに対して追加する際には、﹁デコレーター﹂︵decorator︶を用いることになっている。これらのコードをデコレーターへと分離することで、JUnit は、そうしない場合よりも、コードの明晰さをあげることできたのだ。しかしここで問い返せねばならない。できあがったコードは本当に﹁単純﹂か？私にはそう見える。だがそれは、私が Decorator パターンのことを良く知っているからだ。しかし、そうではない多くの人にとっては複雑だろう。同様に、JUnit では﹁はめこみ可能なメソッド﹂(pluggable methods) を使っているが、私の知る限りでは、初見の人の多くに取って全くわかりにくいものであった。となれば、こう結論づけて良いのだろうか？ JUnit の設計は、経験を積んだ設計者に取っては単純であるが、経験の浅い人々にとっては複雑なものなのだ、と。 XPなら "Once and Only Once" (いちど、ただいちど)とか Pragmatic Programmer's なら DRY (Don't Repeat Yourself : 同じことは一度しか言わない)とかいった標語があるが、こうした﹁重複を排除すること﹂に対する注意こそ、すぐに理解できて驚くほどの効果を持つ優れたアドバイスだと私は考える。このアドバイスに従うだけでかなりの成果がうまれるだろう。しかしこれだけで全てが片付くわけではない。﹁単純さ﹂を見出すことは、依然としてややこしいことなのである。私が最近関わったもので、設計が過剰になりつつあるコードがあった。これにリファクタリングを行って、柔軟性をすこし削ぎ落してしまった。しかし開発者の一人は、﹁過剰な設計をリファクタするほうが、設計皆無なのものをリファクタするより楽だね﹂と述べていた。もちろん、必要とされるより少しだけ単純であることがベストなのだが、仮に少しだけ複雑になったからといって大失敗、ということにはならないのだ。私の知る限りもっとも良いアドバイスは、アンクル・ボブ(Robert Martin)のものである。﹁何が最も単純な設計か﹂という問題にこだわりすぎてはいけない。だって、後になってリファクタできるんだし、すべきだし、どうせやることになるのだから。最終的には、リファクタするのだという意志のほうが、最も単純な設計をいますぐ思い付くことよりもずっと重要なのだ。

リファクタリングは YAGNI 原則に違反しているか？

最近のXPメーリングリストでも、この話題はよく取り上げられる。また、XPにおける設計の役割をみていく上でも、ここで取り上げる価値があるだろう。リファクタリングは、時間は取るくせに機能の追加は行っていないではないか、という指摘からこの疑問はスタートしている。将来のためではなく﹁今﹂のために設計せよ、ということが YAGNI の意味するところであれば、リファクタリングは YAGNI に反しているのではないか？ YAGNI のキモは、現在のストーリーに必要とされない複雑さ (complexity)を加えるな、というところにある。これは﹁単純な設計﹂というプラクティスの一例である。リファクタリングが必要とされるのは、できるかぎり設計を単純にとどめておきたいからであり、であれば﹁もっと単純にできそうだ﹂と思った時にはいつでも、リファクターすべきなのだ。﹁単純な設計﹂は、XPのプラクティスを利用している(exploit)と同時に、それ自身が、できることを増やす(enabling)プラクティスでもある。テスト、連続的インテグレーション、リファクタリングなどを行って初めて、﹁単純な設計﹂を現実に実行できるのである。しかし同時に、設計を単純にすることこそが、変更曲線を平らに近づけていく上で必須なのだ。必要のないややこしさを追加すれば、その追加が﹁柔軟性﹂を与えるだろうと予想していた部分を除くとしても、あらゆる面でシステムの変更が困難になる。しかも、人は予想がへたくそと来た。であれば単純さを追求するのが最善だろう。とはいえ最初から﹁最も単純なもの﹂など出来ないだろう。であれば、目標に近付くために、リファクタリングが必要になるというわけだ。

パターンとXP

JUnit の例を出した以上、パターンを取り上げないわけにはいかないだろう。パターンとXPの関係は面白いし、よく質問されることでもある。XPはパターンをそれほど重視しない(under-emphasized)、とジョシュア・ケリーブスキは主張している。彼の主張は説得力のあるもので、ここで繰り返すことはしない。ただ、多くの人にとってパターンはXPとぶつかるもののように見えていることは心に留めておこう。この議論の核心は﹁パターンは濫用されるきらいがある﹂ということだ。初めてGOF を読んで、すぐに32行のなかに16種類ものパターンがでて来るコードを書いてしまったプログラマがいる、という﹁伝説﹂がそこかしこで聞かれるだろう。そういえばある晩、美味しいシングルモルトの助けを借りて、私とケントで﹁ノットデザインパターン: 23 種のインチキ技﹂なる名前の論文を考えていたことを思い出す。﹁ストラテジーパターン﹂ではなくif文を使え、とか、そんなやつだ。このジョークで言いたいことは、パターンはしばしば濫用されるが、だからと言ってパターン自体が悪い考えとはならない、ということだ。肝心なのは、どうパターンを使うかである。理論的に言ってみよう。﹁単純な設計﹂という﹁フォース﹂が、あなたにパターンを選択せしめるのである。多くのリファクタリングは、この選択を見える形で行っている。しかしリファクタリング無しでも、単純な設計を行う、というルールに従っていれば、パターンを知らずしてパターンにたどりつくものなのである。ただ、そうだとしても、知らないままに使っていることが一番良いといえるだろうか？明らかに、自分がどこに向かっているのかおおまかにでも把握していて、全てを自分でひねり出すかわりに、助言をくれる本を手元に持っているほうがよいだろう。私自身、これはパターンが使えそうだなと思うと、今でも GOF に手を伸ばすのである。私に言わせれば、優れた設計を行おうとするのであれば、パターンには払うコストに見合った価値があることを、知らなくてはいけないのである -- パターンそれ自身がスキル︵技能︶なのだ。同時に私たちは、ジョシュア氏が示したように、パターンを徐々に、抵抗無く取り入れていくための方法をよく知る必要がある。この点でXPがパターンを扱うやりかたは他の人のやり方と異なるかもしれないが、しかしパターンの価値を損ねるようなことは、していないのである。とはいえ、XPがパターンに反対しているのだと普通の人はとらえていることが、いくつかのメーリングリストの議論を読むと明らかに感じ取れる。XPの主導者の大多数が、パターン運動におけるリーダーであったにも関わらず、だ。これはどういうことか？XPの賛成者がパターンよりさらに高次なものに気づいてしまったということなのか、それともパターンは、彼らの思考にあまりに深く埋め込まれてしまい、意識すらされないということなのか？他の人がどう考えるかは判らないが、私の答えはこうだ。パターンは、依然として、とても重要だ。XPは開発プロセスの一つだが、パターンは設計に関する知識の屋台骨であり、この知識は、開発プロセスが何であれ役に立つものなのである。違う開発プロセスは違うやり方でパターンを使用する。XPは﹁必要になるまでパターンを使うな﹂ということ、そして﹁単純な実装を目指すなかでパターンへと脱皮していく﹂ことに力点をおいている。しかしそれでも、パターンは、修得すべき重要な知識なのである。 XP実践者にアドバイスを与えるとすれば、 ● パターンについて学ぶ時間を投資せよ ● パターンを使うべき時についてよく考えよ︵早すぎてはいけない︶ ● まずは、最も単純なかたちでパターンを組み込む方法について考え、複雑なものは後から追加せよ ●パターンを入れてみて、後で﹁失敗したな﹂と思ったら -- 躊躇せず取り除けとなるだろう。私は、XPがパターンを学ぶことについて強調すべきだと思う。どうやってXPのプラクティスに組み入れるかは定かではない。だが、ケントなら絶対、何かうまい手を思い付くだろう。

アーキテクチャを育てる

ソフトウェアの﹁アーキテクチャ﹂とは、一体どういう意味だろうか？私の考えでは、アーキテクチャという単語にはシステムの核となる要素、変更困難な部分、システムの残りの部分がよって立つ基盤、といった含意がある。アーキテクチャは、進化的設計を採用した際にはどんな役割を果たすのだろうか。ここでもまたXPの反対者は、XPはアーキテクチャを無視している、コードにすぐ飛びついて、すべての設計の問題はリファクタリングで何とかしようというのがXPの常道だ、と批判している。興味深いことに、彼らは正しい。そしてこのことはXPの弱点ともなるだろう。ケント・ベック、ロン・ジェフリス、ボブ・マーティンといった最も積極的なXP支持者は、前払いのアーキテクチャ設計をなるべくしないで済まそうと手を尽くしている。必要になるまでデータベースなんか使わず、まずはファイルシステムでスタートして、後半のイテレーションのどこかでリファクターしろ、等々。私は臆病者のXP支持者として知られているが、であればこそ彼らには賛成できない。開始時点での広範囲なアーキテクチャが果たす役割、というものもあると考えるからだ。例えば、アプリケーションの階層をどう切るか、︵必要なら︶データベースとのやりとりをどう扱うか、Webサーバーをどう使う際にどのようなアプローチを取るべきか、などといったことがあげられる。基本的にこれらは、年月を経て見出されたパターンによってカバーされる領域だと思う。パターンに関する知識が増えれば、まずはそれをどう使うか、それなりに決められるようになるだろう。しかし大きな違いは、これらのアーキテクチャ上の決断は石に刻んでおくようなものではないこと、そして開発チームは、むしろ自分たちが初期の決定において間違いを犯したことを素直に認めてそれを修正をする勇気を持つべきだ、ということになる。あるプロジェクトでは、稼働間際になって、もう EJB に頼る必要はなくなったと判断してシステムから取り除いてしまったそうだ。これは非常に大きなリファクタリングであったし、しかも行われたのはプロジェクトの後期だった。しかし﹁できることを増やす﹂プラクティスのおかげで、単に可能だっただけではなく、やるだけの価値がもたらされたのだ。これを逆に考えてみよう。仮に﹁EJBを使わない﹂と決めていたとしたら、後から追加するほうが取り除くより難しいだろうか？[訳注‥いや、追加する方がラクだ。] であれば、最初からEJBを使うのは、EJBを使わずにいろいろ試してやはり必要だとわかった時だけにするべきだ、と言っていいのではないだろうか？これは、いろいろな要因が関係してくる質問だ。確かに複雑なコンポーネントなど用いないほうが、単純さは増すし、手も速く動くだろう。しかし、後から何かを取り除くほうが、後から何かを付け加えるよりラクなこともある、というのも事実だ。私のアドバイスを述べよう。そうなる可能性の高い︵likely︶アーキテクチャがどのようなものになるか、調べることから始めよう。大量のデータと多人数のユーザーを扱うことが期待されているなら、開発の初日からデータベースを使えばよいのだ。ビジネスロジックが複雑になりそうなら、ドメインモデルを入れてしまおう。しかし、もし迷ったときには、YAGNI の神に対する敬意を払い、単純さの増す側に落ちるようにしよう。さらに、何の意味もない部分を自分のアーキテクチャの中に見つけたら、即座にアーキテクチャを単純化するつもりでいなくてはいけない。

UML とXP

私のXPに対する肩入れに関して頂いた質問の中で、一番大きいものの一つは、私と UML との関わりをめぐっての質問である。XPと UML は両立しないものなのではないか？両立しない点はいくつもある。ご存じの通り、XPはダイアグラムの類を徹底的にこき下ろしている。XPの公式な立場としては﹁もし便利だという時には使いなさい﹂という線に落ちついているが、そこには﹁本当のXP実践者はダイアグラムなんか使わない﹂という意味合いが濃厚に出ている。このことは、ケントのような人々がダイアグラムを全く苦手としているという事実によって裏打ちされる。実際、ケントが自分から、決められた表記法に基づいてソフトウェアの図を書いたところを私は見たことがない。この議論は二つの別々の原因からひきおこされていると私は考える。一つは、﹁ソフトウェアダイアグラムを便利だと思う人もいれば思わない人もいる﹂ということである。怖いのは、便利だと思う人は思わない人に対して﹁便利だと思え！﹂と考えているし、逆もまた真だということだ。我々は、こんなふうに思うかわりに、ダイアグラムを使う人もいればいない人もいるのだ、ということをそのまま受け入れるべきなのである。もう一つの原因は、ソフトウェアダイアグラムは重量プロセス(heavyweight process)と思い出させることが多いということである。重量プロセスは、有害無益なダイアグラムを描くのに、長い長い時間をかけてしまう。だから私は、人々に必要なのは、XP実践者がよく唱えている﹁どうしても必要ならしょうがないな︵この弱虫！︶﹂などというメッセージではなく、ダイアグラムを、罠にはまることなく、賢く使うためのアドバイスだと思う。では、ダイアグラムを賢く使うためのアドバイスを示そう。まず最初は、何のためにダイアグラムを描いているのか思い出すべきだ。基本的な価値のモノサシは、コミュニケーションである。コミュニケーションを効果的に行うということは、重要なものを選び出し、重要でないものを省くということだ。この選択性は UML を使う上でカギとなる。全てのクラスに対して図を描くのではなく -- 重要なクラスに対してだけ描くべきだ。各クラスにおいても、全ての属性と操作とを描くのではなく -- 重要なものだけ載せるべきだ。全てのユースケースとシナリオに対してシーケンス図を描くのではなく -- 後は同じである。ダイアグラムの使い方でよくある問題は、みんながダイアグラムを包括的︵comprehensive︶に描いてしまうことだ。コードこそが、包括的な情報の最も優れたソースである。というのも、コードこそ、コードの中身と同期を取るのに一番ラクなものだからだ。ダイアグラムにとって、包括的であることは、わかりやすさ︵comprehensibility︶の敵なのである。ダイアグラムをよく使うのは、コーディングを始める前に設計をいろいろ試してみる時である。XPではこんなことしてはいけないのでは、と思うかもしれないが、これは正しくない。多くの人が、やっかいな仕事をかかえているときには、まずはみんなで集まって、設計のための短いセッションを持つべきだと言っている。ただし、そういうセッションを開くときに注意すべきことがある‥ ●短時間で切り上げよ。 ●全部の詳細を詰めようとしてはいけない︵重要事項だけにとどめる︶。 ●できた設計は﹁最終稿﹂ではなく﹁スケッチ﹂として考えるべし。最後の点を展開してみよう。前払いの設計を行うと、否応なく、設計のある側面が間違っていることがわかり、しかもそれって、コーディングの段階になってはじめて判明するのだ。しかし設計をそこで変更するならこれは問題にならない。問題がおきるのは、人々が﹁設計は終わったのだ﹂と考え、コーディングで得られた知見を設計に再び反映させることをしなかった時である。設計を変更したからといってダイアグラムを描き換えることになるとは限らない。設計に関する理解を深めるためにダイアグラムを描いて、そのあと捨ててしまう、ということはまったく合理的だ。描くことが助けになった、ならばそれで充分ではないか。ダイアグラムが永続的な人工物になる必要なんてない。 UML 図がうまく描けたからといって、それは文化遺産ではないのだ。多くのXP実践者がCRCカードを利用してる。これはUMLとは干渉しない。私はずっと CRC と UML との両方を使っており、目前の仕事によく適している技法のほうを使うことにしている。 UML 図のまた別の使われ方に、開発途中でのドキュメンテーションがある。通常は、CASEツールの中にはいっているモデルがそれである。こうやってドキュメントを用意しておけば、みんながプログラムにたいして仕事をする上で助けになる、ということになっている。しかし実際には、全然助けにならないことが多い。 ● ダイアグラムを最新の状態に保つ作業は、時間がかかり過ぎる。だからコードより古くなってしまう。 ● CASE ツールだとか分厚いバインダーの中とかに隠れて、誰も見ない。こういった問題を認識することで、開発途中のドキュメンテーションに関するアドバイスが導き出される‥ ● ダイアグラムは、意識して苦労することなしに最新状態に保つことのできるものだけを使おう。 ● ダイアグラムは、みんながすぐ見える場所に置こう。私は壁に貼り出すのが好きだ。みんなには、単純な変更なら壁に貼りだしたコピーに直接書き込むように言っておこう。 ● 使い捨てのダイアグラムでない限り、そのダイアグラムをみんな使っているかどうか、ちゃんと気にしよう。 UMLの利用で最後に来るのは、引き渡しのような状況でのドキュメントに使う、というものである。例えば、あるグループが他のグループに引き継ぎを行うような場合である。XPの主張は、﹁ドキュメンテーションを作成する﹂というのも他のストーリーとなんら選ぶところはないのであり、そのビジネス上の価値は顧客が決める、というものだ。ここでも、コミュニケーションのためにダイアグラムをきちんと選択して使っているのなら、UMLは役に立つ。あくまでコードが詳細情報の倉庫であり、ダイアグラムの役割は、重要な面をまとめたり強調したりすることだということを、心に留めて置いて欲しい。

メタファーについて

これはみなさんの前で言っても構わないだろう -- 私はまだ、XPの﹁メタファー﹂とやらについて、よくわかっていないのだ。うまくいく、というのは経験したし、C3 プロジェクトでも役に立ったのだが、だからといって、そのやり方について、私がなにか理解しているということではない。やり方をさらに説明するやり方なんてなおさらだ。 XPのプラクティス﹁メタファー﹂は、Ward Cunninghams の﹁名前の体系(a system of names)﹂というアプローチに基づいている。要は、ドメインを語る時の術語として用いるために、よく知られている一群の名前を思いつくというものである。この名前の体系が、クラスやメソッドに名前をつけるやり方に影響を及ぼす。私はいままで、ドメインの概念モデルを作成することによって、名前の体系を構成してきた。これをやるときには、そのドメインの専門家と一緒に、UML やその先行者を使っていた。いろいろと気を付けるべきことがあることがわかっている。表記法は最小限に押さえなくてはいけない。また、技術的な問題がモデルにこっそり入り込んでこないようにガードしなくてはならない。しかしこれをやっておけば、ドメインを語るための術語を増やす時には、この概念モデルを用いることができるし、しかもドメインの専門家もその術語を理解して、開発者との意志疎通のために用いることが可能になるのだ。このモデルとクラス設計とは、完全には一致しない。それでも、ドメイン全域に対して共通の術語を用意できるだけで充分なのである。さてこの術語が、例えばC3プロジェクトで、﹁賃金台帳︵payroll︶﹂を﹁工場の組立ライン︵factory assembly line︶﹂と表現しているように、﹁比喩的﹂なものであってはいけない、という理由は思いつかない。しかし同時に、ドメインでの術語を基礎として名前の体系の構成をおこなってはいけない、という理由もまた思いつかない。名前の体系を作り出す上で私には有効だった技法を、捨て去ろうという気にもまだなっていない。 XPを批判するときに、少なくともシステムのおおまかな設計 (outline design)は必要なのでは、ということがよく言われる。よくあるXP実践者の反論は、﹁それがメタファーなんだ﹂というものである。しかし私は、﹁メタファー﹂の説明としてしっくりくるものを未だ聞いたことがない、と思う。これはXPの欠陥(gap)であり、XP実践者は、これを解決する必要がある。

おおきくなったら﹁アーキテクト﹂になりたいかい？

この十年かそこらで、﹁ソフトウェア・アーキテクト︵建築家︶﹂という言い方が広まった。しかし私自身はこの単語を使うのを躊躇している。というのも、私のワイフは設計技師︵structural engineer︶であって、そして技師と建築家の関係は、非常に興味深いものであるから…… ﹁アーキテクトは三つのＢにしか向いていない‥バルブと(bulbs)、芝生(bushes)と、鳥たち (birds)だ。﹂︵訳注‥建物の完成予想図に描き込まれた飾りのことを指している︶建築家たちは小綺麗な画を描くのが得意だろうが、実際にそれが建つところまで頑張るのは、エンジニアの仕事だ。だから私は、ソフトウェア・アーキテクトという呼称を避けてきた。だいたい、自分のワイフからも職業上の尊敬を勝ち取ることができない名前なんて、他の皆さんからどう見られるか、わかったものではない。ソフトウェアの世界では、﹁アーキテクト﹂という用語にはたくさんの意味が含まれている︵この業界では、どんな単語にもたくさんの意味が含まれているのだが︶。しかし、ざっくりいって、この単語からはある種のもったいぶりが感じられる -- ﹁私は単なるプログラマじゃない、アーキテクトなんだ﹂。これを言い替えれば、﹁私はアーキテクトなんだから、プログラミングなどやっている余裕はないんだ﹂となるだろう。ここで疑問が生まれる。あなたが技術上のリーダーシップを発揮しようという時に、ありふれたプログラミング作業から自分を遠ざけることは、本当にすべきことだと言えるのだろうか？この問いかけが、多大な感情的反応を引き起こす。私は、人々が﹁アーキテクト﹂としての役割を取り上げられると知って、怒り狂うのを見てきた。よく聞かされたのは、﹁経験豊かなアーキテクトが、XPでは居場所を取り上げられてしまう﹂という叫びだ。設計そのものは重要な役割を果たすのだから、XPが経験や設計スキルを評価しない、というのは事実ではない。実際、XP主導者たち -- ケント・ベック、ボブ・マーティン、そしてもちろんワード・カニンハム -- の多くから私は、設計とは何かについてたくさんのことを学ばせてもらった。しかし、だからといって彼らの果たす役割が、普通﹁技術的リーダーシップ﹂と呼ばれる役割と違うということにはならない。例として、ThoughtWorks社で働く技術的リーダー、デーブ・ライス︵Dave Rice︶氏を取り上げてみよう。彼は、50人からなるプロジェクト内で、何遍かのサイクルを経験した上で、非公式ながら技術的リーダーの役を引き受けている。彼のリーダーとしての役割とは、プログラマと共に時間を過ごすことである。助力が必要となれば協力する。助力を必要とする人がいないか、見て廻る。デーブが自分の席をおいている場所はとても示唆的だ。ThoughtWorks 社にもう長く勤めているのだから、デーブは望めばどんなオフィス部屋だって用意してもらえたはずだ。一時期は、リリースマネージャーのキャラ︵Cara︶と部屋を共有していた。しかし彼はそこを出て、この数ヶ月はプログラマ達が作業をする大部屋にいる。XPが勧める、仕切のない﹁作戦司令室︵war room︶﹂スタイルの部屋だ。わざわざそうした理由は、そこにいれば、何が起きているかわかるし、必要ならすぐ助けにまわることができるからだ。 XPを知っている人なら、私が今取り上げたものがXPにおける﹁コーチ﹂の役割の具体例であることに気付いただろう。XPはコトバにこだわってみせるところがあるが、その一つは、先導的な技術者のことを﹁コーチ﹂と呼ぶことにある。意味するところは明白だ‥XPでの技術的リーダーシップは、プログラマを教育したり、プログラマの判断を助けたりすることによってなされるのだ。それには、技術的スキルだけではなく対人スキルも必要になる。XP2000 の席上でジャック・ボレス︵Jack Bolles︶氏は、もう﹁孤高の達人﹂の出番は減っているのだ、とコメントした。協力と教育こそ、成功へのカギである。会議後の夕食会でデーブと私は、XPを公然と批判している人と話す機会を得た。しかし、今までに自分たちがやってきたことを話しているうちに、お互いに、非常に似通ったアプローチを取っていることに気付かされた。どちらも、適応的で段階的な開発がよいと思っている。テスト作業だって重要だ。じゃあ何でこの人は、激昂するほどXPに反対しているのだろうか？私たちはわからなくなってしまった。と、XP批判者である彼が漏らした一言、それは﹁うちのプログラマ連中が、設計をあちゃこちゃいじったり、リファクタしたりするなんて、耐えられないね﹂といった内容だった。これで全てがクリアになった。﹁自分のプログラマが信用ならないっていうなら、そもそもなんで雇ったんだろう？﹂彼我にある考え方の違いは、後でデーブが私に語ったこの台詞で、さらに明確になるだろう。XPにおいて、経験豊富な開発者がなし得るもっとも大事なことはなにか。それは、若い開発者にできるだけ多くのスキルを伝えてやることだ。全ての重要な決断を自分で下す﹁アーキテクト﹂の替わりに、開発者を教育して重要な決断を下せるように導く﹁コーチ﹂が欲しいのだ。ワード・カニンハムが指摘した通り、これはコーチの持つスキルを増幅することと同じだ。プロジェクトに対する貢献は、どんな孤高のヒーローが独りでなし得る貢献よりも大きくなるだろう。

後からリファクタリングで追加することが難しいものについて

リファクタリングで、設計上の全ての決定を扱えるのだろうか、それともあまりに広範囲に影響がありすぎて、後から追加することが困難なものもあるのだろうか？今のところ、正統派XPの見解は﹁どんなものでも必要になってから付け加えるのは簡単だから、常に YAGNI 原則が成立する﹂となっている。しかし、例外はないのだろうか。後から追加すべきではないかもしれない例として、国際化対応の問題があげられる。これはやはり、後から入れるのは大変だという理由で最初から考えておくべきものなのだろうか？こういったカテゴリーに入る例をあげろと言われたら、いくつも思いつくだろう。だが、まだまだデータが全然集まっていないのが実状だ。例えば国際化対応のような追加の作業が、後になってから出てきたら、それにどれだけの工数がかかったのか気に留めるのは当然だろう。しかし、実際に必要とされる時より何週間も前から追加された機能について、その追加と維持とにかかった工数が実際どれくらいなのか、あまり気に留めてはいないはずだ。さらに、間違って実装してしまい、結局リファクタリングをやるはめになることもある、という事実にもあまり気付いていないはずだ。将来必要とされるかもしれないと思っていたものが、結局使われずじまいだったり、最初に予期したのとは違う形になったりすることが多い、ということがYAGNIを支える議論の一部である。先の作業をしないことで削減できた工数は、必要になったときにリファクタリングで追加する際の工数より小さいはず、ということになる。もう一つ気に留めるべきことは、あなたは本当にそのやり方をわかっているのかどうか、である。国際化対応をすでに数回行っているというなら、採用すべきパターンもわかっているだろう。だから、正しいやり方を行えるはずだ。そういう場合なら、まったく初めてという場合に比べて、予期に基づいた構造を組み入れてもおそらく大丈夫だろう。というわけで私のアドバイスはこうなる。あなたがやり方を知っているという場合には、今やるべきか後でやるべきか、そのコストを比較判断できる立場にいる。しかし一度もやったことのない問題については、コストを十分に正しく評価できないどころではなく、正しく対処できるかどうかもおぼつかない。そんな場合は、追加は後回しにしたほうがいい。そうなってから追加して、大変な思いをしたとしても、最初から追加した時の痛みに比べればまだましだったはずだ。チームの経験が蓄えられて、その問題領域における知見も増えて、要求に対する理解も深まっているからだ。この立場にたどり着いてよくあるのは、なんだ、やっていれば簡単だったろうに、と自分の後ろを2．0の視力でもって振り返ることである。最初からやっていれば、あなたが考えるより、ずっと困難だったかもしれないのに。この話は、ストーリーの順番付けの話題につながる。Planning XPにおいて私とケント・ベックは、意見の相違があることをはっきりと示している。ケントは、ストーリーの順位選択に関係するファクターは、ビジネス上の価値だけを唯一選ぶべきだ、という意見に賛成している。最初は別意見だったが、後にロン・ジェフリスがこれに賛成した。私はまだ迷っていが、ビジネス上の価値と技術的なリスクのバランスであるはずだ、と信じている。だからきっと私は、多少の国際化対応の作業を先にやることで、このリスクを低減しようとするだろう。しかしそれは、最初のリリースで国際化が必要だった場合だけだ。リリースになるたけ早くこぎ着けることはとても重要だ。複雑なものは、もしそれが最初のリリースに必要ないとしたら、最初のリリースをした後にだけやる価値がうまれる。出荷され、稼働に入ったコードの影響力はすごいものがある。顧客の興味範囲は絞られ、信頼性は増し、そして何より学べることがたくさん出てくる。どんなことをしてでも、この日が来るのをなるたけ早めるのだ。最初のリリース後だと、何かを付け加える工数が増えてしまうのだとしても、それでもリリースを早める方がより望ましいのだ。

設計は死んだのか？

全然そんなことはない。だが、設計の本質は変わったのだ。XPの設計が要求するのは、以下の技能である‥ ●コードをなるたけ明快で単純なものにしようとする不断の意志 ●必要とあればいつでも、自信をもって改善が行えるようにするための、リファクタリングの技術 ● パターンに対する広い知見‥単に解決案だけではなくて、用いるべき状況や、どうパターンに持ち込んでいくかを理解していること。 ●その設計を理解する必要がある人に対して、コードを使ったり、ダイアグラムを使ったり、そして何より﹁会話﹂をすることで、相手に理解させるやり方をわきまえていること。このリストを見ると怖じ気づいてしまうかもしれない。しかし、良い設計者であることは、いつも大変なことなんだ。XPがこれを易しいものにしてくれるわけでは全然無い -- 少なくとも私にはそうだ。しかしXPは、有効な設計について考えるための、新しい方法を提供してくれたと思う。それはXPが、進化的設計を、戦略上の選択肢︵a plausible strategy︶としてまた付け加えたからだ。さらにいえば、私は﹁進化﹂の大ファンである --- だって、もし﹁進化﹂が起こり得ないんだとしたら、わたしは、これから、いったい……

謝辞

この数年にわたって私は数多くのすばらしい人から、すばらしいアイデアを見つけては頂戴してきた。そのほとんどが私の記憶の闇に消え去ってしまった。しかしジョシュア・ケリーブスキからよいアイデアを搾り取ったことは覚えている。フレッド・ジョージとロン・ジェフリスから頂いた多くの有用な助言も記憶にある。ワードとケントの両氏から、どれほどの数のすばらしいアイデアが流れ込んできたかも、忘れることができない。質問やタイポの指摘はいつでも大歓迎だ。というわけで、私が不定冠詞をつけ忘れたところを指摘してくれたクレイグ・ジョーンズ氏に感謝。

改訂履歴

この論文の改訂で大きなものを、以下の表にまとめた。 ●February 2001: アーキテクチャを育てる、アーキテクトの役割、そしてリファクタで追加するのが困難なものに関する節を追加した。 ●July 2000: 元論文が XP 2000に提出され、また martinfowler.com に掲載された。

翻訳: 小野剛 (ONO Jun/18/2001) 第二版
訳語に関して、XP-jp メーリングリストのメンバー諸氏から助言を頂いた。ここに謝意を記す。

Sections

Personal tools

Navigation