最終更新: 2026/06/22 18:56
RQ-050 ADR Scope 多階層分類 業界ベストプラクティス徹底調査レポート（Claude Opus 4.7 結果）
作成日: 2026-05-17 / 依頼者: 株式会社ビズリンクパートナーズ (bizlp) / 代表取締役氏 スコープ: ADR の Scope (影響範囲) 軸での多階層分類について、業界フレームワーク・OSS実例・実証研究を一次資料ベースで網羅し、bizlp 提案 (Corporate / Platform / Product / Ops の 4 階層) を評価する。
Q1. ADR Scope 多階層分類の業界事例の網羅
ADR/意思決定文書を Scope (影響範囲) 軸で多階層分類している主要事例を、一次資料ベースで網羅した。Scope 軸そのものを一級メタデータとして強制する標準はゼロで、各フレームワークが「階層化された分類軸」(scope に近い概念) を持つ形である点に注意。
| # | 事例 / フレームワーク | 階層数 | 階層名 (上→下) | 一次資料 | 想定組織規模 | 初公開 / 最新 |
|---|---|---|---|---|---|---|
| 1 | TOGAF v10 — Architecture Landscape (Partitioning) | 3 | Strategic / Segment / Capability | The Open Group, TOGAF Standard "Applying the ADM across the Architecture Landscape" (Chapter 20) — pubs.opengroup.org/togaf-standard/ | 大企業 (Fortune 500 等) | 1995 / TOGAF 10 (2022) |
| 2 | C4 Model | 4 | System Context / Container / Component / Code | c4model.com (Simon Brown) | 個人〜大企業 | 図種命名 2010年, "C4" 命名 2011年, 公式サイト/CC公開 2018年 / 継続更新 |
| 3 | SAFe (Scaled Agile Framework) | 3〜4 | Portfolio / Large Solution / Essential (+ Team) | scaledagileframework.com (Scaled Agile Inc.) | 500+ developers / 大企業 | 2011 / SAFe 6.0 (2023) |
| 4 | AWS Well-Architected Framework | 6 pillars (concern 軸) + Lens (domain 軸) | OpEx / Security / Reliability / Performance / Cost / Sustainability | aws.amazon.com/architecture/well-architected/ | 全規模 | 2015 / 継続更新 (2024 改訂) |
| 5 | Azure Cloud Adoption Framework (CAF) | 7 methodologies | Strategy / Plan / Ready / Adopt / Govern / Secure / Manage | learn.microsoft.com/en-us/azure/cloud-adoption-framework/overview | エンタープライズ | 2018 / 継続更新 |
| 6 | Google Cloud Architecture (Well-Architected) Framework | 5 pillars + cross-pillar perspectives | OpEx / Security / Reliability / Cost / Performance + AI/ML/FSI perspectives | cloud.google.com/architecture/framework | 全規模 | 2020 / v2.0 (2022) |
| 7 | arc42 Template | 暗黙 3 層 (cornerstone → detail → local) | §4 Solution Strategy / §9 Architecture Decisions / building-block 内部 | docs.arc42.org/section-4, /section-9 | 個人〜エンタープライズ | 2005 / 継続更新 |
| 8 | ISO/IEC/IEEE 42010:2022 | n/a (メタモデル) | Stakeholder → Concern → Viewpoint → View | iso.org/standard/74393.html (2nd edition, 2022-11-30 publication) | 標準準拠組織 | 2007 (初版) / 2022 (現行) |
| 9 | DDD Strategic Design (Evans / Vernon) | 2 | Subdomain (problem space) / Bounded Context (solution space) | Eric Evans Domain-Driven Design (2003); martinfowler.com/bliki/BoundedContext.html | 中〜大規模 | 2003 / 継続 |
| 10 | ThoughtWorks Technology Radar — Quadrants (注: scope 軸ではなく technology type) | 4 × 4 マトリクス | Techniques / Tools / Platforms / Languages & Frameworks × Adopt / Trial / Assess / Hold | thoughtworks.com/radar/faq, thoughtworks.com/radar (vol.34 公開 2026-04-15) | 全規模 | 2010 / 半期更新 |
| 11 | MADR (Markdown Any Decision Records) | 自由 (subdirectory category 推奨) | 例: decisions/backend/, decisions/ui/ | adr.github.io/madr/ (4.0.0 release 2024-09-17) | 全規模 | 2017 / 4.0.0 (2024-09-17) |
| 12 | Backstage ADR plugin (@backstage-community/plugin-adr) | 暗黙: catalog entity 階層 (Domain → System → Component) | catalog-info.yaml の backstage.io/adr-location annotation | github.com/backstage/community-plugins, backstage.io/plugins/ | 中〜大規模 | 2021 / 継続更新 |
| 13 | Y-Statements (Zimmermann, SATURN 2012) | 1階層 (use case / component scope を文中表現) | "In the context of <U/C>, facing | ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html; Zimmermann et al., IEEE Software (2013) | 全規模 | 2012 / 継続 |
| 14 | Zimmermann "Sustainable Architectural Decisions" / GADR | 2 (Generic vs Concrete) | Generic AD ↔ Concrete AD | Zimmermann et al., "Sustainable Architectural Decisions: The Decision-Making Process," IEEE Software (2013), DOI: 10.1109/MS.2013.51; CEUR-WS Vol-2339 paper11 (GADR) | エンタープライズ | 2013 / 継続 |
| 15 | TOGAF ADM Phases (A–H) | 8 (phase = process scope) | Vision / Business / Information Sys / Technology / Opportunities / Migration / Governance / Change | TOGAF 10 Standard | 大企業 | 1995 / 2022 |
| 16 | Structured MADR (zircote) | 自由 (frontmatter tags) | YAML frontmatter + JSON Schema validation | github.com/zircote/structured-madr | 中規模 | 2024 / 1.1.0 |
| 17 | log4brains (thomvaill) | tags 自由記述 | YAML frontmatter (MADR 2.1.2 + Log4brains patch) | github.com/thomvaill/log4brains (1.5k GitHub stars) | 中規模 | 2020 / 継続 |
重要観察: ADR の メタデータフィールドとして scope 軸の列挙型を強制している標準はゼロ。MADR は (4a で後述) 「subdirectory による category 化」を推奨し、Backstage は「catalog entity への紐付け」で scope を表現する間接モデルを採用。Scope を一級 frontmatter フィールド化する設計は bizlp の独自拡張領域と位置付けてよい (= プロプライエタリだが、業界標準に背反するものではない)。
Q2. 主要フレームワークの Scope 階層定義
比較表 — 含まれるもの / 境界条件 / 越境 anti-pattern
| フレームワーク | 階層 | 含まれるもの | 隣接階層との境界条件 | 越境 anti-pattern |
|---|---|---|---|---|
| TOGAF v10 | Strategic | 企業全体・長期 5–10 年・executive 向け方向性 | Segment との境界: "executive-level direction setting" vs "portfolio/program-level" | 戦略 Architecture に実装詳細を書く |
| Segment | 業務領域 / portfolio / program 単位の operating model | Capability との境界: "portfolio/program" vs "specific capability increment" | Segment を単一 BU 内に閉じ込めず全社的に書く | |
| Capability | 特定 business capability の詳細 (能力 increment) | 下層 (Solution Architecture) との境界: 設計 vs 実装 | Capability に Solution の deployment 詳細を混入 | |
| C4 Model | System Context | システム境界・外部 actor / external systems | Container との境界: "システム同士" vs "システム内アプリ/データストア" | Context 図に技術選定 (Node.js等) を書く |
| Container | 独立デプロイ可能な app / data store | Component との境界: "プロセス" vs "プロセス内部モジュール" | Container 図に deployment 詳細混入 | |
| Component | Container 内部の主要モジュール | Code との境界: "module" vs "class/function" | Component と Container を同時表現 | |
| Code | クラス・関数 (任意) | — | c4model.com/diagrams/code の公式 FAQ で "Recommended? No, particularly for long-lived documentation because most IDEs can generate this level of detail on demand" と明示 | |
| AWS WA | (横軸) 6 pillars | OpEx / Sec / Rel / Perf / Cost / Sustainability | pillar は scope ではなく concern 軸 | pillar を階層的に扱い tier 化する |
| (縦軸) Lenses | SaaS / ML / FSI 等 domain-specific | 6 pillar 全体を domain で再評価する切り口 | Lens を新規 pillar として扱う | |
| Azure CAF | Strategy / Plan / Ready / Adopt | 順次型 (sequential) — 採用フェーズ | Govern / Secure / Manage との境界: "立ち上げ" vs "継続運用" | sequential を skip して Adopt から始める |
| Govern / Secure / Manage | 継続型 (continuous) — 運用ガバナンス | — | continuous を一過性プロジェクト化 | |
| Google Cloud WA | 5 pillars (横軸) + cross-pillar perspectives | System Design / OpEx / Sec / Rel / Cost / Perf | Cross-pillar perspectives (AI/ML, FSI) が縦軸 | pillar を scope 階層と混同 |
| SAFe | Portfolio | 戦略テーマ・投資 funding・Lean governance | Large Solution との境界: "value stream funding" vs "solution train 実行" | Portfolio Epic を ART に直接落とす |
| Large Solution | 複数 ART の solution train | Essential との境界: "team-of-teams-of-teams" vs "単一 ART" | Large Solution なしで複数 ART を直接 Portfolio に紐付け | |
| Essential | 単一 ART (50–125 人) | Team との境界: "ART" vs "個別 Scrum/Kanban team" | ART なしで Portfolio をいきなり導入 | |
| DDD Strategic | Subdomain | problem space (Core / Supporting / Generic) | Bounded Context との境界: "業務的に何があるか" vs "モデルとしてどう切るか" | 1 Subdomain = 1 Bounded Context を強制 (現実は N:M も可) |
| Bounded Context | solution space のモデル境界 | Aggregate との境界: 戦略 vs 戦術 | Bounded Context を技術境界 (microservice) と等置 | |
| arc42 | §4 Solution Strategy | 「cornerstone — top-level decomposition, key tech, quality-goal approach」(docs.arc42.org/section-4 verbatim) | §9 (詳細決定) との境界: "fundamental"/"basis for many other detailed decisions" | §4 を細かい技術選定で埋める |
| §9 Architecture Decisions | 「architecturally significant decisions」(docs.arc42.org/section-9 verbatim) | building-block 内部との境界: "central" vs "local" | §9 と building-block の重複記述 | |
| building-block 内部 | white-box template 内の局所決定 | — | 中央 §9 に書くべきものを局所に隠す |
Scope 軸として最も近いのは TOGAF Landscape (Strategic/Segment/Capability) と SAFe (Portfolio/Large Solution/Essential)。両者とも 3 階層で、上位ほど「方向性・投資」、下位ほど「実装・実行」という共通構造。C4 は scope というより 抽象度 (zoom level) 軸、AWS WA / GCP WA / Azure CAF は concern / phase 軸。
Q3. 実装事例での Scope メタデータ運用
| 事例 | メタデータ形式 | Scope 値域 | CI / lint 検証 | 実運用課題・批判 |
|---|---|---|---|---|
| Spotify Engineering (Creator Team) | Markdown (RFC → ADR 連携) | チーム単位、scope メタデータなし | 非公開 | 「ADR を書いてもレビューされない / PR 前に読まれない」が Hacker News (news.ycombinator.com/item?id=47226046) で報告。これに対し "Decision Guardian" GitHub Action が community で開発される程度に普及 |
| GitLab Handbook (Engineering Architecture) | Markdown + Jekyll front matter | サブシステム別ディレクトリ (design-documents/cells/decisions/NNN_*.md, /cloud_connector/decisions/, /secret_manager/decisions/, /ai_gateway/decisions/, /organization/decisions/, /ai_context_management/decisions/) | ハンドブック CI (リンクチェック等) | 大規模化で参照グラフが追えない |
| ThoughtWorks Tech Radar | 内部 spreadsheet → 公開 PDF/Web | Quadrant (Tech/Tool/Platform/Lang) × Ring (Adopt/Trial/Assess/Hold) | 半期レビュー会議 | 公式 FAQ で Neal Ford が「Quadrant は arbitrary; 多くの blip が複数 Quadrant に該当しうる」「order doesn't matter」と明言。Scope 軸ではなく technology type 軸である点に注意 |
| MADR 4.0.0 (2024-09-17 release) | Markdown + YAML frontmatter | 公式 frontmatter: status / date / decision-makers / consulted / informed — scope フィールドなし | markdownlint (template/.markdownlint.yml) | "Scope を表現するなら subdirectory category 推奨" (MADR 公式: "MADR logs may be categorized by defining subdirectories … exemplary folder structure: decisions/backend/0001-use-quarkus.md decisions/ui/0001-use-vuejs.md. This comes down to a meta-decision to be made rather early on.") |
| Zimmermann Y-Statements | 1文構造 | "context" 句に scope (use case / component) を埋め込む | なし | 文が長くなる → MADR が後継として section 化 |
| Nygard "Documenting Architecture Decisions" (Cognitect blog, 2011) | 平文 Markdown | Title / Status / Context / Decision / Consequences — scope なし | なし | 原典は最小構成、scope は後発拡張 |
| adr-tools (Nat Pryce) | 連番 Markdown | scope なし、tag 機能なし | adr-list / adr-link CLI | "frontmatter なし"が制約 |
| log4brains (thomvaill) | MADR 2.1.2 + Log4brains patch | YAML frontmatter に tags 自由記述、status enum 拡張 (draft 追加) | log4brains CLI lint, static site build | Apache 2.0、~1.5k GitHub stars。scope の列挙型強制なし |
| Structured MADR (zircote) | YAML frontmatter + JSON Schema | tags 配列 (自由) | ajv-cli / check-jsonschema CI/CD validator (GitHub Action) | 新興 (v1.1.0, 2024–)、採用例少。リスク評価フィールドが特徴 |
| Backstage ADR plugin (@backstage-community/plugin-adr) | catalog-info.yaml の backstage.io/adr-location annotation + MADR v2/v3 解析 | scope は catalog entity (Component/System/Domain) が暗黙的に表現。UI は title/status/date のみ surface | Backstage Search の adr collator | per-ADR レベルで scope を持たない (entity 階層に依存) — つまり scope は「ADR がどの catalog entity に紐付くか」で決まる |
| arc42 §4 + §9 | テンプレート任意 (Markdown / AsciiDoc / wiki) | cornerstone (§4) / detail (§9) / local (building-block) の 3 層階層 | なし | "判断は著者に委ねる" — 一貫性確保が難しい (docs.arc42.org/section-9 が明示) |
実証研究の知見:
- Bhat, Ulker, Mukhin, Cabrera-Lozoya, Trubiani — "Introducing Architecture Decision Records in Practice: An Action Research Study," ECSA 2024 (DOI: 10.1007/978-3-031-70797-1_22; preprint: rebekkaa.github.io/files/2024_ECSA.pdf) — マイクロサービス企業で 7 名インタビューによるアクションリサーチ。結論抜粋: "the decision on where documentation is stored has a massive influence on its perceived usefulness. Practitioners should carefully consider what information to store centrally and what [locally]". bizlp の Scope 軸はまさにこの中央/分散判断のメタデータ化に相当。
- Capilla & Zimmermann (SSRN, 2024) "The Importance of Decision-Making and Reflections in Software Architecture Courses" (DOI: 10.2139/ssrn.5372203) — MADR の "easy and customizable templates connected to open-source repositories constitute an adequate way to produce architecture decision records" と結論。
- Kopp, Armbruster, Zimmermann (ZEUS 2018) "Markdown Architectural Decision Records: Format and Tool Support" (CEUR-WS Vol-2072 paper9) — MADR 原典論文。Y-Statements を section-oriented に変換した経緯を明示。
Q4. 1人法人スケールでの適用可能性
スコアリング (5=即適用可、1=不適合)
| フレームワーク | スコア | 理由 |
|---|---|---|
| TOGAF v10 (Strategic/Segment/Capability) | 2 | 大企業前提。Segment が "portfolio/program" レベルで 1人法人には粒度過大。ただし「上位/中位/下位の 3 区分思考」は流用価値あり |
| C4 Model | 4 | 個人開発でも有効。c4model.com/diagrams/code 公式が Level 4 を "not recommended for anything but the most important or complex components" と明示しており、Level 1+2 中心の運用は実用的 |
| SAFe (Portfolio/LS/Essential) | 1 | Portfolio SAFe は "500+ developers" 前提 (premieragile.com)、ART 自体が 50–125 人の構成単位。1人法人では適用余地ゼロ |
| AWS WA Framework (6 pillars) | 4 | 横軸 pillar は規模非依存だが、Scope ではないので bizlp の Scope 軸とは直交。pillar は concern tag として併用可能 |
| Azure CAF (7 methodologies) | 3 | Strategy/Plan/Ready は 1 人法人でも有効。Govern/Secure/Manage は組織前提部分が多い |
| GCP WA Framework (5 pillars) | 4 | AWS と同様、pillar はサイズ非依存 |
| arc42 (§4 + §9 + local) | 5 | 完全に scale-free。1 人法人にとって最も自然な scope 階層 (cornerstone / significant / local の 3 層) |
| ISO/IEC/IEEE 42010:2022 | 3 | メタモデル自体は規模非依存だが viewpoint/concern を full に展開するのは過剰 |
| DDD Strategic (Subdomain/BC) | 5 | bizlp の管理会計プロダクトに Core/Supporting/Generic Subdomain を直接適用可。SSOT INV や仕訳エンジンを Core、Decision Pipeline を Supporting に位置付け可能 |
| MADR 4.0.0 | 5 | YAML frontmatter にカスタム scope フィールドを追加するだけで対応可。原典が ADR-0010 "Support categories" で明示推奨 |
| Y-Statements | 4 | 1 人法人の AI Agent (Claude/Gemini/GPT) 併用ワークフローで「1文要約」が prompt 化しやすい |
| log4brains | 4 | OSS Apache-2.0、1.5k stars、CLI、静的サイト生成 — 1 人法人向き |
| Backstage ADR plugin | 2 | Backstage 自体の運用コスト (Service Catalog) が過大 |
| ThoughtWorks Tech Radar (Build-Your-Own) | 3 | 公式リポジトリで自前 Radar 構築可。ただし bizlp の Scope 軸とは別概念 (technology type) |
大企業前提のもの (適用不可)
- SAFe — Portfolio SAFe は "500+ developers" 前提、ART は 50–125 人で構成
- TOGAF v10 の Strategic/Segment 区分 — portfolio/program レベルが存在しない 1 人法人には粒度過大
- Backstage — Service Catalog 運用コスト過大
小組織向け簡略化パターン
- arc42 の 3 階層 (cornerstone / detail / local) を直接踏襲
- C4 の Level 1+2 のみ採用 (Level 3+4 は IDE 自動生成で代替)
- MADR の subdirectory category 推奨 を frontmatter
scope:に格上げ
1人法人での "Corporate" の意味
「法人全体 (= 代表取締役氏個人 + 法人格)」と解釈すべき。経営者個人 vs 法人を分離しない。理由:
- 1 人法人では法人運営の意思決定者と技術選定者が同一人物
- 税務・契約・雇用等の意思決定は法人格に紐付くべき (個人事業主との区別が ADR の audit trail 価値)
- Bezos Type 1 (1-way door) 判断 (税理士契約、Google Workspace 契約、GCP 組織構成等) は法人レベルで残す価値が最大
過剰設計回避の判定基準
- A: Scope ラベルが 1 ADR に 1 つに決められない → 階層設計が間違い (重複定義)
- B: 4 階層のうち実 ADR 数が 0–1 件の階層がある → 統合検討
- C: Scope を変えても Tier も連動して変わる → 2 軸が相関しており直交性なし → 1 軸に再統合
- D: AI Agent (Claude等) に分類を聞いたとき 70% 以上で同じ階層に分類される → OK (Bezos の "70% certainty rule" にも整合)
Q5. Tier × Scope の 2軸運用の業界実装
2軸マトリクス運用の業界事例
- ThoughtWorks Tech Radar: Quadrant (4) × Ring (4) の 16 セル matrix — ただし Ring は maturity/adoption 軸 (Adopt/Trial/Assess/Hold) で、bizlp の Tier (Light/Standard/Critical = リスク影響度) とは意味が異なる
- AWS Well-Architected: Pillar (6) × Lens (industry/domain) の matrix — ただし両軸とも concern 軸であり scope ではない
- arc42: §4 (cornerstone) × architecturally significant criteria — 1 軸×重要度の 2 軸的構造だが、ADR メタデータ化は未強制
- 明示的に "scope × tier" の 2 軸を ADR frontmatter にメタデータ化している大規模 OSS / 企業事例は本調査の範囲では確認できず [要追加調査]
→ つまり bizlp は 2 軸メタデータ化のフロントランナー になる可能性が高い。これは設計の独自価値であると同時に、参考にできる先行知見が少ないリスクでもある。
Scope 別に Tier の意味が変わるか?
結論: 変わる。 具体例:
| Scope | Light の典型 | Standard の典型 | Critical の典型 |
|---|---|---|---|
| Corporate | 経費規程の文言修正 | 就業規則の改定 | 雇用契約締結、税理士契約、GCP 組織分離 (Type 1) |
| Platform | docs サイト微調整 | CI/CD パイプライン構成変更 | ADR 制度自体、Decision Pipeline 設計 (Type 1) |
| Product | UI 文言調整 | 仕訳エンジン仕様追加 | SSOT INV データモデル変更 (高 blast radius) |
| Ops | playbook 文言修正 | 月次決算手順変更 | ITGC 統制改定 (監査影響) |
→ 「Corporate × Light」は実在する (経費規程の語彙変更等)。ただし頻度は低く、Corporate × Critical の方が ADR として残す価値が高い。
2軸の直交性
部分相関あり、完全直交ではない。
- Corporate は Critical 寄り (Bezos Type 1 が多い)
- Ops は Light/Standard 寄り (頻繁な playbook 更新)
- Platform / Product は分布が広く比較的直交
→ ピボット集計には有用だが、Scope→Tier の予測力は中程度。これは弱みではなく「2軸を分けて持つ価値があることの証拠」。
成功例・失敗例
- 成功例: GitLab Engineering Handbook が暗黙的にこのパターンを実現 (
design-documents/<subsystem>/decisions/NNN_*.mdの構造で scope を表現、ADR 本文の Status と Context の組合せが tier 代替) - 失敗例 (実証研究): Bhat et al. (ECSA 2024) では、「中央集約 ADR と分散 ADR の使い分けルールを決められなかった企業」で perceived usefulness が低下したことが報告。2 軸を導入する場合は分類基準の明文化が必須で、AI Agent への "分類プロンプト" を ADR-0049 の中に明記すべき
Q6. bizlp の 4段階提案の妥当性検証
業界類例との整合性
| bizlp 階層 | 業界類例 | 整合性 | コメント |
|---|---|---|---|
| Corporate | TOGAF "Strategic", SAFe "Portfolio", Azure CAF "Strategy/Govern" | ◯ | "Enterprise" の方が業界呼称に近いが、1 人法人では "Corporate" の方が法人格を強調できる利点あり |
| Platform | Backstage "Platform"概念, DDD "Supporting Subdomain" (基盤系), Azure CAF "Ready" | ◯ | Platform Engineering (Spotify Backstage 文脈) と整合 |
| Product | TOGAF "Capability", DDD "Core Subdomain", C4 "System Context+Container" | ◯ | 最も自然 |
| Ops | Azure CAF "Manage", AWS WA "Operational Excellence" pillar | △ | "Ops" は scope ではなく concern とみなされることが多い。独立 scope 化する事例は少数派だが、1 人法人で月次決算 / ITGC を独立に追跡する実用価値は高い |
階層名の妥当性 (英語名)
- Corporate vs Enterprise: 大企業文脈では Enterprise が標準だが、1 人法人では Corporate (法人格) の方が個人事業主との対比を明示できる → Corporate 推奨
- Platform vs Foundation: Platform Engineering (Spotify Backstage 文脈) と整合する → Platform 推奨
- Product vs Application: SaaS / 製品ベンダー文脈では Product が標準 → Product 推奨
- Ops vs Operations vs Operational: 短縮 "Ops" は SRE/DevOps 文脈で定着 → Ops 推奨
過不足判定
- 3 階層案 (Corporate / Platform+Product 統合 / Ops): Platform と Product の境界 (Decision Pipeline vs 仕訳エンジン) が ADR 上消える → 不採用
- 5 階層案 (例: + Data 層): SSOT INV を Data scope に分離する案は理論的に可。ただし 1 人法人の 48 ADR 規模では 5 階層は過剰
- 結論: 4 階層 (Corporate / Platform / Product / Ops) が現実的最適解
1人法人スケールでの実用性 (ADR 分布予測)
- Corporate: 推定 5–10 ADR/年 (税務・契約・組織) → 適正
- Platform: 推定 15–25 ADR/年 (Decision Pipeline 等) → 最大頻度
- Product: 推定 10–20 ADR/年 → 適正
- Ops: 推定 5–10 ADR/年 (月次決算手順等) → 適正
→ 48 件の既存 ADR の遡及分類で、各階層に最低 3 件以上が割り当てられる見込みなら 4 階層は持続可能。判定基準 B (1 階層が 0–1 件) に抵触しないか初期 audit で確認すべし。
各階層の深掘り
Corporate (法人運営層):
- 例: 「GCP 組織を 2 階層 (org→folder→project) で運用」「税理士法人 X と顧問契約」「雇用は当面行わず業務委託に統一」「就業規則 v1 (代表者のみ適用)」
- 業界類例: Azure CAF の Strategy/Plan、TOGAF Strategic Architecture
- Tier 分布: Critical 寄り (Bezos Type 1 が多い)
- 1 人法人特有性: 「経営者個人 vs 法人」境界決定をここに集約
Platform (基盤層):
- 例: 「Decision Pipeline で ADR を自動生成」「Vertex AI を Claude/Gemini/GPT のオーケストレーション基盤に集約」「ADR 制度自体 (= ADR-0001)」「docs サイトを GitHub Pages + log4brains で運用」「CI/CD を Apps Script clasp + GitHub Actions で構築」
- 業界類例: Spotify Backstage "Platform" 概念、DDD "Supporting Subdomain"
- Tier 分布: Standard 中心、制度変更時に Critical
- 1 人法人特有性: AI Agent 併用ワークフロー全体がここに含まれる
Product (管理会計プロダクト層):
- 例: 「SSOT INV を Google Sheets で実装」「仕訳エンジンを Apps Script trigger 駆動」「FP&A データマートを BigQuery で構築」「UC スライス (UseCase 単位) で機能分割」「データマートを ★ schema で正規化」
- 業界類例: DDD "Core Subdomain" (管理会計が bizlp の差別化領域)、TOGAF Capability Architecture、C4 Container 層
- Tier 分布: 全 Tier が分布、データモデル変更は Critical
- 1 人法人特有性: Google Apps Script + Sheets の制約が固有 Decision Driver
Ops (運用統制層):
- 例: 「月次決算 playbook v3」「障害対応フロー」「ITGC 統制 (Sox-lite, 1人法人向け簡略版)」「バックアップ手順」「税理士へのデータ受渡しフロー」
- 業界類例: AWS WA "Operational Excellence" pillar、Azure CAF "Manage"
- Tier 分布: Light/Standard 中心、ITGC 改定時のみ Critical
- 1 人法人特有性: 監査人/顧問税理士への audit trail として価値最大、AI Agent (Claude) で playbook を半自動生成
Q7. ADR-0022 からの拡張経路
2層 → 4層への業界標準的な拡張パターン
- Subsume (内包) パターン: 既存「プラットフォーム / テナント」を 4 階層内に位置付け直す
- 「プラットフォーム」→ Platform (そのまま継承)
- 「テナント」→ Product (顧客テナントを 1 プロダクト境界として扱う場合) または Ops (テナント運用の場合)
- Orthogonal (直交) パターン: テナント分離を別軸 (multi-tenancy axis) として保持し、Scope 4 階層と並走
→ bizlp の場合、Subsume パターン推奨。理由:
- 1 人法人で「テナント」≒ 自社運用なので、Product/Ops に吸収可能
- 直交軸を増やすと AI Agent 分類精度が低下 (判定基準 D に抵触)
ADR-0022 を Supersede / Implements / Extends どれか?
| 選択肢 | メリット | デメリット | 推奨度 |
|---|---|---|---|
| Supersede | 履歴が clean、新4階層が canonical | ADR-0022 の "プラットフォーム/テナント" 概念が見えなくなる | △ |
| Implements | 意思継承を明示 | "Implements" は ADR 慣用語でない (MADR/Y-Stmt 共に未定義) | × |
| Extends | 上位概念として残しつつ拡張を明示 | 業界標準で "Extends" 関係は明示的に支援されていない | ○ |
| Refines / Supplements | MADR 慣習に最も近い | 自前定義必要 | ◎ |
推奨: ADR-0022 を Status="accepted" のまま残し、新規 ADR-0049 "Adopt 4-tier Scope (Corporate/Platform/Product/Ops)" を作成し、本文中で "Refines ADR-0022" と明記。MADR の慣習に従い status enum は変更せず、本文中の "Related Decisions" セクションで双方向リンク。
既存 48 ADR を遡及で再分類するか?
- 推奨: 段階的遡及 (Phased Backfill)
- フェーズ 1: 新規 ADR-0049 以降は frontmatter に
scope:必須 - フェーズ 2: 既存 ADR は Tier=Critical のものから優先的に
scope:付与 (推定 10 件程度) - フェーズ 3: 残りは触れたタイミング (supersede / amend 時等) で付与
- フェーズ 1: 新規 ADR-0049 以降は frontmatter に
- 理由: 一括書き換えは Bezos Type 1 (履歴の不可逆改変) になりかねず、Type 2 のスケジュールで進行すべき。Bhat et al. (ECSA 2024) も "where documentation is stored has a massive influence" と警告
拡張に伴うリスクは Bezos Type 1 か Type 2 か?
- 基本は Type 2 (2-way door): frontmatter に
scope:を追加するだけ。フィールド削除すれば roll back 可 - ただし以下は Type 1 化のリスクあり:
- 既存 48 ADR を一括遡及で書き換える場合 → 履歴汚染で戻せない
- Scope 階層名 (Corporate/Platform/Product/Ops) を後から変更する場合 → CI/lint・docs サイト・参照リンクすべてに伝播
- 対策: 階層名を ADR-0049 で確定させ、その後最低 12 か月は変更しないコミット (Two-Pizza decision rule)
最終結論セクション: bizlp 採用推奨案 (298字)
4階層 Scope を採用、ADR-0022 を Refines。 階層 (英 / 日): Corporate (法人) / Platform (基盤) / Product (製品) / Ops (運用)。実装: MADR 4.0.0 frontmatter に scope: corporate|platform|product|ops 列挙型必須フィールドを追加 (markdownlint + 自前 schema で CI 検証)。ディレクトリは flat 維持 (docs/adr/NNNN-*.md)、採番は連番継続 (MADR ADR-0010 が subdirectory 採番分断の落とし穴を警告済)。ADR-0022 関係: 新規 ADR-0049 "Adopt 4-tier Scope" を作成し本文中で "Refines ADR-0022" を明示。ADR-0022 は accepted のまま保持。Tier 連動: 独立軸として併存。CI で (scope, tier) 2-tuple を lint。Corporate×Critical は Bezos Type 1 として review 必須化、それ以外は Type 2 として AI Agent 主導で 1-day 内決定可。
Caveats (調査上の留保)
- ThoughtWorks Tech Radar の Quadrants は scope 軸ではなく technology type 軸。公式 FAQ で「Quadrant は arbitrary」「order doesn't matter」と明言されており、Scope の業界類例として参照すると誤解を招く
- Spotify Backstage の TechDocs/Tech Insights における decision tracking は、Backstage core には ADR 機能はなく、community plugin (
@backstage-community/plugin-adr, 旧 RoadieHQ 発祥) に依存。Scope メタデータは catalog entity 階層に暗黙的に依存 し、per-ADR の scope フィールドは存在しない - 「Tier × Scope の 2 軸を明示的にメタデータ化している大規模 OSS / 企業事例」は本調査範囲では verbatim 確認できず。bizlp は事実上のフロントランナーとなる可能性が高い [要追加調査]
- GitLab Handbook で "platform/product/ops/" という命名は verbatim では確認できず。GitLab は subsystem 別 (cells / cloud_connector / secret_manager / ai_gateway / organization / ai_context_management 等) に decisions/ サブディレクトリを置く構造で、bizlp 提案の 4 階層命名そのものを採用してはいない
- MADR 4.0.0 公式 frontmatter には scope/tier/category フィールドは未定義。bizlp が追加するのはあくまで「MADR を拡張した独自スキーマ」であり、CI で自前 JSON Schema 検証を確立する必要がある (Structured MADR (zircote) の ajv-cli / check-jsonschema パターンが参考事例)
- arc42 §4 vs §9 の 3 層構造 (cornerstone / significant / local) は本調査で最も bizlp の Scope 軸に近い既存事例。bizlp が Corporate を §4 相当、Platform/Product を §9 相当、Ops を building-block local 相当に位置付けると業界類例との整合性が最大化される