ストーリー

ソフトウェアアーキテクチャとは

定義

ソフトウェアアーキテクチャには様々な定義がありますが、実務で最も有用なのは以下の理解です。

// アーキテクチャ的な決定 vs 設計的な決定

// アーキテクチャ的な決定（変更コストが高い）
interface ArchitecturalDecisions {
  systemTopology: "モノリス" | "マイクロサービス" | "モジュラーモノリス";
  communicationStyle: "同期REST" | "非同期メッセージング" | "イベント駆動";
  dataStrategy: "単一DB" | "サービス別DB" | "イベントソーシング";
  deploymentModel: "オンプレミス" | "クラウド" | "ハイブリッド";
  scalingStrategy: "垂直スケーリング" | "水平スケーリング";
}

// 設計的な決定（変更コストが比較的低い）
interface DesignDecisions {
  designPattern: "Strategy" | "Observer" | "Factory";
  variableNaming: string;
  classStructure: string;
  testStrategy: "TDD" | "BDD";
}

アーキテクチャ vs 設計

L2で学んだ「設計」とL3で学ぶ「アーキテクチャ」の境界は明確ではありませんが、実務的には以下のように区別できます。

graph TD
    A["アーキテクチャ（L3）<br/>システム構成、サービス分割、通信方式、<br/>データ戦略、デプロイ戦略、技術選定"]
    B["設計（L2）<br/>クラス設計、パターン適用、<br/>モジュール分割、インターフェース設計"]
    C["実装（L1）<br/>コーディング、テスト、デバッグ"]

    A --> B --> C

    classDef archStyle fill:#4a90d9,stroke:#2c5f8a,color:#fff
    classDef designStyle fill:#67b7dc,stroke:#3a8ab5,color:#fff
    classDef implStyle fill:#8fd4f0,stroke:#5aadcc,color:#333

    class A archStyle
    class B designStyle
    class C implStyle

アーキテクチャ決定の特性：「高コストな変更」

「なぜアーキテクチャの決定がそれほど重要なのか。それはやり直しのコストが桁違いだからだ」 — 佐藤CTO

// 変更コストの比較（概算）
const changeCostComparison = {
  variableRename: {
    effort: "数分",
    risk: "ほぼゼロ",
    impact: "ローカル",
    tooling: "IDE のリファクタリング機能",
  },
  designPatternChange: {
    effort: "数日〜数週間",
    risk: "低〜中",
    impact: "モジュール内",
    tooling: "テスト + リファクタリング",
  },
  architectureChange: {
    effort: "数ヶ月〜数年",
    risk: "高",
    impact: "システム全体",
    tooling: "段階的移行戦略が必要",
  },
};

// 実例：モノリスからマイクロサービスへの移行
const monolithToMicroservices = {
  企業: "某大手ECサイト",
  期間: "約2年",
  チーム: "専任チーム8名 + 各サービスチーム",
  コスト: "数億円規模",
  リスク: "移行中の障害、データ不整合、パフォーマンス劣化",
  教訓: "最初のアーキテクチャ選定の重要性",
};

アーキテクトの役割

アーキテクトは何をする人か

佐藤CTOが、アーキテクトの4つの主要な役割を説明しました。

graph TD
    A["アーキテクト"]
    B["技術的な<br/>意思決定"]
    C["品質の<br/>保証"]
    D["技術の<br/>橋渡し"]
    E["ステークホルダー<br/>マネジメント"]

    A --> B
    A --> C
    A --> D
    A --> E

    classDef centerStyle fill:#4a90d9,stroke:#2c5f8a,color:#fff
    classDef roleStyle fill:#67b7dc,stroke:#3a8ab5,color:#fff

    class A centerStyle
    class B,C,D,E roleStyle

// アーキテクトの日常を型で表現
interface ArchitectDailyWork {
  morning: {
    task: "設計レビュー";
    detail: "新機能のアーキテクチャレビュー、NFRとの整合性確認";
  };
  midday: {
    task: "技術選定ミーティング";
    detail: "メッセージキューの選定（Kafka vs SQS）、POC結果のレビュー";
  };
  afternoon: {
    task: "ADR作成";
    detail: "選定理由の文書化、却下した選択肢とその理由の記録";
  };
  evening: {
    task: "技術戦略の検討";
    detail: "半年後のトラフィック増に対するスケーリング戦略の策定";
  };
}

