EXERCISE 90分

ストーリー

田
田中VPoE
目標アーキテクチャの理論は揃った。ここからはTechForward社の目標アーキテクチャを実際に設計してもらう
あなた
Step 1のアセスメント結果をベースに、3年後の姿を描くんですね
あ
田
田中VPoE
そうだ。ただし「絵に描いた餅」では困る。各領域の具体的な技術選定、プラットフォーム間の統合設計、そして技術標準まで落とし込んでくれ。CTOレビューに耐えるレベルの設計を期待している

ミッション概要

項目内容
演習タイトルTechForward社の目標アーキテクチャ設計
想定時間90分
成果物目標アーキテクチャ設計書（全体図 + 5プラットフォーム設計 + 技術標準）

Mission 1: 統合アーキテクチャの全体設計（30分）

要件

  1. 全体アーキテクチャ図を作成（ビジネス/プラットフォーム/インフラの3層）
  2. 各領域の目標Levelと具体的な目標状態を定義
  3. アーキテクチャ原則を5つ以上策定
  4. 技術レーダー（ADOPT/TRIAL/ASSESS/HOLD）を作成
解答例

目標Level:

領域現状1年後3年後戦略
CI/CD234段階的改善（GitHub Actions統一）
SRE/信頼性234段階的改善（Datadog統一）
AI基盤223並行構築（MLOps基盤新規）
セキュリティ234ハイブリッド（ゼロトラスト並行+既存強化）
クラウド334段階的改善（IaC拡大+コンテナ化）
IDP123並行構築（Backstage新規）
データ234ハイブリッド（DWH改善+リアルタイム並行）

アーキテクチャ原則:

  1. クラウドネイティブ第一: 新規はコンテナ/サーバレス前提
  2. セキュリティバイデザイン: 全パイプラインにセキュリティスキャン統合
  3. 自動化優先: IaC、CI/CD、Policy as Codeで手動作業を排除
  4. オブザーバビリティ標準装備: 全サービスにメトリクス/ログ/トレース
  5. プラットフォーム思考: 共通機能はセルフサービスで提供

技術レーダー:

  • ADOPT: GitHub Actions, EKS, Terraform, Datadog, PostgreSQL/Aurora
  • TRIAL: Backstage, Kafka, dbt, MLflow, OpenTelemetry
  • ASSESS: Cilium, Apache Iceberg, Cedar (AuthZ)
  • HOLD: Jenkins, Zabbix, 手動EC2管理, CloudWatch（Datadogへ統合）

Mission 2: 5プラットフォームの詳細設計（40分）

要件

5つのプラットフォームそれぞれについて以下を設計してください。

  1. 提供機能の一覧
  2. 技術スタックの選定（選定理由付き）
  3. 他プラットフォームとの統合ポイント
  4. 段階的展開計画（Phase 1/2/3）
解答例（IDPのみ抜粋）

IDP（Internal Developer Platform）:

提供機能技術選定選定理由
サービスカタログBackstageOSSで拡張性が高い。プラグインエコシステムが充実
CI/CDテンプレートGitHub Actions Reusable WorkflowsGitHub統合。バージョン管理が容易
環境プロビジョニングTerraform + CrossplaneIaC標準。Kubernetes上での宣言的管理
APIドキュメントBackstage API Docs プラグインOpenAPI/AsyncAPI の統合表示
開発環境GitHub Codespacesクラウドベース。セットアップ時間を最小化

統合ポイント:

  • CI/CD PF: テンプレートからパイプライン自動生成
  • セキュリティ PF: Backstageでセキュリティスコア表示
  • オブザーバビリティ PF: SLO状態をサービスカタログに表示
  • データ PF: データカタログのリンクをBackstageに統合

段階的展開計画:

  • Phase 1（0-6ヶ月）: Backstage基本セットアップ、サービスカタログ登録、テンプレート3種
  • Phase 2（6-12ヶ月）: セキュリティ/オブザーバビリティ統合、テンプレート全言語対応
  • Phase 3（12-24ヶ月）: セルフサービス完全化、AI支援機能追加

Mission 3: 技術標準とガバナンス設計（20分）

要件

  1. 技術標準カタログ（必須/標準/推奨の3層、各3つ以上）
  2. Policy as Codeのポリシーを3つ以上定義
  3. ガバナンス体制の組織図と会議体設計
  4. 例外管理プロセスの設計
解答例

技術標準カタログ:

層標準名適用範囲
必須セキュリティスキャン（SAST/SCA）の全パイプライン統合全リポジトリ
必須コスト管理タグ（cost_center, team, environment）全クラウドリソース
必須データ分類ラベリング（機密/個人特定/一般）全データストア
標準GitHub Actions Reusable Workflow使用全CI/CDパイプライン
標準SLI/SLO定義（可用性、レイテンシ、エラー率）全本番サービス
標準APIバージョニング（URL Path方式）全REST API
推奨OpenTelemetry計装全サービス
推奨ADR（Architecture Decision Record）作成アーキテクチャ変更時
推奨チームトポロジーに基づく組織設計新チーム設立時

Policy as Code（OPA）:

  1. 未承認コンテナレジストリからのイメージ使用禁止
  2. 暗号化されていないデータストアの作成禁止
  3. コスト管理タグなしのクラウドリソース作成禁止

ガバナンス体制:

  • TGB（月1回）: CTO + VPoE + 技術リード6名
  • アーキテクチャ委員会（週1回）: 技術リード4名
  • セキュリティ委員会（週1回）: CISO + セキュリティリード3名
  • データガバナンス委員会（隔週）: CDO + データリード3名

達成度チェック

観点達成基準
全体設計3層アーキテクチャが明確で、各領域の目標Levelに根拠がある
技術選定技術選定に明確な理由があり、技術レーダーと整合している
統合設計プラットフォーム間の連携が具体的に設計されている
段階性Phase分けが適切で、依存関係を考慮している
標準化3層の標準が適切に分類され、自動化方針が明確
ガバナンス組織体制と会議体が機能的に設計されている
L4統合Month 1〜9の知見が適切に統合されている

推定所要時間: 90分