AWSのソリューションアーキテクト、ムクンド・ラオ氏は、膨大な製品やサービスの選定でユーザーが混乱する実態を「ビジネスが技術の迷路に迷い込んでいる」と表現する。製品やサービスを選択するための判断軸を持たない中で、ユーザーは個人の意見が混在するユーザーフォーラムや断片的なブログ記事から情報をかき集めて場当たり的に設計の方針を決めようとしているという意味だ。

　さらに、複数のベンダーを並行評価するために長期間の概念実証（PoC）を続け、結局どれも採用判断に至らないまま検証が終わらない企業もあるという。さらに深刻なのは「shiny-new-toy症候群」だ。新技術を追いかけるあまり、問題に無理やりソリューションを当てはめ、非効率なアーキテクチャを拡大し、リソースを浪費し、持続可能性もないという状態だ。

技術を「適者生存」のルールで捉える

　そこでラオ氏が紹介するのは「生き残るのは、最も強い種や最も賢い種ではない。変化に最も適応できるものだ」という言葉だ。この言葉を技術アーキテクチャにも直接適用できると同氏は説明する。

　ラオ氏によると、AWSの利用で成功しているユーザーはモダナイゼーションを継続的に進め、段階的な変化を積み重ねている。逆に失敗するユーザーは「全書き換え」をしているという。つまり、古いシステムを一気にリプレースしようとする考え方だ。その結果、プロジェクトは長期化し、途中で要件が変わり、完成時には設計が陳腐化しているといった事例がある。

テックデット（技術的負債）は財務負債と同じく計画的に管理せよ

　開発の速度を優先し不完全な実装を進める結果、将来的に改修コストや保守負担が増大するというテックデット（技術的負債）もポイントだ。テックデットも金融負債と同じく、計画的に増大するため、意識的に返済していく必要がある。しかし、経営層から「なぜシステムがこれほど維持コストを食うのか」と問われたとき、答えられるようにしておきたい。その問いへの答えを準備するのが、次に紹介するフレームワークの活用だ。

3Cフレームワーク

　AWSのシニアソリューションアーキテクト、スシャンス・マンガロール氏が紹介するのが「3Cフレームワーク」だ。

Capabilities

　「C」の1つ目は「Capabilities」（ケイパビリティ）だ。大きなシステムを「誰が何の目的で使うか」という単位に切り分ける作業だ。切り分けの方法は4つある。

　1つ目が「このシステムの機能は、どの部門が責任を持つか」だ。例えばEC（電子商取引）システムの場合、「おすすめ商品の表示」はマーケティング部門が、「チャットbotでの問い合わせ対応」はカスタマーサポート部門が責任を持つ。部門ごとに予算、判断基準、スキルが異なるため、システムもその単位で分けると管理しやすくなる。注意すべきは「コンウェイの法則」だ。システムのアーキテクチャは組織の通信構造を反映してしまうため、組織の縦割りがそのままシステムの分断になるリスクがある。

　2つ目が、「業務の文脈ごとに意味が変わる言葉」を境界にして切り分ける方法だ。例えば「顧客」という言葉は、販売部門では「購入者」、サポート部門では「問い合わせ者」、財務部門では「請求先」と意味が変わる。この意味の境界をシステムの境界として使う。

　3つ目が、「関係の強いものは一緒に、関係の薄いものは切り離す」というアーキテクチャの基本原則の適用だ。注文処理に関係する機能はひとまとめにし（凝集）、注文処理と在庫管理は互いに直接依存しないように設計する（疎結合）。疎結合にしておくと、片方を変更しても他方に影響が出にくくなる。

　4つ目が、「競争優位を生む機能」を独立した単位として切り出す方法だ。「最速でチェックアウトできる」というのがビジネスにおける差別化ポイントなら、その機能を他の部分から独立させ、性能投資を集中できるようにする。差別化に関係ない機能と同じ設計基準を適用する必要がなくなる。

Characteristics

　「C」の2つ目は「Characteristics」（アーキテクチャ特性）だ。セキュリティ・可用性・性能など、機能ではなく「品質や動作特性」を意味する非機能要件（NFR）の中でも、トレードオフを受け入れてでも死守すべき要件を5つ以内に絞ったものだ。

　例えば貿易関連の注文管理システムの場合、スケーラビリティ・信頼性・性能・規制準拠を優先すれば、コスト・シンプルさ・アジリティはトレードオフになる。逆に日報の作成機能なら、コスト、実装容易性、保守容易性を優先し、スケールと性能はトレードオフとする。このトレードオフを事前に合意しておくことが、後から「なぜこの設計にしたのか」と問われたときの説明責任を果たす根拠になる。

　マンガロール氏はこれをサッカーに例えて説明する。走る、パス回し、基礎体力の構築はは全プレイヤーが実行する標準的な基礎練習だ。これを同氏は、「Well-Architected Framework」と呼ぶ。ゴールキーパーのセービングやフォワードのシュート練習といったポジション別トレーニングは、「アーキテクチャ特性」だという。

　同一の基盤を使っていても、機能によって必要となる性能は異なる。だから、“ポジション別トレーニング”が必要だというのが同氏の主張だ。

Constraints

　「C」の3つ目は「Constraints」（制約）だ。予算、タイムライン、スキル、リスクなど、チームがコントロールできない要因を指す。ラオ氏はAmazon,comのCTO、ワーナー・ボゲルス氏が提唱する「frugal architect」（制約の中で最大価値を出す設計者）の概念を引用し、「制約はネガティブな要素ではなく創造性を促進するものだ」と述べる。一般的に人は「制約がなければ自由に設計できる」と考えがちだが実際は逆だという。

　「Kubernetesは必須」「特定のデータベースしか使えない」といった企業独自のルールがあった場合は、3Cで設計した後に企業の独自ルールと照合し、必要に応じてルールを更新することが重要だ。

「全社標準化」はなぜ失敗するのか

　「全社で同じ技術を使う」「統一すれば管理しやすい」といった取り組みは一見成功しそうに見える。しかしマンガロール氏はこれを「失敗する」と指摘する。理由は簡単だ。「機能ごとに“求める特性”が違うから」である。ケイパビリティによって最適な特性は異なる、それにもかかわらず、全てに同じアーキテクチャ基準を適用すれば、過剰コストの発生や性能不足、技術負債の増大が発生する可能性がある。

　「重要な機能には多く投資してよい」、逆に「全部平等に設計する必要はない」というのがマンガロール氏の主張だ。

ADRを使ってみる（アーキテクチャ決定記録）

　開発や運用過程の判断を記録し蓄積するためのツールにアーキテクチャ決定記録（Architectural Decision Records：ADR）がある。記録する項目は、タイトル、ステータス、コンテキスト、決定内容、結果、代替案、ステークホルダー、アーキテクチャ特性や制約の9項目だ。同じ検討を繰り返さないために、「却下した案」も残すのが大切だ。さらに、「誰が決めたか」も残すことで、責任の所在が明確になる。ADRを使うことで、「障害時の判断の加速化」「経営への説明責任の向上」「ナレッジの蓄積」が可能となる。

本稿の内容は、2025年12月にAWSが開催した年次イベント「AWS re:Invent 2025」のセッション「Capability-first architecture: Bridging business intent to technology」で共有されたものだ。