目標アーキテクチャの策定

ストーリー

田

田中VPoE

Step 1で現状を把握した。技術課題マップが完成し、優先順位も見えた。次は「どこを目指すか」 — 目標アーキテクチャの策定だ

あなた

理想の技術基盤を設計するんですね

あ

田

田中VPoE

ただし「理想」ではなく「実現可能な目標」だ。3年後にどの領域をどのレベルにするか、各領域がどう連携するか。全体像を一枚の絵にする

あなた

Month 5のクラウドアーキテクチャ、Month 6のプラットフォーム設計、Month 7のデータアーキテクチャ…個別に学んだ設計を統合するということですね

あ

田

田中VPoE

そうだ。個別の設計は部分最適にしかならない。全体最適を実現するのが目標アーキテクチャの役割だ

目標アーキテクチャの全体設計

統合アーキテクチャの全体像

┌──────────────────────────────────────────────────────────┐
│                    ビジネスレイヤー                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐               │
│  │ Webアプリ  │  │ モバイル  │  │ API      │               │
│  └─────┬────┘  └─────┬────┘  └─────┬────┘               │
│        └──────────────┼──────────────┘                    │
│                       ↓                                   │
│  ┌─────────────────────────────────────────────────────┐ │
│  │              API Gateway / Service Mesh              │ │
│  │           （Month 4: ゼロトラスト認証統合）            │ │
│  └─────────────────────┬───────────────────────────────┘ │
├────────────────────────┼─────────────────────────────────┤
│                    プラットフォームレイヤー                  │
│  ┌────────────┐  ┌────────────┐  ┌────────────────────┐ │
│  │ CI/CD基盤   │  │ IDP        │  │ オブザーバビリティ   │ │
│  │ (Month 1)  │  │ (Month 6)  │  │ (Month 2)          │ │
│  └────────────┘  └────────────┘  └────────────────────┘ │
│  ┌────────────┐  ┌────────────┐  ┌────────────────────┐ │
│  │ セキュリティ │  │ AI/ML基盤  │  │ データ基盤          │ │
│  │ (Month 4)  │  │ (Month 3)  │  │ (Month 7)          │ │
│  └────────────┘  └────────────┘  └────────────────────┘ │
├──────────────────────────────────────────────────────────┤
│                    インフラレイヤー                         │
│  ┌─────────────────────────────────────────────────────┐ │
│  │            クラウドネイティブ基盤（Month 5）            │ │
│  │  ┌──────┐  ┌───────┐  ┌────────┐  ┌──────────────┐ │ │
│  │  │ EKS  │  │ サーバ │  │ ストレ │  │ ネットワーク  │ │ │
│  │  │      │  │ レス   │  │ ージ   │  │              │ │ │
│  │  └──────┘  └───────┘  └────────┘  └──────────────┘ │ │
│  └─────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘

目標状態の定義（3年後）

領域	目標Level	目標状態の定義
CI/CD	4	全チームがGitHub Actionsで統一。品質ゲート自動適用。デプロイ頻度: 日次以上
SRE/信頼性	4	全サービスにSLI/SLO定義。統合オブザーバビリティ基盤。MTTR: 30分以内
AI基盤	3	MLOps基盤稼働。3つ以上のAIユースケース本番運用。データガバナンス整備
セキュリティ	4	ゼロトラスト実装。DevSecOpsパイプライン統合。継続的コンプライアンス監視
クラウドインフラ	4	IaC 80%以上。コンテナ化80%以上。FinOps最適化運用
開発者プラットフォーム	3	IDP稼働。標準テンプレート完備。オンボーディング: 1週間以内
データ基盤	4	データメッシュアーキテクチャ。リアルタイム処理。品質SLO運用

アーキテクチャ原則

10の基本原則

