システムアーキテクチャ設計

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

システムアーキテクチャ設計

システム全体の構造を定義し、各コンポーネントの役割と技術選定を明確化することで、開発チーム全体が一貫性のある実装を行うための設計指針を提供します。

🎯 概要

  • 目的: システム全体の構成を明確にし、各コンポーネント間の関係性や責務を定義することで、開発チーム全体が共通の理解を持ち、一貫性のある実装を実現する
  • スコープ: システムを構成する主要なコンテナ・コンポーネントのレイヤー構造、責務分担、技術スタックをカバーする。個別のモジュール内部の詳細設計は対象外
  • 推奨する実施タイミング: 通常、基本設計の初期段階で実施する
  • 関連するステークホルダー: システムアーキテクト、プロジェクトマネージャー、インフラチーム、セキュリティチーム

📥 重要な前提知識・インプット

  • 前提知識: アーキテクチャパターン(レイヤードアーキテクチャ、マイクロサービスなど)、システム間連携方式、非機能要件の理解
  • インプット: 非機能要件一覧、既存システムの構成、技術的制約

📄 成果物の定義

✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
依存関係の健全性 コンポーネント間の依存関係に循環がない
非機能要件整合性 非機能要件を満たしているか
スケーラビリティ スケーリングの方法が明確である
技術選定の妥当性 技術選定の理由が文書化されているか

👁️‍🗨️ レビュー観点:

  • 要件との整合性: 非機能要件(性能・可用性・セキュリティ)がアーキテクチャに反映されているか
  • 技術的実現可能性: チームのスキルセットで実装可能な技術構成か
  • 運用・保守の容易性: 障害対応、監視、デプロイの運用性が考慮されているか
  • コスト妥当性: ライセンス費用、インフラコスト、学習コストが予算内に収まるか
🧪成果物のサンプル
# システムアーキテクチャ

## システム全体構成図

### 概要
システム全体の論理的および物理的な構成を示す。主要なコンポーネント(サブシステム)、サーバー、ネットワークの配置を明確化する。

### システム構成図

```mermaid
graph TB
    subgraph "クライアント層"
        A["Webブラウザ"]
        B["モバイルアプリ"]
    end
    
    subgraph "プレゼンテーション層"
        C["Webサーバー<br/>(Nginx/Apache)"]
    end
    
    subgraph "アプリケーション層"
        D["APIサーバー<br/>(Node.js/Java)"]
        E["バッチサーバー"]
    end
    
    subgraph "データ層"
        F["データベース<br/>(PostgreSQL/MySQL)"]
        G["キャッシュサーバー<br/>(Redis)"]
        H["ファイルストレージ<br/>(S3/NAS)"]
    end
    
    subgraph "外部システム"
        I["外部API"]
        J["既存システム"]
    end
    
    A --> C
    B --> C
    C --> D
    D --> F
    D --> G
    D --> H
    D --> I
    E --> F
    D --> J
```

### コンポーネント説明

| コンポーネント名 | 役割 | 技術スタック | 備考 |
|------------------|------|--------------|------|
| Webブラウザ | ユーザーインターフェース | HTML/CSS/JavaScript | Chrome, Safari, Edge対応 |
| モバイルアプリ | モバイル向けUI | React Native / Flutter | iOS/Android対応 |
| Webサーバー | リクエスト受付・静的コンテンツ配信 | Nginx | リバースプロキシとして機能 |
| APIサーバー | ビジネスロジック処理 | Node.js + Express | RESTful API提供 |
| バッチサーバー | 定期処理・非同期処理 | Python | 夜間バッチ、データ集計等 |
| データベース | データ永続化 | PostgreSQL 14 | トランザクションデータ管理 |
| キャッシュサーバー | 高速データアクセス | Redis 7 | セッション管理、頻繁アクセスデータ |
| ファイルストレージ | ファイル保存 | AWS S3 | 画像、PDF等の保存 |

---

## アーキテクチャパターンと責務分割方針

### 採用アーキテクチャ
**レイヤードアーキテクチャ(3層アーキテクチャ)**を採用する。

### 採用理由
- 各層の責務が明確で、保守性・拡張性が高い
- チーム分割がしやすく、並行開発が可能
- 技術スタックの変更が層単位で可能
- 実績が豊富で、開発メンバーの習熟度が高い

### 層別責務定義

#### プレゼンテーション層(Presentation Layer)
**責務:**
- ユーザーインターフェースの提供
- リクエストの受付とレスポンスの返却
- 入力値の基本的なバリデーション
- セッション管理

**含まれるコンポーネント:**
- Webサーバー(Nginx)
- フロントエンドアプリケーション(React)

**禁止事項:**
- ビジネスロジックの実装
- データベースへの直接アクセス

