ストーリー
佐
佐藤CTO
ATAMでリスクを特定した。次はそのリスクをどう管理するかだ
佐
佐藤CTO
リスクを”ゼロ”にすることは不可能だ。重要なのは、リスクを定量化し、許容レベルまで軽減する戦略を持つことだ。そして、残存リスクをステークホルダーと共有する
リスク分析フレームワーク
リスクの定量化
リスクスコア = 影響度 × 発生確率
影響度 (Impact):
5: 致命的（サービス全停止、データ損失、法的制裁）
4: 重大（主要機能の停止、大量のユーザー影響）
3: 中程度（一部機能の劣化、限定的なユーザー影響）
2: 軽微（パフォーマンス低下、代替手段あり）
1: 無視可能（ほぼ影響なし）
発生確率 (Probability):
5: ほぼ確実（90%以上）
4: 高い（60-90%）
3: 中程度（30-60%）
2: 低い（10-30%）
1: 極めて低い（10%未満）
リスクスコアの解釈:
15-25: 即座に対策が必要（赤）
8-14: 軽減策を計画（黄）
1-7: 監視で対応（緑）NexPayのリスク一覧
技術リスク
| ID | リスク | 影響度 | 確率 | スコア | 軽減策 |
|---|---|---|---|---|---|
| TR-1 | イベントスキーマの後方互換性破壊 | 4 | 3 | 12 | Schema Registry導入、互換性テスト自動化 |
| TR-2 | サービス間の障害伝播（カスケード障害） | 5 | 3 | 15 | Circuit Breaker、Bulkhead、タイムアウト設定 |
| TR-3 | Kafkaクラスターの可用性低下 | 5 | 2 | 10 | MSKマルチAZ、レプリケーション、フォールバックキュー |
| TR-4 | Aurora Global DBのレプリケーション遅延 | 4 | 2 | 8 | 遅延モニタリング、書き込み制御、フェイルオーバーテスト |
| TR-5 | Kubernetesの運用複雑性 | 3 | 4 | 12 | マネージドサービス活用、SREチーム強化、Runbook整備 |
セキュリティリスク
| ID | リスク | 影響度 | 確率 | スコア | 軽減策 |
|---|---|---|---|---|---|
| SR-1 | PCI DSS監査での重大指摘 | 5 | 2 | 10 | 早期QSA相談、セルフアセスメント、ギャップ分析 |
| SR-2 | ゼロデイ脆弱性の悪用 | 5 | 2 | 10 | WAF、IDS/IPS、脆弱性スキャン自動化、迅速なパッチ適用 |
| SR-3 | 内部不正によるデータ漏洩 | 5 | 1 | 5 | 最小権限、監査ログ、特権アクセス管理(PAM) |
プロジェクトリスク
| ID | リスク | 影響度 | 確率 | スコア | 軽減策 |
|---|---|---|---|---|---|
| PR-1 | Kotlinスキル不足による開発遅延 | 3 | 4 | 12 | Phase 0で研修、ペアプログラミング、外部支援 |
| PR-2 | スケジュール遅延（18ヶ月超過） | 4 | 3 | 12 | フェーズゲートでスコープ調整、20%バッファ |
| PR-3 | 主要メンバーの離職 | 4 | 2 | 8 | クロストレーニング、ドキュメント、競争力のある報酬 |
軽減策の詳細
TR-2: カスケード障害の防止
■ 多層防御によるカスケード障害対策
Layer 1: Circuit Breaker（Istio）
- 連続5回エラーでサーキットオープン
- 30秒後にハーフオープンで試行
- 障害サービスへのリクエストを遮断
Layer 2: Bulkhead（接続プール分離）
- サービスごとに接続プールを分離
- 1つのサービスの遅延が他に波及しない
- Payment → Account: 専用プール(max 50)
- Payment → Kafka: 専用プール(max 30)
Layer 3: Timeout + Retry
- gRPCタイムアウト: 3秒（デフォルト）
- 決済API: 5秒（外部API含むため長め）
- リトライ: 最大3回、Exponential Backoff
Layer 4: Fallback
- Account Service障害時 → Redisキャッシュから残高取得
- Notification Service障害時 → メッセージをキューに蓄積（後で再送）
- Investment Service障害時 → 注文受付のみ行い、実行は後でリトライTR-1: スキーマ進化管理
■ イベントスキーマの進化戦略
ルール:
1. フィールドの追加: OK（デフォルト値設定必須）
2. フィールドの削除: NG（deprecated属性を付与し、6ヶ月後に削除）
3. フィールド名の変更: NG（新フィールド追加 + 旧フィールドdeprecated）
4. 型の変更: NG（新バージョンのイベントを定義）
自動チェック:
- CI/CDでスキーマ互換性テストを実行
- Schema Registryに登録されたスキーマとの互換性を検証
- 後方互換性が破壊される変更はPRレベルで拒否PR-2: スケジュール遅延対策
■ スケジュールリスクの管理
バッファ戦略:
- 各フェーズに20%のバッファを設定
- Phase 1 (4ヶ月) → 実質3.2ヶ月 + バッファ0.8ヶ月
スコープ調整の優先順位:
Must Have: 決済、残高管理、KYC（Phase 1で必須）
Should Have: 送金、投資（Phase 2で追加）
Could Have: AI不正検知、高度な分析（Phase 3。遅延時にスコープ縮小可能）
Won't Have (this release): マルチ通貨、海外送金
判断ポイント:
- Phase 1終了時: Phase 2のスコープを確定
- Month 12: Phase 3-4のスコープを再評価
- 月次: マイルストーンの達成状況をレビュー残存リスクの管理
リスク受容の判断
■ 残存リスクの受容判断
軽減策を実施した後も残るリスク（残存リスク）:
| リスク | 残存スコア | 受容判断 | 承認者 |
|--------|----------|---------|--------|
| カスケード障害 | 5 (5×1) | 受容（多層防御で確率を大幅低減） | CTO |
| スキーマ互換性 | 4 (4×1) | 受容（自動チェックで発生を予防） | テックリード |
| レプリケーション遅延 | 4 (4×1) | 受容（モニタリングで早期検知） | SREリード |
| ゼロデイ脆弱性 | 5 (5×1) | 受容（多層防御 + 迅速パッチ体制） | CISO |
残存リスクの報告:
- 月次でリスクレジスターを更新
- 新たなリスクの追加、既存リスクの再評価
- 経営層に四半期ごとにリスクサマリーを報告まとめ
| ポイント | 内容 |
|---|---|
| リスク定量化 | 影響度 × 発生確率でリスクスコアを算出 |
| リスク分類 | 技術リスク、セキュリティリスク、プロジェクトリスクの3分類 |
| 軽減策 | 多層防御、自動チェック、スコープ調整の3つのアプローチ |
| 残存リスク | 完全なリスク排除は不可能。受容判断と承認者を明確化 |
チェックリスト
- リスクスコア（影響度×発生確率）で定量的にリスクを評価できた
- 技術・セキュリティ・プロジェクトの3分類でリスクを特定できた
- 各リスクに対する具体的な軽減策を設計できた
- 残存リスクの受容判断と承認者を定義できた
次のステップへ
次は「ADR（Architecture Decision Records）作成」に進みます。アーキテクチャ上の重要な判断を、後から参照できる形式で記録しましょう。
推定読了時間: 30分