アーキテクトは，アジャイルプロジェクトで意味のある役割を担うことができるだろうか，それとも，彼らの陥りがちな "BDUF(Big Design Up Front / 事前の大規模設計)" のせいで，脇役にならざるを得ないのだろうか？ Microsoftでエンタープライズアーキテクトを務めるNick Malik氏は先日，この問題を探求した記事をブログにポストした。その中で氏は，スクラムを採用したソフトウェアプロジェクトにおいても，アーキテクトは間違いなく重要な役割を果たす，と結論付けている。
Malik氏がブログ記事を書いたのは，氏がアーキテクチャプラクティスをスクラムプロセスに適用しようとした，あるプロジェクトがきっかけだった。記事は冒頭から，ソフトウェアアーキテクチャとアジャイル開発プロセスは相反するものではない，という主張で始まっているが，スクラムの特徴である短い周期のデリバリに話題が及ぶと，システムの設計と作図に何ヶ月もの期間を費やす従来型のアーキテクチャプラクティスは"実に愚か"だと，氏も認めざるを得なくなる。そうではあるが，どのようなソフトウェアプロジェクト – スクラム開発プロセスを通じて実施される場合も含んで – にも，その基盤として認識すべきソフトウェアアーキテクチャは存在するのだ。
ソフトウェアアーキテクチャの価値は，システムのコアインフラストラクチャそのものに関する重要な決定を行う点にあります – 汎化は何処で行うのか？レイヤ構造パラダイムを使用するのか，そうであれば，各レイヤはどのような責務を持つのか？ レイヤにはどのようなモジュールがあって，それらは何の目的で作成されるのか？ システムの責務をどうやってレイヤやコンポーネントに分割するのか？ スケールに際して，モジュールはどのようにデプロイされるのか？モジュール間，および周辺システムとの間の情報フローはどのようなものになるのか？
これらの質問に対してどのような回答をするのか，それがシステムのアーキテクチャが何であるか，ということなのです。
これらの選択についてMalik氏は，いずれもシステムの品質要件全体のパランスに注意して行わなければならない，としている。このような要件は，ソフトウェアアーキテクトの仕事として，ソフトウェアの責務に関する３つの異なるレイヤに関与する。
最上位のレイヤは整合プロセス(Aligning Process)と名付けられる。四半期ないし半年の周期を持って組織全体の情報およびビジネス戦略を検討するもので，組織の"あるべき"ソフトウェアモデルをアウトプットとする。第２のレイヤに位置するのは調整プロセス(Balancing Process)である。特定のソフトウェアプロジェクトに関与するもので，スクラムの初期スプリントでの開発に伴って必要となることが多い。Malik氏はこのレイヤを，論理的システムアーキテクチャを創造する場所である，と説明している。
これらのプロセスは，ひとつのシステムのニーズについて考慮したものですが，ソフトウェアをなぜモジュールやレイヤ，コンポーネントに分割するのか，そのような責務の分割がなぜ生じるのか，その結果として，あるテクノロジである環境にデプロイされたシステムはどのようなものになるのか，といったことを決定するレベルのものに過ぎないのです。
このモデルで最後のレイヤにあるのは実現プロセス(Realization Process)である。Malik氏はこれを"アーキテクチャがソフトウェアになる場所"だ，と表現する。アーキテクトが行った詳細な設計的判断を，ソフトウェア開発者がここでシステム構築に使用するのだ。氏は "ほとんどの場合，チームは記述されたとおりのソフトウェアアーキテクチャを実装するのですが，改善策を選択する場合もあります" として，アーキテクトの選択したデザインパターンを開発者が使用しないことも認めている。
ではスクラムのソフトウェア開発プロセスにおいて，どのように実践されるのだろうか？ 氏はスプリント計画セッションの直前に，ひとつのステップを加えることにした。優先順位付けされた製品バックログから直接スプリント計画セッションや以降のソフトウェアスプリントに進むのではなく，ストーリの改善を検討し，アーキテクチャ的合意を得るための"スプリント前のストーリレビュー"を挟むことにしたのだ。
この新たなアーキテクチャ重視のステップを週１回，スプリント計画セッションの前に実行するように氏は提唱する。
その週のスプリント計画の前に，各メンバとプロダクトオーナが共同で，ストーリの改善，制約の追加，説明と許容基準の改良を行うのです。そしてここにこそ，私たちアーキテクトの出番があります。前述のモデルで "バランス" を取る役割を担うアーキテクトは，そのソフトウェアシステムのアーキテクチャを説明したアウトライン資料を持っています(あるいは作ることができます)から，その設計によって影響を受ける"特定のストーリ"を，そのドキュメントにリンクさせることができるのです。
Malik氏はアーキテクトについて，アジャイルプロジェクトにおいて，"鶏"あるいは"豚"だ，と結論付けている。そのどちらになるのかは，対処しようとしているアーキテクチャ上のレイヤによって決まるという。すなわち，最初の２つのレイヤを作り上げている間のアーキテクトはチームの関与メンバの一員(鶏)であり，作業が第３のレイヤに達した時には犠牲的貢献者(豚)になるというのだ。氏の挙げたこのテーマは，さらにアジャイルプラクティスにおける”アーキテクチャ"の役割へと議論を続けさせる。今年始めのブログ記事で氏は，エンタープライズアーキテクトとは本質的にアジャイルであり，段階的な進行を通じて価値の高いアクティビティを完遂するという彼らの指針は，アジャイルの精神に完全に一致するものだ，と提唱している。アジャイルとアーキテクチャの交差は，アーキテクチャ的な債務を負うことなくソフトウェア開発の効率性を図るという意味で，これからも極めて関心の高い領域であり続けるだろう。