懸田さん（@kkd）にDevLOVE2009の感想をエントリしてもらいました（12/12 DevLOVE2009 Fusion感想）。
氏の興味対象は、動的な世界に適したアーキテクチャの構築なんだろうと思う。プロセスや人の活動だけで動的な世界に対抗することもできるが(それがTDDやAgileでのアプローチ)、その先を考えた時に、どうしても静的な思考でしか捉えることのできない’’構造’’を如何に動的な世界に適合させるかということ。
分かってらっしゃる！という感じなのですが、少しだけ補足説明。
アジャイルは「動的に変化する世界を捉えるためには、イテレーティブに成果物を出しながらコミュニケーションをしていくべきだ」というコンセプトです。それそのものは僕は大賛成です。
そもそもアジャイルが重要とされたのは、"構造"に限界があるからです。構造は強く、そして長く残ります。システム開発は構造として機能を表現します。コードは構造そのものです。現在のシステム開発は、現実を切り取った断面しか実装できません。だから時間が経過すると現実との間にギャップが生じてしまいます。だから、アジャイルのようなプロセスでの対応が必須となります。
しかし、基本的にプロセスというのは構造に比べて脆弱です。具体的には実践者の能力に強く依存しスケールしません。なぜならプロセスの実践ノウハウは形式化しにくく経験を通してしか学ぶことができないからです。だから長期間にわたって安定的に運用することができない。やれるとすれば時間をかけて育てる必要があります。でも、その人が辞めてしまえば最初からやり直しです。
小さなシステムや再構築できればいい。でも、現在ではソフトウェアが重要視されているからこそ、長期にわたりシステムを使い続ける必要が出てきています。経済環境の変化もありますね。これを実現するような持続可能な開発モデルとか漸進的な開発モデルを実現するのに、プロセスだけで対応するのには無理があるのです。
そこで懸田さんが書いている「’構造’’を如何に動的な世界に適合させるか」という挑戦が必要です。Kentが喩えるように、ハンドルを細かく動かすのがアジャイルだとしたら、その制御に安全/安定に応えられる制御構造がアーキテクチャです。ちょっと急にハンドル切ったぐらいで車がひっくり返らないようにするのです。
いわゆる「テストしやすいフレームワーク」があるとしたら、それはダイナミックなプロセス、漸進的な成長を支援する構造といえる。しかし、もし漸進的成長を、アーキテクチャ側で面倒を見るとしたら？ 変化に適応できる構造は、テストしやすい だけではないということが言えるのだろう。
短期的に注目されているのはコンポーネント指向開発です。プラットフォーム（環境）を構築し、その上にコンポーネント（モジュール/プラグイン）を足していく開発モデル。この場合、テストはコンポーネント単位で行えばいいことになります。プラットフォームはコンポーネント間の齟齬を解消し、安全性を提供します。
アーキテクチャが脆弱だと仕様変更が発生した場合にシステムのあちこちに同時に手を入れる必要性が出てきます。これは調停が非常に難しい問題になりがちです。つまり、変化の影響範囲が制御できない。こうなってしまうと安全に複数のチームを並列に走らせることができません。結局、中央のチームが全体を調整する必要が出てしまう。それがボトルネックになるとアジャイルのメリットが失われてしまいます。結局は、ウォーターフォールのように慎重な計画が必要になるのです。
では、どうするか。例えばOSGiではバージョンも含めてコンポーネント間の依存関係が明示されます。そのため依存先のコンポーネントがバージョンアップしても、それを無視することができます。これは変化の影響を限定的にするためには非常に重要なことです。イテレーションが進んでコンポーネントのバージョンが上がったとしても、そのバージョンに依存するところだけ変更すればいいのです。これはEclipseで既に実現されて効果を上げています。
また、依存性が解決されない場合でも動き続けることができます。今日のOSGi勉強会で出ていた例は「ログサービスに依存はするけど、見つからなければそれはそれで動くようにする。ログを出さなければいい」というような振る舞いをさせることができます。環境に適応してコンポーネントが動作を変えるです。
ココまで読んでコンポーネント指向開発って色々と無理があるのでは？と思ったあなたは正常です。課題は多いのです。分割方針とワイヤリング手法。前者はShared Databaseパターンからの脱却であり、後者はイベントドリブンアーキテクチャへの挑戦です。あと、複数のコンポーネントをまたがる場合に動的に現れてくる機能をどうテストするか、とか。いずれもSOAとよく似た話です。
@yusuke_arclamp氏は、もっと先のコンセプトを出しているが、この領域はまだまだ発展段階だし、可能性が多く残されているといえる。
僕がもっと先のコンセプトとして提示しているのが「ソフトウェアに身体性を持たせる」ということです。現在のオブジェクト指向開発の限界は、それが人間の"認識"に強く依存することです。認識は断片的で一時的なものです。その認識に従ってシステムを作っても現実は変化してしまう。であれば、人間が認識したオブジェクトに頼ってシステムを作るのではなく、オブジェクトを取り出す前の環境そのもの（アフォーダンスで言えばサーフェイスのレイアウト）とソフトウェアが直接的にインタラクションすればいい。つまり、ソフトウェアが自律的に学ぶのです。これを完全に実現するのは100年先かもしれませんが、擬似的に実践しようという動きはいろいろと出てきています。上に書いた、コンポーネントが他サービスの状況に応じて動きを変えるというのも1つの方法です。
そもそも、ぼくらは動きを動きそのものとして捉えることができません。例えば扉の開き方を直接デザインすることはできません。それは扉の構造を通じて行う。例えば時間の経過は構造がもたらす状態変化によってしか感じられません。時計の針が進むから時間を感じるわけで、時間そのものの直接感じることは出来ない。すべてのものが停止した世界は「時間が止まっている」のです。
動的な世界というのは、実は静的な構造の状態変化なのです。ソフトウェアは「静的な構造の状態変化」というのを比較的記述しやすい。だから、まだまだ可能性は色々とあると思うのです。
