1. 導入
本記事は、ソフトウェアアーキテクチャの基礎（イントロダクション）部分を読んで作った学習ノートを、もう一度読み直し、記事として整理し直したものだ。
新しい主張を足すのではなく、基礎の枠組みを「説明できる形」に整えることを目的とする。
担当システムの構成図を見て、主要な要素や分岐を追うことはできる。
けれど、「なぜこの構成・設計なのか？」と問われると、意図や判断をうまく言語化できない。
本記事では、この詰まりを整理するために、次の2つの問いを順に確かめる。
問い①：ソフトウェアアーキテクチャとは何か？
アーキテクチャを、構造/アーキテクチャ特性(-ilities)/アーキテクチャ決定/設計指針の4つの側面で定義し、「アーキテクチャは構造だけではない」という視点まで含めて整理する。
問い②：ソフトウェアアーキテクトの役割とは何か？
アーキテクトに求められる役割を、8つの期待として整理し、今の自分にとってのアーキテクトの働きの仮の定義とする。
そのうえで最後に、
ソフトウェアアーキテクチャとソフトウェアアーキテクトの実務が「トレードオフ」と「Why（なぜ）」という2つの法則の文脈でどう結びつくかを確認する。
なお、本記事で扱うのは、イントロダクション部分を読んで作った学習ノートに書いた範囲に限る。
まだ自分の言葉にできていない論点は、最後にTODOとして残す。理解したつもりで広げるのではなく、今言えること/言えないことの境界をはっきりさせること自体を、この記事の一部にしたい。
2. ソフトウェアアーキテクチャの4つの側面
この章では、ソフトウェアアーキテクチャを4つの側面（構造/-ilities/決定/設計指針）で定義し、説明のための整理軸として捉える。アーキテクトに何が期待されているか（役割・振る舞い）は、3章の8つの期待で改めて扱う。
4つの側面は、次のとおりである。
- 構造（Structure）：形（何があり、どうつながるか）
- アーキテクチャ特性（Architectural Characteristics）：成功の条件（どうあるべきか）
- アーキテクチャ決定（Architectural Decisions）：守るルール（やってよいこと／いけないこと）
- 設計指針（Design Principles）：日々のよりどころ（望ましいやり方）
これは「どう整理するか」を決める軸＝メタコンセプトであり、実際の設計・意思決定・運用方針を考える実務全体で使える。
2.1 「構造」とは
構造（Structure）とは、採用しているアーキテクチャスタイル、システムがどのようなモジュール／コンポーネント／サービスへ分解されているか、レイヤー構造・依存関係・インターフェースがどのように接続されているかといった点を指す。
2.2 「アーキテクチャ特性（-ility）」とは
アーキテクチャ特性（Architectural Characteristics: -ility）は、機能そのものではなく、システムがうまく成立しているかどうかを決める非機能の成功条件を指す。その中身は、例えばavailability（可用性）、performance（性能）、security（安全性）といった品質特性である。アーキテクチャ特性は、機能とは別の軸にある。
2.３ 「アーキテクチャ決定」とは
アーキテクチャ決定（Architectural Decisions）とは、システムをどのように作らなければならないかを定めるルールや制約であり、「何が許され、何が許されないか」を決めるものである。
そして決定は、その理由（なぜそう決めたか）とセットで書き残すべきである（例：ADR のような形で記録する）。
たとえば「どのレイヤーがデータ層に直接アクセスしてよいか」を決める、といったものがアーキテクチャ決定に当たる。
2.4 「設計指針」とは何か
設計指針（Design Principles）は、チームがシステムをどのように実装するかを導くためのガイドラインである。
アーキテクチャ決定が「やってよいこと／いけないこと」をはっきり定めるルールであるとすれば、設計指針はそのルールのもとで「どのように実装するのが望ましいか」を示すものである。
たとえば「サービス間の通信では、同期呼び出しよりも非同期メッセージングを優先する」といった方針が、設計指針にあたる。
2.5 4つの定義の関係：アーキテクチャは構造だけではない
アーキテクチャは、ただの「箱と線の図」ではなく、部品どうしの関係や、部品の外から見える性質（たとえば性能や障害時のふるまい）まで含む。
だからアーキテクチャを本当に理解するには、構造だけでなく、残りの3つの側面も一緒に見る必要がある。
- アーキテクチャ特性（-ilities）：成功の条件として、何を大事にしているか
- アーキテクチャ決定：何を許し、何を禁止し、その理由は何か
- 設計指針：日々の実装で、どんな方向を望ましいとするのか
たとえば「マイクロサービスを使っている」と言うと、構造についての情報は分かる。しかしそれだけでは、どの -ilities を最優先しているのか、どんな制約があるのか、どんな指針で日々の設計をしているのかは見えない。
4つの側面はそれぞれ別の観点だが、4つを合わせて初めてアーキテクチャの全体像になる。
ここまでが「ソフトウェアアーキテクチャとは何か」の整理であり、次の章では、このアーキテクチャに対してソフトウェアアーキテクトに何が期待されているのかを、8つの期待として整理する。
3. ソフトウェアアーキテクトに求められる8つの期待
ソフトウェアアーキテクトの役割を定義するのは難しい。文献上の説明は「熟練プログラマ」から「会社の技術戦略の責任者」まで幅広く、完璧な役割定義を探そうとするとかえって迷いやすい。
そこで著者は、「役割そのものを決め切ろうとするのではなく、アーキテクトに共通して期待されることを見るべきだ」と述べている。
彼らが提示したのが、次の8つの期待（Eight Core Expectations）である。これは肩書きや組織の違いに関わらず、アーキテクト役割に置かれる共通の期待とされる。
- アーキテクチャ決定を下す
- アーキテクチャを継続的に分析する
- 最新のトレンドを把握し続ける
- 決定の順守を徹底する
- 多様なものに触れ、経験してみる
- 事業ドメインの知識を持っている
- 対人スキルを持っている
- 政治を理解し、かじ取りをする
著者によれば、効果的で成功するアーキテクトであるための第一歩は、これらの期待を理解し、日々の実務で実践することである。
現時点では、私はこの8つの期待を「ソフトウェアアーキテクトが何をする人か」を捉えるための仮の定義として扱う。
3.1 アーキテクチャ決定を下す
「アーキテクチャ決定を下す」とは、チームや部門、組織全体の技術選択を導く重要な決定を定義することを指す。
それは、制約・ルール・設計指針として表現され、特定のツールを全部自分で選ぶこととは異なる。
ただし、拡張性・性能・信頼性など重要な品質を守るために特定の技術やパターンに標準化し、それを固定することもアーキテクチャ決定に含まれる。
3.2 アーキテクチャを継続的に分析する
「アーキテクチャを継続的に分析する」とは、現在のアーキテクチャや技術環境を定期的に評価し、リスクやボトルネック、劣化の兆候を見つけ、必要な変更を提案することを指す。
これにより、システムは時間が経ってもビジネスの要求や重要な品質特性に沿い続けられる。
3.3 最新のトレンドを把握し続ける
「最新のトレンドを把握し続ける」とは、新しい技術や業界の動きを継続的に追い、システムに影響しうる重要な変化を理解・監視し、その洞察を長期的に妥当なアーキテクチャ選択へつなげることを指す。
3.4 決定の順守を徹底する
「決定の順守を徹底する」とは、定義・文書化・共有したアーキテクチャ決定や設計指針が、開発チームで実際に守られているかを継続的に確認し、逸脱があれば正し、意図した品質（拡張性・可用性・性能など）が保たれるようにすることを指す。
3.5 多様なものに触れ、経験してみる
「多様なものに触れ、経験してみる」とは、幅広い技術・フレームワーク・プラットフォーム・実行環境に手を動かして触れており、それぞれの強み・弱みや組み合わせ方を理解し、単一の技術への深いこだわりではなく、広い視野から決定できる状態を指す。
3.6 事業ドメインの知識を持っている
「業務ドメインの知識を持つ」とは、扱う領域の中核概念や用語、指標、業務プロセスを理解し、それを前提に組織の目的に沿ったアーキテクチャを設計できることを指す。
また、技術用語だけでなく、その業界の言葉で関係者と議論できることも含まれる。
3.7 対人スキルを持っている
「対人スキルを持っている」とは、人を通じてアーキテクチャの実装や意思決定を前に進める力を指す。
具体的には、コミュニケーション、協調、場の進行、リーダーシップを通じて関係者を揃え、信頼を作り、対立を解消し、チームがアーキテクチャの方向性を実行できるようにすることを意味する。
3.8 政治を理解し、かじ取りをする
「政治を理解し、かじ取りをする」とは、アーキテクチャ決定がコストや作業、働き方に影響し、必ず反発や交渉を伴うことを前提に、組織内の力関係や利害を見極め、影響力・交渉・合意形成によって決定を受け入れられ、実行まで運ぶことを指す。
3.9 3章小まとめ
以上の8つは、ソフトウェアアーキテクトに共通して期待される中核である。これらを理解し日々の実務で実践することが、効果的で成功するアーキテクトであるための第一歩になる。
現時点では、この8つの期待をソフトウェアアーキテクトの仮の定義として用いる。
次章では、ここまで整理したソフトウェアアーキテクチャとソフトウェアアーキテクトの実務を読み解くうえでの見方として、2つの法則（トレードオフ／Why）を確認する。
4 ソフトウェアアーキテクチャの2つの法則：トレードオフ / Why
2章ではソフトウェアアーキテクチャを4つの側面（構造／-ilities／決定／設計指針）で整理し、3章ではソフトウェアアーキテクトに求められる8つの期待を確認した。
ここからは、それらを説明し、考え、進めていくときの見方として、2つの法則を置く。
4.1 第一法則：ソフトウェアアーキテクチャはトレードオフがすべてである
すべてのアーキテクチャ決定にはトレードオフがある。単純な正解／不正解はなく、「いつでもこうすべき」という解もない。
4.2 第二法則：「どうやって」よりも「なぜ」の方がずっと重要である
「How（どう作ったか）」よりも「Why（なぜそうしたか）」の方が重要である。設計図や構成図は How を示せるが、Why は示せない。
だから、アーキテクチャ決定の理由や前提、そしてトレードオフの状況を、明確にして書き残す必要がある。
4.3 2つの法則が示すもの
2つの法則は、アーキテクチャとアーキテクトの実務を「トレードオフ」と「Why」の文脈で捉え直すための見方である。
これによって、システムの構成や設計を「形」だけでなく「意図」まで含めて整理しやすくなる。
5. 結論
本記事では、ソフトウェアアーキテクチャの基礎（イントロダクション）から作成した学習ノートを手がかりに、次の2つの問いを順に確かめた。
- 問い①：ソフトウェアアーキテクチャとは何か？
- 問い②：ソフトウェアアーキテクトの役割とは何か？
まず問い①について、本記事で整理した暫定的な答えはこうである。
ソフトウェアアーキテクチャは、構造／アーキテクチャ特性（-ilities）／アーキテクチャ決定／設計指針の4つの側面から捉えることで、少なくとも次の点を一貫した枠で説明できるようになる。
- 構造：分解の単位と接続のしかた
- アーキテクチャ特性（-ilities）：成功条件としての非機能
- アーキテクチャ決定：許可／禁止の制約と、そのトレードオフ
- 設計指針：実装判断のガイドラインと、決定との関係
次に問い②について、ソフトウェアアーキテクトの役割は、完璧な定義を無理に定めるのではなく、8つの期待として整理する方が現実的である、というのが本記事の立場である。
現時点ではこの8つを、ソフトウェアアーキテクトが何をする人かを捉えるための仮の定義として扱う。
そして最後に、ソフトウェアアーキテクチャとソフトウェアアーキテクトの実務は、2つの法則の文脈で読み直せる。第一法則が示すように、アーキテクチャの決定には常にトレードオフがあり、単純な正解はない。第二法則が示すように、構成図や設計図が示すのはHowであり、Whyは示せないため、決定の理由や前提、トレードオフの状況を明確にして書き残す必要がある。この2つの法則は、4つの側面と8つの期待を、意図と判断の文脈で捉えるための見方になる。
ただし、この枠組みだけでアーキテクチャのすべてを語り切れるわけではない。 ソフトウェアアーキテクトの8つの期待により、組織・ビジネス・政治的な力学といった外部要因の存在には触れたが、個別の前提がどのように各アーキテクチャ決定に効いたのかまでを説明するところまでは扱っていない。 本記事で扱った4つの側面、8つの期待、2つの法則は、アーキテクチャとアーキテクト実務を破綻なく説明し、考え始めるための最低限の土台である。
今後、担当システムをこの枠で書き出し、「説明できる部分」と「詰まる部分」を分けてみたい。
その差分が、次に補うべき自分のアーキテクチャのTODOになる。
TODO
- Structure の具体例（アーキテクチャスタイル／分解と接続の実例）を、自分の担当システムに当てはめて書けるようにする
- 様々なアーキテクチャ特性を明らかにする
- アーキテクチャ特性を明らかにし、評価する方法を書く
- システムがビジネスニーズを満たしていることを確認するために、各特性をのように計測するか確認する
- 当システムをこの枠で書き出し、「説明できる部分」と「詰まる部分」を分ける
参考文献