建築家

http://martinfowler.com/bliki/BuildingArchitect.html

「ソフトウェアアーキテクト」という言葉を使うとき、 アーキテクトの役割を理解しやすいように、建築のメタファーを使う。 だが皮肉にもこのことが原因で、建物のアーキテクト（建築家）の本来の役割が正しく理解されずにいる。

ソフトウェアアーキテクトとは、チーフ設計者であり、 プロジェクトのメンバを率いる存在である。 しかしこれは、建築家がやっていることではない。 建築家は、クライアント（建物が欲しいひと）とのやり取りに専念しており、 クライアントにとって重要なことにしか関心がない。 たとえば、建物のレイアウトだとか外観だとか、そういったものだ。 けれども、建物に必要なものは他にもまだたくさんある。

建築家には、建物の構造が確かかどうかについての責任はない。 それは、私の妻Cindyのような、構造エンジニア（structual engineer）の役割だ。 建築家は構造エンジニアを呼んで、自分の思い描く建物を建てさせる（ この時点で既に、効果的な構造体に変更するのに手遅れとなっていることが多い ）。 建物には電気技師、機械技師も必要である（最初に建築家が行ったことが原因で、ここでも同じことが起きている）。

建築家はチーム内の専門家の内のひとりだというのに、 建築家だけがクライアントとのやり取りをすべて把握している。 たしかに建築家は、 建物が計画通りに建つために必要なすべての分野において輝かしい経験がある上に、 大学で概論も勉強しているのだろう。 だが、エンジニアたちから何も情報を得ずに、 すべての分野について話すことなど不可能である。

クライアントとのやり取りということであれば、 ソフトウェア開発でいちばん近いのは、ユーザーインターフェイス設計者である。 こういったメタファはあまり信用していないのだが、 この例からは、建築家をこういった仕事に就けることはやめた方がよいという、役に立つ結論が導ける。 最近の話だが、Cindyがホテルの構造エンジニアとして呼ばれたときのことだ。 彼女は、建築家のレイアウトには、ある骨組みが必要となることに気づいた。 まったく違ったレイアウトにすれば、別の骨組みができ、そうなれば、構造を作る部分において30%のコスト削減できる。 しかし建築家はこの変更を拒否した。 彼の設計はクライアントと契約済みなのだという。

この教訓から得られるのは、 建築家（やユーザーインターフェイス設計者）を顧客とのやり取りを行う業務に就けたなら、 建築家は他の専門家とよくよくコミュニケーションをとらねばならないということである。 もうひとつの問題は、素晴らしいユーザーインターフェイスを作るひとたちが、 他のユーザーインターフェイス構造にかかるコストにはまったく気を配らないという点である。 コストは技術的に深く関わるものであれば、これはまあ、正論である。 Dave Riceはこう指摘している。 アプリケーションにおける並行処理制御および排他制御の戦略は、ユーザーインターフェイスと切り離すことはできない、と。 ユーザーインターフェイスを作るひとたちの中で、この問題を理解しているひとはまだほとんどいない。 典型的な建築家とは違って、彼らはソフトウェアアーキテクトに対する効果的な協力を求められていないのだ。

建築家のメタファーについて最後に。 Michael Pollanが執筆中の「A Place of My Own」は、 建築家と大工との衝突を描いている。 Pollanは、建築家が最終的にこのバトルに勝ち、建物の設計を変更する様を描いている。 彼が指摘しているが、悲しいことに、そのスキルに対して低賃金しか与えていない。 ソフトウェアアーキテクト……あなたが欲しいものには気をつけたほうがいい！