| name | tech-selection |
| description | 技術選定のベストプラクティスガイド。ADR、評価フレームワーク、意思決定プロセス、各技術カテゴリ（クラウド、データベース、言語、フレームワーク）の選定基準、コスト・運用性・セキュリティ評価を網羅。DevOps/SRE/FinOps/SecOps観点を統合した技術的意思決定を支援。Use when: selecting technologies, evaluating tools/platforms, making architectural decisions, creating ADRs, avoiding vendor lock-in, assessing technical debt, or choosing tech stack. |
技術選定ベストプラクティス
技術選定は、システムの成功を左右する重要な意思決定です。このガイドでは、DevOps/SRE/FinOps/SecOpsの観点を統合した体系的な技術選定手法を提供します。
目次
- 技術選定の原則
- 意思決定フレームワーク
- 評価基準
- 技術カテゴリ別選定ガイド
- ケーススタディ
- アンチパターン
技術選定の原則
基本原則
| 原則 | 説明 | 理由 |
|---|
| ビジネス価値優先 | 技術的な面白さより、ビジネス目標達成を重視 | 技術のための技術を避ける |
| 段階的導入 | ビッグバンではなく、小さく始めて検証 | リスク最小化、学習機会創出 |
| boring technology | 枯れた技術を９割、新技術を１割 | 安定性と革新のバランス |
| チーム能力重視 | 学習コストを考慮 | デリバリー速度維持 |
| 総所有コスト（TCO）評価 | ライセンス費だけでなく運用・保守コストも | 隠れたコスト把握 |
| ベンダーロックイン回避 | 標準技術、オープンソース優先 | 移行の自由度確保 |
| セキュリティファースト | セキュリティは後付けできない | リスク最小化 |
| 運用性重視 | 運用・保守のしやすさを考慮 | SRE視点の導入 |
Choose Boring Technology（Dan McKinley）
【イノベーショントークン】
✓ 使用可能なトークン: 3個まで
✗ 全てを新技術にしない
例：
━━━━━━━━━━━━━━━━━━━━━━━━
[🪙] Kubernetes（新技術）
[🪙] GraphQL（新技術）
[🪙] Rust（新技術）
━━━━━━━━━━━━━━━━━━━━━━━━
[✓] PostgreSQL（枯れた技術）
[✓] Redis（枯れた技術）
[✓] Nginx（枯れた技術）
[✓] Python（枯れた技術）
→ 新技術は3つまで、残りは実績ある技術を選択
技術的負債との向き合い方
| アプローチ | タイミング | 適用 |
|---|
| 戦略的負債 | 意図的に負債を取る | MVP、PoC、期限厳守時 |
| 即座に返済 | 発生直後 | Critical、セキュリティ関連 |
| 計画的返済 | スプリント内で定期的 | 中程度の負債 |
| 許容する | 返済不要と判断 | 影響小、レガシー部分 |
def temporary_workaround():
pass
意思決定フレームワーク
ADR（Architecture Decision Records）
ADRとは: アーキテクチャ上の重要な決定を記録する文書
ADRテンプレート
# ADR-001: データベースとしてPostgreSQLを採用
## ステータス
採用済み（2026-04-21）
## コンテキスト
新規サービスのデータベースを選定する必要がある。以下の要件：
- RDB必須（トランザクション、複雑なクエリ）
- スケーラビリティ（初期：10万レコード、3年後：1,000万レコード想定）
- 予算：月$500以下
- チームの経験：PostgreSQL（高）、MySQL（中）、MongoDB（低）
## 検討した選択肢
### 1. PostgreSQL
- ✅ チームの経験豊富
- ✅ JSON型でドキュメント DB的使用も可能
- ✅ AWS RDS、Aurora PostgreSQLで運用シンプル
- ✅ 拡張機能豊富（PostGIS等）
- ⚠️ 水平スケーリングはやや複雑
### 2. MySQL
- ✅ 実績豊富、枯れた技術
- ✅ Aurora MySQL のコスト効率良い
- ❌ チーム経験が中程度
- ❌ JSON型のサポートがPostgreSQLより弱い
### 3. MongoDB
- ✅ 柔軟なスキーマ
- ✅ 水平スケーリング容易
- ❌ チーム経験なし（学習コスト大）
- ❌ トランザクションサポートが後付け
- ❌ RDBの置き換えとしては不適
## 決定
**PostgreSQL（AWS RDS）を採用**
## 理由
1. **チーム能力**: 最も経験が豊富で、即座に生産性発揮
2. **機能性**: JSON型でドキュメントDB的使用も可能、要件を満たす
3. **コスト**: db.t3.medium で月$150程度、予算内
4. **運用性**: AWS RDSで自動バックアップ、パッチ適用
5. **セキュリティ**: 暗号化、IAM認証サポート
6. **将来性**: Aurora PostgreSQL への移行パスあり
## 結果
- デリバリー速度: 高（学習不要）
- コスト: 想定内
- 運用負荷: 低（RDSのマネージド機能活用）
## 補足
- スケーリング限界に達したら Aurora PostgreSQL 移行を検討
- 読み取り負荷が高まったらリードレプリカ追加
評価マトリクス
| 評価項目 | 重み | PostgreSQL | MySQL | MongoDB |
|---|
| 機能要件充足 | 30% | 9/10 | 8/10 | 6/10 |
| チーム経験 | 25% | 10/10 | 6/10 | 2/10 |
| 運用性 | 20% | 9/10 | 9/10 | 5/10 |
| コスト | 15% | 8/10 | 9/10 | 7/10 |
| セキュリティ | 10% | 9/10 | 9/10 | 7/10 |
| 加重スコア | - | 8.85 | 7.65 | 5.15 |
SWOT分析
【技術選択のSWOT分析例：Kubernetes】
Strengths（強み）
├─ コンテナオーケストレーション標準
├─ 豊富なエコシステム
├─ クラウドネイティブ対応
└─ 宣言的設定（IaC）
Weaknesses（弱み）
├─ 学習曲線が急
├─ 小規模環境ではオーバー
├─ 運用の複雑性
└─ デバッグが難しい
Opportunities（機会）
├─ マルチクラウド対応
├─ マネージドサービス（EKS/GKE/AKS）
├─ GitOps実践基盤
└─ サービスメッシュ統合
Threats（脅威）
├─ 技術変化が早い
├─ セキュリティ設定ミスリスク
├─ ベンダー独自機能への依存
└─ 複雑性による障害リスク
結論：中〜大規模なマイクロサービスには適、
小規模・モノリスには過剰
評価基準
総合評価の8つの軸
1. 機能性（Functionality）
| 評価項目 | 確認内容 | ツール例 |
|---|
| 要件充足 | 必須機能を満たすか | 機能一覧チェック |
| 拡張性 | 将来の要件に対応可能か | ロードマップ確認 |
| 互換性 | 既存システムとの統合 | API仕様確認 |
2. 運用性（Operability）- SRE視点
| 評価項目 | 確認内容 | Good | Bad |
|---|
| モニタリング | メトリクス出力可能か | Prometheus metrics | ログのみ |
| ログ管理 | 構造化ログ対応 | JSON logs | 非構造化 |
| デバッグ性 | トラブルシュート容易性 | 詳細エラー | 曖昧なエラー |
| 設定管理 | 環境別設定の容易性 | 環境変数、Config | ハードコード |
| バックアップ | データ保護機能 | 自動バックアップ | 手動のみ |
| スケーラビリティ | 負荷増加への対応 | Auto Scaling | 手動スケール |
operability_checklist:
monitoring:
- [ ] Prometheusメトリクス出力
- [ ] ヘルスチェックエンドポイント
- [ ] SLI測定可能
logging:
- [ ] 構造化ログ（JSON）
- [ ] ログレベル動的変更
- [ ] 分散トレーシング対応
deployment:
- [ ] ローリングアップデート対応
- [ ] ロールバック可能
- [ ] カナリアデプロイ対応
disaster_recovery:
- [ ] 自動バックアップ
- [ ] PITR（ポイントインタイムリカバリ）
- [ ] クロスリージョンレプリケーション
3. セキュリティ（Security）- SecOps視点
| 評価項目 | 確認内容 | チェックポイント |
|---|
| 脆弱性管理 | CVE対応速度 | セキュリティパッチ頻度 |
| 認証・認可 | IAM統合 | OAuth2、OIDC対応 |
| 暗号化 | データ保護 | 転送時・保管時暗号化 |
| 監査ログ | 操作記録 | 改ざん防止、長期保管 |
| コンプライアンス | 規制対応 | GDPR、PCI-DSS等 |
# セキュリティ評価シート
## 認証・認可
- [ ] Multi-Factor Authentication (MFA)
- [ ] Role-Based Access Control (RBAC)
- [ ] 最小権限の原則
- [ ] セッション管理（タイムアウト）
## データ保護
- [ ] 転送時暗号化（TLS 1.2以上）
- [ ] 保管時暗号化（AES-256）
- [ ] 鍵管理（KMS利用）
- [ ] データマスキング
## 脅威対策
- [ ] SQLインジェクション対策
- [ ] XSS対策
- [ ] CSRF対策
- [ ] DDoS対策
## セキュリティ運用
- [ ] 自動脆弱性スキャン
- [ ] ペネトレーションテスト実施
- [ ] セキュリティパッチ自動適用
- [ ] インシデント対応手順
4. コスト（Cost）- FinOps視点
| コスト項目 | 確認内容 | 見落としがちなコスト |
|---|
| 初期コスト | ライセンス、導入費 | トレーニング費 |
| 運用コスト | 月額料金、保守費 | 運用人件費 |
| スケールコスト | 拡大時の増分 | データ転送料 |
| 移行コスト | 乗り換え時 | データ移行、学習 |
class TechnologyTCO:
def __init__(self, name):
self.name = name
self.costs = {
'initial': 0,
'monthly': 0,
'training': 0,
'operation': 0,
'migration': 0,
}
def calculate_3year_tco(self):
"""3年間のTCO計算"""
initial = self.costs['initial'] + self.costs['training'] + self.costs['migration']
monthly = (self.costs['monthly'] + self.costs['operation']) * 36
return initial + monthly
def cost_per_user_per_month(self, users):
"""ユーザーあたり月額コスト"""
total_monthly = self.costs['monthly'] + self.costs['operation']
return total_monthly / users if users > 0 else 0
postgres_rds = TechnologyTCO('PostgreSQL RDS')
postgres_rds.costs = {
'initial': 0,
'monthly': 150,
'training': 0,
'operation': 500,
'migration': 0,
}
mongodb_atlas = TechnologyTCO('MongoDB Atlas')
mongodb_atlas.costs = {
'initial': 0,
'monthly': 200,
'training': 5000,
'operation': 1000,
'migration': 3000,
}
print(f"PostgreSQL 3年TCO: ${postgres_rds.calculate_3year_tco():,.0f}")
print(f"MongoDB 3年TCO: ${mongodb_atlas.calculate_3year_tco():,.0f}")
5. パフォーマンス
| 評価項目 | 測定方法 | 目標値例 |
|---|
| レイテンシ | ベンチマーク | p95 < 200ms |
| スループット | 負荷テスト | 1000 req/s |
| リソース効率 | CPU/メモリ使用率 | < 70% |
6. 成熟度・エコシステム
| 評価項目 | 確認方法 | Good | Bad |
|---|
| コミュニティ | GitHub Stars, Contributors | 活発 | 停滞 |
| ドキュメント | 公式ドキュメント品質 | 充実 | 不足 |
| サポート | 商用サポート有無 | あり | なし |
| 採用実績 | 大規模導入事例 | 多数 | 少数 |
| バージョンアップ頻度 | リリースサイクル | 定期的 | 不定期 |
7. チーム適合性
| 評価項目 | 確認内容 |
|---|
| 既存スキル | チームメンバーの経験 |
| 学習曲線 | 習得難易度 |
| 採用市場 | エンジニア採用の容易性 |
# チーム適合性評価
## 現在のスキルマップ
| 技術 | メンバーA | メンバーB | メンバーC | 平均 |
|------|---------|---------|---------|------|
| PostgreSQL | 上級 | 中級 | 中級 | 中〜上 |
| MongoDB | なし | 初級 | なし | 初級未満 |
| Redis | 中級 | 中級 | 初級 | 初〜中 |
## 学習コスト見積もり
- PostgreSQL: 0時間（既存スキル）
- MongoDB: 40時間/人 × 3人 = 120時間
- Redis: 10時間/人 × 1人 = 10時間
## 採用市場
- PostgreSQL: 豊富（求人多数）
- MongoDB: 中程度
- Redis: 豊富
8. ベンダーロックイン度
| 評価 | 説明 | リスク |
|---|
| 低 | オープンスタンダード、互換性高 | 移行容易 |
| 中 | 一部独自機能使用 | 移行コスト発生 |
| 高 | ベンダー独自技術に深く依存 | 移行困難 |
【ロックイン度の例】
低ロックイン:
- Kubernetes（CNCF標準）
- PostgreSQL（オープンソース）
- Docker（OCI標準）
中ロックイン:
- AWS Lambda（CloudEvents対応進行中）
- GitHub Actions（YAML形式は移行可能）
高ロックイン:
- AWS DynamoDB（独自API）
- Google BigQuery（独自SQL方言）
- Salesforce（独自エコシステム）
ロックイン緩和策:
→ 抽象化レイヤー導入
→ マルチクラウド対応設計
→ データエクスポート機能確保
技術カテゴリ別選定ガイド
1. クラウドプロバイダ選定
主要クラウドの比較
| プロバイダ | 強み | 弱み | 適合ケース |
|---|
| AWS | 最大のサービス数、成熟度 | 複雑、コスト管理難 | エンタープライズ、フルマネージド重視 |
| GCP | AI/ML、データ分析に強い | サービス終了リスク | データサイエンス、Kubernetes |
| Azure | Microsoft製品統合 | Linux対応は後発 | .NET、Windows環境 |
| マルチクラウド | ベンダーロックイン回避 | 複雑性増大、コスト高 | リスク分散、特定要件 |
クラウド選定の決定木
スタート
↓
既存MS製品（Windows/AD）が中心？
YES → Azure
NO ↓
↓
AI/ML、BigDataが主要ワークロード？
YES → GCP
NO ↓
↓
最大限のサービス選択肢、成熟度重視？
YES → AWS
NO ↓
↓
ベンダーロックイン絶対回避？
YES → マルチクラウド（Kubernetes基盤）
NO → AWS（無難な選択）
FinOps視点のクラウド比較
| 項目 | AWS | GCP | Azure |
|---|
| コスト可視化 | Cost Explorer（優秀） | Billing Console（良） | Cost Management（良） |
| 割引制度 | RI, Savings Plans | Committed Use | Reserved Instances |
| 最大割引率 | 最大72% | 最大57% | 最大72% |
| 無料枠 | 12ヶ月 | $300クレジット | 12ヶ月 |
2. データベース選定
データベース選定フローチャート
データ特性の確認
↓
トランザクション必須？
YES → ACID RDB へ
NO → NoSQL候補
↓ ↓
スキーマ固定？ データ構造は？
YES → PostgreSQL Key-Value → Redis/DynamoDB
NO → JSON型活用 Document → MongoDB/DynamoDB
↓ Column → Cassandra
スケール要件？ Graph → Neo4j
大規模 → Aurora
中小規模 → RDS
データベース比較マトリクス
| DB | タイプ | スケール | トランザクション | 複雑クエリ | コスト | 学習曲線 |
|---|
| PostgreSQL | RDB | ↑（垂直） | ◎ | ◎ | 中 | 低 |
| MySQL | RDB | ↑（垂直） | ◎ | ○ | 低 | 低 |
| MongoDB | Document | ◎（水平） | ○ | △ | 中 | 中 |
| DynamoDB | Key-Value | ◎（水平） | ○ | ✗ | 低〜高※ | 中 |
| Redis | Key-Value | ◎（水平） | △ | ✗ | 低 | 低 |
| Cassandra | Wide Column | ◎（水平） | △ | △ | 高 | 高 |
※DynamoDBはアクセスパターン次第でコスト変動大
ユースケース別推奨
| ユースケース | 推奨DB | 理由 |
|---|
| ECサイト | PostgreSQL + Redis | トランザクション + キャッシュ |
| IoTデータ | Cassandra / TimescaleDB | 大量時系列データ |
| SNS | MongoDB + Redis | 柔軟なスキーマ + 高速読取 |
| 分析基盤 | BigQuery / Redshift | 大規模分析専用 |
| セッション管理 | Redis / DynamoDB | 高速Key-Value |
3. プログラミング言語選定
言語比較
| 言語 | 強み | 弱み | 適用領域 |
|---|
| Python | 学習容易、AI/ML豊富 | 速度、型安全性 | データ分析、バックエンド、自動化 |
| TypeScript | 型安全、フロント/バック両対応 | ビルド必要 | Webアプリ（フルスタック） |
| Go | 高速、並行処理、シンプル | エコシステム小 | マイクロサービス、CLI、インフラツール |
| Rust | 最高の安全性・速度 | 学習曲線急 | システムプログラミング、パフォーマンス重視 |
| Java | 成熟、エンタープライズ | 冗長、重い | エンタープライズ、Android |
| JavaScript | Web標準、巨大エコシステム | 型安全性、混沌 | フロントエンド必須 |
言語選定の決定要因
決定要因の優先順位:
1_チームスキル: 40%
- 既存メンバーの経験
- 採用市場の状況
2_要件適合: 30%
- パフォーマンス要件
- エコシステム（ライブラリ）
3_長期保守性: 20%
- コミュニティ活発度
- バージョンアップ安定性
- 企業サポート
4_その他: 10%
- デプロイサイズ
- 開発ツール充実度
4. フレームワーク選定
バックエンドフレームワーク（Python例）
| フレームワーク | タイプ | 学習曲線 | パフォーマンス | 適用 |
|---|
| FastAPI | 軽量 | 低 | 高 | API、マイクロサービス |
| Django | フルスタック | 中 | 中 | 管理画面付きWeb |
| Flask | 軽量 | 低 | 中 | 小規模API、柔軟性重視 |
フロントエンドフレームワーク
| フレームワーク | 特徴 | 学習曲線 | エコシステム | 適用 |
|---|
| React | 柔軟、巨大コミュニティ | 中 | 最大 | SPA全般 |
| Vue | シンプル、段階的導入可 | 低 | 大 | 中小規模SPA |
| Svelte | コンパイル、高速 | 低 | 小 | パフォーマンス重視 |
| Next.js | React + SSR | 中 | 大 | SEO重視、フルスタック |
5. インフラストラクチャ選定
コンテナオーケストレーション
| 選択肢 | 複雑度 | 機能 | コスト | 適用規模 |
|---|
| Docker Compose | 低 | 基本 | 無料 | 開発、単一ホスト |
| ECS Fargate | 低 | 中 | 中 | AWS環境、中規模 |
| Kubernetes | 高 | 最大 | 高 | 大規模、マルチクラウド |
| Nomad | 中 | 中 | 低 | シンプル志向 |
CI/CDツール
| ツール | ホスティング | コスト | 機能 | 適用 |
|---|
| GitHub Actions | SaaS | 無料〜 | 豊富 | GitHub利用時 |
| GitLab CI | SaaS/Self | 無料〜 | 豊富 | GitLab利用時 |
| Jenkins | Self | 無料 | 最大（複雑） | カスタマイズ重視 |
| CircleCI | SaaS | 無料〜 | 中 | シンプル志向 |
ケーススタディ
ケース1: スタートアップのMVP構築
状況
- チーム: エンジニア2名（フルスタック）
- 予算: 月$500
- 期限: 3ヶ月でMVPリリース
- 要件: Webアプリ、ユーザー認証、決済
選定結果
| カテゴリ | 選定 | 理由 |
|---|
| クラウド | AWS | 無料枠活用、豊富なマネージドサービス |
| バックエンド | Python + FastAPI | 迅速開発、シンプル |
| フロントエンド | Next.js | SSR、API Routes、高速開発 |
| DB | PostgreSQL (RDS) | 無料枠、チームの経験 |
| 認証 | Auth0 | 実装時間削減、セキュリティ確保 |
| 決済 | Stripe | 統合容易、信頼性 |
| ホスティング | Vercel (Frontend) + ECS Fargate (API) | 簡単デプロイ、低コスト |
| CI/CD | GitHub Actions | 無料、設定簡単 |
結果
- ✅ 2.5ヶ月でリリース
- ✅ 月額コスト: $380
- ✅ 技術的負債: 最小限（boring technologyの採用）
ケース2: エンタープライズのマイクロサービス化
状況
- チーム: 50名（複数チーム）
- 既存: モノリスJavaアプリ（10年運用）
- 課題: デプロイ速度、スケーラビリティ
- 制約: 段階的移行、既存システム並行稼働
選定結果
| カテゴリ | 選定 | 理由 |
|---|
| クラウド | AWS | エンタープライズサポート充実 |
| オーケストレーション | EKS (Kubernetes) | 標準化、マルチクラウド対応 |
| 言語 | Java (既存) + Go (新規) | 既存資産活用 + 高速軽量 |
| API Gateway | Kong | オープンソース、機能豊富 |
| サービスメッシュ | Istio | トラフィック制御、観測性 |
| DB | Aurora PostgreSQL + DynamoDB | 用途別使い分け |
| 監視 | Prometheus + Grafana | CNCF標準、柔軟 |
| CI/CD | GitLab CI + ArgoCD | GitOps、宣言的デプロイ |
移行戦略
Phase 1 (6ヶ月): インフラ構築
- EKSクラスタ構築
- CI/CDパイプライン整備
- モニタリング基盤
Phase 2 (12ヶ月): Strangler Fig パターン
- 新機能はマイクロサービスで
- 既存機能は段階的に切り出し
- API Gatewayでルーティング制御
Phase 3 (18ヶ月): モノリス縮小
- コア機能のみモノリスに残す
- 残りは全てマイクロサービス化
アンチパターン
1. Resume-Driven Development（RDD）
❌ 悪い例: 履歴書を飾るために新技術を導入
# ダメな意思決定例
「Kubernetesが最新だから使おう」
「Rustが速いらしいから全部書き換えよう」
「Reactが流行ってるからVueから移行しよう」
問題点:
- ビジネス価値がない
- チームの学習コスト無視
- 既存システムの安定性を犠牲
✅ 良い例: ビジネス価値を起点に判断
# 正しい意思決定例
「スケーラビリティ問題を解決するためKubernetesを検討」
「パフォーマンスがビジネス影響大のため、一部コアをRust移行検討」
「採用市場でReactエンジニアが豊富なため、次期PJで採用」
2. Golden Hammer（万能ハンマー）
❌ 悪い例: 1つの技術で全てを解決
「MongoDBを知ってるから、全部MongoDBで」
「Javaが得意だから、全てJavaで」
問題点:
- 適材適所でない
- 非効率なアーキテクチャ
✅ 良い例: Polyglot Persistence
- トランザクションデータ: PostgreSQL
- キャッシュ: Redis
- 全文検索: Elasticsearch
- セッション: DynamoDB
- ログ: S3 + Athena
3. Not Invented Here（NIH症候群）
❌ 悪い例: 既存ツールを使わず自作
「認証システムを自作しよう」
「独自のORMを作ろう」
「監視ツールを自分たちで開発しよう」
問題点:
- 車輪の再発明
- メンテナンスコスト
- セキュリティリスク
✅ 良い例: 既存ツール活用
「Auth0/Cognito で認証」
「既存ORM（SQLAlchemy/TypeORM）を使用」
「Prometheus/Datadogで監視」
自作するのは:
- ビジネスロジック（差別化要因）
- 既存ツールで実現不可能な部分のみ
4. Premature Optimization（早すぎる最適化）
❌ 悪い例: 計測前にマイクロ最適化
def calculate(data):
return [x*2 if x%2==0 else x*3 for x in (int(i) for i in data.split(',') if i)]
✅ 良い例: 計測→ボトルネック特定→最適化
def calculate(data):
numbers = [int(x) for x in data.split(',') if x]
results = []
for num in numbers:
if num % 2 == 0:
results.append(num * 2)
else:
results.append(num * 3)
return results
5. Cargo Cult Programming（カーゴカルト）
❌ 悪い例: 理解せずにベストプラクティスをコピペ
services:
user-service:
auth-service:
notification-service:
email-service:
sms-service:
push-service:
✅ 良い例: 段階的分割
monolith:
modules:
- user
- auth
- notification
services:
user-auth-service:
notification-service:
まとめ：技術選定のチェックリスト
選定前の確認事項
決定後の文書化
導入後のレビュー
技術選定は一度きりではなく、継続的な評価と改善のプロセスです。
