ソフトウェア開発では、アーキテクチャーという言葉が出てきます。 設計と混同されがちな言葉ですが、アーキテクチャーと設計は何が違うのでしょうか？
アーキテクチャーという概念はふわっとしています。
以下に示す考え方はあくまでも、いちシステムアーキテクトとしての私の考え方になります。 より詳細に学びたい場合には、以下の書籍がお勧めです。
アーキテクチャーは「なぜ」を語るもの
アーキテクチャーは元々は建築用語で、建築物の構造や設計法、工法を含めた全体を意味する言葉です。 ITにおいては、目的のITシステムをつくるための設計や、設計方法、実装方法を含めた全体を意味するものと言えるでしょう。
ところで、その設計や設計方法は、どうやって決めればよいでしょうか？ そして、そう決めた根拠はなんでしょうか？
決めるための「なぜ」を明らかにするのがアーキテクチャーになります。
システムとアーキテクチャー
「なぜ」の根拠になるのが、システムの制約です。
システムとは、ユーザーが特定の目的を達成できるように設計された仕組みです。 ITシステムの場合は、主にITで構築されている仕組みのことになります。
システムには、当然ユーザーがいますが、仕組みを動かすための動作環境と、仕組みを提供（つまり開発など）するための運営がないと成り立ちません。
ユーザー - システム - 運営
|
動作環境
システムはこの３つの環境による制約に縛られて存在しています。 つまり、この３つの環境のニーズを満たすものがシステムとなります。
システムを作り上げる際にはこれらの制約を考慮しなければなりませんし、システムが稼働開始してからもこれらの制約は常に発生します。 どの環境のニーズも、ある時点では決まっていたとしても、それが永続的であることはなく、時間と共に変化していきます。 ITシステムの場合、その傾向は特に顕著でしょう。
これらの制約が考慮された設計を実現するのが、システムのアーキテクチャーです。 つまり、これらの制約があるから～この設計なのだ、ということを語ります。
制約から設計に至るまでには、アーキテクチャー特性の決定、アーキテクチャーの決定、設計指針の決定、構造の決定という４つの段階を踏みます。
アーキテクチャーの特性というのは、簡単に言うと非機能要件ですが、もっと広範なものです。 アーキテクチャーの決定というのは、アーキテクチャーの特性を実現するための構造のルールです。 設計指針というのは、アーキテクチャーの特性を満たす設計を決めるためのガイドラインです。 これらに沿った設計を行うことで、システムの制約を満たす設計ができます。
アーキテクチャーとトレードオフ
３つの環境のニーズというのは、基本的には相反するものが多いため、すべての要求を満たすシステムというのは現実的にはありえません。 したがって、必然的にアーキテクチャーはトレードオフとの戦いになります。
同じようなトレードオフに、QCDのトレードオフがありますが、プロジェクト管理の現場では不思議とトレードオフという言葉を聞きません（私はよく言います）。 すべてを必達せよというのが、一般的なプロジェクトの基本の思想になっているからなのかもしれません。 そして（事情はともあれ）それを受け入れる余地があるからでしょう。
システムアーキテクトに求められること
システムアーキテクチャーを設計する人のことをシステムアーキテクトと呼びます。 システムアーキテクトは、先に述べた３つの環境のニーズを満たすアーキテクチャー特性、アーキテクチャー、設計指針を決め、システムを設計します。
まずは、システムの作り方やシステムの構成要素の特性を理解しておく必要があります。 広ければ広いほどよいのは言うまでもありません。
また、技術的な面だけでなく、アーキテクチャー特性を決めるためのビジネス面の理解や、組織の理解、業界の理解といったものも必要になります。 アーキテクチャー特性はトレードオフの塊なので、関係各所と折衝する能力も必要になります。
その上で、それらを全部考慮した最適なシステムを構想する力が必要になります。
この力は、論理的な設計とは少しかけ離れた、ひらめきにも似たものと私は考えています。 未知の未知という言葉がありますが、システムアーキテクトはこれに立ち向かわなければならないからです。
システム開発含め、とにかく多くの様々な経験を積むことが、システムアーキテクトへの道であり、システムアーキテクトであり続けるための方法と言えるでしょう。
