設計の終焉?

(原題: 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 のよ うにコード詳細からはなれた設計技法を使って、より抽象的なレベルの仕事を することが可能になる。 設計が済んだら、作成のために別のグループ（別の会社の場合もある）に渡し てしまえる。より大きなスケールでものを考えているので、設計者はソフトウェ アエントロピーを引き起こすような一連の戦術的決定を回避できる。プログラ マは設計の指示に従って、また設計に従う限りにおいて、きちんとしたシステ ムを作ることができる、というわけだ。

計画的設計によるアプローチは、すでに７０年代から存在していて、多くの人 が使ってきた。「書いて直せ」の進化的設計より計画的設計のほうが良い面も たくさんあるだろう。しかし欠点もある。最初の欠点は「プログラミングの局 面で対処しなくてはならない全ての問題を見通すことなど不可能だ」というこ とだ。であれば、設計から再考せざるをえないようなことにプログラミングの 段階で出喰わしてしまうことは、必ず起きる。しかし、もしその時に設計者の 仕事は終わっていて、彼らは既に他のプロジェクトに移っていたとしたらどう なるだろう？プログラマはごそごそとコードを書き加えるようになり、エント ロピーが頭をもたげてくる。仮に設計者がまだいた場合でも、設計上の課題を 整理して、図を書き直して、その上でコードを改変するのには時間がかかって しまう。普通は、より早くできるフィックスがあったり、時間的な制約も厳し かったりするものだ.. というわけで、エントロピーの（再）登場となる。

さらに、設計者のカルチャーの問題もよくみられる。彼らは、技能と経験が豊 富だから設計者に選ばれたのだろうが、自分自身は設計で忙しすぎて、コーディ ングをしている暇がない。しかし、ソフトウェア開発のツールやマテリアル類 はどんどん変わっている。コーディングをしない人は、技術の絶え間ない流れ に起きている変化を見逃すだけではなく、コーディングをする人に対する尊敬 の念も、あわせて失ってしまうことだろう。

建築の世界にも「施工者」と「設計者」との緊張関係は見られるが、ソフトウェ アの世界のほうがより強烈である。建築とソフトウェアには重要な違いがある からだ。建築業界では、設計する人の技能と施工する人の技能に関して、より はっきりとした区分がある。しかしソフトウェアではこれがはっきりしないの だ。 設計が中心となる環境で働こうとするプログラマは、高い技能、それも設計者 が出して来る設計を批判的に見ることが出来るくらいに高い技能が必要とされ るだろう。特に設計者が、日々変化する開発プラットフォームの現状にあまり 詳しくない場合はなおさらそうである。

これらの問題点はもちろん、その気になれば解決可能な問題である。おそらく、 人間関係の緊張を和らげるような手を打つことができるかもしれない。おそら く、多くの問題に対処できる有能な設計者を手配したり、設計図の「書き直し」 にも対応できるきちんとした開発プロセスを採用したりすることが可能だろう。 それでもまだ別の問題がある。それは「変化する要求」という問題だ。変化す る要求こそ、私が関わったソフトウェアプロジェクトで一番、頭の痛い問題で ある。

変化する要求に対処する一つの方法は、柔軟性(flexibility)を設計に盛り込 むことである。これにより、要求の変化に応じた変更が簡単にできるようにし ておくのだ。しかしこれを行うには「どのような種類の変化が起きるのか」と いう洞察が必要になる。変化しやすい領域に対処できるよう、設計の側で準備 しておくことはできるだろう。しかしこれだと、予見された変化に対する助け にはなるが、予見されなかった変化に対しては、助けにならない(どころか害 悪になりかねない)。 だから、要求を十分に咀嚼して、変化しやすい領域を切り分けなければならな い。私の見たところ、これは非常に難しい。

要求を十分に理解していないことが原因となって、これらの問題が起きること もある。だから多くの人は、設計を将来変更しないですむよう、よりよい要求 を得るための「要求定義工学プロセス」をうちたてようとすることになる。 しかしこの方向でも、解決をえることは出来ないだろう。予見されなかった要 求変更の多くは、ビジネス上での変化によって引きおこされた。ビジネス上で の変化は、どんなに要求定義プロセスを洗練させようとも防ぎようのないこと だ。

ここまでくると、計画的設計は不可能に思えて来る。実際、これは本当に大き な問題である。ただ私自身は、計画的設計が進化的設計よりもダメだと主張し ようとは思っていない。進化的設計の大多数が「書いて直せ」方式で行われて いるからである。実際、私は計画的設計のほうが「書いて直せ」より望ましい と思う。しかし計画的設計の問題点にも気づいているからこそ、新しい方向を 探ろうとしているのだ。

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

この議論を理解する上で基礎となるのが、「ソフトウェアの変更に関する曲線」 の存在である。この変更曲線が述べるところによると、プロジェクトが進行す るにつれて、変更を行うコストは指数的に増大する、のだそうだ。変更曲線は よく、「分析の段階では１ドルで済む変更が、製品の段階で直すとなると、何 千ドルにもなる」などと表現される。分析フェーズなど持たないその場しのぎ のプロセスしかなくても、多くのプロジェクトでうまくいっていることを考え るとこれは皮肉に聞こえるが、それでも、累乗効果の議論は生き残る。 この指数関数的な変更曲線が意味するところは「進化的設計がまともに機能す る余地などない」ということだ。さらにこれは「計画的設計は注意深く行わな くてはいけない」という意味にもなる。計画的設計におけるどんな間違いも、 同じように、指数関数的な増幅を受けるからだ。

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支持者として知られているが、であればこそ彼ら には賛成できない。開始時点での広範囲なアーキテクチャが果たす役割、とい うものもあると考えるからだ。例えば、アプリケーションの階層をどう切るか、 （必要なら）データベースとのやりとりをどう扱うか、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）氏を取り上げてみよう。彼は、５０人からなるプロジェクト内で、何遍 かのサイクルを経験した上で、非公式ながら技術的リーダーの役を引き受け ている。彼のリーダーとしての役割とは、プログラマと共に時間を過ごすこと である。助力が必要となれば協力する。助力を必要とする人がいないか、見て 廻る。デーブが自分の席をおいている場所はとても示唆的だ。ThoughtWorks 社にも う長く勤めているのだから、デーブは望めばどんなオフィス部屋だって用意し てもらえたはずだ。一時期は、リリースマネージャーのキャラ（Cara）と部屋 を共有していた。しかし彼はそこを出て、この数ヶ月はプログラマ達が作業を する大部屋にいる。XPが勧める、仕切のない「作戦司令室（war room）」スタ イルの部屋だ。わざわざそうした理由は、そこにいれば、何が起きているかわ かるし、必要ならすぐ助けにまわることができるからだ。

XPを知っている人なら、私が今取り上げたものがXPにおける「コーチ」の 役割の具体例であることに気付いただろう。XPはコトバにこだわってみせると ころがあるが、その一つは、先導的な技術者のことを「コーチ」と呼ぶことに ある。意味するところは明白だ：XPでの技術的リーダーシップは、プログラマ を教育したり、プログラマの判断を助けたりすることによってなされるのだ。 それには、技術的スキルだけではなく対人スキルも必要になる。XP2000 の席 上でジャック・ボレス（Jack Bolles）氏は、もう「孤高の達人」 の出番は減っ ているのだ、とコメントした。協力と教育こそ、成功へのカギである。

会議後の夕食会でデーブと私は、XPを公然と批判している人と話す機会を 得た。しかし、今までに自分たちがやってきたことを話しているうちに、お互 いに、非常に似通ったアプローチを取っていることに気付かされた。どちらも、 適応的で段階的な開発がよいと思っている。テスト作業だって重要だ。じゃあ 何でこの人は、激昂するほどXPに反対しているのだろうか？私たちはわからな くなってしまった。と、XP批判者である彼が漏らした一言、それは「うちのプ ログラマ連中が、設計をあちゃこちゃいじったり、リファクタしたりするなん て、耐えられないね」といった内容だった。これで全てがクリアになった。 「自分のプログラマが信用ならないっていうなら、そもそもなんで雇ったんだ ろう？」彼我にある考え方の違いは、後でデーブが私に語ったこの台詞で、さ らに明確になるだろう。XPにおいて、経験豊富な開発者がなし得るもっとも大 事なことはなにか。それは、若い開発者にできるだけ多くのスキルを伝えてや ることだ。全ての重要な決断を自分で下す「アーキテクト」の替わりに、開発 者を教育して重要な決断を下せるように導く「コーチ」が欲しいのだ。ワード・ カニンハムが指摘した通り、これはコーチの持つスキルを増幅することと同じ だ。プロジェクトに対する貢献は、どんな孤高のヒーローが独りでなし得る貢 献よりも大きくなるだろう。

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

リファクタリングで、設計上の全ての決定を扱えるのだろうか、それとも あまりに広範囲に影響がありすぎて、後から追加することが困難なものもある のだろうか？今のところ、正統派XPの見解は「どんなものでも必要になってか ら付け加えるのは簡単だから、常に YAGNI 原則が成立する」となっている。 しかし、例外はないのだろうか。後から追加すべきではないかもしれない例と して、国際化対応の問題があげられる。これはやはり、後から入れるのは大変 だという理由で最初から考えておくべきものなのだろうか？

こういったカテゴリーに入る例をあげろと言われたら、いくつも思いつく だろう。だが、まだまだデータが全然集まっていないのが実状だ。例えば国際 化対応のような追加の作業が、後になってから出てきたら、それにどれだけの 工数がかかったのか気に留めるのは当然だろう。しかし、実際に必要とされる 時より何週間も前から追加された機能について、その追加と維持とにかかった 工数が実際どれくらいなのか、あまり気に留めてはいないはずだ。さらに、間 違って実装してしまい、結局リファクタリングをやるはめになることもある、 という事実にもあまり気付いていないはずだ。

将来必要とされるかもしれないと思っていたものが、結局使われずじまい だったり、最初に予期したのとは違う形になったりすることが多い、というこ とがYAGNIを支える議論の一部である。先の作業をしないことで削減できた工 数は、必要になったときにリファクタリングで追加する際の工数より小さいは ず、ということになる。

もう一つ気に留めるべきことは、あなたは本当にそのやり方をわかってい るのかどうか、である。国際化対応をすでに数回行っているというなら、採用 すべきパターンもわかっているだろう。だから、正しいやり方を行えるはずだ。 そういう場合なら、まったく初めてという場合に比べて、予期に基づいた構造 を組み入れてもおそらく大丈夫だろう。というわけで私のアドバイスはこうな る。あなたがやり方を知っているという場合には、今やるべきか後でやるべき か、そのコストを比較判断できる立場にいる。しかし一度もやったことのない 問題については、コストを十分に正しく評価できないどころではなく、正しく 対処できるかどうかもおぼつかない。そんな場合は、追加は後回しにしたほう がいい。そうなってから追加して、大変な思いをしたとしても、最初から追加 した時の痛みに比べればまだましだったはずだ。チームの経験が蓄えられて、 その問題領域における知見も増えて、要求に対する理解も深まっているからだ。 この立場にたどり着いてよくあるのは、なんだ、やっていれば簡単だったろう に、と自分の後ろを２．０の視力でもって振り返ることである。最初からやっ ていれば、あなたが考えるより、ずっと困難だったかもしれないのに。

この話は、ストーリーの順番付けの話題につながる。Planning XPにおいて私とケント・ベックは、意見の相違があることをはっきりと示 している。ケントは、ストーリーの順位選択に関係するファクターは、ビジネ ス上の価値だけを唯一選ぶべきだ、という意見に賛成している。最初は別意見 だったが、後にロン・ジェフリスがこれに賛成した。私はまだ迷っていが、ビ ジネス上の価値と技術的なリスクのバランスであるはずだ、と信じている。だ からきっと私は、多少の国際化対応の作業を先にやることで、このリスクを低 減しようとするだろう。しかしそれは、最初のリリースで国際化が必要だった 場合だけだ。リリースになるたけ早くこぎ着けることはとても重要だ。複雑な ものは、もしそれが最初のリリースに必要ないとしたら、最初のリリースをし た後にだけやる価値がうまれる。出荷され、稼働に入ったコードの影響力はす ごいものがある。顧客の興味範囲は絞られ、信頼性は増し、そして何より学べ ることがたくさん出てくる。どんなことをしてでも、この日が来るのをなるた け早めるのだ。最初のリリース後だと、何かを付け加える工数が増えてしまう のだとしても、それでもリリースを早める方がより望ましいのだ。

設計は死んだのか？

全然そんなことはない。だが、設計の本質は変わったのだ。 XP の設計が要求するのは、以下の技能である：

• コードをなるたけ明快で単純なものにしようとする不断の意志
• 必要とあればいつでも、自信をもって改善が行えるようにするための、リファクタリングの技術
• パターンに対する広い知見：単に解決案だけではなくて、用いるべき状況や、 どうパターンに持ち込んでいくかを理解していること。
• その設計を理解する必要がある人に対して、コードを使ったり、ダイアグ ラムを使ったり、そして何より「会話」をすることで、相手に理解させるやり 方をわきまえていること。

このリストを見ると怖じ気づいてしまうかもしれない。しかし、良い設計 者であることは、いつも大変なことなんだ。XP がこれを易しいものにしてく れるわけでは全然無い -- 少なくとも私にはそうだ。しかし XP は、有効な設 計について考えるための、新しい方法を提供してくれたと思う。それは XP が、 進化的設計を、戦略上の選択肢（a plausible strategy）としてまた付け加え たからだ。さらにいえば、私は「進化」の大ファンである --- だって、もし 「進化」が起こり得ないんだとしたら、わたしは、これから、いったい……

謝辞

この数年にわたって私は数多くのすばらしい人から、すばらしいアイデアを見 つけては頂戴してきた。そのほとんどが私の記憶の闇に消え去ってしまった。 しかしジョシュア・ケリーブスキからよいアイデアを搾り取ったことは覚えている。 フレッド・ジョージとロン・ジェフリスから頂いた多くの有用な助言も記憶にある。 ワードとケントの両氏から、どれほどの数のすばらしいアイデアが流れ込んで きたかも、忘れることができない。

質問やタイポの指摘はいつでも大歓迎だ。というわけで、私が不定冠詞をつけ忘 れたところを指摘してくれたクレイグ・ジョーンズ氏に感謝。

改訂履歴

この論文の改訂で大きなものを、以下の表にまとめた。

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

© Copyright Martin Fowler, all rights reserved