コンウェイの法則

「アーキテクチャの話をするなら、避けて通れない法則がある。コンウェイの法則だ」 — 佐藤CTO

コンウェイの法則とは

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

— メルヴィン・コンウェイ（1967年）

システムの構造は、それを設計した組織の構造を反映する。

// コンウェイの法則の具体例

// 組織構造が3チームの場合
interface Organization {
  frontendTeam: "フロントエンドチーム（5名）";
  backendTeam: "バックエンドチーム（8名）";
  infraTeam: "インフラチーム（3名）";
}

// → システムもレイヤー分割になりがち
interface SystemArchitecture {
  frontend: "SPAアプリケーション";
  backend: "モノリシックAPI";
  infra: "共有インフラ基盤";
}

// ドメインチーム構成の場合
interface DomainOrganization {
  orderTeam: "注文チーム（フルスタック4名）";
  paymentTeam: "決済チーム（フルスタック3名）";
  inventoryTeam: "在庫チーム（フルスタック3名）";
}

// → システムもサービス分割になりやすい
interface DomainSystemArchitecture {
  orderService: "注文サービス";
  paymentService: "決済サービス";
  inventoryService: "在庫サービス";
}

逆コンウェイの法則（Inverse Conway Maneuver）

優れた組織は、望ましいアーキテクチャに合わせて組織構造を変えるというアプローチを取ります。

良いアーキテクチャ決定 vs 悪いアーキテクチャ決定

佐藤CTOが、実際のプロジェクトから学んだ教訓を共有してくれました。

良い決定の例

// ケース：ECサイトのアーキテクチャ選定
const goodDecision = {
  context: {
    チーム規模: "8名",
    フェーズ: "プロダクト検証期（PMF前）",
    要件: "素早い機能追加と検証",
  },
  decision: "モジュラーモノリス",
  reasoning: {
    なぜモノリスか: "チーム規模が小さく、マイクロサービスの運用コストが見合わない",
    なぜモジュラーか: "将来のサービス分割に備え、モジュール境界を明確にしておく",
    トレードオフ: "スケーラビリティの上限はあるが、開発速度を優先",
  },
  result: "PMF達成後、トラフィック増に応じて段階的にサービスを分離できた",
};

悪い決定の例

// ケース：スタートアップのアーキテクチャ選定
const badDecision = {
  context: {
    チーム規模: "3名",
    フェーズ: "MVP開発",
    要件: "最速でローンチ",
  },
  decision: "最初からマイクロサービス + Kubernetes",
  reasoning: {
    表面的な理由: "将来のスケーラビリティのため",
    本当の理由: "技術的に挑戦してみたかった",
  },
  result: {
    ローンチ遅延: "3ヶ月遅れ",
    運用負荷: "インフラ管理に工数の40%を消費",
    教訓: "ビジネスフェーズに合わないアーキテクチャは害になる",
  },
};

判断基準のフレームワーク

アーキテクチャのスコープ

アーキテクチャは複数のレベルで存在します。

graph TD
    A["エンタープライズアーキテクチャ<br/>（組織全体のIT戦略・システム群の関係）"]
    B["ソリューションアーキテクチャ<br/>（特定の問題を解決するシステム全体の構成）"]
    C["ソフトウェアアーキテクチャ<br/>（1つのシステム内部の構造）← L3の主な対象"]

    A --> B --> C

    classDef entStyle fill:#2c5f8a,stroke:#1a3d5c,color:#fff
    classDef solStyle fill:#4a90d9,stroke:#2c5f8a,color:#fff
    classDef swStyle fill:#67b7dc,stroke:#3a8ab5,color:#fff

    class A entStyle
    class B solStyle
    class C swStyle

L3では主にソフトウェアアーキテクチャを対象としますが、ソリューションレベルの視点も養います。

まとめ

チェックリスト

• アーキテクチャの定義を自分の言葉で説明できる
• アーキテクチャと設計の違いを理解した
• アーキテクトの4つの役割を把握した
• コンウェイの法則を理解し、具体例を挙げられる
• 良い/悪いアーキテクチャ決定の違いを理解した

次のステップへ

アーキテクチャが「何か」を理解したところで、次は「ビジネス要件の分析手法」を学びます。優れたアーキテクチャは、ビジネスの理解から始まります。ステークホルダー分析やドメイン分析の手法を身につけましょう。

推定読了時間: 30分