技術選定は「一番良い技術を選ぶこと」ではありません。チームと事業にとって、いま妥当な技術を、説明できる形で選ぶことです。このドキュメントでは、そのための考え方・プロセス・評価観点・アンチパターンをまとめます。
目次
- 基本原則
- 選定プロセス
- 評価観点チェックリスト
- 比較表（スコアリング）の例
- 領域別のポイント
- よくあるアンチパターン
- ADR（Architecture Decision Record）テンプレート
- 導入後に行うこと
- まとめ：判断に迷ったときの問い
1. 基本原則
| 原則 | 内容 |
|---|---|
| 課題から始める | 技術の話の前に「何を解決したいか」を言語化する。手段が目的化していないかを確認する。 |
| 退屈な技術を優先する | 実績があり、枯れていて、問題が出たときに情報が見つかる技術を基本にする（“Choose Boring Technology”）。 |
| イノベーショントークンは有限 | 新しい技術を導入できる数には限りがある。事業の差別化につながる領域に絞って使う。 |
| 可逆性で慎重さを変える | 後から変えにくい決定（言語、DB、クラウド基盤）は慎重に。変えやすい決定（ライブラリ、ツール）は素早く決めて試す。 |
| チームが運用できるか | 導入できることと、数年運用し続けられることは別物。保守・障害対応・採用まで含めて考える。 |
| 決定を記録する | 「なぜ選んだか」「何を選ばなかったか」を残す。将来の見直しの土台になる。 |
2. 選定プロセス
Step 1. 課題と要件を明確にする
- 解決したい課題、背景、ゴール
- 機能要件：何ができる必要があるか
- 非機能要件：性能、可用性、スケーラビリティ、セキュリティ、コンプライアンス
- 制約条件：予算、期限、既存システム、社内標準、チームのスキル
- 想定する期間と規模：PoCか、数年運用する本番か。ユーザー数・データ量の見込み
要件には優先度（Must / Should / Could）をつけておくと、後の比較がぶれにくくなります。
Step 2. 候補を洗い出す
- 2〜4案程度に絞る（多すぎると比較が浅くなる）
- 「何もしない」「既存技術で頑張る」案も必ず候補に入れる
- 自作（Build）・OSS採用・SaaS/マネージドサービス購入（Buy）の観点で幅を持たせる
Step 3. 評価軸を決めてから比較する
- 候補を見る前に評価軸と重み付けを決める（後付けだと結論ありきになりやすい）
- 評価観点は「3. 評価観点チェックリスト」を参照
Step 4. 検証する（PoC / スパイク）
- 机上の比較だけで決めない。リスクが高い部分を中心に小さく試す
- 検証項目と合格基準を事前に決め、期間を区切る（例：1〜2週間）
- 「動いた」だけでなく、つまずいた点・ドキュメントの質・デバッグのしやすさも記録する
Step 5. 意思決定と合意形成
- 比較結果・検証結果・推奨案とその理由をまとめ、関係者でレビューする
- 反対意見や懸念は記録に残し、リスクとして扱う
- 最終決定者を明確にする（全員一致を待たない）
Step 6. 記録と見直し
- ADR（Architecture Decision Record）として残す（テンプレートは後述）
- 見直しのトリガーを決めておく（例：ユーザー数が10倍になったら、サポート終了が告知されたら）
3. 評価観点チェックリスト
適合性
- 課題・要件（特にMust要件）を満たすか
- 非機能要件（性能・可用性・セキュリティ）を満たすか
- 既存システム・アーキテクチャと統合しやすいか
成熟度・持続性
- 本番での採用実績が十分にあるか（同規模・同業種の事例）
- メンテナンスが継続しているか（リリース頻度、Issue・PRへの対応状況）
- 開発元・コミュニティは健全か（特定個人や1社への依存度、資金面）
- ロードマップやバージョンポリシー、LTS（長期サポート）があるか
- 破壊的変更の頻度と、移行パスの提供状況
エコシステム
- ドキュメントの質と量（公式・日本語情報含む）
- ライブラリ、プラグイン、周辺ツールが揃っているか
- 困ったときに情報が見つかるか（Stack Overflow、GitHub Issues、ブログ）
チーム・組織
- チームの既存スキルとの距離（学習コスト）
- 採用市場でその技術の経験者を確保できるか
- 社内に知見を持つ人・相談できる人がいるか
- 社内標準・技術ポートフォリオとの整合性
運用
- 監視・ログ・トレースの仕組みが整えやすいか
- デプロイ・ロールバック・スケールが容易か
- 障害時に原因を調査できるか（可観測性、デバッグツール）
- バージョンアップの手間（依存関係の更新頻度）
コスト
- ライセンス費用・利用料（従量課金の場合は規模拡大時の試算も）
- 学習・移行・運用にかかる人的コスト
- TCO（総保有コスト）で比較しているか
リスク
- ライセンスの条件（商用利用可否、コピーレフト、ライセンス変更の履歴）
- セキュリティ（脆弱性対応の速さ、CVEの履歴、サプライチェーン）
- ベンダーロックインの度合いと、撤退時の移行コスト
- 法規制・データ所在地などのコンプライアンス要件
4. 比較表（スコアリング）の例
重み付きスコアで比較すると議論の論点が明確になります。ただし点数はあくまで議論の材料であり、最終判断は理由とセットで行います。
| 評価軸 | 重み | 案A | 案B | 案C（現状維持） |
|---|---|---|---|---|
| 要件適合 | 5 | 4 | 5 | 2 |
| 成熟度 | 4 | 5 | 3 | 5 |
| 学習コスト | 3 | 4 | 2 | 5 |
| 運用性 | 4 | 4 | 3 | 4 |
| コスト | 3 | 3 | 4 | 5 |
| 加重合計 | 75 | 67 | 73 |
Must要件を満たさない案は、スコアに関係なく除外します。
5. 領域別のポイント
| 領域 | 特に重視したい観点 |
|---|---|
| プログラミング言語 | 変更コストが最大級。チームのスキル、採用、エコシステムを最優先。 |
| データベース | データモデルとアクセスパターンに合うか。移行コストが非常に高いので慎重に。迷ったら汎用RDBから。 |
| フレームワーク | 流行より安定性。メジャーバージョンアップの頻度と移行のしやすさ。 |
| インフラ / クラウド | マネージドサービスで運用負荷を下げられるか。ロックインとのトレードオフ。 |
| ライブラリ | 比較的入れ替えやすいので素早く決めてよい。ただし依存の多さ・メンテ状況は確認。 |
| SaaS / 外部サービス | 料金体系の変化、データのエクスポート可否、SLA、サービス終了リスク。 |
6. よくあるアンチパターン
- 履歴書駆動開発：個人が使ってみたい技術を、プロジェクトの都合と関係なく選ぶ
- ハイプ駆動：話題になっているから選ぶ。数年後に廃れて保守者がいなくなる
- 銀の弾丸思考：新技術ですべての課題が解決すると期待する
- 過剰設計：将来の想定規模を過大に見積もり、いまのチームに重すぎる構成を選ぶ
- 結論ありきの比較：先に答えを決め、評価軸を後から都合よく設定する
- 技術の乱立：チームやプロジェクトごとにバラバラな技術を選び、知見が分散する
- 決定理由が残っていない：数年後に誰も「なぜこれを使っているのか」を説明できない
- 選んだら終わり：導入後の見直しをせず、前提が変わっても使い続ける
7. ADR（Architecture Decision Record）テンプレート
# ADR-XXX: [決定のタイトル]
## ステータス
提案中 / 承認済み / 廃止 / ADR-YYYで置き換え
## コンテキスト
- 解決したい課題と背景
- 前提となる要件・制約
## 検討した選択肢
1. 案A：概要、メリット、デメリット
2. 案B：概要、メリット、デメリット
3. 現状維持：概要、メリット、デメリット
## 決定
[選んだ案] を採用する。
## 理由
- 決め手となった評価軸と根拠
- PoCの結果
## 影響・トレードオフ
- 受け入れたデメリットやリスク
- 必要になる対応（学習、移行、運用体制）
## 見直しの条件
- どのような状況になったら再検討するか8. 導入後に行うこと
- 小さく始める：一部の機能やサービスから導入し、段階的に広げる
- 知見を共有する：社内ドキュメント、勉強会、コーディング規約を整備する
- 振り返る：導入から一定期間後に、期待した効果が得られたかを評価する
- 出口を用意する：うまくいかなかった場合の撤退方法を考えておく
- 技術ポートフォリオを管理する：社内で使っている技術を一覧化し、「推奨 / 利用可 / 非推奨 / 廃止予定」などで分類する（Tech Radar）
9. まとめ：判断に迷ったときの問い
- その技術で、どの課題が解決されるのか？
- 既存の技術ではなぜダメなのか？
- 3年後もそれを運用・保守できるか？
- 担当者が抜けても、チームで面倒を見られるか？
- 失敗した場合、どれくらいのコストで引き返せるか？
- この決定の理由を、半年後の新メンバーに説明できるか？