3.1 アーキテクチャの基礎

概要と動機

ソフトウェアアーキテクチャとは、変更にコストがかかる重要な設計上の決定の集合です。主要なコンポーネントの構造、それらの間の関係、そしてシステム全体が示さなければならない性質。多くの人が一つの一貫した製品を築けるようにする、共有された頭の中のモデルだと考えてください。小さなチームでは、アーキテクチャは少数の頭の中に住み、進めながら進化できます。大きな組織(何百人ものエンジニア、数十のチーム、複数の製品、何年ものロードマップ)では、アーキテクチャは全員の足並みを揃えるものになります。それが明確なら、チームは衝突せずに独立して動きます。曖昧なら、あらゆるチーム間の依存が交渉になり、あらゆるインシデントが考古学のプロジェクトになります。

企業と政府にとって、基礎はさらに重要です。システムが長寿命で、厳しく規制され、部門間で共有されるからです。税のシステム、給付のプラットフォーム、国の医療記録、銀行の中核の元帳は、それを築いた人々のキャリアより長生きします。結合、データのオーナーシップ、品質特性について今日下す決定は、十年以上にわたって、何が可能かを制約します。規制当局と監査人は、文書化された擁護できるアーキテクチャを、ますます期待しています。信頼性、セキュリティ、プライバシー、アクセシビリティが後付けではなく設計に組み込まれたという証拠。基礎を正しくやることは、学術的なことではありません。新しい義務づけに適応するプラットフォームと、ゼロから作り直さなければならないプラットフォームの違いです。

本章は、技術の流行より長持ちする持続的な基礎を扱います。品質特性(「〜性」)、アーキテクチャ上重要な要求、フィットネス関数と進化的アーキテクチャ、C4とarc42による軽量なドキュメント、そして構造化されたトレードオフ分析。これらは、大きなチームが偶然ではなく意図してアーキテクチャについて推論できるようにする道具です。

主要原則

アーキテクチャはトレードオフであり、正解ではない。 すべての重要な決定は、一つの品質を別のものと交換します。仕事は、それらの取引を意図して、透明に行うことです。
品質特性は要求である。 性能、可用性、セキュリティ、保守性は、機能と同じ厳密さで規定しなければ、締め切りの圧力のもとで犠牲にされます。
すべての要求がアーキテクチャ上重要なわけではない。 乏しい設計の注意を、構造を形づくり、変更が難しく、リスクの高い要求に集中させます。
アーキテクチャは進化できなければならない。 知識は最初が最も少ないため、大きな事前設計は失敗します。漸進的に設計し、主要な性質を自動のチェックで守ります。
図だけでなく、決定を文書化する。 選択の背後にある推論(と却下された選択肢)は、結果の絵よりも価値があります。
作らなかった人にもアーキテクチャを読めるようにする。 新しく加わった人、監査人、将来の保守担当者が、意図を再構成できなければなりません。
できる決定は先送りし、しなければならない決定は下す。 変更が安い所では選択肢を開いたままにし、遅いコミットメントが高くつく所でのみ、早くコミットします。

推奨事項

品質特性を測定可能なシナリオとして規定する

「システムは速くあるべき」や「高可用であるべき」のような漠然とした目標は、テストも徹底もできません。代わりに、各品質特性を、刺激、文脈、測定可能な応答を伴う具体的なシナリオとして書きます。「同時ユーザー数がピークの5万人に達したとき、検索リクエストの95%が300ミリ秒以内に完了する」。ドメインにとって重要な特性をカバーします。可用性、性能、スケーラビリティ、セキュリティ、保守性、オブザーバビリティ、アクセシビリティ、可搬性、コスト効率。すべてを同時に最大化することはできないので、声に出して順位付けします。最大の一貫性に調整されたシステムは、同時に最大の可用性にもなりません。

アーキテクチャ上重要な要求(ASR)を特定する

ASRを通常の要求から切り分ける時間を取ります。要求がアーキテクチャ上重要なのは、多くのコンポーネントに触れる、満たすのに高価、厳しい制約を課す、あるいは技術的にリスクが高い場合です。規制による義務づけ(データ所在地、保持、監査可能性)、高負荷のシナリオ、記録のレガシーシステムとの統合、厳しいセキュリティ境界は、通常ASRです。それらの短く生きたリストを保ち、主要な設計上の決定をそのリストまでたどれるようにして、レビュアーがアーキテクチャがなぜその形なのかを見られるようにします。

