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

[PeterEeles（レベル：初級 IBMシニアITアーキテクト），＠IT]

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

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

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

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

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

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

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

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

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

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

図3 異なる用語の範囲

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

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

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

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

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

---

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

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）