ビジネスルール 作成ルール

Business Rule (BR) Documentation Rules

本ドキュメントは、業務分析・要求定義のために ビジネスルールを統一形式で記述する標準ルールです。ビジネスルールは、複数の業務プロセス（BPS）から参照される横断的な判断・条件・計算ロジックを定義します。

1. 全体方針

• 対象は「判断・条件・計算ロジック」であり、概念レベルの入力条件＋判定結果（または出力） を明確化する。
• 実装詳細（例: 物理テーブル名、SQL、UI操作、実装クラス/関数名）は記載しない（詳細は「9. 禁止事項」参照）。
• 1ファイル = 1 ビジネスルール。複雑な場合はサブルールへ分解し、親子関係はサブルール側の part_of で表現する。

2. 用語定義

用語	定義
ビジネスルール	業務上の判断・制約・計算ロジック。複数プロセスで共通に参照される定義
入力	ルールが参照する概念データ・前提条件
判定	真偽またはカテゴリ分類の結果
出力	計算値・カテゴリ・フラグなど、ルールの適用結果
例外	入力不備・矛盾・外部参照失敗など

3. ファイル命名・ID規則

• ファイル名: br-<番号>-<短い日本語名>.md （例: br-0010-在庫不足判定.md）
• Frontmatter:
  • id: br-low-stock-judgment のように小文字ハイフン形式。
  • title: 「在庫不足判定」など。
  • サブルールへ分割する場合: br-low-stock-threshold, br-stock-reservation-deduction などの id を付与し、サブルール側で part_of: [br-low-stock-judgment] を指定。

4. 推奨 Frontmatter 項目

項目	説明	必須
id	ルールID (br-xxx-xxxx)	○
type	rule 固定	○
title	ルール名	○
status	draft/ready/deprecated	○
part_of	親ルールID（サブルールの場合）	任意
based_on	根拠となる仕様ID（BPS/UIS/BEL/BES 等）	任意
supersedes	置き換え関係（古仕様→新仕様）	任意

NG/OK例（抜粋）

• NG例: type: api（列挙外）, id: BR_LowStock（大文字/アンダースコアNG）, extra: foo（未定義プロパティNG）
• OK例: type: rule, id: br-low-stock-judgment, status: ready

5. 本文構成（標準テンプレ）

各 BR ファイルは以下見出しを順番に並べる。

1. 概要
2. 入力
3. ルール（判定/計算）
4. 出力
5. 例外 / 異常系
6. メモ / 将来課題

6. 記述ガイド詳細

6.1 概要

短い一文で、何を判断/計算するルールかを業務用語で記述する。

6.2 入力

• 業務データ辞書のエンティティ・論理名を列挙し、利用目的を簡潔に付記。
  • 例: エンティティ:在庫、項目:在庫数・予約数、目的:不足判定の基準
• 必要に応じて用語集の用語ID（tm-xxx-xxx）や外部 IF 仕様の ID を併記。
• 入力は概念レベルで記述する（詳細は「9. 禁止事項」参照）。

6.3 ルール（判定/計算）

• 箇条書きで条件式と意味をセットで記述する。
• 数式や条件式は業務用語に沿って表現し、必要なら TypeScript 風の擬似コードで補足してもよい。

例：

1. 不足判定: 在庫数 − 予約数 < 発注点 → 真なら不足
2. 優先度分類: 定番商品は高優先、季節商品は中優先、その他は低優先

擬似コード例：

type 商品 = { 商品ID: string; 定番: boolean; 発注点: number }
type 在庫 = { 商品ID: string; 在庫数: number; 予約数: number }

function 在庫不足判定(商品: 商品, 在庫: 在庫): boolean {
  return 在庫.在庫数 - 在庫.予約数 < 商品.発注点
}

6.4 出力

• 判定結果（真偽/カテゴリ/数値）を列挙。
• 他プロセスが参照するための概念的な出力定義（例: 「不足フラグ」「優先度ランク」）。

