滑らかなアーキテクチャ：ソフトウェア開発をちゃんと考える（7）

今回は（アレグザンダーのパターン）シリーズ最終巻「まちづくりの新しい理論」に目を通してみよう。われわれの（アレグザンダーの、ではなく）キーワードは「滑らか」、あるいは滑らかなアーキテクチャ」だ。

　「まちづくりの新しい理論」は、「成長する全体」をいかにして作り出すかという理論とその実験の書である。「成長する全体」を作り出すための「最優先のルール」と「7つの中間的ルール」を定め、それをサンフランシスコの5年間、約90のプロジェクトからなるウォータフロント開発計画でシミュレートした過程が述べられている。

　われわれは、この最優先のルールと、7つの中間的ルールをわれわれソフトウェアの言葉に翻訳しながら、具体的なソフトウェア開発プロジェクトに対してシミュレートする。

　まず、「成長する全体」とは何か。もちろんアレグザンダーはあるべき「まち」を念頭に置いている（それに対して近代的な都市計画にはこれらの性質が欠けているという）。

1. 全体は少しずつ成長する
2. 全体は予測できない
3. 全体はホロニックである <注1>
4. 全体は常に情感に満ちている

　われわれにとってどうだろうか。例えば古典的な（といってもいまでもごく当たり前の）基幹システムを考えてみると、

1. システムは基本的に納品時に完成している。実際にはその後も変化するが、それは「保守」であって本質ではない
2. システムは完全に予測（設計）できていなければならない。従って、往々にして最も重要なのはデータベースのスキーマが完成していることであり、なおかつ将来を見通したレイアウトでなければならない
3. システムは部分の総和（静的なコンポーネントの固定的な接続）である
4. システムに情感（！！）は必要ない

　古典的な基幹システムはアレグザンダーがいう近代的な都市計画にほかならない。これでいいのか。良しとするならば、その先の話は必要ない。しかし、これからのITをベースとした柔軟で迅速なビジネスのための基幹システムを考えたとき、

1. システム全体を最初から考え尽くすことはできないし、寿命が来たからといってすべて作り直すということはあり得ない。つまりシステムは少しずつ成長するしかない
2. いまのビジネスや社会の状況、技術の進展などを考えればシステム全体を予測することはできない
3. 単なる部分の総和でシステムを構成することはできない。それぞれが自律的で多様なコンポーネントの複雑で動的な関係を基に首尾一貫したシステムを作らなければならない
4. 利用者にとっての単なる機能以上の品質（深層品質ともいう）、作り込み、手触り感、感情を喚起する力こそが重要である

のではないか。としたら、先に進んでみよう。アレグザンダーは「成長する全体」を実現するための最優先のルールは「さまざまな場所で次々と行われる建設は、都市を癒やす（＝全体を取り戻す）ような方法でなされるべきである」という。われわれの言葉でいい換えてみよう。「さまざまな場所で次々と行われるシステム構築は、ビジネス環境を癒す、つまりビジネス環境の全体性を取り戻すような方法でなされるべきである」。ここでビジネス環境とは、企業組織、組織の構成員、取引先や顧客、ユーザーなどの関係する組織／個人からなる世界のことを考えている。ああ、われわれにそんな重大な使命があったとは！

　さて、このいささか抽象的な「最優先のルール」を具体化するために、アレグザンダーは取りあえず（というのはそれは状況によって変わるだろうから）7つの中間的ルール

1. 漸進的成長
2. 大きな全体の成長
3. ビジョン
4. ポジティブな都市空間
5. 大きな建物の内部プラン
6. 施工
7. 中心の形成

を置く。われわれの関心対象に即して、4を「ポジティブな情報空間」、5を「大きなシステムの内部プラン」、6を「構築」といい換える。順に見ていくことにしよう。

1. 漸進的成長

　漸進的成長とは、まさにインクリメンタル開発ということ。 皆さん、よくご存じですね。基幹システムといえども、まずは小さいドメイン（例えば商品管理部）を対象にし、ユーザーが直接操作できる機能ごとに開発して、リリースしていく。多分、旧システムとの接続性を確保し続けなければならないのが、一番のネックになるだろう。

2. 大きな全体の成長

　しかし、漸進的成長だけでは大きな全体を作り出すことはできない。いままでのやり方ならばそのために計画（設計）を立てるのだけれど、われわれはそうしない。なぜならば人為的な計画（設計）から生まれるものは成長しないし、全体的な深層品質にも欠けるから。

　ではどうするか。インクリメンタルにモノを作りながら、もう1つ上のレベルはどうあるべきか、常にユーザーを含めて議論と評価を繰り返す。全体についての目標は紙には書かれないが、関係者全員の頭の中にある。1つのインクリメントで作り出されたユーザー機能は、隣り合うユーザー機能や上位レベルの在り方を喚起する力がなければならない。そのうちに「中心」（大きな構造）が自然に現れてくる。これがある種の「アーキテクチャ」、エクストリーム・プログラミングでいう「メタファ」ですな。