進化的アーキテクチャとフィットネス関数を採用する

アーキテクチャを、固定された設計図ではなく、導かれた方向へ一歩ずつ変わるものとして扱います。フィットネス関数は、特定のアーキテクチャ上の特性が保たれていることの、自動化された客観的なテストです。どのモジュールも禁じられた層からインポートしないというビルド時のチェック、p99レイテンシが回帰したらパイプラインを失敗させる性能テスト、既知の脆弱な依存関係をブロックするセキュリティスキャン、どのサービスも別のサービスのデータベースへの直接接続を持たないことを確認するテスト。フィットネス関数は、アーキテクチャの意図を継続的に徹底されるガードレールに変えます。それは、大きく変化するチームにわたってその意図を生かしておく唯一の方法です。

C4とarc42で文書化する

C4モデルを使って、構造を四つの拡大率(システムコンテキスト、コンテナ、コンポーネント、コード)で記述し、各読み手が自分に合うレベルを読め、単一の図がすべてを語る必要がないようにします。周囲の物語のテンプレートとしてarc42を使います。目標、制約、コンテキスト、解決の戦略、構成要素、実行時のシナリオ、デプロイ、横断的関心事、決定、リスク。個々の決定は、短いアーキテクチャ決定記録(ADR)として記録します。文脈、決定、状態、帰結を、決定ごとに一つのファイルで、コードと並べてバージョン管理します。文書化の習慣を一つだけ採用するなら、ADRにしてください。大きなチームにとって、他の何よりも見返りがあります。

構造化されたトレードオフ分析を実施し、リスクで設計を駆動する

賭け金の高いシステムには、アーキテクチャトレードオフ分析手法(ATAM)のような手法を使い、候補のアーキテクチャを優先順位付けされた品質特性のシナリオに対して量ります。それは感度点(決定が一つの特性に強く影響する所)とトレードオフ点(複数に影響する所)を表面化します。より軽い方法として、リスク駆動の設計を採用します。設計の労力をリスクに比例させて使う。低リスクで十分に理解された部分には、ほとんど儀式は要りません。新奇で、影響が大きく、不可逆な決定は、プロトタイプ、スパイク、正式なレビューに値します。

トレードオフ: 長所と短所

アプローチ	長所	短所
重い事前のアーキテクチャ	調整の明確さ。固定スコープのプログラムで後の驚きが少ない	知識が最も少ないときに決定する。遅い。変更に脆い
創発的 / 進化的アーキテクチャ	学びに適応する。無駄が少ない。速いデリバリーを支える	フィットネス関数がないとずれるリスク。強いエンジニアリングの規律が必要
ATAM型の正式な評価	厳密で監査可能。隠れた衝突を表面化する	時間と専門性を要する。小さな変更には過剰
軽量なADR + C4	安く、読みやすく、漸進的。多くのチームにスケールする	最新に保つ規律の分だけ良いものになる

中心的な緊張は、確実性と適応性の間にあります。固定価格の政府のプログラムや安全が重要なシステムは、後の変更や失敗のコストが莫大なので、より多くの事前の厳密さと正式な評価に傾きます。動きの速い製品組織は、自動化に守られた進化的アプローチに傾きます。ほとんどの大きな組織は両方を必要とします。不可逆で影響の大きい決定と横断的関心事にはより重いガバナンス、それ以外のあらゆる所ではより軽く創発的な設計。両極端はそれぞれの形で失敗します。過剰なアーキテクチャは何年も無駄にして何も届けず、不十分なアーキテクチャは、スケールも監査もできない絡まりを生みます。

チームで議論すべき問い

