先日、憧れのITアーキテクトと「アジャイル・アーキテクチャ」について議論。きちんと理想と現実と捉えていて、さすがという感じでした。
アーキテクチャ自身がアジャイルなわけではない
まず言われたのが「アジャイルなアーキテクチャ」といってしまうと、アーキテクチャ自体がアジャイルに変化するというミスリードをするのではないかという点。確かにそうですね。広義のアーキテクチャというのは全体性を決定する思想・概念であり、それ自体がアジャイルに変化することが求めることはあまりないと思っています。狭義のアプリケーション・アーキテクチャに変更が求められる場合はありえますが、それすら広義のアーキテクチャには織り込み済みであるべきです。
では、僕らが考えるアジャイル・アーキテクチャとは何か。それは"適切なアジャイル性を実現するアーキテクチャ"と定義できそうです。
ここで出てきたのがアーキテクチャの結合度、可変性分析、そしてチームの開発能力。
"いわゆるアジャイル"のアーキテクチャは成熟度が低い
アーキテクチャの結合度というのは、アプリケーション内の要素がどの程度の結合度でつながっているのかをしめす指標です。IBMが定義しているService Integration Maturity Model (SIMM)を参照してみます。これはSOAを文脈でアーキテクチャの成熟度を示しており、成熟度が高いほど疎結合が実現されています。
1. Silo (data integration)
2. Integrated (application integration)
3. Componentized (functional integration)
4. Simple services (process integration)
5. Composite services (supply-chain integration)
6. Virtualized services ( virtual infrastructure)
7. Dynamically reconfigurable services (eco-system integration)
で、面白いのは、結合度が高いほどアジャイルか、というとそうでもない点です。
むしろ、一般的にアジャイルといえばスクリプト言語ですが、ここで使われているアーキテクチャは成熟度が低い（結合度が高い）ことがわかります。Ruby On Railsでいわれる"Convention Over Configuration"（設定より規約が重要）、例えばデータベースのテーブルがエンティティとして定義されているというのは結合度が高い証拠です
勘違いしてはいけないのは「結合度が高いから悪い」というわけではない点です。アプリケーションの結合度を高めるとアプリケーション内での実装スピードは早くなります。これはアプリケーションの実装スピードの効率化に大きく寄与します。
ですから、アプリケーション内の実装のアジリティという点では結合度を高くすべきなのです。
なにが変化するのかを見極める
ここから話を展開すると、では何を目的としてアーキテクチャの結合度を調整すべきなのかということになります。ここで重要なのが可変性分析です。可変性とは、ビジネスにおいて何がどのように変更されるのか、ということです。
例えばビジネスルールの可変性があると認識されるとパラメタ化を考えることができます。この場合はルールエンジンを導入してパラメタによってビジネスを動かすことができるようになります。しかし、ビジネスルールの変更がビジネスロジックの変更まで及ぶと判定されて場合パラメタ化は意味がなくなります。むしろ不自由なルールエンジンがアプリケーションの制約となってしまうのです。
もちろん、こうした議論は0か1ではなくて、部分によって違うとか、季節によって違うとか、より包括的な外的要素によって決定されています。
一方で、ある部分は捨て去ることを前提にゴリゴリと素早く作ることが求めらることもあるでしょう。こうした場合は結合度を上げるのが正しいアプローチです。これは可変性が低い、あるいは生存期間が短いことを前提にしています。とりあえず早く安く、などで作り始めたシステムが重要性が高まってしまい、しかも社内にそんなシステムがごろごろしていて、メンテナンス性も低い、なんてことが起きてしまうのは可変性分析が甘いことが原因です。
つまり、アプリケーションが必要とする結合度は、そのアプリケーションが目的としているビジネスの可変性をいかに理解するかにかかっているのです。
マルチパラダイムデザインなどでいわれている共通性(commonality)と可変性(variability)の話と同じです（参照：『マルチパラダイムデザイン』への序論）。
チームの能力がアーキテクチャの適用範囲を決定する
可変性分析が完璧であっても、それだけでアーキテクチャが決定することはありません。これには、そのアーキテクチャを使ってアプリケーションを実装するチームの能力が大きく関係します。
チームがアーキテクチャに十分習熟していれば結合度の関係なく、それなりのアプリケーションを作ることができたります。例えば関数型言語で本格的なエンタープライズ・アプリケーションができた、というのはありえる話ではありますが、アーキテクトが常に期待すべきことではないでしょう。
冷静にチームの能力を見て判断をすることが重要です。
適切なアジャイル性を実現するアーキテクチャ
こうして考えてくると、アーキテクチャにおいて重要なのは「適切なアジャイル性を実現する」ということであることが良く分かります。かつ、仕事の範囲や好みがでるところでもあります。個人的には調整可能性を残すためにも設定ファイルがあったほうが好きなのですが、ま、これも好みの範囲でしょう。
どんなときでも「正しいアーキテクチャ」は存在しえません。だからこそ、ITアーキテクトは自らの頭を働かせて論理を組み立てるのです。それはITアーキテクトの説明責任であり、最大の責務であると思います。
ビジネスを見て、そしてチームを見て、あとは自分の論理で信ずる選択をしなくてはいけません。
