デジタルツイン下流 ― Layer ② Process binding
このページの内容: 下流プロジェクト（pentaglyph-docs を
git subtreeでlibs/pentaglyph-docs/に取り込んだデジタルツイン・プラットフォーム）が、upstream の pentaglyph self-architecture（Phases 0-5）マージ後に Layer ② Process を具体的な運用環境に束縛する方針の実例。パターンは一般化されており、固有のプロジェクト名 / チケット ID / 寄稿者名は redact されています。
| メタデータ | 値 |
|---|---|
| ケーススタディタイプ | Layer ② Process binding（抽象から具体へ） |
| 下流 archetype | デジタルツイン・プラットフォーム（プライベート、規制業界） |
| upstream canon バージョン | pentaglyph self-architecture Phases 0-5 |
| ステータス | In progress ― 3 つの follow-up User Story を計画中 |
1. TL;DR
Section titled “1. TL;DR”upstream の pentaglyph self-architecture 作業がマージされた後（5 layers ⓪–⑤ を surface + ADR 0001-0009 + Layer ② canon binding）、下流チームは pentaglyph 自身が ―― 埋めるべきでない ―― ギャップ に気づきました:
「pentaglyph は canon（Scrum Guide 2020 / North 2003 BDD / Beck 2002 TDD）を link-out で束縛している。しかし我々のチームは具体的な Sprint cadence、CI/CD ↔ Sprint trigger、BDD/TDD ツールをまだ選んでいない ―― それらは意図的に pentaglyph のスコープ外。これらの具体的な束縛なしでは、新参は『キットをそのまま採用』できない ―― 即興で運用してドリフトし、upstream の利点を失う」
このケーススタディは以下を記録します:
- pentaglyph Layer ② が提供するもの（upstream 側、完了済）
- pentaglyph が意図的にスコープ外に残しているもの（と、その理由 ――
STRATEGY §9.1の 4 軸テスト） - 下流が選んだ 3 つの具体束縛:
- Track 1: Scrum cadence binding →
docs/detailed-design/cross-cutting/development-lifecycle/scrum-cadence.md - Track 2: CI/CD ↔ Sprint integration →
docs/detailed-design/infra/ci-cd/CICD.mdの拡張 - Track 3: BDD/TDD ツール採用 ADR →
docs/arc42/09-decisions/00XX-bdd-tdd-tool-adoption.md
- Track 1: Scrum cadence binding →
2. pentaglyph Layer ② が提供するもの（upstream）
Section titled “2. pentaglyph Layer ② が提供するもの（upstream）”self-architecture ロードマップの Phase 2 が template/docs/design-guide/ に以下の束縛を delivery しました:
| ファイル | 束縛した canon | ステータス |
|---|---|---|
dev-cycle.md | Scrum Guide 2020 (Schwaber & Sutherland) | Stable |
bdd-workflow.md | Dan North 2003 / Adzic 2011 SbE | Stable |
tdd-workflow.md | Beck 2002 / Fowler | Stable |
dod-dor.md | Definition テンプレート (Cohn / 業界ベースライン) | Stable |
_binding-a-new-process.md | Meta-doc: 新 process canon の束縛方法 | Stable |
重要なのは、すべての束縛 doc が同じ境界を異なる言葉で宣言しています:
「ツール選定はしない。Sprint Backlog を Jira / Linear / Azure DevOps Boards / GitHub Projects / 紙のどれで追跡するかは Layer ③ Automation の関心事」
「Sprint cadence はプロジェクト固有。この束縛は 1 週間 / 2 週間 / 4 週間 Sprint を規定しない ―― チーム / ドメインに合わせて選ぶ」
これが意図的な穴です。穴こそが要点 ―― これにより pentaglyph がドメイン中立かつ 10 年安定でいられます。しかし穴はプロジェクトごとに埋める必要があります。
3. pentaglyph が意図的にスコープ外に残すもの（と、その理由）
Section titled “3. pentaglyph が意図的にスコープ外に残すもの（と、その理由）”STRATEGY.md §9.1 の 4 軸テストが pentaglyph が束縛するもの vs 下流に委ねるものを決めます:
| 軸 | 意味 | 4 つ全部 ✅ なら | どれか ❌ なら |
|---|---|---|---|
| Day-1 必要性 | プロジェクトが初日に必要、後回しできない | 束縛する | 下流に委ねる |
| スイッチングコスト | あとから変えるのが高くつく | 束縛する | 下流に委ねる |
| External canon | 安定・無料・正本のドキュメントが存在する | それに束縛（link-out） | 独自に発明しない |
| ドメイン中立性 | 規制 / スタートアップ / B2B / OSS / AI / embedded で機能する | 束縛する | 下流に委ねる |
下流のギャップへの適用:
| 具体判断 | Day-1? | スイッチコスト | External canon | ドメイン中立? | pentaglyph 束縛? |
|---|---|---|---|---|---|
| Scrum cadence (1 週 vs 2 週) | ✅ | ⚠️ 中 | ❌ (Scrum Guide silent) | ❌ (チーム依存) | NO ― 下流に委ねる |
| CI ツール選択 | ✅ | 🔴 高 | ❌ (canon なし) | ❌ (クラウド依存) | NO ― Layer ③ Automation |
| BDD ツール | ⚠️ | 🟡 低-中 | ❌ (複数ツール) | ❌ (言語依存) | NO ― 下流に委ねる |
| BDD / TDD / Scrum 概念として | ✅ | 🔴 高 | ✅ | ✅ | YES ― Phase 2 で束縛済 |
つまり下の 3 Track はすべて「下流に委ねる」側に落ちます。それが意図したアーキテクチャ であって、pentaglyph のギャップではありません。
4. 3 つの具体束縛（Tracks）
Section titled “4. 3 つの具体束縛（Tracks）”各 Track が親 Feature 配下の 1 User Story に対応。各々 1 日の集中作業でサイズ化されており独立 ―― 任意の順序 / 並列で実行可能。
4.1 Track 1 ― Scrum cadence binding
Section titled “4.1 Track 1 ― Scrum cadence binding”ゴール: docs/detailed-design/cross-cutting/development-lifecycle/scrum-cadence.md を下流プロジェクト固有の pentaglyph design-guide/dev-cycle.md override として執筆。「このプロジェクトで Scrum はどう運用されているか?」 の正本回答。
内容（必須）:
- Cadence: 1 週間 Sprint（月-金）
- Events（timebox 付き）:
- Sprint Planning: 月曜、最大 2h
- Daily Scrum: 15 分、非同期（地理的に分散したチーム）
- Sprint Review: 金曜、最大 1h ― DoD gate + Velocity 再計算を含む
- Sprint Retro: Review 後の金曜、最大 45 分
- Roles（Scrum Guide 2020 マッピング）:
- Product Owner: ドメインチャンピオン / 資金提供者
- Scrum Master: AI エージェント skill に分散 （impediment 検出、DoD gate、facilitation）。非標準だが意図的
- Developers: AI エージェント役割 + 人間レビュア
- Artefact マッピング ― pentaglyph 抽象リストをこのプロジェクトのチケットシステムにインスタンス化
- バージョンバンプ ― Sprint Review が semver minor バンプ + tag をトリガ
- Override 宣言 ―
overrides: libs/pentaglyph-docs/template/docs/design-guide/dev-cycle.md
4.2 Track 2 ― CI/CD ↔ Sprint integration
Section titled “4.2 Track 2 ― CI/CD ↔ Sprint integration”ゴール: docs/detailed-design/infra/ci-cd/CICD.md を Sprint cadence との相互作用 で拡張。CI に新機能を足すのではなく、既存リリース ceremony に名前を与えて新参が reverse-engineering しないようにする。
内容:
- Trigger matrix ― 各 pipeline について、何が発火させ、どの Sprint event にマップされるか
- Sprint-Review リリースフロー ― DoD gate → バージョンバンプ → tag → CD-prod auto-fire → post-deploy smoke test の正本シーケンス
- Cold-start / drift handling ― Sprint 1 週目の re-bake fragility パターン
- path-aware CI skip ルール ― 何が full CI vs fast path をトリガするか
- 失敗 runbook ― 直近の CI ポストモーテムへのリンク
4.3 Track 3 ― BDD / TDD ツール採用 ADR
Section titled “4.3 Track 3 ― BDD / TDD ツール採用 ADR”ゴール: 下流が採用する BDD と TDD ツールを決定し、MADR ADR として記録。
Decision drivers（ADR にプリフィル）:
- 既存テストスタック ― 広範な単体テストカバー、Gherkin /
.featureファイルなし - 現行 AC プラクティス ― Connextra 形式 + checkbox。一部 AC は Given/When/Then 形式だが executable でない
- テスト成熟度 ― 単体 / E2E は高い。BDD を上に足す限界価値は moderate、high ではない
- PoC vs production ― マルチテナント + 規制ロールアウトが executable AC の価値（コンプラ目的）を上げる
- AI エージェント互換性 ― pytest-bdd 追加はエージェントが新プロンプトを必要とする層を増やす
候補決定:
| Option | 評価 |
|---|---|
| A. 新機能のみ pytest-bdd を採用 | SbE alignment を維持。エージェントワークフローに friction を追加。早期にツールロックイン |
| B. マルチテナントロールアウトまで BDD 採用を defer | 早すぎるツールコミットを回避。選択肢を残す。AC ドリフトリスク |
| C. G/W/T を AC 表記としてのみ採用（.feature ファイルなし）、既存単体テストで TDD-first | 最安。現行習慣に合う。“executable AC” 利点を失う。pentaglyph upstream の “tool-free first” guidance に整合 |
推奨: PoC では Option C、マルチテナントマイルストーンで再検討。
5. 一般化可能なパターン
Section titled “5. 一般化可能なパターン”固有プロジェクト詳細を redact しても、これらのパターンは travel します:
- 3-Track 分解 ― 1 Feature を Cadence + Tooling 統合 + Decision-ADR に分けると、各 PR が 1 日で出荷可能
- front-matter での override 宣言 ―
overrides: libs/pentaglyph-docs/template/docs/design-guide/<file>で pentaglyph alignment が後で static lint 可能に - AI エージェントへの Scrum Master 役割分散 ― 非標準だが、小規模で AI 強化された team で viable。Scrum Guide コンプラ的サプライズを避けるため明示的にドキュメント化
- BDD 採用の “tool-free first” ― runner にコミットする前に G/W/T を執筆規約として好むのは pentaglyph のドメイン中立性哲学と整合
6. Lessons learned
Section titled “6. Lessons learned”3 Track マージ後に追記。特に:
- 4 軸テストは束縛境界を正しく予測したか?
- pentaglyph upstream に push-back すべき部分はあったか?
- 下流固有束縛のうち、実はキットの default にできるほど汎用なものはあったか?
design-guide/dev-cycle.md― Scrum Guide 2020 bindingdesign-guide/bdd-workflow.md― BDD bindingdesign-guide/tdd-workflow.md― TDD bindingdesign-guide/dod-dor.md― DoD/DoR bindingdesign-guide/_binding-a-new-process.md― meta-doc- Schwaber & Sutherland — Scrum Guide 2020
- Dan North — Introducing BDD (2003)
- Gojko Adzic — Specification by Example (2011)
- Kent Beck — Test Driven Development (2002)