二つの品質特性が負荷のもとで衝突したとき、どちらが勝ち、その優先順位を書き留めていますか。 すべてのアーキテクチャはトレードオフを強います。最大の一貫性は可用性を損ない、厳格なセキュリティはレイテンシを加え、積極的なキャッシュは監査可能性と戦います。大きなチームでは、危険は、異なるスクワッドが静かに異なる優先順位を想定し、一つがスループットのために最適化する一方、別のものが厳格な一貫性を守り、衝突がインシデントの間にしか表面化しないことです。企業や政府の設定では、規制当局がどの特性を守りなぜかを尋ねるので、順位付けは民間伝承ではなく、明示的で擁護できるものでなければなりません。品質特性のシナリオを持ち込み、順序が曖昧でなくなるまで、声に出して、二つずつ互いに順位付けしてください。それから勝者をフィットネス関数として符号化し、優先順位が締め切りの圧力のもとで浸食されずに保たれるようにします。
最近の決定のうち、どれが一方通行の扉で、両開きの扉より多くの精査を受けましたか。 リスク駆動の設計は、設計の労力を、決定を元に戻すのがどれだけ難しいかに比例して使うと言いますが、ほとんどのチームはあらゆる変更をほぼ同じ儀式でレビューします。それは安く可逆な選択に注意を無駄にし、不可逆なもの(法的な記録に焼き込まれたデータモデル、公開APIの契約、中核のデータストア)が、不十分な異議申し立てで通り抜けます。先四半期の重要な決定を取り出して可逆性で分類し、不可逆なものがプロトタイプ、スパイク、正式なレビューを得たかを問ってください。長寿命の企業や政府のシステムでは、間違った一方通行の扉のコストは十年にわたって複利で増えるので、追加の厳密さは何倍も見返りがあります。プロセスの重さを、差分の大きさではなく、決定の可逆性に合わせてください。
次の賭け金の高い、元に戻しにくい決定に、誰が部屋にいる必要があり、どのシナリオに対して選択肢を採点しますか。 ATAM型の構造化されたトレードオフのレビューは、決定が不可逆で、いくつかの品質特性に同時に触れるときに、そのコストに見合い、その力は、そこにいる人々から来ます。デリバリー、セキュリティ、運用、そして結果を感じる方針やビジネスの担当者。その声の一つを飛ばせば、キャッシュの選択が監査可能性の要求を静かに壊しうるように、ビルドの後に衝突を発見します。優先順位付けされた品質特性のシナリオを採点の基準として持ち込み、一つの選択肢が単一の特性を大きく振る感度点と、複数に動かすトレードオフ点を探してください。求める成果は、却下した選択肢とその理由を記録する短いADRで、推論がそれを行った人々より長生きするようにします。これを正当化する今後の決定がないように見えるなら、それ自体が確かめる価値があります。不可逆な決定が地平線にない大きなプログラムは、たいてい十分先を見ていないからです。
新しく加わった人や外部の監査人が、書かれたアーキテクチャだけを持っていたとして、システムがなぜその形かを再構成でき、最後にそれをテストしたのはいつですか。少数の上級者の頭の中にあるアーキテクチャは単一障害点です。その人々が異動すれば、元に戻しにくいあらゆる決定の背後の推論も一緒に去り、次のチームはインシデントを通じてそれを学び直します。大きな組織にとって、アーキテクチャの読みやすさ(現実に合うC4の図、arc42の物語、却下された選択肢を記録するADR)が、数十のチームが会議なしに同じシステムについて推論できるようにするものです。最近のADRと現在の図を、コンポーネントを作っていない誰かに渡し、人に尋ねなければならなくなるまでにどこまで進むかを見てください。企業や政府の設定では、監査人がまさにこの演習を行い、去年のシステムを記述するドキュメントは、認証しなければならない人々をまさに誤解させるので、ないよりも悪いものです。書かれた記録の鮮度を測定可能な性質として扱い、それを真実に保つ背後に、フィットネス関数かレビューの周期を置いてください。
アーキテクチャ上の特性のうち、今日自動のフィットネス関数で守られているものはどれで、まだ全員がルールを覚えていることに頼っているものはどれですか。ウィキのページやレビュアーの記憶にだけ住む意図は、締め切りが来た瞬間に浸食されます。層のルール、共有データベースなしの境界、レイテンシの予算こそが、圧力のもとのチームが削るものだからです。大きく速く変わるコードベースでは、生き延びる唯一の意図は、ビルドが徹底する意図なので、主張する特性と実際にチェックする特性のギャップが、本当のアーキテクチャ上のリスクです。重要な特性を一覧にし、それぞれを徹底されている、手作業でレビューされている、守られていないのどれかに印を付け、フィットネス関数ならもっと早く捉えられたずれをレビューが捉えた直近の三回を持ち込んでください。規制された公共のシステムでは、これが二重に重要です。規制当局は、データ所在地や監査可能性を意図したかではなく、それが継続的に成り立ったことをどう証明するかを尋ねるので、緑のパイプラインは方針の文書よりはるかに強い答えです。失敗が起こりやすく高価な特性の自動化を優先し、一部は手作業のままであることを受け入れます。
要求がアーキテクチャ上重要かどうかを誰が判断し、ASRのリストがすべてにも何にもならないようにするにはどうしますか。 アーキテクチャ上重要な要求を名指しする価値は、選択性から来ます。すべての要求を重要として扱えば設計は止まり、何も重要として扱わなければ、構造的でリスクの高い、変更しにくいものが、守られずに通り抜けます。大きなチームでは、各スクワッドに局所的に決めさせたくなる誘惑があり、それは一貫しない基準と、あるグループの「軽微な」選択が別のグループの構造を制約するときのチーム間の驚きを生みます。現在のASRのリスト、使った基準(多くのコンポーネントに触れる、満たすのに高価、厳しい制約、技術的にリスクが高い)、境界を声に出して試すいくつかの境界線上の要求を持ち込んでください。企業や政府では、データ所在地、保持、監査可能性のような規制による義務づけはほぼ常に重要で交渉不可能なので、リストを誰が所有し、どうレビューされ、ASRを加えたり落としたりする決定がどう記録されるかを名指ししてください。誰も統治しないASRは、精査のもとで誰も擁護しない要求だからです。