No.	原則	説明	関連Month
1	クラウドネイティブ第一	新規構築はクラウドネイティブ前提。コンテナ/サーバレス活用	M5
2	セキュリティバイデザイン	セキュリティは後付けではなく設計段階から組み込む	M4
3	オブザーバビリティ組み込み	すべてのサービスにメトリクス、ログ、トレースを標準装備	M2
4	自動化優先	手動作業を排除し、CI/CD、IaC、ポリシーasCodeを徹底	M1
5	疎結合	サービス間はAPIとイベントで疎結合に接続	M5
6	プラットフォーム思考	共通機能はプラットフォームとして提供し、チームの自律性を支援	M6
7	データドリブン	すべての判断をデータに基づいて行い、データ品質を保証する	M7
8	AI Ready	AI活用を前提としたデータ収集・管理・パイプラインを整備	M3
9	段階的移行	ビッグバンを避け、ストラングラーフィグパターンで段階的に移行	M5
10	フィードバックループ	継続的に計測・改善するサイクルを組織に埋め込む	M2/M9

ADR（Architecture Decision Record）の活用

# ADR-001: CI/CDツールをGitHub Actionsに統一する

## ステータス
提案中

## コンテキスト
現在CI/CDはJenkins、GitHub Actions、Bitriseの3ツールに分散しており、
ナレッジの断片化とメンテナンスコストの増大が発生している。

## 決定
全チームのCI/CDパイプラインをGitHub Actionsに統一する。
モバイルビルドはGitHub Actions + Fastlaneで対応する。

## 根拠
- GitHub Actionsはソースコード管理（GitHub）と統合されており、管理が一元化
- マーケットプレイスのアクションが豊富で再利用性が高い
- IDP（Month 6）との統合が容易
- セキュリティスキャン（Month 4）のパイプライン統合が標準サポート

## 影響
- Jenkins習熟者の再教育が必要（15名程度）
- 既存Jenkinsジョブ約200件の移行が必要
- 移行期間中は2ツール並行運用のコストが発生

## 代替案
- GitLab CI/CD: GitHub依存を避けられるが、ソースコード管理の移行も必要
- CircleCI: 機能は十分だが、追加コストが発生
- Jenkinsへの統一: 既存資産が活用できるが、モダンCI/CDの機能が不足

目標状態の設計手法

C4モデルによる可視化

レベル	対象	描くもの	対象者
Level 1: Context	システム全体	外部システムとの関係	経営層、ビジネス
Level 2: Container	主要コンポーネント	アプリ、DB、メッセージキュー等	技術リーダー
Level 3: Component	コンテナ内部	モジュール、サービス間のAPI	開発チーム
Level 4: Code	コード構造	クラス図、シーケンス図	個々の開発者

技術レーダーによる技術選定

技術レーダー（TechForward社版）

ADOPT（採用）:
  - GitHub Actions（CI/CD統一）
  - Kubernetes/EKS（コンテナオーケストレーション）
  - Terraform（IaC統一）
  - Datadog（オブザーバビリティ統一）
  - PostgreSQL/Aurora（RDBMS標準）

TRIAL（試行）:
  - Backstage（IDP）
  - Apache Kafka（イベントストリーミング）
  - dbt（データ変換）
  - MLflow（MLOps）

ASSESS（評価）:
  - OpenTelemetry（テレメトリ標準化）
  - Cilium（ネットワークセキュリティ）
  - Apache Iceberg（データレイクフォーマット）

HOLD（保留/撤退）:
  - Jenkins（GitHub Actionsへ移行）
  - Zabbix（Datadogへ統合）
  - 手動EC2管理（IaC/コンテナ化へ移行）

まとめ

ポイント	内容
統合アーキテクチャ	3層（ビジネス/プラットフォーム/インフラ）で全領域を統合設計
目標Level	各領域の3年後の目標Levelと具体的な状態を定義
アーキテクチャ原則	10の基本原則で技術判断の一貫性を確保
ADR	重要な技術判断を記録し、後から追跡可能にする
技術レーダー	ADOPT/TRIAL/ASSESS/HOLDで技術選定を可視化

チェックリスト

統合アーキテクチャの3層構造を理解した
各領域の目標Levelと目標状態を定義できる
10のアーキテクチャ原則を把握した
ADRの書き方と活用方法を理解した
技術レーダーによる技術選定の可視化を把握した

次のステップへ

次は「プラットフォーム戦略」を学びます。目標アーキテクチャを支えるプラットフォーム層の設計、特にMonth 6で学んだIDPをどう組織全体に展開するかを深掘りしましょう。

推定読了時間: 30分