2007年6月19日に実施されたJavaWorldDAY2007にて、JavaとLLで実現する「アジャイル・アーキテクチャ」という講演をさせてもらいました（使用したパワーポイントのPDFファイル）。
もともとがITアーキテクト次号の特集用に書いたものなのでコードよりも概論が多くなっています。しかも、マシンがうまくディスプレイを認識してくれなくてもデモもできずにすみませんでした。以下、概要です。
アジェイル・アーキテクチャとは何か
どんなことにでも対応できる万能アーキテクチャは存在しません。僕なりには「ビジネス環境で起こりうる変化に迅速に対応できるように適切に選択されたアーキテクチャ」ととらえています。ポイントは以下の2つになります。
- 起こりうる変化を管理する
- その変化にしたがって適切なアーキテクチャを選択する
いまそこにある変化
では、起こりうる変化とは何か。これまでアプリケーションの変化予測というとスケールの変化（ユーザー数やトラン数の増減）と機能の変化を考えてきたように思います。サイジング設計とか。
しかし、注目すべきなのは「意味の変化（外部との関係性の変化）」だと考えています。たとえば、アクセスで作った簡単なツールがいつの間にか業務のコアシステムになってしまうとか、雑誌で紹介されたサイトのアクセス数が急激に伸びるとか。意味が変化すると根本的なシステムのあり方が変わってしまい、もはやシステムがビジネスに対応できなくなってしまいます。
こうした場合に考えるべきなのはリスク（将来の不確定要素）管理です。確定的に未来を考えても意味がないわけです。
適切なアーキテクチャとは
そして、こうした状況で必要なアーキテクチャとは何か。それは2つの軸に分けられます。
- 生産性向上を目指す ＝ 早く作る。だめになったら捨てる
- 外部接続性向上を目指す ＝ 継続する。部品の交換と再利用
ですが、この2つは開発において相反する要素です。
- 生産性を向上させるキーワード ： 単純さ、ルーティーン、固定、暗黙的な規約、内部都合で好きにできる、決定事項、俺流
- 外部接続性を向上させるキーワード ： 複雑さ、未知、柔軟、明示的な規則、外部都合に振り回される、調整事項、標準
どちらが良い悪いというのは「起こりうる変化」に応じて考えなくてはいけません。外圧（使う視点）で考えればビジネス特性（実験事業か継続事業か）、利用者のリテラシ、法律など。内圧（作る視点）で考えればエンジニアのスキルやシステム規模、そしてコストなど。なお、アプリケーションの部位というスコープでも同じような発想が必要になります。
こうしたことを総合的に考えて、適切なアーキテクチャを選択するのがアーキテクトの仕事になります。
アーキテクチャの実現手段
極端に考えると、生産性を目指すのがLL的なアプローチで、外部接続性を考えるのがSOA的なアプローチです。今回のネタであるJava＋LL（JavaVM上で、Java言語とLL言語を組み合わせて使う）というのは、中規模程度のアプリケーションにおいて間を狙ったようなアプローチです。
Java内における多言語化については既に発生している事態（Java、JSP、XML、SQL、アノテーション…）ですし、分業化による道具としての言語の専門化については当然の（仕方のない？)流れです。
この中でJava、LL、XMLというのはそれぞれ特徴を持っています。具体的には以下のような切り分け。
- Java ： 手続きの表現が得意。複雑なビジネスロジックに向く
- XML ： 構造表現が得意。設定的な感じ。パターン化できるビジネスロジックやパターン化できるプレゼンテーション層に向く
- LL ： 中間的。非定型なプレゼンテーション層とかグルー層に向く
これについては既にSarugauなどで紹介しています（ちなみにSarugauは新しいバージョンを作りはじめていて、これも完成後にOSS化します）。
まとめ
具体的なノウハウをあまり出していないので概念論的ですが「アジャイル・アーキテクチャとは、ちゃんと考えてちゃんと選択すること」、それから「Java+LLみたいな手法もありだよ」って感じで。
