目的
表面的な比較ではなく、ギャップの根本原因を理解し、付け焼き刃ではない本質的な改善戦略を立案する。
ギャップ分析フレームワーク
1. 分析軸の定義
単一の軸ではなく、複数の観点から対象を捉える。
| 軸 | 観点 | 重要度 |
|---|---|---|
| 機能 | 何ができるか | 高 |
| 品質 | どれだけ信頼できるか | 高 |
| 運用 | どれだけ管理しやすいか | 中 |
| セキュリティ | どれだけ安全か | 高 |
| コスト | どれだけ費用対効果があるか | 中 |
2. 類似概念の調査
各軸において、業界標準や先行事例を調査する。
それぞれがどのようにこの問題を解決しているか調査する。
類似概念調査
| 概念 | アプローチ | 強み | 弱み |
|---|---|---|---|
| Cognito | AWSマネージド | AWS統合、スケーラビリティ | カスタマイズ制限 |
| Auth0 | SaaS | 機能豊富、SDK充実 | コスト高、ベンダーロック |
| Keycloak | OSS自前運用 | 柔軟性、コスト | 運用負荷 |
| Firebase Auth | Googleマネージド | 導入容易 | AWS連携が弱い |
業界標準: OAuth 2.0 / OIDC、SAML 2.0 先行事例: Netflix（自前基盤）、Spotify（Auth0採用）
3. ギャップの洗い出し
現行システムと類似概念との差分を特定する。
現行システムが優れている点
| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| カスタム認証フロー | ◎ 完全自由 | △ 制限あり | +柔軟性 |
| 既存DB統合 | ◎ 直接接続 | △ Lambda必要 | +シンプル |
| 監査ログ形式 | ◎ 自社標準 | △ CloudTrail形式 | +統一性 |
現行システムが劣っている点
| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| 可用性 | △ 99.9% | ◎ 99.99% | -0.09% |
| MFA対応 | △ TOTP のみ | ◎ 多方式 | -3方式 |
| スケーラビリティ | △ 手動 | ◎ 自動 | -自動化 |
4. 根本原因の自問
なぜそのギャップが生じているのかを掘り下げる。
これはギャップではなく、当時の合理的判断の結果である。
根本原因分析
ギャップ1: MFA方式の制限
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜTOTPのみ？ | 他を実装していないから |
| 中層 | なぜ実装していない？ | リソースを他に優先したから |
| 深層 | なぜ優先しなかった？ | 当時の要件で十分だったから |
| 根本 | スコープ決定 | 当時の規模に最適化した設計 |
結論: 規模拡大に伴い「埋めるべきギャップ」に変化
ギャップ2: 可用性
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜ99.9%止まり？ | 単一AZ構成だから |
| 中層 | なぜ単一AZ？ | コスト最適化のため |
| 深層 | なぜコスト優先？ | スタートアップ期の制約 |
| 根本 | リソース制約 | 成長段階に応じた投資判断 |
結論: 事業成長に伴いマルチAZ化を検討すべき
5. 戦略立案
根本原因に基づき、付け焼き刃ではない戦略を策定する。
戦略の選択肢:
- 全面Cognito移行 → 移行コスト大、カスタム機能喪失
- 段階的ハイブリッド → 複雑性増、柔軟性維持
- 現行強化 → 運用負荷増、完全制御維持
戦略方針: 「段階的ハイブリッド移行」
現行の強みを維持しながら、マネージドサービスの利点を取り込む。
ギャップ別対応戦略
| ギャップ | 根本原因 | 戦略 | 対応 |
|---|---|---|---|
| MFA方式 | スコープ決定 | 転嫁 | Cognito MFAを部分導入 |
| 可用性 | リソース制約 | 軽減 | マルチAZ化を実施 |
| カスタム認証 | 意図的設計 | 受容 | 現行維持、強みとして活用 |
具体的アクション
- 優先度: 高
- 現行システムのマルチAZ化 - 可用性99.95%を目標
- 優先度: 中
- Cognito MFAの部分導入検証 - 既存フローとの統合設計
- 優先度: 低
- ハイブリッド構成の本番適用 - 監視・運用体制の整備
戦略の根拠
なぜこの戦略か？
- 全面移行はリスクが高く、カスタム機能を失う
- 現行の強み（柔軟性）は競争優位性
- マネージドサービスの「良いとこ取り」が最適
- 段階的移行でリスクを分散
ギャップ分析テンプレート
# [対象] ギャップ分析
## 1. 分析軸
| 軸 | 観点 | 重要度 |
|----|------|--------|
| | | |
## 2. 類似概念調査
| 概念 | アプローチ | 強み | 弱み |
|------|-----------|------|------|
| | | | |
## 3. ギャップマトリクス
### 優れている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
### 劣っている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
## 4. 根本原因分析
### ギャップ: [名前]
| 層 | 問い | 回答 |
|----|------|------|
| 表層 | | |
| 中層 | | |
| 深層 | | |
| 根本 | | |
**結論**: [埋めるべき/受け入れる]
## 5. 戦略立案
### 方針: [一言で]
### ギャップ別対応
| ギャップ | 根本原因 | 戦略 | 対応 |
|----------|---------|------|------|
| | | 回避/軽減/転嫁/受容 | |
### アクション
- 優先度 高:
- 優先度 中:
- 優先度 低:
### 戦略の根拠
**なぜこの戦略か？**
-自問チェックリスト
ギャップを特定したら、以下を必ず自問する：
- なぜこのギャップが存在するのか？
- これは意図的なトレードオフか、見落としか？
- ギャップを埋めることで何を失うか？
- ギャップを埋めないことで何を失うか？
- 同じ問題を別のアプローチで解決できないか？
- このギャップはユーザーにとって本当に重要か？
アンチパターン
| 振る舞い | 問題 | 代わりに |
|---|---|---|
| 全ギャップを埋めようとする | 差別化喪失、リソース浪費 | 優先順位を付ける |
| 表面的な機能追加 | 根本解決にならない | なぜなぜ分析で原因特定 |
| 競合の模倣 | 二番煎じ | 独自の強みを伸ばす |
| ギャップを隠す | 信頼喪失 | 透明に説明し代替案提示 |
ADRへの記録
ギャップ分析に基づく重要な意思決定は ./docs/adr に記録する。
# ADR-XXXX: [ギャップ]への対応方針
## ステータス
採用
## コンテキスト
ギャップ分析により、[対象]において[ギャップ]が特定された。
## 根本原因
[なぜなぜ分析の結果]
## 決定
[戦略: 回避/軽減/転嫁/受容]を選択する。
## 理由
- [根本原因に基づく理由]
- [トレードオフの考慮]
## 結果
- 期待される効果:
- 受け入れるリスク: