「アーキテクチャ」という言葉は便利すぎる – 定義しなければ会話は成立しない

「アーキテクチャを理解していますか」と聞かれることがあります。技術者同士の会話では、それらしい確認に見えるかもしれません。しかし、この質問はそのままではかなり雑です。何のアーキテクチャなのかが分からず、理解するとは既存の構造を説明できることなのか、要求や制約から構造を設計できることなのかも分かりません。

アーキテクチャという言葉は便利です。便利であるがゆえに、対象や意味を明確にしないまま使うと、話している人同士が別のものを想像したまま会話が進みます。高度な言葉を使っているようで、実際には確認すべきことを曖昧にしているだけの場合があります。

この記事では、アーキテクチャを「対象を構成する要素と、その関係、境界、原則を定めた構造」として扱います。ただし、この定義だけではまだ足りません。アーキテクチャについて会話するなら、何の、どの範囲の、どの抽象度の、どの観点のアーキテクチャなのかを定義しなければなりません。

アーキテクチャは構成図ではない

アーキテクチャを構成要素の一覧や構成図と同じものとして扱うと、議論が薄くなります。構成図は、ある時点の要素と接続を表すには有用です。しかし、なぜその要素に分けたのか、どこに境界を置いたのか、どの依存関係を許容したのか、何を維持する原則にしたのかまでは、図だけでは説明できません。

含まれるもの	確認すべきこと
要素	何に分割し、それぞれが何を担うのか
責務	どの要素が、どの判断や状態を所有するのか
境界	どこから先を別の責務、別の変更単位、別の障害ドメインとして扱うのか
関係	どの依存関係を許容し、どの依存関係を禁止するのか
原則	構造を維持するために、どの判断基準を置くのか
トレードオフ	性能、可用性、複雑性、コスト、変更容易性のどこに重みを置くのか

つまり、アーキテクチャを語るなら、構成だけでなく判断を語る必要があります。構成要素を並べるだけなら説明資料です。なぜその構造でなければならないのかを示して初めて、アーキテクチャの話になります。

アーキテクチャはシステムだけの言葉ではない

IT の世界ではアーキテクチャという言葉が頻繁に使われるため、システム設計の言葉のように感じることがあります。しかし、アーキテクチャはシステムだけの言葉ではありません。ビジネス、組織、情報、データ、セキュリティ、ネットワーク、インフラストラクチャー、アプリケーションなど、さまざまな対象に対して使われます。

• Business Architecture
• Enterprise Architecture
• Organization Architecture
• Information Architecture
• System Architecture
• Software Architecture
• Application Architecture
• Infrastructure Architecture
• Network Architecture
• Security Architecture
• Data Architecture
• Solution Architecture

したがって、「アーキテクチャを理解していますか」という質問には、まず何のアーキテクチャですか、という確認が必要です。この確認を省いたまま返答を求めるなら、質問した側が自分の頭の中の対象を勝手に前提化しているだけです。

分野を指定してもまだ足りない

さらに厄介なのは、修飾語を付ければ意味が一意になるわけでもないことです。たとえば Network Architecture と言っても、企業全体の WAN 構造なのか、データセンター内部のネットワークなのか、特定サービスを構成するネットワークなのかによって対象は異なります。

同じ対象でも、抽象度によって見えるものは変わります。経営層へ説明する全体構造、設計レビューで扱う責務境界、障害対応で見る経路制御、運用手順へ落とす設定単位は同じではありません。アーキテクチャという言葉を使うなら、少なくとも分野、対象、抽象度、観点を明示する必要があります。

軸	曖昧な言い方	会話できる言い方
分野	ネットワークアーキテクチャ	サービス基盤のネットワークアーキテクチャ
対象	基盤全体	顧客向け API 基盤の east-west 通信
抽象度	全体構成	障害ドメインと経路制御の設計単位
観点	良い構成か	障害時の切り離しと運用変更の影響範囲

「このサービス基盤のネットワークアーキテクチャについて、障害ドメインと経路制御の観点から考える」と言えば、ようやく議論の対象が見えます。ここまで具体化しなければ、同じ言葉を使っていても別の話をしている可能性があります。

理解しているという言葉も一つではない

「アーキテクチャを理解している」という表現も、同じくらい曖昧です。既存のアーキテクチャ資料を読み、構成を説明できれば理解していると言うことはできます。しかし、それは利用できること、変更できること、選定できること、設計できることと同じではありません。

