LESSON 30分

ストーリー

高橋アーキテクト
新しいプロジェクトのフロントエンドフレームワーク、何にしましょう?
高橋アーキテクト
君はどう思う?
あなた
Reactが人気ですし、Reactでいいんじゃないですか?
高橋アーキテクト
“人気だから”は技術選定の理由にならない。技術選定には体系的なフレームワークが必要だ。なぜその技術を選ぶのか、他の選択肢と比べてどう優れているのか、リスクは何か。これらを明確にして初めて、チームを説得できる
あなた
フレームワークで選ぶ…フレームワークですか
高橋アーキテクト
そうだ。技術を選ぶための”型”を持っておくことが、テクニカルリードの武器になる

技術選定の5ステップ

interface TechSelectionProcess {
  // Step 1: 要件の明確化
  requirements: RequirementAnalysis;
  // Step 2: 候補の列挙
  candidates: TechCandidate[];
  // Step 3: 評価基準の設定
  criteria: EvaluationCriterion[];
  // Step 4: 評価と比較
  evaluation: EvaluationMatrix;
  // Step 5: 決定と記録
  decision: DecisionRecord;
}

// Step 1: 要件を明確にする
interface RequirementAnalysis {
  // 機能要件
  functional: string[];
  // 非機能要件
  nonFunctional: {
    performance: string;
    scalability: string;
    security: string;
    availability: string;
  };
  // 制約条件
  constraints: {
    budget: string;
    timeline: string;
    teamSkills: string[];
    existingStack: string[];
    compliance: string[];
  };
}

評価基準マトリクス

技術を評価する際の標準的な基準セットです。

interface EvaluationCriterion {
  name: string;
  weight: number; // 1-5(重要度)
  description: string;
}

const standardCriteria: EvaluationCriterion[] = [
  // 技術的観点
  { name: "機能適合性", weight: 5, description: "要件を満たす機能が揃っているか" },
  { name: "パフォーマンス", weight: 4, description: "速度・リソース効率は十分か" },
  { name: "スケーラビリティ", weight: 4, description: "将来の成長に対応できるか" },
  { name: "セキュリティ", weight: 5, description: "セキュリティ要件を満たせるか" },

  // エコシステム観点
  { name: "コミュニティサイズ", weight: 3, description: "活発なコミュニティがあるか" },
  { name: "ドキュメント品質", weight: 3, description: "公式ドキュメントは充実しているか" },
  { name: "エコシステム成熟度", weight: 4, description: "ライブラリやツールは揃っているか" },

  // チーム観点
  { name: "学習コスト", weight: 4, description: "チームの習得にかかる時間" },
  { name: "チーム内の経験者", weight: 3, description: "既に経験のあるメンバーがいるか" },
  { name: "採用市場", weight: 3, description: "エンジニアを採用しやすいか" },

  // ビジネス観点
  { name: "ライセンスコスト", weight: 3, description: "商用利用の費用" },
  { name: "ベンダーロックイン", weight: 4, description: "特定ベンダーへの依存度" },
  { name: "長期サポート", weight: 4, description: "メンテナンスの継続性" },
];

評価マトリクスの実例

## フロントエンドフレームワーク選定マトリクス

| 基準(重み) | React (5段階) | Vue (5段階) | Svelte (5段階) |
|-------------|:---:|:---:|:---:|
| 機能適合性 (5) | 5 | 4 | 3 |
| パフォーマンス (4) | 4 | 4 | 5 |
| スケーラビリティ (4) | 5 | 4 | 3 |
| コミュニティサイズ (3) | 5 | 4 | 3 |
| ドキュメント品質 (3) | 4 | 5 | 4 |
| エコシステム成熟度 (4) | 5 | 4 | 3 |
| 学習コスト (4) | 3 | 4 | 5 |
| チーム内の経験者 (3) | 4 | 2 | 1 |
| 採用市場 (3) | 5 | 3 | 2 |
| ベンダーロックイン (4) | 4 | 5 | 5 |
| 長期サポート (4) | 5 | 4 | 3 |
| **加重合計** | **175** | **152** | **134** |
// 加重スコアの計算
function calculateWeightedScore(
  criteria: EvaluationCriterion[],
  scores: Record<string, number>
): number {
  return criteria.reduce((total, criterion) => {
    const score = scores[criterion.name] || 0;
    return total + criterion.weight * score;
  }, 0);
}

定量評価と定性評価の組み合わせ

数値だけでは判断できない要素も考慮します。

## 定性評価のポイント

### React を選ぶ場合の利点
- チーム内に3名の経験者がおり、即戦力になる
- 社内の他プロジェクトでも採用済みで、ナレッジ共有が容易
- Next.js との組み合わせで SSR/SSG にも対応可能

### React を選ぶ場合のリスク
- バンドルサイズが大きくなりがち
- 状態管理ライブラリの選択で議論が発生する可能性
- React 19 以降のServer Componentsへの移行コスト

### 最終判断
定量評価(加重スコア)と定性評価を総合して、
チームの状況に最も適した選択を行う。

まとめ

ポイント内容
5ステップ要件 → 候補 → 基準 → 評価 → 決定
評価基準技術・エコシステム・チーム・ビジネスの4観点
評価マトリクス基準に重みをつけた加重スコアで比較
定性評価数値では捉えきれないチーム固有の事情も考慮

チェックリスト

  • 技術選定の5ステップを説明できる
  • 評価基準マトリクスを設計できる
  • 加重スコアの計算方法を理解した
  • 定量・定性評価の組み合わせの重要性を把握した

次のステップへ

次は「PoC(概念実証)の進め方」を学びます。評価マトリクスだけでは判断できない場合に、実際に手を動かして検証する方法を学びましょう。


推定読了時間: 30分