Booch氏の”On Design”再考

アーキテクチャについて色々調べていると、必ずで言っていいほど、Grady Booch氏の「All architecture is design but not all design is architecture.」という一文に遭遇することになると思います*1。ただ、この一文が有名であるにもかかわらず、前後の文脈について言及しているものが少なかったりするので、Booch氏のオリジナルの記事である”On Design”に直接当たり、その意味を再考してみます。(オリジナルは6段落ほどの、短いエントリーです)

デザインとは?

Booch氏は初めに、この記事を書いた動機について触れています。Dick Gabriel氏の 「デザインとは何だろう?」というポストに対する回答として、この記事を書いたようです。

The aforementioned Dick Gabriel posed a question to the Hillside Group: what is design? Here’s my reply to him:

Booch氏は、問いに答えるために、まずは名詞としての「デザイン」について定義します。

As a noun, design is the named (although sometimes unnamable) structure or behavior of an system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions).

ここでは、デザインを「名前が付けられた(しばしば無名でもあるが)構造または振る舞いであり、その存在がシステムにおける制約事項を解決もしくは解消に貢献するもの」であると定義しています。また、続けて「ゆえに、デザインは可能な決定空間の1点を表す」と述べています。これは何を意味しているのでしょうか。

システムを設計するに当たっては、色々な制約の上で決定を行うことが必要となります。例えば、以下のような要件があったとします。

[要件]システムの設定情報(ユーザIDやパスワードなど)を、システム管理者が変更できるようにする。

この要件を実現するための選択肢として、以下のような候補が考えられます。

・ システムの設定情報をXMLで定義する
・ システムの設定情報をyamlで定義する
・ システムの設定情報をDBに持たせる
・ システムの設定情報ソースにハードコードする(変更の度にコンパイル!)
・ etc...

このうちいずれを選ぶのかは、そのシステムの制約(コストや他の技術との整合性、要員のスキルなど)に依存します。そのような制約の上で選択した構造や振る舞いこそが「デザイン」であり、そのデザインは、複数の選択肢から特定の1つを選んだという意味で、決定空間の1点を表す、ということをBooch氏は述べています。

次は動詞としての「デザイン」です。

As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness).

動詞としてのデザインは、先ほど述べた名詞としての「デザイン」ような決定を行う活動のことです。通常、システムが取りうる決定空間は、非常に大きく複雑(つまり、難しい選択が多数存在する)です。そのような決定を行う上で、経験的な分析を用いて最適解に到達するための”サイエンス”的な手法と、そのような経験的なものを越えて、エレガントさや新規性といった機会を与えてくれる”アート”的な手法が存在するという点についても言及しています。

アーキテクチャとは?

そして、いよいよ目的の段落にたどり着きます。

A few related terms:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

ついにあの有名な一文が登場します。「全てのアーキテクチャはデザインだが、全てのデザインがアーキテクチャであるわけではない」です。また、続けて「アーキテクチャはシステムを形作る重要なデザインの決定を表し、重要性は変更に要するコストで測定される」と述べています。

アーキテクチャがそのシステムにおける決定空間の1点を表すという点では、アーキテクチャはデザインの一種です。ただ、アーキテクチャを特色付けるのは、それが「システムを形作る重要な決定を表す」ということです。ここで、重要さは変更にかかるコストとして計測されます。あえてベン図で書けば、以下のような感じでしょうか。

f:id:GOLEM-XIV:20120523191818p:image

つまり、この文脈においてBooch氏は、アーキテクチャはデザインの一種である、別の言い方をすればデザインに含まれると主張しています。また、アーキテクチャとそれ以外のデザインを分けるのは、”変更のコスト”であると述べています。

具体的に考えて見ます。例えば、あるシステムを構築するにあたり、以下のいずれを選択するか、これも1つの決定であり、デザインの一種です。

  • VBによる2層C/Sシステムとする
  • JavaによるWebシステムとする

しかしながら、この決定を後から変更するのは非常に困難です。もし変更するのであれば多大なコストが必要となるのは想像に難くありません。よって、ここで決定したものはアーキテクチャであると言えます。もちろん、具体的にどのくらいの変更コストからがアーキテクチャを表すのかは、実際には状況によりけりです。

「アーキテクチャ上の決定」の必要性

ということで、「デザイン」の定義から始まり、あの有名な一文”All architecture is design but…”を含む、Booch氏のエントリーを概観してみました。

Booch氏が述べているように、アーキテクチャは後から変更することが困難であるような決定を表します。よって、なぜそのような決定を行ったのか、他の代替案としてどのようなものが存在したのかということを文書化し、システム構築から保守までを通じて、メンテナンスすることは非常に重要です。このような文書を「アーキテクチャ上の決定(Architectural Decision)」と呼んだりします。これらの決定を文書化して顧客と合意することは、アーキテクトにとって重要なタスクの1つです。

おまけ:その他の定義について

ちなみに、アーキテクチャの定義には様々なものがあります。有名なのはIEEE 1471の定義でしょうか。

アーキテクチャとは、コンポーネント、コンポーネント間および環境との関係、またその設計と進化の指針となる原理に体現されたシステムの基本構造である。*2

アーキテクチャの定義を集めたページなんていうものもあるようです。お気に入りの定義を探しているのも面白いかもしれません。

定義なんて重要なの?という方もいるかもしれません。卑近な例ですが、もしあなたがアーキテクトである場合、お客さんと名刺交換した際に「あなたがアーキテクトであることはわかりました。で、結局のところ、SEやプログラマ、コンサルタントと何が違うんですか?」と問われた時のことを想像してみてください。少なくとも”自分にとっての”アーキテクチャの定義を言語化しておくことはとても大切だと思います。

*1:平鍋さんのエントリーでも、Booch氏の「All architecture is design but…」の一文に言及しています。非常に興味深いエントリーです。

*2http://www.atmarkit.co.jp/im/carc/serial/redge41/redge41b.html#2 より引用

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です