tech-selection

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の観点を統合した体系的な技術選定手法を提供します。

目次

1. 技術選定の原則
2. 意思決定フレームワーク
3. 評価基準
4. 技術カテゴリ別選定ガイド
5. ケーススタディ
6. アンチパターン

技術選定の原則

基本原則

原則	説明	理由
ビジネス価値優先	技術的な面白さより、ビジネス目標達成を重視	技術のための技術を避ける
段階的導入	ビッグバンではなく、小さく始めて検証	リスク最小化、学習機会創出
boring technology	枯れた技術を９割、新技術を１割	安定性と革新のバランス
チーム能力重視	学習コストを考慮	デリバリー速度維持
総所有コスト（TCO）評価	ライセンス費だけでなく運用・保守コストも	隠れたコスト把握
ベンダーロックイン回避	標準技術、オープンソース優先	移行の自由度確保
セキュリティファースト	セキュリティは後付けできない	リスク最小化
運用性重視	運用・保守のしやすさを考慮	SRE視点の導入

Choose Boring Technology（Dan McKinley）

【イノベーショントークン】

✓ 使用可能なトークン: 3個まで
✗ 全てを新技術にしない

例：
━━━━━━━━━━━━━━━━━━━━━━━━
[🪙] Kubernetes（新技術）
[🪙] GraphQL（新技術）  
[🪙] Rust（新技術）
━━━━━━━━━━━━━━━━━━━━━━━━
[✓] PostgreSQL（枯れた技術）
[✓] Redis（枯れた技術）
[✓] Nginx（枯れた技術）
[✓] Python（枯れた技術）

→ 新技術は3つまで、残りは実績ある技術を選択

技術的負債との向き合い方

アプローチ	タイミング	適用
戦略的負債	意図的に負債を取る	MVP、PoC、期限厳守時
即座に返済	発生直後	Critical、セキュリティ関連
計画的返済	スプリント内で定期的	中程度の負債
許容する	返済不要と判断	影響小、レガシー部分

# 技術的負債の記録（コード内）
# TODO: [TECH_DEBT] この実装は暫定対応。次回スプリントでリファクタリング予定
#       理由: リリース期限を優先するため
#       影響: パフォーマンス10%低下
#       期限: 2026-05-01
#       担当: @engineer_name
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視点

コスト項目	確認内容	見落としがちなコスト
初期コスト	ライセンス、導入費	トレーニング費
運用コスト	月額料金、保守費	運用人件費
スケールコスト	拡大時の増分	データ転送料
移行コスト	乗り換え時	データ移行、学習

# TCO（Total Cost of Ownership）計算例

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,         # db.t3.medium
    'training': 0,          # 既存スキル
    'operation': 500,       # 運用工数（月5h × $100）
    'migration': 0,
}

mongodb_atlas = TechnologyTCO('MongoDB Atlas')
mongodb_atlas.costs = {
    'initial': 0,
    'monthly': 200,         # M10クラスタ
    'training': 5000,       # 学習コスト
    'operation': 1000,      # 運用工数（慣れていない）
    'migration': 3000,      # データ移行
}

print(f"PostgreSQL 3年TCO: ${postgres_rds.calculate_3year_tco():,.0f}")
# → $23,400

print(f"MongoDB 3年TCO: ${mongodb_atlas.calculate_3year_tco():,.0f}")
# → $51,200

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:
  # ... 50個のサービス

# 問題点:
# - チーム3人に50サービス
# - 運用負荷が膨大
# - ネットワークレイテンシ増

✅ 良い例: 段階的分割

# ✅ 良い例：モノリス→モジュラーモノリス→必要に応じてマイクロサービス
# Phase 1: モノリス（module分割）
monolith:
  modules:
    - user
    - auth
    - notification

# Phase 2: 必要なら分離
services:
  user-auth-service:  # 認証負荷高いため分離
  notification-service:  # 非同期処理のため分離

まとめ：技術選定のチェックリスト

選定前の確認事項

• ビジネス価値: この技術は明確なビジネス価値を生むか？
• 要件適合: 機能要件・非機能要件を満たすか？
• チーム能力: 既存スキルで対応可能か？学習コストは？
• TCO評価: 3年間の総コストを試算したか？
• 運用性: SRE視点で運用可能か？（監視、デバッグ、スケーリング）
• セキュリティ: SecOps視点で安全か？（認証、暗号化、監査）
• エコシステム: コミュニティ、ドキュメント、サポートは充実？
• ロックイン: ベンダー依存度は許容範囲か？移行経路は？
• boring technology: 新技術は3つまでに抑えたか？
• PoC実施: 本番導入前に検証したか？

決定後の文書化

• ADR作成: Architecture Decision Record を記載
• 評価マトリクス: 他選択肢との比較を残す
• リスク洗い出し: 想定されるリスクと対策を記載
• 成功指標: どうなれば成功か定義
• 撤退基準: どうなったら別技術に移行するか定義

導入後のレビュー

• 3ヶ月レビュー: 想定通りか確認
• 6ヶ月レビュー: TCO、パフォーマンス、チーム習熟度
• 1年レビュー: 継続利用 or 見直し判断

---

技術選定は一度きりではなく、継続的な評価と改善のプロセスです。