アジャイルアーキテクチャ - 矛盾? それとも賢明なパートナーシップ?

原文(投稿日：2010/05/14)へのリンク

 アジャイル技術とアーキテクチャに関する考え方の間にある意見の相違について、数多くの解説者たちが話題にしている。  

アジャイル世界において、アーキテクチャはしばしばBDUF (Big Up Front Design)とみなされ、その結果、たびたび軽く見られたり、「YAGNI」(You ain’t gonna need it)の考え方で後回しにされたりする。

一方、IEEE Software Magazineの2010年3、4月号で以下のように述べられた。 

アジャイル開発は、産業界のソフトウェア開発プラクティスに大きな影響を与えてきました。ところが、アジャイル開発の幅広い人気にも関わらず、アジャイルに取り組む際にソフトウェアアーキテクチャの役割や重要性に関する問題が増加しています。大規模なソフトウェア集約システムにおいて、品質目標を達成するためにアーキテクチャは重大な役割を持つと主張する人たちは、アーキテクチャにあまり注意を払わない開発アプローチの拡張性に疑いを持っています。

IEEEは特集号でアジリティとアーキテクチャの関係に注目し、アジリティとアーキテクチャ間の緊張状態の中で、これらが2つに分けられるものではないことを調査しています。

特集号の紹介文では、主要なアジャイル実践者たちのアジャイルアーキテクチャに関する視点をいくつか引用する。

最初のスプリントやイテレーションから「ステークホルダに価値を提供する」という動機もあります。しかし、もしエンドユーザだけでなく開発者たちがステークホルダの重要な部分であったら? Alistair Cockburn 氏は、動くスケルトンから始め、繰り返し進化させる戦略を発展させました。Mary Poppendieck氏とTom Poppendieck氏は、「分けられるシステムアーキテクチャ」の概念を考え出しました。そして、最後に、Kent Beck氏は「アーキテクチャがどんなソフトウェアプロジェクトでも重要であるように、XPプロジェクトでも重要だ。アーキテクチャの一部はシステムのメタファ(XPプラクティスの1つ)によってとらえられる」という意見を述べました。

この記事は、続いて「本当の問題」を確認する。その問題とは、アジャイルとアーキテクチャ間の対立を解決することに取り組む必要があるということだった。

• セマンティクスを明らかにする – 企業やプロジェクトで実際に「アーキテクチャ」の意味するものは何か? 設計上の決定すべてがアーキテクチャに関連する訳ではなく、実際に設計上の決定がアーキテクチャ的に重大なことはほとんどない。多くのプロジェクトにおいて、設計上の決定は開発プロセスのほんの初期段階で決定される。 
• コンテキストが重要 – プロジェクト環境。企業、ビジネスドメイン、既存の技術、プロジェクトの大きさ、変化率、システムの年数、危機的状況、管理、マーケットの状況、平均寿命といった側面はすべてアーキテクチャ上の意思決定の必要性に影響を与える。 
• ライフサイクルの中にある場合 – ライフサイクルの中で十分早い段階に、アーキテクチャ上の決定がなされるべきだ。なぜなら、「アーキテクチャは、システムの構成や振る舞いに関して重大な決定を含んでいるからだ。」これらの決定は後で変更するのがもっとも難しく、アーキテクチャに関するストーリーは、初期のイテレーションで機能ストーリーに織り交ぜる必要がある。
• アーキテクトの役割 – Martin Fowler氏が2つのアーキテクチャに関する見解を述べている。

o   Architectus reloadus – 外部との協調に注目しながら大きな決定を下し、それを見守る人。

o   Architectus oryzus – 開発チームの中で内部的な協調に注目しながら、コードに取り組んだり、メンターになったり、プロトタイプを作ったり、問題解決をしたりする人。

• すべてのドキュメントが悪いわけではない – 大抵の場合、アーキテクチャ上の要求は「動くスケルトン」のプロトタイプとして表現される。このプロトタイプは、数少ない確かなメタファにサポートされた最終ターゲットとなるものだ。しかしながら、時にはもっと明確なアーキテクチャに関するドキュメントが必要かもしれない。おそらく、外部規制へ準拠していることを証明したり、大きな分散チームに伝えるたりするために使われる。
• アーキテクチャは手法を持つ – アジャイル手法は、アーキテクチャの価値を明示的に述べてはいても、アーキテクチャを定義していく方法については沈黙しがちである。利用可能なアーキテクチャ上の手法をいくつか調査するのに、時間と労力を費やす価値はあるだろう。(この記事では、数多くの手法をリストしている)
• アーキテクチャは価値を持つ – アーキテクチャにかかる費用は簡単に示せる。特に、BDUFのアプローチでは簡単だ。しかし、その価値はいつもすぐに目に見えるものではないかもしれない。ビジネスの価値の条件におけるアーキテクチャ上の必要性を表すことは、アーキテクチャがチームにもたらす価値を明らかにするのに役立つ。

Bobおじさん (Martin氏)がObject Mentorブログで次のように述べた。

アジャイル開発に関して知らない間に続いている神話の1つは、事前に決められるアーキテクチャと設計は悪いということです。この神話によると、アーキテクチャ上の決定を事前に下すために時間を費やしてはいけません。代わりに、何もないところからアーキテクチャと設計を進化させるべきです。一度に1つのテストケースです。

 申し訳ないけれども、これはくだらないことです。

 この神話は、まったくアジャイルではありません。むしろ、Big Design Up Front (BDUF)をアジャイルから追放しようとすることに対して過度に反応したものです。BDUFに害があることは疑いの余地がありません。設計者やアーキテクトが、テストされていない仮説に結び付けられたことに基づいて、システム設計を何度も行うために何ヶ月も費やすのは、まったく理にかなっていません。John Gall氏の言葉を言い換えれば、走り書きから設計された複雑なシステムは、決して動きません。

 しかしながら、事前に解決すべきアーキテクチャ上の問題があります。初期の段階で決定されなければならない設計上の決定事項があります。まったくひどい行き止まりの中に自分自身を投げ込んでしまう可能性がありますが、これはちょっと事前に考慮すれば避けられるかもしれません。

 ここで大きさを強調していることに注意してください。大きさが問題です。「B」は悪くて、「L」は良いのです。実のところ、「LDUF」は絶対に必要です。

Agile Architectウェブサイトで、具体的なアドバイスをいくつか見つけられる。

アジャイル開発手法は、ソフトウェア開発プロセスを改善しようとしています。そうすれば、私たちは役に立つ解決策をもっと多く、もっと速く提供できます。しかしながら、いくつもの成功に関わらず、大企業や大規模プロジェクトにおいて、これらの手法を適用するのはとても時間がかかります。この理由の1つは、多くのアジャイル手法がアーキテクチャに関して弱く、複雑な企業環境の中でより大規模なシステムを提供する現実とかけ離れていると考えられていることです。同時に、多くのアーキテクチャプロセスは、時間がかかって扱いにくく、官僚的です。これらは、もっとアジャイル的なアプローチから恩恵を受けるでしょう。このウェブサイトは、アジリティをアーキテクチャに、アーキテクチャをアジリティにもたらすことで、このジレンマに立ち向かう方法を考えています。

このサイトは、アジャイルアーキテクト の役割とアジャイルアーキテクチャの原則について議論している。 

あなたのチームは、どうやってDBUFとLDUF間のギャップを埋めるだろうか?　アジリティとアーキテクチャの間に対立はあるだろうか?