ストーリー

意思決定の3つのレベル

技術的な意思決定は、影響範囲に応じて3つのレベルに分類されます。

enum DecisionLevel {
  // 個人レベル: 変数名、アルゴリズム選択
  TACTICAL = "tactical",
  // チームレベル: ライブラリ選択、API設計
  OPERATIONAL = "operational",
  // 組織レベル: フレームワーク移行、クラウド選択
  STRATEGIC = "strategic",
}

interface TechnicalDecision {
  level: DecisionLevel;
  reversibility: "easily_reversible" | "costly_to_reverse" | "irreversible";
  timeConstraint: "immediate" | "days" | "weeks";
  stakeholders: string[];
  impactScope: "individual" | "team" | "organization";
}

// 判断基準の例
const decisionCriteria: Record<DecisionLevel, string[]> = {
  [DecisionLevel.TACTICAL]: [
    "可読性", "パフォーマンス", "既存コードとの一貫性"
  ],
  [DecisionLevel.OPERATIONAL]: [
    "チームの生産性", "保守性", "学習コスト", "コミュニティサイズ"
  ],
  [DecisionLevel.STRATEGIC]: [
    "ビジネスインパクト", "スケーラビリティ",
    "採用市場", "長期コスト", "ベンダーロックイン"
  ],
};

意思決定フレームワーク: DACI

大きな技術的意思決定には、DACIフレームワークが有効です。

## DACI フレームワーク

| 役割 | 英語 | 説明 |
|------|------|------|
| D | Driver（推進者） | 決定プロセスを推進する人 |
| A | Approver（承認者） | 最終的に決定を承認する人（1人） |
| C | Contributor（貢献者） | 知識や意見を提供する人 |
| I | Informed（通知先） | 決定後に通知を受ける人 |

### 活用例: データベース移行の意思決定

- **Driver**: テクニカルリード（あなた）
- **Approver**: CTO
- **Contributors**: DBエンジニア、バックエンドチーム、SRE
- **Informed**: フロントエンドチーム、プロダクトマネージャー

One-Way Door と Two-Way Door

Amazonで知られる意思決定の分類法です。

interface DecisionType {
  type: "one-way-door" | "two-way-door";
  description: string;
  approach: string;
}

const oneWayDoor: DecisionType = {
  type: "one-way-door",
  description: "取り消しが困難な決定",
  approach: "慎重に分析し、合意を形成してから決定する",
  // 例: プログラミング言語の変更、クラウドプロバイダーの移行
};

const twoWayDoor: DecisionType = {
  type: "two-way-door",
  description: "比較的容易に戻せる決定",
  approach: "素早く決定し、データに基づいて軌道修正する",
  // 例: ライブラリの選択、UIフレームワーク、テストツール
};

// テクニカルリードの判断
function decideFast(decision: TechnicalDecision): string {
  if (decision.reversibility === "easily_reversible") {
    return "Two-Way Door: 速やかに決定し、実行しながら学ぶ";
  }
  if (decision.reversibility === "irreversible") {
    return "One-Way Door: RFC/ADRを書き、チームで議論してから決定";
  }
  return "中間: 期限を設けて調査し、決定する";
}

意思決定のアンチパターン

避けるべき意思決定のパターンを理解しましょう。

// 意思決定プロセスのテンプレート
interface DecisionProcess {
  // 1. 問題の定義
  problem: string;
  // 2. 制約条件の明確化
  constraints: string[];
  // 3. 選択肢の列挙
  options: Option[];
  // 4. 評価基準の設定
  criteria: EvaluationCriterion[];
  // 5. トレードオフの分析
  tradeoffs: Record<string, { pros: string[]; cons: string[] }>;
  // 6. 決定と理由の記録
  decision: string;
  rationale: string;
  // 7. 振り返りの日程
  reviewDate: Date;
}

interface Option {
  name: string;
  description: string;
  estimatedEffort: "small" | "medium" | "large";
}

interface EvaluationCriterion {
  name: string;
  weight: number; // 1-5
  description: string;
}

決定を記録する重要性

なぜその決定をしたのかを記録することは、テクニカルリードの最も重要な仕事の一つです。

## 意思決定記録の例

### 決定: APIの認証方式にJWTを採用

**日付**: 2025-03-15
**ステータス**: 承認済み
**参加者**: 高橋、田中、鈴木

**背景**:
新規APIのユーザー認証方式を決定する必要がある。

**選択肢**:
1. セッションベース認証
2. JWT（JSON Web Token）
3. OAuth 2.0 + OpenID Connect

**決定**:
JWT を採用する。

**理由**:
- マイクロサービス間でのステートレスな認証が可能
- モバイルアプリとの親和性が高い
- チーム内に JWT の実装経験者が2名いる

**リスク**:
- トークンの無効化が困難 → 短い有効期限 + リフレッシュトークンで対応
- トークンサイズが大きい → ペイロードを最小限にする

まとめ

チェックリスト

• 意思決定の3つのレベルを説明できる
• DACIフレームワークの使い方を理解した
• One-Way / Two-Way Doorの判断ができる
• 意思決定のアンチパターンを把握した
• 決定を記録する重要性を理解した

次のステップへ

次は「ステークホルダーとのコミュニケーション」を学びます。技術的な決定をビジネスサイドに伝え、合意を形成する方法を掘り下げましょう。

推定読了時間: 25分