セクター別の視点

スタートアップ。 儀式をほぼゼロに、記録をほぼ完全に保ってください。正式なATAMのワークショップと重いテンプレートは省きますが、それでも元に戻すのが苦痛な選択(データストア、モノリスかサービスか、認証プロバイダー)について、十数個の短いADRを書き、最初の顧客が実際に感じる二、三の品質特性のシナリオを固定します。乏しい資源はエンジニアリングの注意なので、失敗するとあなたを沈める特性、たとえばテナントの隔離だけを守り、それ以外は創発的で変更が安いままにしておきます。

小規模事業者。 専任のアーキテクトはおらず予算も厳しいので、ほとんどコストがかからない基礎に頼ってください。少数の品質特性を具体的な数字で名指しし、元に戻すのに苦労することにはADRを書き、重い構造的な決定は選んだプラットフォームやベンダーに担わせます。特注のインフラを作るより、よくサポートされたスタックを買うことを好み、ベンダーの文書化されたアーキテクチャを、ゼロから著す必要のある制約ではなく、引き継ぐ制約として扱います。

大企業。 課題は、多くのチームと何年ものロードマップにわたる一貫性なので、共有の仕組みに投資します。アーキテクチャのギルド、共通の品質特性のシナリオの集合、コードの隣に保存されたADR、そして規模では一人のレビュアーが取り締まれない境界を徹底するCIのフィットネス関数。不可逆で横断的な決定には構造化されたトレードオフ分析を使い、C4の図を設計レビューの共有の地図として保ち、グループが局所的には妥当でも全体では衝突する選択をしなくなるよう、ASRのリストを中央で統治します。

政府。 長寿命で規制されたシステムは、文書化された擁護できるアーキテクチャを、気の利いたものではなく、調達と説明責任の要件にします。データ所在地、保持、監査可能性、アクセシビリティを、監査人が直接読めるarc42の記述に書き込まれた、アーキテクチャ上重要な要求として扱い、方針とセキュリティの担当者を含む軽いトレードオフのワークショップを実施して、衝突(キャッシュと監査可能性など)がコードの前に紙の上で表面化するようにします。責任ある職員がデューデリジェンスを示せるだけ完全に推論の跡を保ち、公的機関を十年間単一のベンダーに縛りつけるものより、明確な出口の選択肢を持つアーキテクチャを好みます。

事例

