2008/10/25アーキテクチャとは何だろうか?この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。ぼくの知識の中で、もっともらしいと思われているのが幾つかある。IEEE1471のアーキテクチャに関するコンセプチャルなフレームワークこれは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か?」に答えているようだ。システムには1つのアーキテクチャがあり、1つ以上のアーキテクチャ記述によって記述されており、1つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは1つ以上の関心事をもっており、1つの視点は1つ以上の関心事をカバーしている。」と読む(読めるか?)。RUPRUPは、それ自身、「アーキテクチャ中心」という冠詞が付いており、アーキテクチャは主に非機能要件から決定されるとしている。早期に決定することがプロジェクトのリスクを下げる上で重要とされている。Programming)では、「ぼくは"A"からはじまる言葉をここではわざと使っていない。」として、アーキテクチャを避けている。後に、「小さくはじめて育てる」とか、「アプリケーションの薄い縦スライスを作ってそれを太らせていく方法で、アーキテクチャは創発する」としている。これは、リファクタリング技術を最大限に活かした手法であるが、アーキテクチャが不連続に変わってしまう「アーキテクチャジャンプ」のリスクがある。本では、「アーキテクチャには技術できまる”ターキテクチャ”と、マーケティング要素から決まる”マーケテクチャ”の両面性がある」としている。Architecture)よく知られたアーキテクチャをパターンとしてカタログ化するアプローチ。パターンムーブメントの中で、「デザインパターン」の自然な延長に出てきた。ぼくが最も興味があるのが、アーキテクチャの創発を「自然に起こる」のを待つアジャイルのアプローチと、最も変更しにくい部分と考えてなるべく早期に決定しようとするRUPアプローチのバランスである。アジャイルでもリスクの高いストーリーを先に回すことで、アーキテクチャ創発を促すことができる。Implements)」というパターンを組織プロセスパターンの中に含めているのもJim本人だ。アーキテクチャは、創発するのか、あるいは、(経験から)選択するものなのか。直感的には、短期的な機能を実装することに焦点を当てると、健全なアーキテクチャは決まりにくいのではないか。Upfront)の弊害も多すぎる。先日マイクロソフトの萩原さんと話をしていたときにも、この話題になった。こんなスライドを発見してぶっとんだ。すべてのアーキテクチャはデザインである。すべてのデザインがアーキテクチャであるわけではない。システムのアーキテクチャは、有意なデザイン上の意思決定で定義される。(ここで、有意かどうかは変更コストによって計測される)ほとんどのアーキテクチャは、偶然的である。ときに意図的なものもある。すべてのソフトウェアが主要な役割をしめるシステムには、アーキテクチャが存在し、それは、日々起こる何万もの意思決定の積み重ねである。コードはいつでも正しい。それは正しいことの全体ではない。個々人を含むチーム記憶の歴史的な全体)に存在する。