2010年、私はあなたはソフトウェアアーキテクト？という記事を書いた。これはソフトウェア開発者であることとソフトウェアアーキテクトであることの違い、変遷について述べたものだ。ソフトウェア産業はこの8年間で大きく変わったが、ソフトウェア開発チームは依然として基本的なこと、特にソフトウェアアーキテクチャに関することで苦しんでいるように見える。以前よりも間違いなく重要になったことは、分散環境のソフトウェアシステムを分散環境のチームで構築することだ。このトピックの導入として、いくつかの通説の誤りを正すため、すべてのソフトウェア開発者がソフトウェアアーキテクチャに関して知っておくべき5つの事項を述べる。
1. ソフトウェアアーキテクチャは Big Design Up Front ではない
ソフトウェアアーキテクチャは伝統的に Big Design Up Front とウォーターフォール型のデリバリーに関連付けられてきた。ここではチームはコードを書き始める前に全ての設計が完了しているとみなす。2001年 "アジャイルソフトウェア開発宣言" は "計画に従うことよりも変化への対応を" 価値とすべきであるとしたが、これは時に我々は計画を立てるべきではない、と誤って解釈されることがある。その結果、実際に目にしたことだが、いくつかのソフトウェア開発チームは、事前に設計を完了させるやり方から、事前に全く設計しないやり方へ転換してしまった。両極端のやり方は愚かなことだが、事前に設計を仕上げることが必ずしも完了状態に必要ないと考えるとすると、比較的簡単に、ちょうどいいポイントを見つけることができる。代わりに、事前に設計を完了させることを、出発点を設けチームに指示を出すことであるとして考えよう。これはステップを抜かされることが多いがチームに大きな価値を与えることであり、彼らが何を構築しようとしているか、そしてそれがどのように機能するかを理解することに役立つ。
あるソフトウェア設計に至るためには、いくつかの設計上の決定をする必要がある。アーキテクチャと設計の差異に関する議論について、 Grady Booch 氏は "アーキテクチャは重要な決定を表し、その重要性は変更のコストによって決まる。" と言った。言い換えると、どの決定が後で変更するコストが高いか？ということだ。これに従えば、事前の設計を考える際に有効なことは、トレードオフ理解した上で "重要な決定" を行ったか、ということだ。これらの重要な決定は典型的に技術選定と構造（たとえば分解戦略、凝集度、機能的境界など）に関連付く。モノリシックなソフトウェアシステムを構築しているとしたら、プログラミング言語の選択は多くの理由から重要になるだろう。マイクロサービスアーキテクチャを採用している場合は、プログラミング言語の選択の重要度を減らせるかもしれないが、その他に考えなければならないトレードオフが発生する。同様に、ヘキサゴナルアーキテクチャはビジネスロジックと技術選定を分離することができるが、やはりトレードオフが生じる。
事前の設計プロセスでは、したがって、たとえばデータベースの各カラムの文字列長などについての理解よりもソフトウェアシステムの全体像に影響を与える重要な決定についての理解を深めるべきだ。私はチームに対して、彼らが何を、どのように（高いレベルで）作ろうとしていて、設計したものが実際に機能するかどうか、よく理解していてほしい。これは、最も優先度の高いリスクは何か、どうすればそれを適切に緩和することができるか、を明らかにすることによって達成される。必要があればコードも書くべきだ。要約すれば、事前の設計は、自分によって有利に働くようにすることだ。
2. すべてのソフトウェアチームはソフトウェアアーキテクチャを考えるべきである
これは全てのソフトウェアチームに当てはまる。ガレージでスタートアップを立ち上げようとしているようなチームから、数百もの開発者が世界中に分散しているようなチームでも同様だ。出発点と指示を決めることは技術的なリーダーシップをもたらす。これを行う際に失敗すると、混沌、たとえば貧弱な構成、理解しづらく内部的に一貫性の無いコードベース（よくある "大きな泥だんご" ）、メンテナンスが困難でパフォーマンスやスケーラビリティ、セキュリティなどのについて重要な品質上の要件が満たせない可能性のある機能群、につながる。ひとことでいえば、全てのチームは技術的なリーダーシップが必要である。
3. ソフトウェアアーキテクチャの役割はコーディング、コーチング、そしてコラボレーションである
多くの人々がソフトウェアアーキテクトにもつイメージは、伝統の "象牙の塔" のようなソフトウェアアーキテクト、すなわち、リレー競走で始めの走者がバトンを渡すように、何の疑いももたない開発チームに対して指示を出す人物である。しかしこれはあるべき姿ではなく、その代わりに多くのモダンなソフトウェアアーキテクトは、コーディング、コーチング、コラボレーティブな設計を活かしたアプローチを好む。私が会ってきた良いソフトウェアアーキテクトの多くは、コーディングを楽しみ、かつ必要に応じてコーディングをしないこともある、良い開発者でもある。日々移り変わる技術に注意を払わないことは簡単だ。私が好きな考え方は、ソフトウェアアーキテクトは、彼らがチームの一員としてコードを書くこともできるという意味で &qout;マスタービルダー&qout; であるべきだ、というものである。チームの一員となり、コードを書くと、ソフトウェアアーキテクチャの役割は非常に簡単になる。なぜなら、開発されているシステムを深く理解でき、他の開発者たちからは同僚であるとみなされるからだ。
ソフトウェアアーキテクチャの役割は必ずしも1人の人物によってなされる必要はない、ということに言及することも価値がある。これは始めるのにちょうどよく、この役割は複数の人物間で共有される共同作業となる。しかし、注意点がある。コラボレーティブな技術的リーダーシップは容易であるとするアドバイスには気をつけてほしい。そんなことはなく、ソフトスキルは困難だ。私は定期的に、2-5人のグループにソフトウェアシステムの設計をしてもらうというソフトウェアアーキテクチャの「型」を実施しているが、このグループの中には、設計と技術選定に関する決定についてコンセンサスをとるに至らないグループもある。極端な例では、エゴと人格の衝突によってグループが分断されてしまう。重要なことは、チームについてよく理解し、技術的リーダーシップを適切な度合い、やり方で発揮していることを確実にすることだ。
4. UMLを用いる必要はない
ソフトウェアアーキテクチャの伝統的な考え方はしばしば、あらゆる詳細をとらえるために巨大な UML (Unified Modeling Language) モデルのイメージを作り上げようとする。不運にも、モデリングと UML はアジャイル以前の時代の "Big Design Up Front" のプラクティスと成り果ててしまい、その全てはチームによってここ数年で投げ捨てられてしまった。私は世界中を旅しているが、出会ってきたソフトウェア開発チームの中で、メンバーのうち誰も UML を知らないというチームの割合は増加している。
近年、多くの人々が共通してアドバイスすることは、アイディアを分かち合う方法として "ただホワイトボードにボックスと線を書くこと" だ。私はそうした図を、これまでのソフトウェアアーキテクチャの「型」を通じて、数ギガバイト分の写真として所有している。いくらかの自身をもって言えることは、業界としてソフトウェアアーキテクチャについて会話する能力を失ってしまったということだ。私は、みなさんが想像できるあらゆる図を見てきた。読みにくく不規則に色が塗られたボックスと線でできた、ソリューションについて何も教えてくれないようなものもあった。ソフトウェアアーキテクチャについて会話できないチームは、上述したような出発点と指示を設定することができないだろう。
ソフトウェアアーキテクチャについて会話するための私のソリューションは、私が "C4 model" - コンテキスト、コンテナー、コンポーネント、そしてコード - と呼ぶ、抽象性第一のアプローチだ。これは本質的には、ソフトウェアシステムを表現するための階層的で拡大縮小可能なマップを作成することになる。どんなソフトウェアシステムであっても、そのシステムを取り囲む世界に対してどのように適合しているかを表現する、システムコンテキストの図を作るだろう。これに対し、システム境界を拡大して内側のコンテナーを表現する。コンテナーは、ウェブブラウザーで動作するシングルページアプリケーションやサーバーサイドウェブアプリケーション、単体のマイクロサービス、データベーススキーマ、などの展開可能であり実行可能なものである。有用であれば、各コンテナーをさらに拡大して内側のコンポーネントを表現することができる。最終的に、オプショナルだが、各コンポーネントをさらに拡大すると、それらを構成するコードレベルの要素（クラス、インターフェイス、関数、オブジェクトなど）を表現できる。 C4 モデルは表記方法に依存しない。私はよくシンプルな "ボックスと線" で表記するが、何らかの UML を用いても構わない。
より多くの情報、動画、サンプル図、そしてツールのリンクは c4model.com にある。もしあなたのチームがソフトウェアアーキテクチャの会話に困っていたり、ホワイトボードや Wiki に書いた図が意味を成さなかったりしていたら、確実に価値があることだろう。
5. 良いソフトウェアアーキテクチャはアジリティを可能にする
"アーキテクチャ" と "アジャイル" に関して依然としてよくある思い違いは、それらが互いに相反するものである、とするものだ。しかしこれは単純に誤りである。対称的に、良いソフトウェアアーキテクチャはアジリティを可能にし、要求やビジネスプロセスなどの変化を受け入れ、実装に移すことに役立つ。何が "良いアーキテクチャ" として考えられているかは、やはり議論の余地があるが、私にとっては、良いアーキテクチャの核となる特徴は、適切な分解戦略に基づいて凝集度が高められているか、ということだ。もしあなたが、コードベースに分割することができるように見えない、既存の大きな泥だんごに大規模な変更を行う辛さを経験していたとしたら、良く構造化された（凝集度の高い）コードベースを保つことが重要であると認めるだろう。
私が見るに、今日のチームにとっての大きな問題は George Fairbanks 氏が彼の著作 Just Enough Software Architecture で "architecture indefferent design (アーキテクチャに関心をもたない設計)" と表現したものだ。言い換えると、彼らはトレードオフを十分に検討せずに何らかのアーキテクチャスタイルを採用している、ということだ。これは今日の世界では、既存のモノリシックなコードベースがめちゃくちゃであるということに単純に反発したいがために、マイクロサービスのアーキテクチャスタイルを採用しているチームによくあてはまる。笑い話だが、こうしたチームにはその後 "分散された大きな泥だんご" を作ってしまう。そしてソフトウェア設計と分解のプロセスこそが重要であり、モノリシックかマイクロサービスアーキテクチャかは関係無いということに気づくのである。アジリティと良い設計はただでは手に入らない。自覚的な努力と、トレードオフの考慮が必要である。これは、出発点とある程度の事前の設計を用意することがなぜ決定的な意味を持つかの理由だ。
著者について
Simon Brown氏はソフトウェアアーキテクチャを専門とする独立コンサルタントであり、"Software Architecture for Developers"（ソフトウェアアーキテクチャ、技術的リーダーシップ、そしてアジリティとのバランスととることに関する開発者フレンドリーなガイド）の著者である。彼はコードのマップを作成するシンプルなアプローチである C4 ソフトウェアアーキテクチャモデルの開発者でもある。Simon 氏は国際的なソフトウェア開発のカンファレンスにも定期的に登壇し、組織の可視化とソフトウェアアーキテクチャのドキュメンテーションのために世界中を旅している。