ADR §2 判断基準 (Decision Drivers) 執筆ガイド
根拠 ADR: ADR-0053 — ADR 本文 §2 (旧 §3 候補) に Q42 9-tag MCDA を必須化 関連: ADR-0050 Synthesis 標準テンプレート (本ガイドの上流) / synthesis_rationale.md (Q42 タグの bizlp 解釈表) / synthesis_anti_patterns.md (アンチパターン共通)
1. このガイドが扱う問題
ADR 本文 §2 判断基準 (Decision Drivers) を Gate 4 で 4/5 以上取るための執筆規約。ADR-0052 / adr-nav-registration-lint v1 で 2/5 が連発した事故への構造的対応。
前提: 評価軸を ad-hoc に書く → Gate 4 が「評価軸が暗黙」「却下理由から逆引き必要」と指摘 → 2/5 で停滞 (ADR-0053 §1.3)。本ガイドの手順に従えば Q42 タグ + WSM + K.O. が機械的に書ける。
2. Mode 別の必須度
| Mode | §2 判断基準 | §2.1 評価軸 | §2.2 スコア表 | 備考 |
|---|---|---|---|---|
| Light | 推奨 (省略可) | 任意 | 任意 | 起案コスト過大化回避、§3 代替案で軽量比較で代替可 |
| Standard | 必須 | 必須 (3-5 軸) | 必須 | Gate 4 で 4/5 を狙う |
| Critical | 必須 | 必須 (3-5 軸) | 必須 | 5/5 を狙う、K.O. 不通過時は段階 1 戻し (ADR-0050 §4.4) |
3. Q42 9 タグ早見表 (bizlp 解釈)
詳細は synthesis_rationale.md 参照。ADR 起案ではまず以下の "案件タイプ別" でデフォルト軸を選ぶと迷わない。
3.1 Q42 9 タグ一覧
| タグ | 意味 | bizlp 拡張解釈 (ADR-0050 §4.2) |
|---|---|---|
#reliable | 信頼性・冪等性・障害耐性 | bizlp では事業継続性 (財務基盤・LLM トークンコスト持続) も含む |
#flexible | 将来変更耐性・拡張性 | 組織成熟度・経営層拡大時の対応余地 |
#maintainable | 保守容易性・可読性・引き継ぎ性 | AI Agent + 将来 Jr (2026-10 入社) の解釈可能性 |
#efficient | 処理効率・リソース消費 | GAS 6 分制限 / Workers Paid plan / 月次 LLM コスト |
#usable | UX・誤操作耐性 | 起案者の認知負荷、Jr のオンボーディング容易性 |
#operable | 運用性・監視性・bypass 容易性 | bizlp「不可逆操作は技術的にブロック」方針整合 (CLAUDE.md Prohibited) |
#suitable | 業界 FW 照合性・既存資産整合 | ADR-0019/0042/0050 等を Refines する整合性 |
#secure | セキュリティ・機密保護 | OAuth/scriptId/取引先名/金額の漏洩防止 |
#safe | 安全性・不可逆操作の制御 | prod デプロイ / シート列削除 / 本番データ書換の停止条件 |
3.2 案件タイプ別のデフォルト軸
| 案件タイプ | 推奨軸 (3-5 個) |
|---|---|
| Pipeline / インフラ改修 (例: ADR-0052) | #reliable [Must] / #operable [Must] / #maintainable / #suitable / #usable |
| ドキュメント / 規約 (例: ADR-0051 / nav-lint) | #maintainable [Must] / #operable [Must] / #suitable / #flexible / #usable |
| データモデル / スキーマ (例: ADR-0047 star schema) | #suitable [Must] / #maintainable [Must] / #reliable / #flexible / #efficient |
| AI prompt / LLM 連動 (例: ADR-0042 lifecycle) | #reliable [Must] / #maintainable [Must] / #suitable / #operable / #efficient |
| ガバナンス / プロセス (例: ADR-0050 framework) | #maintainable [Must] / #suitable [Must] / #flexible / #reliable / #operable |
迷ったらこの表からスタートし、案件固有の事情で 1-2 軸入れ替える。
4. 重要度ラベルと係数 (ADR-0050 v1 暫定)
| ラベル | 係数 | 選定基準 |
|---|---|---|
| [Must] | ×2.0 | この軸で score < 3 なら案件目的達成不可。K.O. criterion 適用対象。複数許容、軸数の半分以下が目安 (5 軸→2-3 個 / 4 軸→2 個 / 3 軸→1-2 個) |
| High | ×1.0 | 重要だが妥協余地あり |
| Medium | ×0.5 | あれば嬉しい、なくても致命的でない |
K.O. criterion (Suhr 1999 CBA): Must 軸の少なくとも 1 つで score < 3 の案は 不採用。加重和首位案でも K.O. 不通過なら採択不可。
5. スコアリング 0-5
| Score | 意味 |
|---|---|
| 5 | この軸で理想的、改善余地なし |
| 4 | 良好、軽微な懸念のみ |
| 3 | 許容範囲 (Must 軸の最低ライン) |
| 2 | 懸念あり、Must 軸なら K.O. 不通過 |
| 1 | 重大な懸念、Must 軸なら K.O. 不通過確実 |
| 0 | 機能要件未充足、ほぼ全軸で不採用 |
採点根拠は備考列で言語化し、spurious quantification (見せかけ定量化、ADR-0050 anti-patterns §1.4) を回避する。
6. 加重和の計算
正規化加重和 = (Σ score × 係数) / (満点 × Σ 係数)
- 満点 = 5 (1 軸あたりの最大 score)
- Σ 係数 = 全軸の係数合計 (5 軸で Must 2 個 + High 2 個 + Medium 1 個 = 2.0×2 + 1.0×2 + 0.5×1 = 6.5)
例: 5 軸構成 (Must 2 / High 2 / Medium 1) の場合、満点係数合計 = 6.5、案素点満点 = 32.5。
| 軸 | 係数 | score | score × 係数 |
|---|---|---|---|
#maintainable [Must] | ×2.0 | 5 | 10.0 |
#suitable [Must] | ×2.0 | 5 | 10.0 |
#operable High | ×1.0 | 5 | 5.0 |
#reliable High | ×1.0 | 5 | 5.0 |
#usable Medium | ×0.5 | 5 | 2.5 |
| 合計 | 32.5 | ||
| 正規化 | 32.5 / 32.5 = 1.000 |
加重和は 絶対判定ではなく K.O. 通過候補のタイブレーク用 (Suhr 1999)。K.O. 通過 2 案のうち加重和差が 0.1 ポイント未満なら他の質的判断 (組織方針 / 中長期戦略) でタイブレーク。
7. 記入例 (ADR-0052 Pipeline UI retroactive mode より)
2.1 評価軸
| # | 軸 | 重要度 (係数) | 案件特有の解釈 |
|---|---|---|---|
| 1 | #reliable | [Must] (×2.0) | retroactive validation の安全性、PR 自動生成事故 (PR #821) の構造的防止 |
| 2 | #operable | [Must] (×2.0) | bizlp 既存「不可逆操作は技術的にブロック」方針整合 |
| 3 | #maintainable | High (×1.0) | chat.html / src/index.ts の保守負荷 |
| 4 | #suitable | High (×1.0) | ADR-0019/0037 を Refines する整合性 |
| 5 | #usable | Medium (×0.5) | 誤クリック耐性、dialog のうざさ vs 安全性 |
2.2 評価軸 × 案スコア表
| 軸 | 係数 | 採択案 | 案 A1 | 案 A2 | 案 A3 |
|---|---|---|---|---|---|
#reliable [Must] | ×2.0 | 5 | 2 | 4 | 2 |
#operable [Must] | ×2.0 | 5 | 1 | 4 | 1 |
#maintainable High | ×1.0 | 4 | 5 | 2 | 5 |
#suitable High | ×1.0 | 5 | 3 | 3 | 3 |
#usable Medium | ×0.5 | 5 | 2 | 3 | 4 |
| 加重和 (正規化) | 0.969 | 0.462 | 0.692 | 0.492 | |
| K.O. 通過 (Must ≥3) | ✓ | ❌ | ✓ | ❌ |
→ 採択案が加重和首位 = K.O. 通過案。案 A1/A3 は #operable=1 で K.O. 不通過、却下根拠が機械的に明確化。
8. よくある誤り (アンチパターン共通、synthesis_anti_patterns.md 参照)
| # | パターン | 対策 |
|---|---|---|
| 1 | Must 軸全部にする (K.O. インフレ) | Must は軸数の半分以下が目安。「絶対譲れない」と思ったら案件分割を検討 |
| 2 | スコアを「全部 4」など曖昧に並べる | 採点根拠を備考列で言語化。差がつかないなら軸選定がブレている |
| 3 | 加重和首位を機械的に採択 | K.O. 通過 → 加重和首位の順で判定。Must 軸 score を最初に確認 |
| 4 | Q42 タグを案件名に置換 (例: #cost-effective) | Q42 9 タグ完全固定 (ADR-0050 §4.2)。案件固有の意味は「案件特有の解釈」列で記述 |
| 5 | 評価軸を段階 2 (代替案調査) の後に追加 | Post-hoc rationalization 違反。段階 1 で軸を pre-register し、確定後は変更しない |
9. CLI チェック
scripts/adr-lint.mjs に Standard/Critical ADR の §2 構造チェックを追加済 (ADR-0053 Confirmation §6.5)。
# 起案前にローカル確認
node scripts/adr-lint.mjs docs/adr/your-new-adr.md
期待出力: ✅ PASS docs/adr/... (§2 判断基準 + Q42 タグ + スコア表すべて検出)
10. 関連ドキュメント
- ADR-0053 — 本ガイドの根拠 ADR
- ADR-0050 — Q42 9-tag MCDA を確立した上流
- synthesis_writing_guide.md — Synthesis 文書 (RQ-XXX_synthesis.md) 向けの上流ガイド
- synthesis_rationale.md — Q42 9 タグ bizlp 解釈表 (詳細)
- synthesis_anti_patterns.md — アンチパターン全集 (本ガイド §8 は抜粋)
- ADR テンプレ:
docs/adr/templates/template.md§2