ソフトウェアアーキテクチャーって何なの？（後編）：The Rational Edge（2/2 ページ）

[Peter Eeles，＠IT]

アーキテクチャーはチーム構造に影響を与える

　アーキテクチャーは、所定の関心事に対応する関連要素の一貫したグループ分けを定義する。例えば、注文処理システムのアーキテクチャーは、受注要素、アカウント管理、顧客管理、注文処理、外部システムとの統合、持続性、およびセキュリティのグループ分けを定義する。

　これらのグループ分けには、それぞれ異なるスキルセットが必要になる。従って、いったんアーキテクチャーを定義したら、ソフトウェア開発チームの構造をそれに合わせることが完全に理にかなう。しかし、アーキテクチャーが当初のチーム構造の影響を受けたり、その逆のケースも多々ある。この落とし穴は、一般的にはとても理想的とはいえないアーキテクチャーに結びつくため、回避することが最も好ましい。「Conwayの法則」には、「4 つのグループにコンパイラを開発させると4パスコンパイラができ上がる」とある。実際には、アーキテクチャーを作成している組織を反映したアーキテクチャーを意図せず作成する場合が多い。

　しかし、純粋に事務的な理由から、既存のチーム構造と利用可能なスキルが可能なことを大幅に制約し、設計者がこれを考慮に入れる必要があるため、この多少理想化された見方が常に現実的ではないことも真実だ。

アーキテクチャーはどのシステムにもある

　正式に文書化されていなかったり、システムが極めてシンプルで要素が1つしかなくても、どのシステムにもアーキテクチャーが存在することは注目に値する。通常、アーキテクチャーを文書化することはかなり有益なことだ。アーキテクチャーは文書化されていた方が、されていないより慎重に検討され、結果的により効率的になる。アーキテクチャーの記録プロセスが、当然ながら配慮の行き届いた検討に結びつくためだ。

　逆に、アーキテクチャーが文書化されていないと、これが規定された要件を保守性や最優良事例への適応といった対応品質の点で満たすことは（不可能でなくとも）難しくなる。既存の大半のアーキテクチャーは文書化されていないと思われるが、これらは意図的というより偶発的なものだ。

アーキテクチャーには特定の範囲がある

　アーキテクチャーにはさまざまな種類があり、最も有名なものが土木工事などの各種建造物の構造に関連するものだ。ソフトウェアエンジニアリングの分野でさえ、さまざまな形式のアーキテクチャーを目にするようになる。例えば、ソフトウェアアーキテクチャーのコンセプトのほかにも、エンタープライズアーキテクチャー、システムアーキテクチャー、構成アーキテクチャー、情報アーキテクチャー、ハードウェアアーキテクチャー、アプリケーションアーキテクチャー、インフラアーキテクチャーなどのコンセプトがある。これからは、設計作業の具体的な範囲を定義するほかの用語も目にするようになるだろう。

　残念ながら、業界にはこれらの用語の意味についても、相互関連についても一致した定義がなく、その結果、同じ用語が異なる意味を持っていたり（同音異義語）、複数の用語が同じ意味を持っていたりする（同義語）。しかし、これらの用語の範囲は図3から推論できる。この図と以下の説明を見れば、納得できないものや自社では使っていないものも必ず出てくる。しかし、これらの用語が業界に実際に存在することと、そこに一致した意味がないことを示すことが肝心なのだ。

図3 異なる用語の範囲

　図3は以下の要素を示している。

• ソフトウェアアーキテクチャーは本稿の最大の焦点であり、すでに定義済み
• ハードウェアアーキテクチャーはCPU、メモリ、ハードディスク、プリンタなどの周辺機器などの要素や、これらの要素を接続する要素を考慮する
• 構成アーキテクチャーは、ビジネスプロセス、組織の構造、役割や責務、そして組織の中核業務に関連する要素を考慮する
• 情報アーキテクチャーは、情報を整理する構造を考慮する
• ソフトウェアアーキテクチャー、ハードウェアアーキテクチャー、構成アーキテクチャー、および情報アーキテクチャーは、本章で先に説明したとおり、いずれもシステムアーキテクチャー全体のサブセットである
• エンタープライズアーキテクチャーは、ハードウェア、ソフトウェア、および人員などの要素を考慮する点でシステムアーキテクチャーと同じものである。しかし、エンタープライズアーキテクチャーの方が事業目的達成を重視し、ビジネスの俊敏性や組織の効率性などを考慮する点で業務との結びつきが強い。エンタープライズアーキテクチャーの範囲は会社をまたぐ場合もある

　予想されるとおり、設計者（ソフトウェア設計者やハードウェア設計者など）とアーキテクティング（ソフトウェアアーキテクティングやハードウェアアーキテクティングなど）のように対応した形式がある。

　これらの定義を見てきたが、答えの出ていない問題も多い。エンタープライズアーキテクチャーとシステムアーキテクチャーの違いは何だろうか？　エンタープライズはシステムなのか？　情報アーキテクチャーは、データに対する要求の高いソフトウェアアプリケーションの一部で見られるデータアーキテクチャーと同じなのだろうか？　残念ながら、これらの疑問に対する一致した答えはない。

　いまのところは、このように異なる定義が存在するものの、これらの用語やその関連については業界に一貫した定義がないことだけ認識しておきたい。従って、自分が所属する組織に関連する用語を選択し、これを適切に定義しておくことを推奨する。こうすれば、少なくとも一定の整合性を実現し、コミュニケーションミスの可能性を削減することができる。

---

　本稿は、ソフトウェアアーキテクチャーの核となる特性の定義に重点を置いてきた。しかし、まだ答えの出ていない疑問が多く残っている。ソフトウェア設計者の役割は何だろうか？　 設計者が関係する重要な作業は何だろうか？「アーキテクティング」のメリットは何だろうか？　これらをはじめとするさまざまな疑問には、本シリーズの続きで答えていく。

要約

つまり、ソフトウェアアーキテクチャーとは何なのか。アーキテクチャーとは構造を定義するものである。そして、ソフトウェアの動作を定義するのもアーキテクチャーである。さらに、ソフトウェア全体の中で重要な要素に重点を置くのがアーキテクチャーだ。

アーキテクチャーは利害関係者のニーズのバランスを取る。アーキテクチャーは論理的根拠に基づく判断を具体化する。アーキテクチャーはアーキテクチャースタイルに準拠できる。アーキテクチャーはその環境の影響を受ける。アーキテクチャーはチーム構造に影響を与える。アーキテクチャーはどのシステムにもある。アーキテクチャーには特定の範囲がある。

アーキテクチャーの定義を固めるために、その特徴を挙げていくとこういう感じになる。一言でまとめるのは難しい。つまり、ソフトウェアアーキテクチャーとは、上記のような要素をあわせ持ったものだということができるのである。