RQ-039: ADR 採択基準・粒度分類・品質ルーブリックの学術的・実務的根拠

Decision Pipeline (LangGraph) の Triage v0.2 / Scoring v0.1 が採用している基準の妥当性を学術文献・業界標準で裏付ける調査

調査の動機

drp の Triage プロンプトが採用する以下の判定基準について、 学術的・業界標準的な裏付けの強度を明らかにすることが目的。

• ADR 対象外: UI 微調整・typo・自明なリファクタ・既存パターン準拠 CRUD
• Light モード (閾値 35/50): 内部実装の選択（外部 I/F に影響しない）
• Standard モード (閾値 40/50): データモデル変更 / 新規モジュール / 業務フロー変更
• Critical モード (閾値 45/50): 認証 / 課金 / 会計仕訳 / 外部 API / セキュリティ / マイグレーション
• 「迷ったら厳しめに倒す」原則

ローカル docs/adr/0019-drp-migration.md および drp/src/nodes/triage.ts で実装済の基準を、 業界標準・査読論文と照合する。

TL;DR（核心の答え）

4 カテゴリ分類とモード境界の妥当性は学術・業界の双方で強くサポートされる。 特に「Critical = 認証 / 課金 / 会計 / 外部 API / マイグレーション」は、 Nygard (2011) の 5 領域・Chen et al. (2013) ASR・Zimmermann (2020) 5+2 criteria・ Bezos Type 1（一方向ドア）すべてに合致し、業界平均より厳しめで妥当。

一方、数値スコア閾値 35/40/45 の絶対値は学術的根拠を持たない。 Basili GQM (1994) も Capilla et al. (2016) AKM survey も「閾値は組織内 calibration」と説き、 Tofan et al. (2011) GQM for AD models も合格点を組織コンテクスト依存とする。 これらは「経験的に設定されたヒューリスティクスであり、組織内合意としてのみ正当化される」と 明文化することで透明性を担保すべき。

Key Findings（重要な発見）

1. Michael Nygard (2011) 以降の ADR 採択基準の系譜

ADR 採択基準の発展は以下の系譜で整理できる:

Tyree & Akerman (2005, IEEE Software, 13 フィールド重量型)
  ↓
Kruchten (2004, decision ontology: existence / property / executive)
Kruchten, Capilla, Dueñas (2009, IEEE Software, Decision View)
  ↓
Nygard (2011, blog: 5 領域定義・5 節軽量フォーマット)
  ↓
ISO/IEC/IEEE 42010 (2011/2022, Architecture Decision を一級概念化)
van Heesch, Avgeriou, Hilliard (2012, JSS, 4 viewpoint)
Chen, Babar, Nuseibeh (2013, IEEE Software, ASR grounded theory)
Zdun, Capilla, Tran, Zimmermann (2013, IEEE Software, Y-Statements)
  ↓
Kopp, Armbruster, Zimmermann (2018, ZEUS, MADR 初出)
ThoughtWorks Technology Radar (2017-11, Adopt 入り)
  ↓
Zimmermann (2020, blog, "5+2 architectural significance criteria")
Zimmermann (2023, Adoption Model 5 levels)

Nygard (2011) の事実上の業界標準定義

*"We will keep a collection of records for 'architecturally significant' decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques."*

この 5 領域定義が AWS Prescriptive Guidance / Microsoft Azure WAF にもそのまま採用されている。

Chen, Babar, Nuseibeh (2013) の ASR 定義

500 組織・90 名・1,448 person-year の実証研究から grounded theory で導出:

"Architecturally Significant Requirements are requirements with measurable effect on architecture and quality."

これが adr.github.io の公式定義の出典になっている。

Zimmermann (2020) の 5+2 criteria

bizlp-gas-accounting の Critical 5 領域 (認証 / 課金 / 会計 / 外部 API / マイグレーション) は、 この 5+2 のうち 5 つの基準を満たす典型的ケースに該当する。

2. 「judgment-bearing decision」と「自明な実装選択」の区別

bizlp-gas-accounting の「ADR 対象外」基準（UI 微調整・typo・自明リファクタ・既存パターン CRUD）は、 以下の学術概念で裏付けられる:

Kruchten (2004) decision ontology

