ソフトウェアプロジェクトにおいてソフトウェアアーキテクチャは出来がわるくて軽視されていないだろうか？ 独立系コンサルタントでCodingTheArchitecture.comの創業者であるSimon Brown氏は、最近のブログ記事でそう問題提起した。アーキテクトのミスキャストとアジャイルプロジェクトにおけるアーキテクチャに対する漫然としたアプローチが、アーキテクチャ規範をこのようにひどい状態にしていると彼は主張する。
Brown氏によれば、隔離された象牙の塔にいるアーキテクトがソフトウェアアーキテクチャの評判に傷をつけているという。開発チームと緊密に仕事をして、現実的で完全な解決策を設計する代わりに、多くのアーキテクトは開発者とは別に仕事をして、難解でハイレベルな仕様を開発者に手渡すのだ。ソフトウェアアーキテクトがプロジェクトに直結した価値を生み出せないと、アーキテクチャという公式業務は主役の座をおろされ、準備不足の開発者がソフトウェア設計に責任をもたなくてはいけなくなる。Brown氏はこれを大きな問題だと考えるとともに、アジャイルプロジェクトがこの問題を悪化させていると考えた。アジャイルプロジェクトはすばやいデリバリーの名のもとに、確固たるアーキテクチャ原則を軽視することが多いと彼は言う。
ところで、この古めかしいソフトウェアアーキテクチャというものは一体何なのでしょうか？ 多くのソフトウェアチームはソフトウェアアーキテクトを不要だと考えているようです。その代わりに、「自己組織化したチーム」「YAGNI」「進化的アーキテクチャ」「最終責任時点」といった言葉をうるさく言います。もし彼らにアーキテクトが必要になったら、おそらく「アジャイルアーキテクト」を募集するのでしょうね。私にはこれが実際に何を意味するのかわかりませんが、UMLの代わりにポストイットを使ったり、図を書く代わりにTDDをするといったものなんじゃないかと思います。非常にハイレベルなシステムメタファーだけを使うという考えを素通りしても、愚かにもうまくいくよう願う言い訳として「創発的設計」を使ってはいけません。
しかし望みはまだある。Brown氏はどんなプロジェクトにも確固たるアーキテクチャ原則の役割はあると主張し、ソフトウェアアーキテクチャのコミュニティはその価値を説明し、明日のアーキテクトに投資するようもっと取り組むべきだと語る。InfoQはBrown氏にコンタクトして、ソフトウェアアーキテクチャの現状とその技術の磨き方について質問した。
InfoQ: あなたの記事についたコメントを引用しますが、「本物のアーキテクトとは一体何をするのでしょうか？」
Brown氏: 「アーキテクト」という言葉にある大きな問題のひとつは、各個人やチーム、組織がそれぞれ独自の定義をしていることです。私の場合、ソフトウェアアーキテクチャの役割はソフトウェアチームに技術的なリーダーシップをもたらすことです。私はどんなソフトウェアプロジェクトにも、ある程度は事前の設計が必要だと固く信じています。コツは「過不足なく」やることです。つまり、初期のハイレベルな構造を作り、主要なリスクに対処し、チーム全員がともに取り組むべきビジョンを作ることです。事前の作業だけなく、アーキテクチャにはデリバリーライフサイクル期間中、初期の設計を保ちつつ必要に応じて進化させる役割もあります。私がここでお話しているのは地位ではなく役割についてであって、その役割はチームの一人もしくは多人数で引き受けても構わないということを強調しておきます。最近、QCon London 2012カンファレンスでワークショップを開きました。そこで私たちはソフトウェアアーキテクチャの役割に関する数多くの質問に答えました。http://www.codingthearchitecture.com/2012/03/13/photos_from_my_qcon_london_2012_tutorial.htmlで、そのまとめを読むことができます。実に興味深いことに、私たちが論じている役割は多くの組織でよく見られるのとは非常に異なっています。
InfoQ: ソフトウェアアーキテクチャがまだ誤解されているように思うのはなぜですか？ この役割をもっと理解してもらうには何をすればよいと思いますか？
Brown氏: ソフトウェアアーキテクチャは誤解されていると思っています。というのも、ソフトウェアアーキテクチャの役割は業界で評判がわるいからです。加えて、原則に関する世の中の教育コンテンツの多くは、ハイレベルすぎたりアカデミックすぎるきらいがあります。「ビジネステクノロジーストラテジスト」や「価値提案」といった言葉をうるさく言うと、多くのソフトウェア開発者は原則について学ぶことから遠ざかってしまいます。私たちが "Coding the Architecture" というWebサイトを作ったのは、ソフトウェア開発者が関連するソフトウェアアーキテクチャの現実的で実践的な視点を提供するためです。それはなぜかって？あまりに多くのソフトウェアプロジェクトが基本的な理由のために失敗しているからです。そして私はソフトウェアアーキテクチャを、単にソフトウェア開発に含まれる役割として、すべてのソフトウェア開発者が基礎知識として持つべきものとして見てほしいのです。ソフトウェアアーキテクトであるソフトウェア開発者はみな、間違いなく私たちが作りたい自己組織化したチームにとって、すばらしいスタートをもたらしてくれます。
InfoQ: ブログ記事で、あなたは「アジャイルはアーキテクチャを必要としているのだろうか、それとも、アーキテクチャはアジャイルを必要としているのだろうか？」と問いかけていますね。その質問には実際にどう答えますか？
Brown氏: どれだけアジャイルかにかかわらず、どんなソフトウェアプロジェクトも「アーキテクチャ」について検討する必要があります。なぜなら、重要な非機能要件や制約というのはなくならないからです。したがって答えはイエスです。アジャイルプロジェクトはソフトウェアアーキテクチャの役割を必要としています。しかし残念なことに、あせってアジャイルを導入すると、多くのチームがこのことを忘れてしまうのです。逆に、従来のプロジェクトにおいて、ソフトウェア軽量なアプローチをアーキテクチャに適用することで学べることもたくさんあります。アジャイルをうまく使えば、何もかも事前に設計しておく必要はありません。
InfoQ: アーキテクトの役割というのは開発者にとって自然な発展だと思いますか？それとも、難しいスキルセットを要する異なるパスだと見なしていますか？
Brown氏: これは「場合によりけり」ですね。コードを書くことで駆り立てられ、そのレベルで創造性を発揮するソフトウェア開発者もいますし、より大規模なソフトウェア設計にチャレンジするのを楽しむソフトウェア開発者もいます。私の知る最高のソフトウェアアーキテクトは、テクノロジーに深く精通し、「棟梁」になってからアーキテクトの役割につきました。自分の扱っているテクノロジーを理解することが大事です。ソフトウェアやデプロイする環境の背後にどんな推進力があるのか理解するために、一歩引いて「全体像」見るのです。すぐれたソフトウェアアーキテクトは両方ができる必要があります。ですから、ソフトウェアアーキテクトがすべてのソフトウェア開発者のキャリアパスの次ステップである必要はありません。そして、一般に信じられているように、ソフトウエアアーキテクトになることはコーディングをあきらめなくてはならないことを意味してはいません。
InfoQ: 組織において、どのようにアーキテクトを「育成」すればよいのでしょうか？
Brown氏: 残念ながら、多くの組織では育成されていません。ソフトウェア開発者はただ困難なところに投げ出されたり苦しんでいるのです。それはサポートが得られなかったり、マネジメントのポジションに押し出されるためです。ソフトウェアアーキテクチャのスキルを伸ばすのは簡単です。その役割を共同にすればよいのです。すでにアーキテクトの役割にいる人にコーチさせて、そうでない人を指導するのです。ソフトウェアチーム全体がソフトウェアアーキテクチャを受け入れる必要があります。であれば、それを生み出して形作る作業に関わらせない手はないでしょう？組織内で"Architecture Katas"（訳注: Kataは空手の型）を開くとよいでしょう。そこでスクラッチからソフトウェアのピースを設計する方法を訓練するのです。結局のところ、定期的にこれができているソフトウェア開発者はどれくらいいるでしょうか？
ソフトウェアアーキテクチャを訓練するガイドについてはhttp://www.codingthearchitecture.com/2012/01/05/contextualising_just_enough_up_front_design.htmlを参照するとよいでしょう。