#### アプリケーション層(Application Layer / Business Logic Layer)
**責務:**
- ビジネスロジックの実装
- トランザクション制御
- データの整合性チェック
- 外部システムとの連携制御

**含まれるコンポーネント:**
- APIサーバー
- バッチサーバー
- ビジネスロジック処理モジュール

**禁止事項:**
- UI表示に関する処理
- データベース固有の処理の直接実装(DAOを経由する)

#### データ層(Data Layer)
**責務:**
- データの永続化
- データの読み取り・書き込み
- データの物理的な管理

**含まれるコンポーネント:**
- データベース(PostgreSQL)
- キャッシュサーバー(Redis)
- ファイルストレージ(S3**禁止事項:**
- ビジネスロジックの実装(ストアドプロシージャは最小限)

### コンポーネント間通信フロー

```mermaid
sequenceDiagram
    participant U as ユーザー
    participant P as プレゼンテーション層
    participant A as アプリケーション層
    participant D as データ層
    
    U->>P: リクエスト送信
    P->>P: 入力バリデーション
    P->>A: APIコール
    A->>A: ビジネスロジック実行
    A->>D: データアクセス要求
    D->>A: データ返却
    A->>P: レスポンス返却
    P->>U: 画面表示
```

---

## 採用技術スタック

### フロントエンド

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| フレームワーク | React | 18.x | コンポーネント指向、豊富なエコシステム |
| 状態管理 | Redux Toolkit | 1.9.x | 予測可能な状態管理、デバッグツール充実 |
| UIライブラリ | Material-UI | 5.x | デザイン統一、レスポンシブ対応 |
| ビルドツール | Vite | 4.x | 高速なビルド、HMR対応 |
| 言語 | TypeScript | 5.x | 型安全性、IDE支援充実 |

### バックエンド

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| 実行環境 | Node.js | 20.x LTS | 非同期処理に強い、JavaScript統一 |
| フレームワーク | Express | 4.x | シンプル、拡張性高い、実績豊富 |
| ORM | Prisma | 5.x | 型安全、マイグレーション管理容易 |
| バリデーション | Zod | 3.x | TypeScript統合、実行時型チェック |
| 言語 | TypeScript | 5.x | 型安全性、保守性向上 |

### データベース・ストレージ

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| RDB | PostgreSQL | 14.x | ACID特性、豊富な機能、実績 |
| キャッシュ | Redis | 7.x | 高速、セッション管理、Pub/Sub |
| オブジェクトストレージ | AWS S3 | - | 高可用性、スケーラビリティ |

### インフラ・DevOps

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| コンテナ | Docker | 24.x | 環境統一、デプロイ容易 |
| オーケストレーション | Kubernetes | 1.28.x | スケーラビリティ、自動復旧 |
| CI/CD | GitHub Actions | - | リポジトリ統合、無料枠充実 |
| モニタリング | Datadog | - | 統合監視、アラート機能 |
| ログ管理 | CloudWatch Logs | - | AWS統合、検索・分析機能 |

### 開発ツール

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| バージョン管理 | Git | - | 標準的なVCS |
| リポジトリ | GitHub | - | コラボレーション機能充実 |
| IDE | VSCode | - | 拡張機能豊富、軽量 |
| API設計 | OpenAPI (Swagger) | 3.x | API仕様の標準化 |
| テスト | Jest | 29.x | テストフレームワーク標準 |

### バッチ処理

| 技術要素 | 技術名 | バージョン | 採用理由 |
|----------|--------|------------|----------|
| 言語 | Python | 3.11.x | データ処理ライブラリ豊富 |
| スケジューラ | cron / AWS EventBridge | - | 定期実行の標準 |
| データ処理 | pandas | 2.x | データ分析・加工に最適 |

### 技術スタック選定基準

以下の基準に基づいて技術選定を実施した:

1. **実績と安定性**: 本番環境での十分な実績があること
2. **コミュニティとサポート**: 活発なコミュニティ、豊富なドキュメント
3. **学習コストとスキル**: チームメンバーの習熟度、習得容易性
4. **拡張性と保守性**: 将来の機能追加・変更への対応力
5. **ライセンスとコスト**: 商用利用可能、運用コストの妥当性
6. **セキュリティ**: セキュリティアップデートの提供状況

---

🔄 設計の進め方・プロセス

🏗️ プロセス1: システム全体構成図

設計対象:

システムを構成する主要なコンテナ、コンポーネントを特定し、それらの配置とネットワークを決定する。

具体例:

  • どのようなサブシステム(Webサーバー、APIサーバー、バッチサーバーなど)に分割するか
  • 各サーバーをどのネットワークセグメント(DMZ、内部ネットワークなど)に配置するか
  • データベース、キャッシュサーバー、ストレージをどこに配置するか
  • 外部システムとの連携ポイントをどこに設けるか

設計原則:

  • 単一責任の原則: 各サブシステムは明確な責務を持ち、機能が重複しないように分割する
  • 障害の影響範囲の限定: 外部連携など障害リスクの高い部分は独立したコンポーネントとして分離し、障害時の影響を最小限に抑える
  • 可用性の確保: 重要度の高いコンポーネントは冗長化構成を検討し、単一障害点を排除する
  • セキュリティ境界の明確化: DMZ、内部ネットワークなど、適切なネットワークセグメント分割を行い、ファイアウォールで保護する
  • スケーラビリティの考慮: 負荷が集中するコンポーネントは水平スケールできる構成とし、ロードバランサーで負荷分散する

文書化の推奨表現:

  • 視覚的な図の作成: システム構成図を作成し、各コンポーネントの配置、ネットワークセグメント、通信経路を視覚的に表現する
  • コンポーネント一覧の整備: 各コンポーネントの役割、責務、使用技術を一覧表にまとめる
  • ネットワーク構成の詳細化: IPアドレス範囲、ポート番号、ファイアウォールルールなどの具体的な情報を記載する
  • 設計判断の記録: なぜその構成を選択したのか、検討した代替案とその評価結果を残す
🏗️ プロセス2: アーキテクチャパターンと責務分割方針

設計対象:

システム全体で採用するアーキテクチャパターンと、各レイヤー・コンポーネントの責務を決定する。

具体例:

  • レイヤードアーキテクチャ、マイクロサービスアーキテクチャ、イベント駆動アーキテクチャのいずれを採用するか
  • プレゼンテーション層、ビジネスロジック層、データアクセス層をどのように分割するか
  • 各コンポーネント(例: ユーザー管理サービス、注文管理サービス)がどの機能を担当するか
  • コンポーネント間の呼び出し方法(同期API、非同期メッセージング)をどうするか

設計原則:

  • 要件に応じたパターン選定: システム規模、チーム構成、非機能要件を総合的に評価し、過度に複雑でない適切なパターンを選ぶ
  • 疎結合の実現: コンポーネント間の依存関係を最小限にし、インターフェースを通じた疎結合な設計とする
  • 単一責任の徹底: 各レイヤー・コンポーネントは明確な責務を持ち、責務が重複したり曖昧にならないようにする
  • 循環依存の回避: コンポーネント間の依存関係を一方向に保ち、循環依存が発生しないように設計する
  • 変更容易性の確保: 将来の機能追加や変更時に、影響範囲が限定されるような境界設計を行う
  • 採用理由の明文化: なぜそのパターンを選択したのか、判断基準と理由を文書化し、チーム内で共有する

文書化の推奨表現:

  • アーキテクチャ図の作成: レイヤー構造やコンポーネント間の依存関係を示すアーキテクチャ図を作成する
  • 責務マトリクスの整備: 各レイヤー・コンポーネントが担当する機能と責務を一覧表で明確にする
  • パターン適用の根拠: 採用したアーキテクチャパターンの選定理由、メリット・デメリットを記載する
  • 制約事項の明記: アーキテクチャ上の制約や守るべきルール(例: 依存関係の方向性)を文書化する
🏗️ プロセス3: 採用技術スタック

設計対象:

システム実装に使用する具体的なプログラミング言語、フレームワーク、データベース、ミドルウェア、クラウドサービスを決定する。

具体例:

  • フロントエンド: React、Vue.js、Angularのいずれを使うか
  • バックエンド: Java(Spring Boot)、Python(Django)、Node.js(Express)のいずれを使うか
  • データベース: PostgreSQL、MySQL、MongoDBのいずれを使うか
  • キャッシュ: Redis、Memcachedのいずれを使うか
  • クラウド: AWS、Azure、GCPのどのサービスを使うか
  • CI/CD: GitHub Actions、GitLab CI、Jenkinsのいずれを使うか

設計原則:

  • チームスキルとの整合: チームメンバーが習熟している技術、または習得可能な技術を優先的に選定する
  • 実績と安定性の重視: 本番環境での十分な実績があり、コミュニティが活発で、ドキュメントが充実している技術を選ぶ
  • 非機能要件への適合: パフォーマンス、スケーラビリティ、セキュリティなどの非機能要件を満たす技術を選定する
  • 将来性の考慮: 技術の成熟度、アップデート頻度、長期サポート(LTS)の有無を確認し、将来も使い続けられる技術を選ぶ
  • コストの評価: ライセンス費用、運用コスト、学習コストを総合的に評価し、予算内に収まる技術を選ぶ
  • 選定理由の明文化: なぜその技術を選んだのか、他の候補との比較結果を含めて文書化する

文書化の推奨表現:

  • 技術スタック一覧の作成: 採用する全ての技術をカテゴリ別(フロントエンド、バックエンド、インフラなど)に整理した一覧表を作成する
  • バージョン情報の明記: 各技術の具体的なバージョンとサポート期限を記載する
  • 選定理由の文書化: 各技術の採用理由、評価した代替技術との比較結果を記録する
  • 依存関係の整理: 技術間の依存関係や互換性要件を明確にする
  • 学習リソースの共有: チームメンバーが参照すべき公式ドキュメント、チュートリアル、ベストプラクティスへのリンクを提供する
  • ライセンス情報の記録: 各技術のライセンス形態と商用利用の可否を明記する

🚨 よくある失敗と予防策

❌ 失敗: システム全体構成の検討不足

具体例:

Webアプリケーションの開発において、システム全体の論理的分割を十分に検討せず、すべての機能を単一のアプリケーションサーバーに配置。外部APIとの連携部分も同じサーバー内に実装した結果、外部APIの応答遅延時にシステム全体が影響を受け、他の機能も使えなくなった。また、物理配置の検討が不十分で、冗長化構成を考慮していなかったため、サーバー障害時にサービス全体が停止する事態となった。

リスク:

単一障害点の発生、システム全体への影響拡大、可用性の低下、スケーラビリティの欠如、保守性の低下といった問題が発生する。

予防策:

  • 機能の論理的分割: 機能特性や変更頻度に基づいてサブシステムを適切に分割する
  • 外部依存の分離: 外部システム連携部分は独立したコンポーネントとして分離し、障害の影響範囲を限定する
  • 冗長化構成の検討: 可用性要件に基づき、冗長化やフェイルオーバー戦略を設計段階で検討する
  • ネットワークセグメント分割: セキュリティ要件に応じて、DMZ、内部ネットワークなどの適切なセグメント分割を行う
❌ 失敗: アーキテクチャパターン選定の誤り

具体例:

月間ユーザー数1000人程度の社内システムにおいて、将来の拡張性を理由にマイクロサービスアーキテクチャを採用。10個のマイクロサービスに分割し、それぞれにAPI Gateway、サービスメッシュを導入した結果、3人の開発チームでは管理しきれず開発期間が2倍に。一方、別プロジェクトでは複数チームで大規模開発を行うにもかかわらずモノリシックなレイヤードアーキテクチャを採用し、チーム間の開発競合が頻発してリリースサイクルが遅延した。

リスク:

開発コストと期間の増大、チーム規模とアーキテクチャのミスマッチ、保守性の低下、パフォーマンス問題の発生、デプロイの複雑化といった問題が発生する。

予防策:

  • 要件とチーム規模の考慮: システム規模、チーム構成、非機能要件を総合的に評価してアーキテクチャパターンを選定する
  • 採用理由の明文化: なぜそのアーキテクチャを選択したのか、判断基準と理由をアーキテクチャ決定記録(ADR)に記載する
  • 段階的移行の検討: 初期はシンプルなレイヤードアーキテクチャから始め、必要に応じてマイクロサービス化を検討する
  • 責務境界の明確化: 各コンポーネント・レイヤーの責務を明確に定義し、重複や循環依存を防ぐ
❌ 失敗: 技術スタック選定の失敗

具体例:

新しいWebアプリケーション開発において、チームメンバー全員がJavaとSpring経験者であるにもかかわらず、「モダンな技術を使いたい」という理由でNode.jsとReactを採用。学習コストが想定以上にかかり、開発が3ヶ月遅延。また、採用したORMライブラリがパフォーマンス要件を満たせず、途中で別のライブラリに移行する事態となった。データベースも性能検証を行わずにNoSQLを採用したが、トランザクション要件に合わず、結果的にRDBMSに変更する大規模な手戻りが発生した。

リスク:

開発遅延とコスト増大、チームスキルとのミスマッチ、パフォーマンス要件を満たせない、技術的負債の蓄積、大規模な手戻り作業の発生といった問題が発生する。

予防策:

  • チームスキルの評価: 採用技術に対するチームの習熟度を確認し、学習コストを見積もりに含める
  • 技術評価マトリクスの作成: 学習コスト、パフォーマンス、コミュニティサポート、ライセンスコスト、サポート期間などの観点で技術候補を評価する
  • PoC(概念実証)の実施: 重要な技術選定については、性能要件やチーム適性を検証する小規模なPoCを実施する
  • 選定理由の文書化: 各技術スタックの選定理由を明記し、将来の技術変更判断の参考とする
  • 長期サポートの確認: 採用技術のLTS(Long Term Support)バージョンやサポート期間を確認し、運用期間中のサポートを保証する

📚 参考資料・関連リンク

  • 参考文献: 『ソフトウェアアーキテクチャの基礎』、『マイクロサービスパターン』
  • 関連する他のガイド: API設計ガイド、データベース設計ガイド、セキュリティ設計ガイド
  • ツール・テンプレート: draw.io、PlantUML、C4モデルテンプレート