知識ベーススキーマ設計

要件定義で定めた「知識ベースの単一ソース」「規則の宣言的管理」「根拠の追跡可能性」を満たすデータ構造の設計です。方針の決定記録は ADR-0008 にあります。

全体構造

知識ベースは4種のデータで構成し、すべて src/data/tailoring/ の YAML として本リポジトリで版管理します。

graph TD
  Q["questions.yaml<br>質問(入力モデル)"] -->|回答が条件になる| R["rules-*.yaml<br>テーラリング規則"]
  R -->|調整を適用| P["integrated.yaml<br>ピットイン方式参照モデル<br>(既存・ADR-0007)"]
  R -->|横断項目を参照| PR["practices.yaml<br>プラクティス語彙"]
  C["constraints.yaml<br>禁止事項(不変条件)"] -->|上書きを検査| W["修正・採択ワークフロー"]

• 質問(questions): 画面に出す入力項目。回答の選択肢 id が規則の条件になる
• 規則(rules): 「入力 → 調整」の対応。参照モデルへの差分として記述する
• プラクティス(practices): ゲートやロールの構造に載らない横断的な運用項目の語彙(コア指定・負債運用・成果物の適否の確認の基準など)
• 制約(constraints): 入力に関係なく常に守る禁止事項。ユーザーの上書き検査に使う

設計判断のポイント

1. 規則は「参照モデルからの逸脱」だけを書く(差分方式)

ベースは常にピットイン方式参照モデルです。「グロース期は標準どおり」のような規則は書きません。これにより規則の総数が抑えられ、参照モデルの改版が自動的に全提案へ反映されます。

2. 説明のない調整は型レベルで書けない

調整1件ごとの note(画面にそのまま出す説明)、規則ごとの reason(なぜ)と source(根拠ページ)を必須にしています。要件定義の「ブラックボックスの推薦はしない」を、運用ルールでなくスキーマで強制します。

3. 条件は「質問→回答」の等値照合だけ

規則の条件(when)は、質問 id と回答 id の組み合わせに限定しています。同一質問内の複数回答は OR、質問間は AND です。数式や自由な論理式は導入しません(人が読んで検証できる範囲に条件語彙を留める)。

# 例: 1〜2名 かつ 作成を指示した本人以外の確認者がいない 場合の規則(限界ケース)
- id: r-s-no-external-reviewer
  when:
    q-team-size: [size-1-2]
    q-external-reviewer: [reviewer-no]
  adjustments:
    - target: { type: gate, id: g-indep-review }
      action: omit
      note: 作成を指示した本人以外の確認者を置けない。省略ではなく未達として表示する(ADR-0028)
    - target: { type: gate, id: g-ci }
      action: strengthen
      note: 代償措置としてCI基準を厳格化する。未達の解消にも、独立レビューの代替にも数えない
  reason: 機械検証の強化は代償措置であり、独立した人の確認の代わりにならない。未達として表示し続ける
  source: /process-compass/phase4-process-design/tailoring-guide/
  priority: 40

4. 調整操作は6動詞に限定する

action	意味	例
omit	対象を適用しない。標準の規則による省略と、目的を達成する構成を示せない未達の両方を、この動詞で表す	PoC では出荷判定を省略。確認者を置けない 1〜2名の体制では、独立レビューが未達
simplify	簡略化する	企画承認を1枚企画書に
strengthen	厳格化する	規制業では CI に規制チェックを追加
merge-into	別の対象へ統合する	要件合意を仕様承認に統合
set	パラメータを設定する	コアレビュア数を2名に
note	注記のみ(構造は変えない)	価値責任者は発注側に置く

対象(target)は gate / role / activity / phase / process / practice の6種で、practice 以外は integrated.yaml の id を参照します。

omit は、省略と未達を区別しません。規則のデータが持つのは「適用しない」という操作までです。省略(omitted)と未達(unmet)の区別は、準拠テンプレートが構成を導出するときに付けます(ADR-0028)。独立レビューの omit を「独立レビューの省略」と読まないでください。確認者を置けない体制の独立レビューは、未達として表示し続けます。

5. 優先度は初期値のみ定義する

規則の競合(例: PoC は独立レビューを省略、規制業は厳格化)に備えて priority を持たせています(補助の限界ケース 40 > 品質・規制 30 > 開発形態 20 > 規模・事業フェーズ 10)。適用順序と競合解決の意味論は提案ロジック設計で定義します。

収録済みの規則

フェーズ4のテーラリングガイドの調整表を全件符号化し、スキーマを実データで検証済みです。

ファイル	内容	規則数
rules-team-size.yaml	軸A: チーム規模(1〜2名 / 3〜9名 / 10名以上)	3
rules-business-phase.yaml	軸B: 事業ステージ(S0 / S1 / S2)	4
rules-quality.yaml	軸C: 期待品質・規制(高品質 / 規制業)	2
rules-dev-form.yaml	軸D: 開発形態(発注側 / 受注側)	2
rules-criticality.yaml	軸E: 安全重要度(CL1 / CL2 / CL3)	3
rules-supplementary.yaml	補助: 限界ケース・既存ゲート接続・AI制約	5

制約(禁止事項)は9件を収録しています。内容はテーラリングの禁止事項の9件と同一です。件数は npm run test:engine が検査します。第8章の禁止事項を増減したときは、データと検査の件数を同時に改めます。

安全重要度の優先度

軸Eの規則は priority 50 とし、限界ケースの代替(40)より優先します。人員が確保できないことを理由に、危害の深刻度に基づく要求が黙って外れる経路を作らないためです。

たとえば「1〜2名・作成を指示した本人以外の確認者なし・CL3」では、限界ケースの規則が独立レビューを適用しない状態(未達)へ倒そうとします。しかし軸Eの規則が勝って2名の要求が残り、両立しない条件として警告に現れます。利用者はこれを見て、設計を変えて危害の帰結を下げるか、体制を確保するか、当該の機能を実施しないかを判断します。安全重要度 CL1 以上と規制業では、1〜2名の構成そのものを認めません(第8章 軸E)。

検証と版管理

• スキーマ検証は Astro Content Collections(Zod)で行い、npm run check に統合されている。規則の書式誤りはビルドが落ちる
• 全ファイルに schemaVersion: 0 を持たせ、条件語彙の拡張(数値範囲など)が必要になったら版を上げる
• 規則の追加・修正は YAML 編集だけで完結する。組織への適用事例から得た知見は、規則として追記していく(コミュニティが知識ベースを鍛える運用)