Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
システムアーキテクチャ設計
システム全体の構造を定義し、各コンポーネントの役割と技術選定を明確化することで、開発チーム全体が一貫性のある実装を行うための設計指針を提供します。
🎯 概要
- 目的: システム全体の構成を明確にし、各コンポーネント間の関係性や責務を定義することで、開発チーム全体が共通の理解を持ち、一貫性のある実装を実現する
- スコープ: システムを構成する主要なコンテナ・コンポーネントのレイヤー構造、責務分担、技術スタックをカバーする。個別のモジュール内部の詳細設計は対象外
- 推奨する実施タイミング: 通常、基本設計の初期段階で実施する
- 関連するステークホルダー: システムアーキテクト、プロジェクトマネージャー、インフラチーム、セキュリティチーム
📥 重要な前提知識・インプット
- 前提知識: アーキテクチャパターン(レイヤードアーキテクチャ、マイクロサービスなど)、システム間連携方式、非機能要件の理解
- インプット: 非機能要件一覧、既存システムの構成、技術的制約
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]システムアーキテクチャ
- 必須要素: システム全体構成図、物理配置図、レイヤー構成図、コンポーネント責務定義書、技術スタック一覧
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 依存関係の健全性 | コンポーネント間の依存関係に循環がない |
| 非機能要件整合性 | 非機能要件を満たしているか |
| スケーラビリティ | スケーリングの方法が明確である |
| 技術選定の妥当性 | 技術選定の理由が文書化されているか |
👁️🗨️ レビュー観点:
- 要件との整合性: 非機能要件(性能・可用性・セキュリティ)がアーキテクチャに反映されているか
- 技術的実現可能性: チームのスキルセットで実装可能な技術構成か
- 運用・保守の容易性: 障害対応、監視、デプロイの運用性が考慮されているか
- コスト妥当性: ライセンス費用、インフラコスト、学習コストが予算内に収まるか
🧪成果物のサンプル
# システムアーキテクチャ
## システム全体構成図
### 概要
システム全体の論理的および物理的な構成を示す。主要なコンポーネント(サブシステム)、サーバー、ネットワークの配置を明確化する。
### システム構成図
```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モデルテンプレート