変幻する実行可能知識 19パターン III - なめらかなアーキテクチャ今回はシリーズ最終巻「まちづくりの新しい理論」に目を通してみよう. 我々の (アレグザンダーの, ではなく) キーワードは「なめらか」だ. 「まちづくりの新しい理論」は, 「成長する全体」をいかにして作り出すかという理論とその実験の書である. 「成長する全体」を作り出すための「最優先のルール」と「七つの中間的ルール」を定め, それをサンフランシスコの5年間, 約90のプロジェクトからなるウォータフロント開発計画でシミュレートした過程が述べられている. 我々は, この最優先のルールと, 七つの中間的ルールを我々ソフトウェアの言葉に翻訳しながら, 具体的なソフトウェア開発プロジェクトに対してシミュレートしてみよう. まず, 「成長する全体」とは何か. もちろんアレグザンダーはあるべき「まち」を念頭に置いている (それに対して近代的な都市計画にはこれらの性質が欠けていると言う).
我々にとってどうだろうか. 例えば古典的な (といっても今でもごく当たり前の) 基幹システムを考えてみると,
古典的な基幹システムはアレグザンダーが言う近代的な都市計画に他ならない. これでいいのか. 良しとするならば, その先の話は必要ない. しかし, これからのITをベースとした柔軟で迅速なビジネスのための基幹システムを考えたとき,
のではないか. としたら, 先に進んでみよう. アレグザンダーは「成長する全体」を実現するための最優先のルールは「さまざまな場所で次々と行われる建設は, 都市を癒す (= 全体を取り戻す) ような方法でなされるべきである」と言う. 我々の言葉で言い換えてみよう. 「さまざまな場所で次々と行われるシステム構築は, ビジネス環境を癒す, つまりビジネス環境の全体性を取り戻すような方法でなされるべきである」. ここでビジネス環境とは, 企業組織, 組織の構成員, 取引先や顧客, ユーザなどの関係する組織/個人からなる世界のことを考えている. ああ, 我々にそんな重大な使命があったとは! さて, このいささか抽象的な「最優先のルール」を具体化するために, アレグザンダーはとりあえず (というのはそれは状況によって変わるだろうから) 七つの中間的ルール
を置く. 我々の関心対象に即して, 4を「ポジティブな情報空間」, 5を「大きなシステムの内部プラン」, 6を「構築」と言い換える. 順に見ていくことにしよう. 1. 漸進的成長漸進的成長とは, まさにインクリメンタル開発ということ. 皆さん, よくご存知ですね. 基幹システムといえども, まずは小さいドメイン (例えば商品管理部) を対象にし, ユーザが直接操作できる機能ごとに開発して, リリースしていく. 多分, 旧システムとの接続性を確保し続けなければならないのが, いちばんのネックになるだろう. 2. 大きな全体の成長しかし, 漸進的成長だけでは大きな全体を作り出すことはできない. 今までのやり方ならばそのために計画 (設計) を立てるのだけれど, 我々はそうしない. なぜならば人為的な計画 (設計) から生まれるものは成長しないし, 全体的な深層品質にも欠けるから. ではどうするか. インクリメンタルにモノを作りながら, もう一つ上のレベルはどうあるべきか, 常にユーザを含めて議論と評価を繰り返す. 全体についての目標は紙には書かれないが, 関係者全員の頭の中にある. ひとつのインクリメントで作り出されたユーザ機能は, 隣り合うユーザ機能や上位レベルのあり方を喚起する力がなければならない. そのうちに「中心」 (大きな構造) が自然に現れてくる. これがある種の「アーキテクチャ」, エクストリーム・プログラミングで言う「メタファ」ですな. 例えばインクリメントが進んでユーザ機能が増えてくると, それをうまくつながなければならない, という「きっかけ (てがかり)」が生じる. つなぎ方がだんだんできてきたら, それをプロトコルなどの形で「位置付ける」. プロトコルはユーザ機能が増え, つなぎ方が多様になるにつれて, 「徐々に成長し」, 柔軟な構造ができてくるだろう. あるいはユーザの間で仕事やちょっとしたメッセージを回す必要が出てくる. 今までの基幹システムではあまりこういうことは考えなかったかもしれないけれど, これもひとつの中心になる. 我々が最近アスペクトと呼ぶモノと関連しているかもしれない. 中心はひとつとは限らないし, 複数の中心からなる中心もあるかもしれない. 3. ビジョンこれはすべてのプロジェクト (我々で言えば各ユーザ機能に相当するだろうか) の出発点で, 何をするために何を作るのかを, 理想的な姿としてありありと目に浮かぶようにすることから始めなさい, というルールだ. ビジョンは「価値」と言ってもいいかもしれない. ビジョンがあり, それをみんなで共有できて初めて, 要求なり仕様として書き下ろしなさい, と. 難しいと言えば難しい. ユーザ・インタフェースに関する部分は例えばペーパー・プロトタイピングなどでまかなえるかもしれない. しかしもっと深い部分に対するビジョンも必要になる. 我々は心の奥底から何がしたいのか, 何が人生にとってプラスになるのか. 今までは基幹システムに「価値」なんて厄介なモノは求められなかったろうに... 4. ポジティブな情報空間これはビジョンを具体化するに当たって, 外部空間 (建物やシステムの外) がネガティブになってはいけない, というルールだ. もう少し言ってしまえば, どんなに立派なシステムができあがっても, システム化の対象にならなかった部分にいろいろなしわ寄せがいってはいけない, ということになる. 例えばシステムに入力するために前もって自分でノートで整理して計算する必要があるとか, 出力をエクセルで整形し直さないと人に見せることができないとか, システム化したために今まで手軽に手でやっていたことがすごく煩雑になってしまうとか... (あるある) そのためには, システム化対象以外も含めた, 全関係者によるシナリオ書き, シミュレーション, ロール・プレイングなどが必要になるだろう. 超手軽なアプリケーション構築ツール (例えばRuby on Railsのような) も力になるかもしれない. 5. 大きなシステムの内部プランそれぞれのユーザ機能やコンポーネントなど各部分もそれぞれ全体性を持つべし, という再帰性ルール. アレグザンダーは建物が持つべき全体性のルール (例えば「オフィスの玄関は会談から直接見えるようにすること」など) を多く挙げているが, そのままでは我々の役には立たない. 我々のコンポーネントが持つべき全体性のルールにはどんなものがあるだろう? 例えば
など, いろいろなルールを考えることができるはず. emacsや初期Unix, Lispなどさまざまな例題はありそうだが, まだこの「ソフトウェアの美しさ」をまとめた論考はあまりないように思える. 重要な仕事かもしれない. 6. 構築これはもっと詳細なレベル (我々で言えばコードのレベルだろうか) での全体のルールであり, 5と同じようなものだ. 7. 中心の形成アレグザンダーはここで, (建築にとっての)「中心とは何か」を具体的に定義している. 我々にとっての中心とは何だろうか. ひとつは5で挙げたような全体性のルールも中心を形成する. もう一つは2で挙げたようなある種のアスペクト (今はアスペクトというと, ログ取りのような些末なものとしか考えられていないが) も中心を形成するだろう. アレグザンダーはその詳細をパターン・ランゲージに続くシリーズ Nature of Order (「秩序の本質」) に譲っているが, 我々もここでこれ以上議論する余裕はなさそうだ. さて, アレグザンダーの「成長する全体」を具体化するためのルールを我々の立場から見てきた. キーワードは「なめらかなアーキテクチャ」じゃないかと思う. 小さいものを少しずつ, なおかつ常に全体性を希求しながら作り込んでいく (ニュートン的ですか?). このような考え方は部分的にエクストリーム・プログラミングなどのアジャイル・プロセスにも取り込まれている. しかしやはりいちばん難しいのは, 「全体性」とは何か, どうすればそれを得られるのか, という点に尽きるだろう. |