ストーリー
佐
佐藤CTO
技術選定は、チームの生産性を左右する重要な決断だ
佐
佐藤CTO
流行っているからではなく、プロジェクトとチームに合った技術を選ぶ。その判断基準を持つことが大事だ
Technology Radarアプローチ
ThoughtWorksのTechnology Radarのように、技術を4つのリングで分類します。
| リング | 意味 | アクション |
|---|---|---|
| Adopt（採用） | 実績があり推奨 | 積極的に使用する |
| Trial（試行） | 有望だが検証中 | PoCで検証する |
| Assess（評価） | 注目に値する | 調査・学習する |
| Hold（保留） | 非推奨 | 新規利用を避ける |
評価基準マトリクス
| 基準 | 重み | 確認ポイント |
|---|---|---|
| 成熟度 | 20% | リリース年数、メジャーバージョン、安定性 |
| コミュニティ | 15% | GitHub Stars、Stack Overflow回答数、カンファレンス |
| エコシステム | 15% | ライブラリ数、ツール連携、プラグイン |
| チームスキル | 20% | 既存メンバーの経験、学習コスト |
| パフォーマンス | 10% | ベンチマーク結果、ユースケースとの適合性 |
| ロックインリスク | 10% | ベンダー依存度、移行容易性、OSS vs 商用 |
| 運用性 | 10% | デプロイ容易性、監視・デバッグ、ドキュメント |
スタック別の選定ポイント
フロントエンド
| 技術 | 適したケース | 注意点 |
|---|---|---|
| React | 大規模SPA、エコシステム重視 | バンドルサイズ管理 |
| Next.js | SSR/SSG、SEO重要 | Vercel依存のリスク |
| Vue.js | 中規模、学習容易性重視 | 大規模での実績が少ない |
バックエンド
| 技術 | 適したケース | 注意点 |
|---|---|---|
| Node.js/TypeScript | フルスタック統一、I/O多い | CPU集約型処理に不向き |
| Go | マイクロサービス、高パフォーマンス | エコシステムがJSほど広くない |
| Python/FastAPI | ML連携、プロトタイピング | 型安全性、パフォーマンス |
データストア
| 技術 | 適したケース | 注意点 |
|---|---|---|
| PostgreSQL | 汎用RDBMS、JSON対応 | 水平スケーリング |
| MongoDB | スキーマレス、ドキュメント | トランザクション制限 |
| Redis | キャッシュ、セッション | 永続化の信頼性 |
ロックインリスクの評価
| リスクレベル | 特徴 | 例 |
|---|---|---|
| 低 | OSS、標準API準拠 | PostgreSQL、Kubernetes |
| 中 | マネージドサービス | AWS RDS、CloudSQL |
| 高 | プロプライエタリAPI | DynamoDB、Firestore |
| 極高 | 独自言語・フレームワーク | 特定PaaSの独自機能 |
緩和策:
- 抽象化レイヤー（ポート＆アダプター）を導入
- マルチクラウド対応のOSSを優先
- 定期的に移行コストを再評価
PoCの進め方
| フェーズ | 期間 | 成果物 |
|---|---|---|
| 1. 仮説設定 | 1日 | 検証したい技術的仮説リスト |
| 2. 最小実装 | 3-5日 | 動くプロトタイプ |
| 3. 評価 | 1-2日 | パフォーマンス計測、使用感レポート |
| 4. 判定 | 1日 | 採用/不採用の判定とADR |
まとめ
| ポイント | 内容 |
|---|---|
| 体系的評価 | 感覚ではなく重み付きスコアで評価する |
| チーム適合 | 技術の良さだけでなくチームとの適合を重視 |
| ロックイン | ベンダーロックインのリスクを常に評価する |
| PoC | 不確実性が高い技術はPoCで検証する |
チェックリスト
- Technology Radarの4リングを理解した
- 技術評価の基準マトリクスを把握した
- ロックインリスクの評価方法を理解した
- PoCの進め方を把握した
次のステップへ
次はレビュー可能な設計書の書き方を学びます。
推定読了時間: 30分