• Existence decisions (ontocrises): 構造要素の存在 → Standard / Critical 該当
• Anti-decisions (anticrises): 禁止事項 → Critical 該当
• Property decisions (diacrises): 品質属性・制約 → Light / Standard 該当
• Executive decisions (pericrises): ビジネス・プロセス・技術選定 → Light 該当

UI 微調整・typo は上記いずれにも該当しない「derivative changes」として除外可能。

Bezos Type 1 / Type 2 (2015/2016 letter to shareholders)

• Type 1 (one-way door, irreversible): 不可逆な決定 → Critical
• Type 2 (two-way door, reversible): 可逆な決定 → Light / Standard

「迷ったら厳しめに倒す」原則は Type 1 の過少評価リスク >> Type 2 の過剰評価コスト という 非対称リスク認識に基づく合理的判断。

"Last responsible moment" (Poppendieck) / Fowler / Booch

• Booch (SATURN 2016): "architectural decisions are design decisions that are costly to change"
• 自明な実装選択を ADR 化しないことは、Lean Software Development 原則と整合。

3. 粒度分類 (Light / Standard / Critical) の根拠

業界事例（複数階層を採用している組織）

bizlp-gas-accounting の 3 階層 (Light / Standard / Critical) は、 これらの業界実践と整合的であり、Microsoft Azure WAF の「difficult to reverse」 基準と Bezos Type 1 を併用することで理屈は強化できる。

学術文献での粒度議論

• van Heesch, Avgeriou, Hilliard (2012, JSS): 4 viewpoint (Detail / Relationship / Chronology / Stakeholder Involvement) で 粒度の異なる切り口を提供。階層化の理論的根拠を提供。
• Zimmermann (2023) "Adoption Model": 5 段階 (intuitive emerging → ad-hoc → defined → measured → continuously improving)。 bizlp-gas-accounting の現状は measured レベル（スコアリングによる定量化）に該当し、 業界では稀な高度な運用段階。

4. 数値閾値 (35 / 40 / 45) の理論的根拠の有無

結論: 学術的根拠は存在しない。

確認した文献

• Basili, Caldiera, Rombach (1994) GQM: 「閾値は組織別に calibrate すべき」と明示。
• Tofan, Galster, Avgeriou (2011, SHARK workshop): AD models 向け GQM を提案するが、合格閾値は組織コンテクスト依存。
• Capilla, Jansen, Tang, Avgeriou, Babar (2016, JSS) "10 years of SAKM": AKM ツール 3 世代を比較するも、 全て定性的観点で、数値閾値の理論的根拠は提示されない。
• Manteuffel, Tofan, Avgeriou, Koziolek, Goldschmidt (2016, JSS): tool usefulness の case study も定性的。

経験的裏付け（数値そのものではなく、平均値からの逆算）

bizlp-gas-accounting の閾値は、採点 10 項目 × 5 段階スケールから逆算すると以下に対応する:

採点スケール (02_scoring.md L31-39) で「5=模範的・4=十分・3=最低限」と定義されているため、 閾値は内部的に整合する設計だが、他組織の閾値と比較する外部根拠は存在しない。

5. ADR 品質ルーブリックの学術研究

Zimmermann (2020) "Done-done criteria" (5 項目)

1. Evidence: PoC 結果など、設計が動作する証拠
2. Criteria: 最低 2 つの代替案を品質属性で比較
3. Agreement: チーム合意
4. Documentation: lean なテンプレートで記録
5. Realization / Review Plan: 事後評価計画

bizlp-gas-accounting の 02_scoring.md 10 項目は、この 5 項目を細分化したものに対応:

• Zimmermann #1 (Evidence) → 採点 #1 (問題定義) + #9 (完了条件)
• Zimmermann #2 (Criteria) → 採点 #2 (代替案) + #3 (判断基準)
• Zimmermann #3 (Agreement) → 採点外 (本リポは個人開発のため不要)
• Zimmermann #4 (Documentation) → 採点 #5 (影響範囲) + #6 (運用罠)
• Zimmermann #5 (Review Plan) → 採点 #7 (ロールバック) + #10 (Review After)

採点 #4 (過去 ADR 整合性) と #8 (コスト試算) は bizlp 独自の追加項目で、 本リポ特有の「Supersede/Conflict 連鎖の重視」と「業務委託コスト管理」の要求に対応。

