ストーリー

アーキテクチャレビューの設計

レビューの目的と構成

■ NexPayアーキテクチャレビュー構成

レビュー1: テクニカルレビュー（エンジニアリングチーム向け）
  目的: 設計の技術的妥当性を検証
  時間: 2時間
  参加者: テックリード、シニアエンジニア、SRE
  焦点: アーキテクチャアプローチ、トレードオフ、実装可能性

レビュー2: セキュリティレビュー（セキュリティチーム向け）
  目的: セキュリティ設計の妥当性を検証
  時間: 1.5時間
  参加者: CISO、セキュリティエンジニア、外部QSA
  焦点: 脅威モデル、PCI DSSスコープ、データ保護

レビュー3: エグゼクティブレビュー（経営層向け）
  目的: 投資承認を得る
  時間: 30分
  参加者: CEO、CFO、CTO、プロダクト責任者
  焦点: ビジネスインパクト、ROI、リスク、タイムライン

テクニカルレビューの準備

レビューアジェンダ

■ テクニカルレビュー（2時間）

00:00-00:20  アーキテクチャ概要
  - ビジネスコンテキストとドライバー
  - C4 Level 1-2の説明
  - 主要な品質属性シナリオ

00:20-00:50  設計の深掘り
  - サービス分解とドメインモデル
  - データアーキテクチャ（イベントソーシング + CQRS）
  - サービス間通信パターン（同期/非同期/Saga）

00:50-01:10  横断的関心事
  - セキュリティアーキテクチャ
  - 可観測性設計
  - DR/BCP設計

01:10-01:30  実装・運用計画
  - 技術スタック選定とADR
  - CI/CDパイプライン
  - 移行フェーズとスケジュール

01:30-02:00  質疑応答とフィードバック
  - ATAMで特定したリスクの共有
  - オープンディスカッション
  - アクションアイテムの整理

想定される質問と回答

■ 想定Q&A（テクニカルレビュー）

Q: なぜモジュラーモノリスではなくマイクロサービスなのか？
A: PCI DSSスコープの分離が最大の理由。モジュラーモノリスでは
   全体がスコープに含まれ、監査コストが大幅に増加する。
   また、20名以上のチームでの並行開発とデプロイの独立性が
   ビジネス要件として必須。（ADR-001参照）

Q: イベントソーシングの運用経験がチームにない。大丈夫か？
A: Phase 0でアーキテクトコンサルの支援を受けつつ、
   プロトタイプで検証する。決済サービスのみに限定適用し、
   他サービスはシンプルなCRUDを採用する。（ADR-002参照）

Q: Kafka障害時に決済が止まるのではないか？
A: 決済の同期フロー（残高確認→与信→引落）にKafkaは含まれない。
   Kafkaは後続の非同期処理（通知、ポイント付与等）のみ。
   決済完了後のイベント発行が遅延しても決済自体は完了している。

Q: マルチリージョンのコストは正当化できるか？
A: Tier 1（決済）のRTO 1分を満たすにはActive構成が必須。
   Tier 3-4はWarm/Cold Standbyでコストを抑える。
   リージョン障害による決済停止の損害額（分あたり¥200万）
   を考慮すると、年間¥1,500万のコスト増は十分に正当化される。

エグゼクティブレビューの準備

スライド構成

■ エグゼクティブレビュー（30分）

Slide 1: タイトル（30秒）
  「NexPay技術アーキテクチャ提案」

Slide 2: 市場機会とビジネス目標（2分）
  - デジタル決済市場の成長（年20%）
  - NexPayのポジショニング
  - 月間取引額1,000億円を目指すロードマップ

Slide 3: 技術戦略の3本柱（3分）
  ① 安全な決済基盤（PCI DSS準拠）
  ② スケーラブルなプラットフォーム（100万ユーザー対応）
  ③ 高速な機能開発（週次リリース体制）

Slide 4: アーキテクチャ概要（3分）
  - 1枚の全体図（C4 Level 1）
  - 技術的な詳細は省き、ビジネス的な意味を説明
  - 「6つの専門チームが独立して開発・リリースできる構造」

Slide 5: 投資とリターン（5分）
  - 投資: ¥15.3億（18ヶ月）
  - 年間効果: ¥26.5億
  - ROI: 340%（3年間）
  - 投資回収: 本番稼働後8ヶ月

Slide 6: タイムライン（3分）
  - 4つのフェーズの概要
  - 主要マイルストーン
  - Phase 1完了（Month 7）でパイロット決済開始

Slide 7: リスクと対策（3分）
  - 技術リスク: 上位3つとその軽減策
  - 「何もしないリスク」の提示
  - セキュリティリスクへの対策

Slide 8: 承認依頼（2分）
  - Phase 0（¥2億）の実行承認を依頼
  - 3ヶ月後の報告予定
  - Phase 1への移行判断はPhase 0完了時に

質疑応答（8分）

経営層向けの言い換え

■ 技術用語のビジネス翻訳

技術の言葉 → ビジネスの言葉:

マイクロサービス → 「6つの専門チームが独立して機能をリリースできる構造」
イベントソーシング → 「すべての取引履歴を完全に記録し、監査に即座に対応」
CI/CD → 「開発した機能を安全かつ迅速に本番に届ける自動パイプライン」
Canaryデプロイ → 「新機能をまず5%のユーザーで検証し、問題なければ全体に展開」
Kubernetes → 「トラフィックの増減に応じて自動でサーバーを増減する仕組み」
mTLS → 「すべてのサービス間通信を暗号化し、なりすましを防止」
Circuit Breaker → 「1つのサービスの障害が全体に波及しない安全装置」
SLO 99.99% → 「年間で停止が許されるのは52分以内」

プレゼンテーションの技術

効果的な伝え方

■ プレゼンテーションの5原則

1. 聴衆に合わせる
   - エンジニア: 技術的な深さ、トレードオフの議論
   - 経営層: ビジネスインパクト、数字で語る

2. ストーリーで語る
   - 問題 → 解決策 → 効果 の流れ
   - 「現在〇〇という課題があり、△△を実施することで、
      □□の効果が得られます」

3. 数字を使う
   - 「速い」→「p99レイテンシ800ms以内」
   - 「安全」→「PCI DSS Level 1準拠、99.99%可用性」
   - 「効果的」→「ROI 340%、投資回収8ヶ月」

4. ビジュアルで見せる
   - アーキテクチャ図（C4モデル）
   - タイムライン図
   - コスト/効果のグラフ

5. 質問を歓迎する
   - 「良い質問ですね」で受ける
   - 答えられない場合は「確認して後日回答します」
   - 事前にFAQを準備しておく

まとめ

チェックリスト

• テクニカルレビューのアジェンダを設計できた
• 想定質問と回答を準備できた
• エグゼクティブレビュー用のスライド構成を作成できた
• 技術用語をビジネスの言葉に翻訳できた

次のステップへ

次は「演習：アーキテクチャレビューを実施しよう」に進みます。Step 5で学んだATAM、リスク分析、ADR、プレゼンテーションを統合して、セルフレビューを実施しましょう。

推定読了時間: 30分