version: "1.0.0" name: decision-making description: 技術選定・設計判断などの意思決定を構造化するスキル。複数の選択肢で迷っている場面、技術スタック・API設計・サービス境界などの重要な決定を下す必要があるときに使う。

技術的意思決定

目的

技術選定・設計判断・方針決定を構造化し、根拠のある決定を下して記録する。評価軸とトレードオフを明示し、「なぜこう決めたか」を後から追跡できる状態にする。

使うタイミング

• 技術スタック・フレームワーク・ライブラリの選定
• データスキーマ・公開API・サービス境界の設計方針を決めるとき
• 複数の実装アプローチで迷い、チームの合意が必要なとき
• 過去の決定を見直すかどうか判断するとき

可逆性で扱いを変える

最初の仕事は「この決定は可逆か」を判定すること。

可逆な小事に大会議を開かない。不可逆な大事を勢いで即決しない。

進め方

1. 決めることを一文で書く

• 「〇〇において△△を選択する」という形式で問いを明確化する
• 問いが曖昧なまま進むと評価軸がずれる

1. 可逆性を判定する

• 「後から変えるコストはどのくらいか」を見積もる
• 可逆ならここで即決して手順4以降をスキップしてよい

1. 評価軸を先に決める

• 選択肢を見る前に軸を決める（後から足すと好みの正当化になる）
• 軸の例: 開発速度、運用負荷、チーム習熟度、スケーラビリティ、ロックインリスク、コスト
• 軸に優先順位をつける（全軸を同等に扱わない）

1. 選択肢を3つ以上出す

• 2択は視野が狭い。第3の選択肢を必ず探す
• 「何もしない／現状維持」も選択肢に含める
• 組み合わせ案（ハイブリッド）も検討する

1. トレードオフ表で比較する

• 成果物テンプレートの評価表を埋める
• 各セルに「なぜそのスコアか」の根拠を1行で書く
• スコアが拮抗した軸こそ深掘りする

1. 調査の打ち切り基準を設ける

• タイムボックスを切る（例: 技術選定の調査は2日まで）
• 「追加で調べても順位が入れ替わる見込みがない」なら決める
• 不確実性が残るなら小さく試す（スパイク、[[task-breakdown]] 参照）
• 完璧な情報は永遠に揃わない

1. 決定し、記録する

• 採用した選択肢と理由を書く
• 「採用しなかった選択肢とその理由」を必ず記録する（ADR形式: [[architecture-design]]）
• 再検討のトリガー（前提が何に変わったら見直すか）を明記する

1. 迷ったときのデフォルト原則を適用する

• 枯れた技術 > 流行の技術
• 標準 > 独自実装
• シンプル > 高機能
• 書き直しやすい設計 > 最初から完璧な設計
• いま必要なもの > いつか必要かもしれないもの（[[mvp-development]] のYAGNI原則）

成果物テンプレート

## トレードオフ評価表
 
**決める問い**: ○○において△△を選択する
 
**評価軸（優先順）**: 1. 軸A  2. 軸B  3. 軸C
 
| 選択肢 | 軸A (優先度: 高) | 軸B (優先度: 中) | 軸C (優先度: 低) | 総評 |
|---|---|---|---|---|
| 選択肢1 | ◎ 根拠: | ○ 根拠: | △ 根拠: | |
| 選択肢2 | ○ 根拠: | ◎ 根拠: | ○ 根拠: | |
| 選択肢3(現状維持) | △ 根拠: | ○ 根拠: | ◎ 根拠: | |
 
凡例: ◎ 優れている  ○ 問題なし  △ 懸念あり  × 重大な問題

## 決定記録（ADR簡易版）
 
**タイトル**: ○○において△△を採用する
**決定日**: YYYY-MM-DD
**決定者**:
**ステータス**: Accepted / Proposed / Superseded by #NNN
 
### 背景
（なぜこの決定が必要になったか）
 
### 決定内容
（何を決めたか、1〜2文で明確に）
 
### 採用した選択肢
（選択肢名）
 
### 採用しなかった選択肢と理由
-選択肢2: （却下した理由）
-選択肢3: （却下した理由）
 
### 再検討のトリガー
（前提が何に変わったらこの決定を見直すか）

チェックリスト

• [ ] 決める問いを一文で書いた
• [ ] 可逆性を判定した（可逆なら即決してよい）
• [ ] 評価軸を選択肢を見る前に決めた
• [ ] 選択肢を3つ以上（「何もしない」含む）出した
• [ ] タイムボックスを設定した
• [ ] トレードオフ表の各セルに根拠を書いた
• [ ] 採用しなかった選択肢とその理由を記録した
• [ ] 再検討のトリガーを明記した
• [ ] 不可逆な決定では「段階的移行の余地」を確認した

不可逆な決定の前に追加確認

• [ ] 本当に戻せないか（戻すコストはどのくらいか）
• [ ] 最悪のケースは何か、受け入れられるか
• [ ] 段階的に移行できないか（スパイク・フィーチャーフラグ等）
• [ ] 誰に（チーム・ユーザー・外部API利用者に）影響するか

アンチパターン

• 評価軸の後付けで好みを正当化: 「やっぱりこの軸も重要で…」と選択肢を見てから軸を追加するのはNG。最初に軸を確定させる
• 2択しか出さない: 視野が狭い証拠。必ず第3案と「何もしない」を検討する
• 調査が趣味化して決まらない: 「もう少し調べれば…」は永遠に終わらない。タイムボックスを守る
• 決定理由を記録しない: 半年後に「なぜこれを使っているんだっけ」となる。ADRを書く
• 可逆な小事に大会議: 変数名・内部実装に全員を集めない
• 不可逆な大事を勢いで即決: テンションが高いときほど立ち止まる
• サンクコストで継続: 「ここまでやったのに」は理由にならない。前提が変わったら再決定してよい
• 「飽きた」での技術変更: 問題のない技術を「新しいものを試したい」で変えるのはコスト浪費
• 決定の先送り: 決めないことは「現状維持を選んだ」のと同じ。しかも全員をブロックする。期限を決めて決める

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

複数エージェントによる独立評価

不可逆・高コストな決定では、複数のエージェントに独立して評価させる。

• 目的は多数決ではなく論点の発見。評価が割れたセル・評価軸こそ深掘りする
• 手順: 同じトレードオフ表と背景情報を渡し、互いの結論を見せずに評価させる → 司令塔が差分を比較 → 割れた箇所を「見落としていた論点」として追加調査する
• 全員が同じ結論なら自信度が上がる。割れた場合は「なぜ割れたか」が意思決定に使える情報

関連スキル

• [[orchestration]] - マルチエージェント協調の共通原則
• [[architecture-design]] - アーキテクチャ決定記録(ADR)の詳細フォーマット
• [[requirements-definition]] - 意思決定の前提となる要件の確認
• [[task-breakdown]] - 不確実性が残る場合のスパイク実施
• [[mvp-development]] - YAGNI原則・最小構成の判断基準
• [[estimation]] - 選択肢ごとのコスト・工数の見積もり
• [[microservices]] - サービス境界という不可逆な決定の具体例
• [[non-functional-requirements]] - 技術選定の制約を与える非機能要件
• [[code-review]] - 決定の妥当性を第三者視点で検証
• [[skill-navigator]] - どのスキルを使うか迷ったときの案内