ADR smells / anti-patterns

• Kruchten, Nord, Ozkaya (2019): "Technical Debt from Decision Making"
• Richards & Ford (2020) Fundamentals of Software Architecture: "Covering Your Assets" (恐れて決めない), "Groundhog Day", "Email-Driven Architecture"
• Zimmermann (2023): "How to create ADRs — and how not to" で 11 anti-patterns
• Zimmermann (2025): "Seven Architectural Decision Making Fallacies"

採点 #6 (運用上の罠) と #7 (ロールバック性) は、これらの anti-patterns を予防する設計。

妥当性評価マトリクス

含意とアクションアイテム

維持すべき設計（外部根拠が強い）

1. 4 カテゴリ分類: Nygard 5 領域 + Chen ASR + Zimmermann 5+2 で完全裏付け済。変更不要。
2. Critical = 会計を含む 5 領域: 規制業界（SOX / 税法 / PCI-DSS）対応として業界平均より厳しめで妥当。
3. 「迷ったら厳しめ」原則: Bezos Type 1 非対称リスクモデルと整合。
4. 採点 10 項目: Zimmermann Done-done criteria の細分化として正当化可能。

明示すべき「外部根拠なし」（透明性確保）

1. 数値閾値 35/40/45 は組織内ヒューリスティクスであることを 02_scoring.md 冒頭に明記。
2. 採点項目 #4 (過去 ADR 整合性) / #8 (コスト試算) が bizlp 独自追加であることを明示。
3. ルーブリック「0 = 完全欠落」厳格維持の判断を ADR-0020 で正式記録。

将来の改善余地（Zimmermann Adoption Model "continuously improving" へ）

1. 事後評価ループの追加: 各 ADR について 6 ヶ月後の DORA 指標 / インシデント数との相関分析。
2. 動的閾値: プロジェクトフェーズ（PMF 前 / 後 / スケール期）に応じた閾値係数導入。
3. LLM による ADR 生成補助: Mayer & Weinreich; Zhang et al. (2022) の手法を参考に Triage prompt の自動改善。

主要参考文献

学術論文（査読あり）

1. Tyree & Akerman (2005). "Architecture Decisions: Demystifying Architecture." IEEE Software 22(2). DOI: 10.1109/MS.2005.27
2. Kruchten, Capilla, Dueñas (2009). "The Decision View's Role in Software Architecture Practice." IEEE Software 26(2). DOI: 10.1109/MS.2009.52
3. van Heesch, Avgeriou, Hilliard (2012). "A Documentation Framework for Architecture Decisions." JSS 85(4).
4. Chen, Babar, Nuseibeh (2013). "Characterizing Architecturally Significant Requirements." IEEE Software 30(2).
5. Zdun, Capilla, Tran, Zimmermann (2013). "Sustainable Architectural Design Decisions." IEEE Software 30(6).
6. Capilla, Jansen, Tang, Avgeriou, Babar (2016). "10 years of software architecture knowledge management." JSS 116.
7. Kopp, Armbruster, Zimmermann (2018). "Markdown Architectural Decision Records." ZEUS 2018.
8. Ahmeti et al. (2024). "Architecture Decision Records in Practice." ECSA 2024.

業界白書・一次資料

9. Nygard (2011). "Documenting Architecture Decisions." Cognitect blog. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
10. ISO/IEC/IEEE 42010:2022 "Systems and software engineering — Architecture description."
11. ThoughtWorks Technology Radar (2017-11). "Lightweight Architecture Decision Records — Adopt."
12. AWS Prescriptive Guidance (2022). "Architectural Decision Records."
13. Microsoft Azure Well-Architected Framework. "Maintain an architecture decision record (ADR)."
14. Spotify Engineering (2020). "When Should I Write an Architecture Decision Record."
15. Bezos (2016). Amazon Letter to Shareholders. (Type 1 / Type 2 decisions)

Decision Pipeline 内部資料

16. ADR-0019: docs/adr/0019-drp-migration.md
17. Triage v0.2: docs/_internal/decision_pipeline/prompts/01_triage.md
18. Scoring v0.1: docs/_internal/decision_pipeline/prompts/02_scoring.md
19. RQ-038: docs/_internal/research_prompts/RQ-038_adr_skill_architecture_result.md

変更履歴