先日のSpring勉強会の流れで「複雑系のアーキテクチャ」というのを考えています。複雑系[wikipedia]とは、簡単に言うと「複雑な現象でも、実は単純な法則の積み重ねから出来ている」という話です。
例えば川の流域面積（川幅と長さ）がべき乗則[wikipedia]になっているとか、同じルールが木の枝振り（太さと長さ）にも現れるだとか、そういう話です。
しかも、そういった現象が自然だけではなくて複雑な社会現象でも同じようなことが観測されています。有名なのは富の配分をしめしたパレートの法則（上位20%の人が富の80%を所有している）です。
僕が複雑系のアーキテクチャに興味を持つには理由があります。それは「要件全体を分析してアーキテクチャを導き出すというデザイン手法に限界がある」という問題意識です。
アーキテクティングというのは事前に実施すべきものです。後からアーキテクチャを変更するのはコストがかかります。ですから、事前にすべての要件を分析して出来る限り最適なアーキテクチャを構成したいところです。ところが、これには限界があります。
現在のシステム要件は非常に複雑です。しかも、ビジネス環境は速いスピードで変化してしまいます。そのため、どれだけ分析を続けていても要件全体を把握することはできないのです。特にエンジニアは全体を要素に分解して分析していけばいいという還元論[wikipedia]や構造主義[wikipedia]のような感覚にとらわれている場合が多い。でも、実体としては後から後から要件が生まれてくる。もちろんスコープを決めることは重要ですが、ある程度の変化は許容できなければユーザーに価値を提供できません。
要件を分析していてもアーキテクチャは決まらない。では、どうやってアーキテクチャを作ればいいのでしょうか？
ヒントになるのはアジャイルです。アジャイルではプラクティスという単純な法則に従うことで複雑なプロジェクトを成功させようとしています。この概念は複雑系とつながります。
（ちなみにアジャイルと複雑系の関係についていえば、ジム・ハイスミスが2000年に書いた「適応型ソフトウエア開発-変化とスピードに挑むプロジェクトマネージメント（邦訳）」をあげることが出来ます。彼はアジャイルの人として有名ですね）
つまり、複雑系のアーキテクチャというのは、なんらかの単純な法則に従ってモジュール分割をしていくことで複雑なシステムであってもマネジメントされた美しい構造になるということです。
注意すべきことは「単純な法則」というのが動的な生成プロセスの中に埋め込まれているということです。システムを分析して仮に「モジュールの複雑度とバグの発生件数がべき上則になる」ことが分かったとします。これはとても興味深く面白い話です。ですが、これはシステムの断面を分析した結果に過ぎません。いかにしてその状態になったのかというのが分からなければ、それはカオスの中の偶然なのです。
結果を分析して美しいというだけでは複雑系のアーキテクチャではありません。その状態が、なんらかの単純な法則によってジェネラティブ（生成的）に現れていることが重要です。
その点に置いてパターンはヒントですが答えではないように思います。パターンそのものは静的なのです。パターンをカタログ化しても、それをいかに適用すべきかについては示唆を与えてくれません。もちろん若干の指針はありますが、単純というわけにはいかないでしょう。一方のアジャイルの法則は単純です。「朝会をする」「ペアプロをする」という単純な法則はプロセスの中でいつ実行すべきかが明快で、しかも実行できない人はいないでしょう（成熟度はありますが）。
当然ですが、単純な法則がすぐに見つかるとは思っていません。それなりの時間が必要です。最近ではプラットフォームという考え方を実装しようとしています。個別のプラグインとそれらを連携させるための機構。そして、それらを統合するためのパターンや原則の提示。世界的に見てもOSGiがトレンドになりつつあり、同じような方向に進んでいるのではないかと感じています。
 | 適応型ソフトウエア開発-変化とスピードに挑むプロジェクトマネージメント (Object Oriented Selection) 翔泳社 2003-07-09 by G-Tools |