スタートアップ。 6人のシード段階のSaaSチームは、アーキテクチャを正式なプロセスではなく共有のドキュメントに保ちますが、元に戻すのが苦痛な決定は書き留めます。約十二個のADRを記録し(なぜドキュメントストアではなくPostgresか、なぜサービスではなくモジュラーモノリスか、なぜその認証プロバイダーか)、初期の顧客に実際に重要な二つの品質特性のシナリオを固定します。「サインアップが2秒以内に完了する」と「どの顧客も他のテナントのデータを読めない」。7人目と8人目のエンジニアを雇ったとき、それらのメモのおかげで新人は、物事がなぜそうなっているのかを尋ねて全員を中断する代わりに、最初の週に出荷できます。

大企業。 多国籍の銀行が12の地域の決済システムを統合するために、小さなアーキテクチャのギルドを立ち上げます。ギルドは八つの品質特性のシナリオ(「毎秒1万トランザクションを一つも失わずに処理する」と「リージョンを15分で復旧する」を含む)を定義し、約四十のADRを記録し、継続的インテグレーション(CI)でフィットネス関数を徹底します。どのサービスも別のドメインのデータベースに書き込めず、すべてのサービス間の呼び出しは追跡されなければならず、重大なCVE(共通脆弱性識別子)を持つ依存関係はビルドを失敗させる。C4のコンテキストとコンテナの図が、あらゆる設計レビューの共有の地図になり、チーム間の統合の論争は大きく減ります。

政府。 国の機関が給付のプラットフォームをモダナイズしており、法律はデータ所在地、7年間の監査可能性、アクセシビリティ適合を保証するよう求めています。アーキテクトはこれらをASRとして扱い、監査人が直接レビューするarc42の記述に書き込みます。デリバリーチーム、セキュリティ、方針の担当者とともに、軽いATAMのワークショップを実施して二つの候補のアーキテクチャを比べ、望ましい設計のキャッシュ戦略が監査可能性の要求と衝突することを発見します。コードの一行を書く前に紙の上でそのトレードオフを捉えたことで、何か月もの手戻りが省かれ、責任ある大臣にデューデリジェンスの文書化された証拠が与えられます。

ビジネスケース: 動機、ROI、TCO

アーキテクチャの基礎の見返りは、おもに避けられたコストなので、予算が付きにくく、飛ばすのは高くつきます。採用のコストはささやかです。数人の経験豊富なアーキテクトの時間、いくつかのワークショップ、文書のテンプレート、フィットネス関数へのCIへの投資で、通常はプログラムの予算の一桁の小さな割合です。それらを採用しないコストは、後で、割増で届きます。規定されなかった品質特性が本番で失敗したときの手戻り、文書化されていない結合が義務づけられた変更をブロックしたときの緊急の再プラットフォーム化、誰もシステムを理解していないための長引くインシデント、デリバリーを止めたり罰金を引き起こしたりする失敗した監査。

リーダーシップには、選択肢の価値とリスクを軸に論拠を示してください。良いアーキテクチャの基礎は、将来の変更のコスト(十年のシステムの寿命にわたるデリバリー速度と総所有コストへの直接のてこ)を下げ、深刻なインシデントの頻度と長さを減らし、規制当局と監査人が今や求める文書の跡を生み出します。ADRの習慣だけで、新しい経営陣が「なぜこれをこう作ったのか」と問い、法医学的な調査ではなく数分で答えを得た最初のときに元が取れます。できる所では数字を付けてください。避けられた一回の大きな再アーキテクチャや一回の失敗した監査のコストを、その実践の小さな継続的なコストと量ります。

アンチパターンと落とし穴

象牙の塔のアーキテクチャ。 図を作るがコードに触れず、デリバリーチームと話さないアーキテクト。その設計は無視されるか、作れません。
形容詞としての品質特性。 数字もシナリオもなく、したがって検証もトレードオフもできない「スケーラブルで、安全で、信頼できる」。
大きな事前設計。 理解が最も弱いときに決定を固定して、最初のコードの一行の前にすべての詳細にコミットすること。
嘘をつくドキュメント。 去年のシステムを記述する図。誤解させるので、ないよりも悪いものです。
履歴書駆動の設計。 ASRを満たすためではなく、キャリアを築くために技術を選ぶこと。
金メッキ。 要求が決して求めなかった規模、柔軟性、一般性のために設計し、コストと複雑さを恒久的に加えること。
アーキテクチャ上のガードレールがない。 大きなチームにわたって構造を保つために、フィットネス関数ではなく善意に頼ること。

