アジャイル開発とアーキテクチャ

アーキテクチャの基本的な考え方は、機能要求に先行して構築されてることです。

この原則は、EA（Enterprise Architecture）、DOA（データ中心アプローチ）、プロダクトライン開発のアーキテクチャでもほぼ同じ思想を持っています。

一方、アジャイル開発ではTDDなどを使い、要求を定義しその実現を検証しながら開発を進めます。その結果、開発される成果物は必然的に要求との依存性が高くなります。要求との追跡性の重視や、ビジネス価値の追求を重視すれば、その傾向はさらに強くなります。それ自体は悪いことではなく、顧客の満足を考えればいい結果をもたらすでしょう。

リファクタリングを行うことで得られる結果は、インターフェイス定義の明確化（変化する部分と変化しにくい部分の分離）、コンポーネントやクラスやサービスの粒度の適正な決定を行えること、拡張性のためのより良い解を得られることなどです。

アーキテクチャをコンポーネントの関係でとらえるとリファクタリングはこの構造を決める上で有効な手段と感じるでしょう。

ただし、ここでアジャイル開発におけるアーキテクチャの構築で2つの注意点があります。

（１）アーキテクチャは現在の要求だけで構築すべきでない。

（２）コンポーネントの構造だけがアーキテクチャではない。

たとえば、（１）で要求がゴールの達成やそのための戦略に基づいて定義されていたとすれば、アーキテクチャは直接的な要求を満足するだけでなく、ゴールの達成のために構築されるので、より合理性を持ちます。ただ、その場合であっても、EAにあるように、システムのアーキテクチャが存在する以前からビジネスアーキテクチャは先行して存在しており、その一部がシステムアーキテクチャになることを考えると、アーキテクチャはシステムへの要求とは独立する存在と考えたほうが適切といえるでしょう*１。これは、教育システム、法令システムの社会構造が、個別のそれらへの要求を超えて存在しているのと同じ状況です。個別の要求はアーキテクチャに対して変化を及ぼすことはあっても、アーキテクチャは要求とは独立して存在すべきなのです。より分かりやすい例は、開発言語やRDBを大きなアーキテクチャとみなせば、これらの技術が大きくは社会的な要求によって変わったにしても、個別プロジェクトの要求くらいでは変わらないことでも分かるでしょう。

*1 ZachmanもEAはシステムアーキテクチャというより、Enterprise（企業経営、活動）のためのと言っている。

（２）は概念や哲学などの発想を言っています。たとえば、トランザクションモデルでのスナップショット分離レベルのような比較的新しいトランザクションモデルを概念として取り入れることもアーキテクチャの一部です。しかし、こうした技術は、コンポーネントの粒度の決定、インターフェイス定義の明確化とは独立しています。発想できることは、開発プロセスにアジャイルを使うかどうかとは別の次元です。アジャイルを使うことにより、多くの概念の発想ができる可能性が高くなるのであれば、アジャイルはアーキテクチャ構築に有効な手段となるでしょう。

一般には、（１）では要求の裏付けとなるゴールまで考えたアーキテクチャよりは、要求を直接実現するアーキテクチャになりやすく、（２）では、発想の探求よりも要求の実現を第1と考える傾向が強くなるので、この場合には、アジャイル開発におけるアーキテクチャの構築はうまくいかないでしょう。

現実には、アジャイル開発は、既存のフレームワークや開発基盤技術の上で行うのが前提であるので、アーキテクチャの大半はアズイズで与えられていて、その上でロジックの構造だけを考える場合が多いので有効となっているとみられます。MVCやデータアクセスの方法が与えられている場合か、プロジェクトリーダの頭の中に基本的なアーキテクチャのアイディアがアジャイルとは関係のない次元に存在している場合が多いといえます。

さて、皆さんの意見はどうでしょうか？