6.5 例外 / 異常系

• 入力欠損・値の矛盾（発注点 < 0 等）・外部参照失敗など。
• 失敗時挙動（スキップ/再試行/警告ログ/オペ通知）を記述。

6.6 メモ / 将来課題

既知の改善余地（閾値動的化、季節要因考慮など）。

7. 命名・記述スタイル

• ルール名は「名詞＋判断/計算」: 例 在庫不足判定, 発注優先度算定。
• 条件は簡潔に（禁止事項は「9. 禁止事項」参照）。
• 数式は意味説明と併記し、業務用語で読み下せるようにする。

8. 階層分解ガイド

シグナル	サブルールへ分割検討
条件が5種以上	ルール別に分離
出力が多種（>3）	目的別再編
複数ドメインに跨る参照	参照境界で分割

親子関係は、サブルール側で part_of を指定します（親ルール側に子を列挙しない）。

9. 禁止事項

項目	理由
物理テーブル名・SQL全文	概念レベル逸脱
画面操作手順	概念レベル逸脱
実装クラス・関数名の列挙	実装依存・メンテ不能
ビジネスルール重複記述	変更時不整合リスク
未定義略語乱用	用語集との整合欠如

10. よくある誤りと対策

• 複雑なロジックを長文で記述 → サブルールへ分割し参照。
• 物理データ項目を記載 → 概念データ辞書の論理名に置換。
• BPSの手順を流用 → 本ドキュメントでは判断・計算のみを記述。

11. サンプル（簡易）

---
id: br-low-stock-judgment
type: rule
title: 在庫不足判定
status: draft
part_of: []
based_on: []
---

## 概要

在庫数から予約数を差し引いた有効在庫が発注点を下回るか判定する。

## 入力

- 在庫（在庫数・予約数）
- 商品（発注点）

## ルール（判定/計算）

1. `(在庫数 − 予約数) < 発注点` → 不足

## 出力

- 不足フラグ（boolean）

## 例外

- 発注点未設定: ログ WARN, 商品スキップ

## メモ

将来: 閾値を曜日別に動的化

12. 生成 AI への指示テンプレート

生成 AI にビジネスルールを作らせるときは、以下のような指示を与える。

• 以下のルールに従って、ビジネスルール（BR） を 1 ルール分作成してください。出力は Markdown とします。

• 対象は 1 つのビジネスルール（br-xxx-xxxx）です。業務レベルの判断/計算に限定してください。

  • 禁止: 物理テーブル名・物理項目名・SQL全文、画面操作手順、実装クラス/関数名などの実装詳細

• 本文構成は、次の見出し（日本語）をこの順序で必ず出力してください：

  1. 概要
  2. 入力
  3. ルール（判定/計算）
  4. 出力
  5. 例外 / 異常系
  6. メモ / 将来課題

• 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（不要な項目は省略可だが、id / type / title / status は必須）：

  ---
  id: br-<英小文字とハイフンで構成したID> # 例: br-low-stock-judgment
  type: rule
  title: <ビジネスルール名> # 例: 在庫不足判定
  status: draft # draft / ready / deprecated のいずれか
  part_of: []
  based_on: []
  supersedes: []
  ---

• 入力 は概念レベルの業務データで記述し、業務データ辞書にあるエンティティ・論理名を想定して書いてください。

• ルール（判定/計算） は、式と意味を併記し、日本語の条件句で表現してください。必要であれば TypeScript 風擬似コードを補助的に使用して構いません。

• 出力 では、このルールの結果として得られるフラグ・数値・カテゴリを明確に記述してください。

• 例外 / 異常系 では、主要な 2〜4 ケースを挙げ、挙動（スキップ/再試行/通知等）を記載してください。

• 全体を 業務用語で統一 し、略語を使う場合は、業務用語集に存在する一般的な略語のみとし、意味が推測しづらい略語や内部コードは使用しないでください。