成熟度モデル

レベル1: 開始。 アーキテクチャは暗黙的で、個人の頭の中に住んでいます。文書化された品質特性も、ADRも、共有された図もありません。構造はインシデントの間に発見され、あらゆるチーム間の依存は、ゼロから再交渉されます。
レベル2: 発展。 一部のチームは、元に戻すのが痛い決定を書き留め、主要な図をスケッチしますが、実践は一貫しません。あるスクワッドはADRを保ち、別のスクワッドはまったく保たず、品質特性は測定可能なシナリオではなく形容詞として名指しされ、ドキュメントはプロジェクト間で古くなります。
レベル3: 標準化。 品質特性のシナリオとアーキテクチャ上重要な要求が、文書化された組織全体の標準に規定され優先順位付けされています。ADRは日常的でコードの隣に保存され、C4とarc42のドキュメントは共通のテンプレートに維持され、重要な決定には、すべてのチームで構造化されたトレードオフのレビューが求められます。
レベル4: 管理。 アーキテクチャは主張されるのではなく、ベースラインに対して測定されます。CIのフィットネス関数が、p99レイテンシ、層の違反、追跡されない呼び出し、脆弱な依存関係のような特性を報告し、ADRのカバレッジとドキュメントの鮮度が指標として追跡され、トレードオフのレビューが優先順位付けされたシナリオに照らして選択肢を採点し、合意されたベースラインからのずれは、驚きではなく定義された対応を引き起こします。監査人は物語だけでなく、測定された証拠に頼れます。
レベル5: オーケストレーション。 アーキテクチャは、組織全体で継続的かつ適応的に進化します。フィットネス関数とインシデントのデータが、どの特性が重要で設計の労力がどこに向かうかにフィードバックされ、ASRのリスト、品質特性の優先順位、ガードレールは、義務づけとリスクの変化に応じて見直され、実践はデリバリー、セキュリティ、リスクの計画と統合されるので、プラットフォームはゼロから作り直されるのではなく、新しい要求に適応します。

議論のためのアイデア

最も重要なシステムにとって、本当に交渉不可能な三つの品質特性はどれで、それぞれを今日、測定可能なシナリオとして述べられますか。
決定が、ADRに値するだけアーキテクチャ上重要か、ただ行えばよいかを、どう判断しますか。
現在のコードレビューが見逃すずれを、フィットネス関数はどこで捉えますか。
あなたの組織は過剰にアーキテクチャしていますか、不十分にアーキテクチャしていますか。そして、どちらかを教える証拠は何ですか。
チームのチームという構造で、アーキテクチャの責任は誰にあり、象牙の塔と完全な無政府状態の両方をどう避けますか。
外部の監査人は、今日書き留められているものから、アーキテクチャの意図をどう再構成しますか。

要点

アーキテクチャは、元に戻すのが高くつく決定の集合です。それらのトレードオフを意図して行い、記録します。
品質特性を測定可能なシナリオとして規定し、構造を形づくるアーキテクチャ上重要な要求を特定します。
漸進的に設計し、主要なアーキテクチャ上の特性を自動のフィットネス関数で守ります。
C4の図、arc42の物語、コードの隣に保たれた決定ごとのADRで、軽く、しかし真実に文書化します。
厳密さをリスクに合わせます。不可逆で影響の大きい決定には重い分析、それ以外のあらゆる所には軽いプロセス。
ビジネスケースは、避けられた手戻り、短いインシデント、速い将来の変更、監査に備えた証拠です。

参考文献とさらなる読み物

Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures
Simon Brown, Software Architecture for Developers (and the C4 model)
Mark Richards and Neal Ford, Fundamentals of Software Architecture
George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
Michael Nygard, “Documenting Architecture Decisions” (the ADR pattern)
Gernot Starke and Peter Hruschka, arc42 documentation template
Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
ISO/IEC 25010, Systems and software quality models