「パタン・ランゲージによる住宅の生産」の序文に「1. 建築と施工は分離されていてはならない。（アーキテクトビルダー）」とある。何処かで聞いたようなことがあると思う。アジャイルソフトウェア開発宣言 に「プロセスやツールよりも個人と対話を…」とあるのと非常に似ている。
引用として、生産プロセスの基本条件を抜き出すと、
- 建築家と施工は分離されてはならない。（アーキテクトビルダー）
- 生産システムは、地域の高度に分散化された職人群（拠点）を利用する。（ビルダーズヤード）
- 共有地はユーザーによって最も大切な場所であり、彼らの管理下にあるべきである。（共有地の共同設計）
- ユーザーは、自分自身の住まいの間取りについて、現代建築のような受け身の姿勢ではなく、核家族によってそれぞれ異なる間取りができるような積極的な姿勢で参加しなければならない。（個々の住宅のレイアウト）
- 施工のシステムや技術やディテールは、プロセスそのものが必要とする、連続的な巧妙かつ微妙な修正の利くものを選ばなくてはならない。（一歩一歩の建設）
- コストコントロールは、柔軟な設計思考のプロセスに適応しなければならない。（コストコントロール）
- 建物の細工は、手づくりの楽しいものではなくてはならない。（プロセスの人間的リズム）
とある。
GoF のパタンは、「パタンランゲージ」の真髄を取りこぼしてしまったのか？
その昔、アジャイル協議会があったころ（確か、2002年頃だったと思う）、MVC, GoF のパターンの説明会の中で、東野高校 の見学発表というのがあった。アレグザンダー建築に則った設計をしているので、アジャイル＆パタンランゲージを学習する一環として発表していた方がいたのだが、果たして「パタンランゲージ」からヒントを得て「GoF パターン」を UML に加味して利用するというスタイルだったはずなのだが…真髄を取りこぼしてしまったのかどうかは定かではない。ちなみに、GoF の原著を読み直してみると、「6.3 The Pattern Community」あたりにアレグザンダーのあれとはあれこれが違うのだ、と書いてあるのでひょっとすると取りこぼしてしまっているのかもしれない。
ただし、建築のパタンランゲージから、プログラミングのパターンに移るときに重要だったのは、
- パターンに名前を付けること。
- 名前を共有することで、複雑な UML を共有できること。
がある。そこで「パタンランゲージ」の「ランゲージ（言語）」たる部分として、各種のパターンを組み合わせるベストプラクティスを作ることが可能、というのがある。GoF パターン以下、○○パターンというのを共有することができるようにはなったが、パターンの組み合わせで「相互の語る」ことができるようになったかというと疑問である。実は、Java カラー本や、ファウラーの「アナリシスパターン」のように、ある程度もまでは基礎パターンの組み合わせで構築物たるシステムを語ることができようになったとは思えるものの、まあ、浸透はしていない。まだ、データベースやネットワークやCPUやメモリなどの各部品は交差せずにそのままのような気がする。
ただし、建築業界がアレグザンダーの提唱する「パタンランゲージ」に則っているかというとそうでもなく、新国立競技場のごたごたしかり、別なところで変なことになってるし、脱構築ナントか的におかしなことになっている。少なくとも、建築と土建が別々になってしまい「アーキテクトビルダー」は不在である。
かつて「アーキテクト」ブームというものがあった
今思えば「フルスタックエンジニア（苦笑）」と同じぐらい「アーキテクト（苦笑）」という職種ブームがあった。SIer と下請けプログラミング会社のはざまだったか、全体設計をする人という意味で「建築家」に近い位置を想定したものだろうが、責任を負わないので建築家とも異なるし、国家試験があるわけでもない「自称アーキテクト」でしかない。様々なパターンを知っているという点では、一種の物知りではあったかもしれないが、そこには責任がない以上、職種とは呼べない。資格さえもない。最も本物の「建築家」のほうもずいぶん怪しい感じなので、それを真似した「アーキテクト」もかなり怪しい。今となっては、アーキテクチャという分野は存在するが、アーキテクトという人は存在しないような気がする。
というのも、先の「アーキテクトビルダー」に話を戻すと、「建築家と施工は分離されない」ので、いわば「設計」と「コーディング」は分離されない。「アーキテクト」を名乗る（あるいはアーキテクチャを構築する）のであれば、要件定義から全体への設計、そしてコーディングまで一貫するのが必須だろうし、そういう仕事の仕方をせざるを得ない。昨今のゼネコンのように、建築会社と施工会社（SIerと各種孫請け）を分けてしまっては、アーキテクトビルダーは成り立たない。成り立つことすらできない。
ゆえに、かつて「アーキテクト」ブームがあったと断言する。
それはさておき、アジャイルを再考する
一言で「アジャイル」と言っても、かつての「アジャイルソフトウェア開発宣言」から遠く離れてしまったアジャイル開発もあるので、元に戻って考えてみる。住宅を生産する、ということは一過性のプロセス（二度と同じ形では進まない）という点で、ソフトウェア開発と似ている。これは、製造業が主に「プロダクト」として同じ製品を効率よく作成することを目的としているのに対して、「プロジェクト」として同じ過程にはならないことを意味している。例えば、同じ IT 業界の中であっても、サーバーのセッティングやルーターの設定のようなものは限りなく「プロダクト」に近い。部品を使い同じレベルのものを大量に作るからだ。逆に何らかの業務アプリケーションを作る場合には「プロジェクト」になる。それぞれの会社では業務プロセスが異なるので、それぞれにカスタマイズされた「プロジェクト」が必要になる。当然、混在するパターンも多く、Wordpress でホームページを作るパターンは「プロダクト」に近いし、SAP などの製品を取り込むパターンも「プロダクト」に近い。また、研究開発は「プロジェクト」と言えるかもしれないが、終わり≒納期が判然としない場合が多い（とはいえ、永遠にやっている研究者はいないが）ので「プロジェクト」でも違ったスタイルになる。
プロジェクトというものは PMBOK で定義されているように、
- とある予算（人員）のなかでやりくりをする。
- 同じ生産プロセスにはならない。
- 期限や納期が存在する。
ことがプロジェクトであり、これを統率するのが「プロジェクトマネージメント」になる。予算や人員は無限ではないし、納期が必ず存在する。そして経済的な側面から効率化を求められる。そういう点で「住宅を建てる」ことに似ている。特に、納期があることとコストマネージメントが必須になる（新国立にコストマネージメントが存在するかどうかは怪しい）。
ここで、セル生産のように分業式ではあるものの作り手の創造性が効率化に寄与する。かつ、住宅においては住む人自身が利用者であり、利用する期間が非常に長いゆえに下手を打つと快適さは長期に損なわれる。ソフトウェア開発の場合には、利用する期間が短期と長期にわかれる。ゲームや一過性のインターネットサービスのようなものは、リリースまでの短期性が重視されることがおおく（最近では、短期すぎるゆえに失敗するパターンも多いのだが）おもに利用期間は「短期」になる。ゆえに、それゆえにとある失敗を長く引きずらずに済むという利点もある（ただし、その失敗は短期的な収入に大きな影響を与えるかもしれない）。もう一つ、業務システムのように会社が続く限り長く使われる長期的なシステムもある。銀行のシステムや工場のFAもそうなのだが、十数年単位で成果物が使われる。
ソフトウェアは、バージョンアップすることによって後からの機能が追加することができるが、住宅においても有機的に住居を追加することも可能である。それは住宅地の進化なのかもしれない。最初に区画整理された計画に沿うだけではなく、ある程度の計画から想定しえない方向に進んでいくこともしばしばである。それは経済的な側面が多いだろうし、今からだと少子化とか過疎地化とかがある。それらを踏まえたうえで、完全な計画をせずに、順応させる。
住宅において、住んでいる家族の構成は年月とともに変わる。子が育ち家を出るかもしれないし、子が増えるかもしれない。それらは、硬直化された建築システムに縛られるのではなく、緩やかに変化できる「可能性」を残しておく必要がある。同じように、長期に利用する業務システムの場合にも、ある程度の変化を許容する「可能性」を残さねばならない。これらは、ソフトウェア開発から最初の納品（リリース）までではなく、その先にもある。昨今「継続的な」というスタイルで言及されることが多いが、これらの「リリース前」と「リリース後」は同列に扱う必要がある。逆に言えば、リリース後だけを重視してもダメだし、リリース前だけを重視してもダメだ。
そこには、建築家＆施工と住宅（とそれに住んでいる人）と関係が続くことが分かっている。渋谷の拙い地下道のように造りっぱなしなのではなく、乗客は日々渋谷の地下と地上を行き来する。その往来の増減によっても、ある程度の「変化の許容」が必要になる。それは決して未来を見通すことはできないからだ。未来を見通すことはできないからこそ、ある程度の変化が許容できる状態を維持し、維持するために利用者と開発者との長期的な連携を維持する。ひょっとすると、本格的に維持するためには人の寿命は短いかもしれないが、創業100年と続く菓子屋のように、とある意思を次いでいくことは可能かもしれない。
そんな意思を継いでいくところで、「パタンランゲージ」があり「GoF パターン」があり「アジャイル開発技法」があるのではないかな、と思ったりするのだ、どうだろう。ちょっと、その道筋で肯定的に GoF のパターンをいくつか考え直してみたい。
[amazonjs asin=”4306052613″ locale=”JP” title=”パタン・ランゲージによる住宅の生産 (SD選書)”]