関与段階	実際に求められる能力
理解	既存構造、要素、関係、前提を説明できる
利用	決められた構造の中で、正しく使える
適用	リファレンスアーキテクチャや既存パターンを対象環境へ合わせられる
変更	既存構造を壊さず、影響範囲を理解して変えられる
選定	複数の構造や製品候補から、要求と制約に合うものを選べる
設計	要求、制約、境界、責務、依存関係、トレードオフを定義して構造を作れる

これらはすべてアーキテクチャに関わる能力ですが、同じ能力ではありません。既存の構造を説明できる人に、要求が曖昧な状態から境界と責務を設計できることまで期待するのは乱暴です。反対に、設計できる人であっても、特定製品のリファレンス構成を細部まで暗記しているとは限りません。

リファレンスアーキテクチャを使うことと設計することは違う

リファレンスアーキテクチャは有用です。過去の知見が整理され、一般的に成立しやすい構造が提示されています。ゼロからすべてを考える必要を減らし、設計品質を一定以上に引き上げる役割もあります。

しかし、リファレンスアーキテクチャを利用した経験と、アーキテクチャそのものを設計した経験は区別すべきです。リファレンスアーキテクチャには、想定規模、障害モデル、運用方法、組織構造、製品、コスト、性能、セキュリティ要件など、多くの前提が含まれています。利用者は、その前提の中で構成を実現できます。

一方で、アーキテクチャを設計する側では、その前提自体を問い直す必要があります。なぜこの境界なのか、なぜこの依存関係を許容するのか、どこを障害ドメインとするのか、何を一貫性の単位とするのか、将来条件が変わった場合にどこまで構造を維持できるのか。こうした判断を積み重ねて構造が形成されます。

既存アーキテクチャを理解できることと、アーキテクチャを設計できることは別の能力です。上下関係の話ではありません。必要な能力が違うだけです。この区別をしないまま「アーキテクチャ経験がありますか」と聞いても、確認したい能力には届きません。

本当に確認したいなら判断理由を聞けばよい

能力を確認したいなら、「アーキテクチャを理解していますか」と聞くより、具体的な設計判断を聞いた方がよほど分かります。アーキテクチャには必ず選択があり、選択がある以上、そこには理由があり、同時に捨てた選択肢があります。

• なぜこの境界をここに置いたのか
• どの範囲を一つの障害ドメインとしているのか
• この依存関係を許容した理由は何か
• 要求が変わった場合、どこを変更する必要があるのか
• この構造にしたことで、何を諦めたのか
• 将来の変更に対して、どこを固定し、どこを差し替え可能にしたのか

こうした問いに答えられるかどうかを見れば、その人が構造をどの深さで見ているのかは自然と分かります。構成を暗記しているだけなのか、既存パターンを適用できるのか、制約から構造を設計しているのかが見えます。大きな言葉で能力を確認したつもりになるより、判断理由を問う方が正確です。

便利な言葉ほど具体化する

アーキテクチャという言葉が便利であること自体は問題ではありません。システム全体について話すときにも、一つの分野、一つの機能、一つの構造について話すときにも使えます。問題は、便利だからこそ、話し手が自分の頭の中にある意味を相手も共有していると思い込むことです。

「アーキテクチャを考えます」「アーキテクチャをレビューします」「アーキテクチャを理解してください」。どれも、そのままでは対象が曖昧です。何のアーキテクチャなのか、どの対象なのか、どの抽象度なのか、どの観点なのか、理解、利用、適用、変更、選定、設計のどこまでを求めているのかを明確にする必要があります。

むしろ、アーキテクチャという言葉が大きいからこそ、その後ろには修飾語が必要です。言葉を大きくするほど、会話は抽象的になります。抽象的な会話が必要な場面はありますが、対象を定義しない抽象化は、単なる曖昧さです。

まとめ

「アーキテクチャを理解していますか」という質問は、一見すると高度な技術的確認に見えます。しかし、アーキテクチャという言葉の広さを考えると、そのままでは曖昧すぎます。システムに限定しても分野は多く、同じ分野でも対象、抽象度、観点によって意味は変わります。

さらに、理解すること、利用すること、適用すること、変更すること、選定すること、設計することは別の能力です。そこを分けずに一つの言葉へ押し込むと、相手の能力を確認したつもりで、実際には何も確認できていない状態になります。

アーキテクチャという言葉は便利すぎます。便利すぎる言葉ほど、定義しなければ会話は成立しません。何の、どの範囲の、どの抽象度の、どの観点のアーキテクチャなのか。そして、どの関与段階を求めているのか。そこまで明確にして初めて、アーキテクチャについて話す意味があります。

参考書籍

参考資料

• Martin Fowler: Software Architecture Guide
• O'Reilly Japan: ソフトウェアアーキテクチャの基礎

関連する記事