Skip to content

技術選定の意思決定フレームワーク:チームに向けた技術選択の方法

数年間テックリードを務めてきて、最も悩むのはコードを書くことではなく、技術選定です。私の意思決定フレームワークを記録します。

なぜ技術選定は難しいのか

表面上の理由:選択肢が多く、それぞれに一長一短がある
根本的な理由:評価基準が統一されておらず、暗黙の制約が明らかにされていない

例えば:
PM:急いで、来週リリースしないといけない
マネージャー:成熟した技術を使って、問題を起こさないでほしい
チーム:最近学んでいる新しいフレームワーク、使ってみていいですか?
あなた:...

意思決定マトリクス

私は評価に 5 つの次元を使います:

1. チームの習熟度(Team Familiarity)
   既存の経験は?学習曲線はどのくらい?

2. 成熟度(Maturity)
   コミュニティの規模は?Issue への対応速度は?会社が維持しているか?

3. 適合度(Fit)
   解決する問題と私たちの問題はどれほど一致しているか?

4. 移行コスト(Migration Cost)
   将来変更する場合のコストはどのくらい?(ロックインリスク)

5. 運用コスト(Operational Cost)
   リリース後のメンテナンスはどれだけ複雑か?

実際のスコアリング例(新プロジェクトでの状態管理の選定):

ZustandJotaiRedux ToolkitValtio
チーム習熟度3141
成熟度4353
適合度5434
移行コスト5434
運用コスト5434
合計22161816

最終的に Zustand を選択:適合度が最高で、チームに基礎知識があり、移行が容易。

よくあるアンチパターン

「このライブラリの GitHub Star が最多だから」

Star 数はあなたのユースケースに適しているかどうかを表しません。moment.js は 4 万 Star ありますが重すぎます。今では dayjs やネイティブの Temporal が使われています。

「大企業が使っている」

大企業のシナリオはあなたのシナリオではありません。彼らはそのソリューションを 1000 人のエンジニアでメンテナンスしています。あなたのチームは 5 人です。

「新技術の方が先進的だ」

最新 ≠ 最良。問題は:それが今直面している具体的な問題のどれを解決するのか?

「まず試してみてから考えよう」

「試してみる」はよく「そのままになった」に変わります。POC には明確な評価基準が必要です。そうでなければサンクコストの罠にはまりやすいです。

RFC ドキュメント

私たちのチームでは、重要な技術的意思決定には RFC(Request for Comments)を書きます:

markdown
# RFC:状態管理ソリューションの選定

## 背景

現在のプロジェクト...には以下の問題があります...

## 目標

- 状態管理の方法を統一する
- ボイラープレートコードを削減する
- TypeScript 体験を向上させる

## 候補ソリューション

### 案 A:Zustand

メリット:...
デメリット:...
リスク:...

### 案 B:Redux Toolkit

...

## 推奨案

案 A(Zustand)、理由:...

## 意思決定基準

[条件] が発生した場合、再評価します。

## 影響範囲

- 移行が必要なファイル:...
- 想定工数:...

## 反対意見

@エンジニア は...と考えており、それへの回答は...

RFC の価値はドキュメント以上のものです

  1. 考えを整理することを強制する
  2. チームに発言の機会を与える
  3. 数ヶ月後にその決定がなされた理由を確認できる

不可逆的な決定 vs 可逆的な決定

ベゾスの「一方向のドア vs 双方向のドア」理論は技術的意思決定にも当てはまります:

高可逆性(双方向のドア)→ 迅速に決定し、うまくいかなければ変える
  - 状態管理ライブラリ
  - UI コンポーネントライブラリ
  - テストフレームワーク

低可逆性(一方向のドア)→ 慎重に決定し、より多くの時間を検証に費やす
  - データベースの選定
  - フロントエンド・バックエンドアーキテクチャ(SPA vs SSR vs MPA)
  - 主要言語/フレームワーク
  - クラウドプロバイダーの選択

「双方向のドア」の決定に過度な分析をしないでください。決定して、動かしてから改善してください。

まとめ

  • 技術選定には「なんとなく良さそう」ではなく、多次元マトリクスを使う
  • 重要な決定には RFC を書き、チームを巻き込み、意思決定の記録を残す
  • 可逆的な決定と不可逆的な決定を区別し、不可逆的なものにはより慎重になる
  • 避けること:Star 数、大企業の保証、新技術の魅力を主な判断基準にすること
  • 最も重要な質問:この技術は私たちが今直面している具体的な問題のどれを解決するのか?

MIT Licensed