　例えば、インクリメントが進んでユーザー機能が増えてくると、それをうまくつながなければならない、という「きっかけ（手掛かり）」が生じる。つなぎ方がだんだんできてきたら、それをプロトコルなどの形で「位置付ける」。プロトコルはユーザー機能が増え、つなぎ方が多様になるにつれて、「徐々に成長し」、柔軟な構造ができてくるだろう。

　あるいはユーザーの間で仕事やちょっとしたメッセージを回す必要が出てくる。いままでの基幹システムではあまりこういうことは考えなかったかもしれないけれど、これも1つの中心になる。われわれが最近アスペクトと呼ぶモノと関連しているかもしれない。中心は1つとは限らないし、複数の中心からなる中心もあるかもしれない。

3. ビジョン

　これはすべてのプロジェクト（われわれでいえば各ユーザー機能に相当するだろうか）の出発点で、何をするために何を作るのかを、理想的な姿としてありありと目に浮かぶようにすることから始めなさい、というルールだ。ビジョンは「価値」といってもいいかもしれない。ビジョンがあり、それをみんなで共有できて初めて、要求なり仕様として書き下ろしなさい、と。

　難しいといえば難しい。ユーザー・インターフェイスに関する部分は 例えばペーパー・プロトタイピングなどで賄えるかもしれない。しかしもっと深い部分に対するビジョンも必要になる。われわれは心の奥底から何がしたいのか、何が人生にとってプラスになるのか。いままでは基幹システムに「価値」なんて厄介なモノは求められなかったろうに……。

4. ポジティブな情報空間

　これはビジョンを具体化するに当たって、外部空間（建物やシステムの外）がネガティブになってはいけない、というルールだ。もう少しいってしまえば、どんなに立派なシステムが出来上がっても、システム化の対象にならなかった部分にいろいろなしわ寄せがいってはいけない、ということになる。例えば、システムに入力するために前もって自分でノートで整理して計算する必要があるとか、出力をエクセルで整形し直さないと人に見せることができないとか、システム化したためにいままで手軽に手でやっていたことがすごく煩雑になってしまうとか……（あるある）。

　そのためには、システム化対象以外も含めた、全関係者によるシナリオ書き、シミュレーション、ロール・プレイングなどが必要になるだろう。超手軽なアプリケーション構築ツール（例えばRuby on Railsのような）も力になるかもしれない。

5. 大きなシステムの内部プラン

　それぞれのユーザー機能やコンポーネントなど各部分もそれぞれ全体性を持つべし、という再帰性ルール。アレグザンダーは建物が持つべき全体性のルール（例えば「オフィスの玄関は階段から直接見えるようにすること」など）を多く挙げているが、そのままではわれわれの役には立たない。われわれのコンポーネントが持つべき全体性のルールにはどんなものがあるだろう？ 例えば

• 情報に対する操作は基本的に対称的であること（操作Aができるのならば、Aと相補的な操作も可能。例えば setter／getter、constructor／destructorなど）
• ある情報がなぜそこに存在しているかが説明できること（誰がいつ作成したか、など）
• ある情報に対して可能な操作は基本的に均一に見えること（ある操作はメニューにあり、ある操作はパネルを出さないと見えないなどではなく）

など、いろいろなルールを考えることができるはず。 Emacsや初期UNIX、Lispなどさまざまな例題はありそうだが、まだこの「ソフトウェアの美しさ」をまとめた論考はあまりないように思える。重要な仕事かもしれない。

6. 構築

　これはもっと詳細なレベル （われわれでいえばコードのレベルだろうか）での全体のルールであり、5と同じようなものだ。

7. 中心の形成

　アレグザンダーはここで、（建築にとっての）「中心とは何か」を具体的に定義している。われわれにとっての中心とは何だろうか。1つは5で挙げたような全体性のルールも中心を形成する。もう1つは2で挙げたようなある種のアスペクト（いまはアスペクトというと、ログ取りのようなさまつなものとしか考えられていないが）も中心を形成するだろう。アレグザンダーはその詳細をパターン・ランゲージに続くシリーズ「Nature of Order （『秩序の本質』）」に譲っているが、われわれもここでこれ以上議論する余裕はなさそうだ。

　さて、アレグザンダーの「成長する全体」を具体化するためのルールをわれわれの立場から見てきた。キーワードは「滑らかなアーキテクチャ」じゃないかと思う。小さいものを少しずつ、なおかつ常に全体性を希求しながら作り込んでいく（ニュートン的ですか？）。このような考え方は部分的にエクストリーム・プログラミングなどのアジャイル・プロセスにも取り込まれている。しかし、やはり一番難しいのは、「全体性」とは 何か、どうすればそれを得られるのか、という点に尽きるだろう。