業務プロセス仕様書作成ルール

Business Process Specification (BPS) Documentation Rules

本ドキュメントは、業務分析・要求定義のために 業務プロセス仕様を統一形式で記述する標準ルールです。業務プロセス仕様は、概念データフローで定義された各プロセスについて、開始条件・手順・入出力・例外処理などを詳細に記述します。

1. 全体方針

対象は「業務上の単位処理（プロセス）」であり、概念レベルの手順＋判断ポイント＋入出力を明確化する。
システムへの実装（例：物理テーブル名、SQL、UI操作、実装クラス/関数名）については記載しない（詳細は「9. 禁止事項」参照）。
1ファイル = 1 プロセスとし、複雑な場合は子業務プロセスへ分解する。

2. 用語定義

用語	定義
業務プロセス	業務イベントまたは条件を契機に起動し、明確な成果物/状態変化を生む処理単位
トリガー	プロセスを開始させるイベント
前提条件	プロセス開始前に成立しているべき条件
入力	プロセスが参照/取得するデータ（概念レベル）。業務データ辞書の論理名で参照、idを付与する場合は用語集の用語idで参照
処理	手順/判断の論理的なステップ。順序と分岐を含む
出力	プロセスが生成/更新/通知するデータ・イベント・状態変化
例外	異常/例外パス（入力不備・判定失敗・外部連携失敗等）

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

ファイル名: bps-<番号>-<短い日本語名>.md （例: bps-0010-在庫不足検知.md）
Frontmatter:
- id: bps-low-stock-detection のように小文字ハイフン形式。
- title: 「在庫不足検知」など。
- 子業務プロセスへ分割する場合: bps-low-stock-check, bps-low-stock-alertなどのidを付与し、子側で part_of: [bps-low-stock-detection] を指定します。

4. 推奨 Frontmatter 項目

項目	説明	必須
id	プロセスID (bps-xxx-xxxx)	○
type	`domain` 固定	○
title	プロセス名	○
status	`draft`/`ready`/`deprecated`	○
part_of	親プロセスID（子プロセスの場合）	任意
based_on	根拠となる仕様ID（BES/BEL/BR/UIS 等）	任意
supersedes	置き換え関係（古仕様→新仕様）	任意

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

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

概要
トリガー
前提条件
入力
処理
出力
例外 / 異常系
メモ / 将来課題

6. 記述ガイド詳細

6.1 概要

短い一文＋業務プロセスの5W1Hをビジネス用語で書く。

6.2 トリガー

起点となる業務内容と業務イベント ID（bes-xxx-xxx）を列挙。
- 例: 商品の在庫数が更新された: 在庫数更新イベント(bes-stock-amount-updated)
BEV（個別業務イベント仕様）が存在する場合は、イベントの「契約」（発行者/発生源/ペイロード/結果/主な購読先）は BES を参照し、BPS のトリガー/入力では 購読側（このプロセスが受ける）観点で簡潔に記述します。

6.3 前提条件

開始前に真であるべき条件を列挙。例: 「対象商品が販売中状態」「店舗が営業中」等。

6.4 入力

業務データ辞書のエンティティ、論理名を列挙し、利用目的を簡潔に付記。
- 例: エンティティ:在庫、項目:発注点、目的:発注判定基準
必要に応じて用語集の用語ID(tm-xxx-xxx)を併記。
外部システム IF の場合は IF 仕様の ID を引用。
イベントの付帯情報（ペイロード）は、BES があれば BES を正とし、BPS にはこのプロセスで参照する範囲を記述します。

6.5 処理

番号付き箇条書きで最小限のステップ。分岐は if / else ではなく日本語条件句。

例:

定番商品以外は除外
発注数量を計算（発注数量 = 注文毎の発注点 − 現在在庫数）
発注数量 > 0 の場合、発注候補を生成
bes-order-candidate-generated「発注候補生成」イベントを発火

もしくは、複雑処理については、TypeScriptの擬似コードでロジックを示す。具体的には、

業務イベントを受けるハンドラとして書く
「イベント → 入力読み取り → BR呼び出し → イベント発火」のフローとする
商品を取得するや発注候補生成イベントを発火するは、インフラ詳細に踏み込まず、概念レベルの名前だけに留める

例：

// トリガー: bes-stock-amount-updated「在庫数更新」イベント
type 在庫数更新イベント = {
  商品ID: string
  新在庫数: number
}

function 在庫数更新イベントを処理する(イベント: 在庫数更新イベント) {
  const 商品 = 商品を取得する(イベント.商品ID) // 概念レベルでOK
  const 在庫 = 在庫を取得する(イベント.商品ID)
  if (!商品.定番商品フラグ) {
    return // 定番以外は自動発注対象外
  }

  // 以下はサンプルでビジネスルールを直書き
  const 発注数量 = 商品.発注点 - 在庫.現在在庫数
  if (発注数量 > 0) {
    const 発注候補 = {
      商品ID: 商品.商品ID,
      発注数量: 発注数量,
    }
    // 出力: bes-order-candidate-generated「発注候補生成」イベント発火
    発注候補生成イベントを発火する(発注候補)
  }
}

6.6 出力

新規生成: レコード/イベント/通知。
更新: どの項目がどう変わるか（増減/ステータス変更）。
削除（あれば）。

6.7 例外 / 異常系

外部呼び出し失敗 / 入力欠損 / 矛盾（発注点 < 0）など。
失敗時挙動（再試行回数 / 中断 / 警告ログ / オペレーション通知）を記述。

6.8 メモ / 将来課題

既知の改善余地（閾値動的化、並行処理最適化など）。

7. 命名・記述スタイル

プロセス名は「名詞＋機能動詞」: 例 在庫不足検知, 自動発注候補生成。
ステップは簡潔に。禁止: 冗長なスクリーン操作列（「ページを開く→スクロール→クリック」）。
条件文は業務用語ベースで。「在庫数 − 予約数 < 発注点」などは式と意味を併記可。
受動態より能動態（「システムは候補を生成する」）。

8. 階層分解ガイド

シグナル	子業務プロセスへ分割検討
ステップ数が10超	冗長化・可読性低下
分岐が3種類以上	条件別プロセス分離
複数イベント混在	イベント別に分割
出力が多種（>5）	目的別再編

親子関係は、子プロセス側で part_of を指定します（親プロセス側に子を列挙しない）。

9. 禁止事項

項目	理由
UI操作列の逐語的記述	可読性低下・設計変更に弱い
物理テーブル名・SQL全文	概念レベル逸脱（DB設計に記述）
画面レイアウト詳細	画面仕様へ委譲
機能要件以外の雑多な会話ログ	メンテ不能
ビジネスルール重複記述	変更時不整合リスク
未定義略語乱用	用語集との整合欠如

10. よくある誤りと対策

在庫不足判定ロジックをステップ内に長文記載 → BR 化して参照。
画面遷移記述を羅列 → 「トリガー」「出力」に要約。
外部 API エラー未記載 → 例外セクションで HTTP タイムアウト・再試行方針を明示。

11. サンプル（簡易）

markdown

---
id: bps-order-candidate-generation
type: domain
title: 発注候補生成
status: draft
part_of: []
based_on: [bes-stock-amount-updated]
---

## 概要

在庫数が発注点を下回ったかどうかを判定し、発注候補を生成する。

## トリガー

- 商品の在庫数が更新された: 在庫数更新イベント(bes-stock-amount-updated)

## 前提条件

- 商品が販売可能状態
- 発注点 > 0

## 入力

- 更新があった在庫(tm-inventory)

## 処理

### 処理（ステップ例）

1. 定番商品以外は除外
2. 発注数量を計算（発注数量 = 注文毎の発注点 − 現在在庫数）
3. 発注数量 > 0 の場合、発注候補を生成
4. bes-order-candidate-generated「発注候補生成」イベントを発火

### 処理（擬似コード例）

```ts
// 例外処理は省略
// トリガー: bes-stock-amount-updated「在庫数更新」イベント
type 在庫数更新イベント = {
  商品ID: string
  新在庫数: number
}

function 在庫数更新イベントを処理する(イベント: 在庫数更新イベント) {
  const 商品 = 商品を取得する(イベント.商品ID)
  const 在庫 = 在庫を取得する(イベント.商品ID)
  if (!商品.定番商品フラグ) {
    return // 定番以外は自動発注対象外
  }

  // 以下はサンプルでビジネスルールを直書き
  const 発注数量 = 商品.発注点 - 在庫.現在在庫数
  if (発注数量 > 0) {
    const 発注候補 = {
      商品ID: 商品.商品ID,
      発注数量: 発注数量,
    }
    // 出力: bes-order-candidate-generated「発注候補生成」イベント発火
    発注候補生成イベントを発火する(発注候補)
  }
}
```

## 出力

- 発注候補生成イベント発火(bes-order-candidate-generated)

## 例外

- 発注点未設定: ログ WARN, 商品スキップ
- 外部API遅延（商品取得失敗: 3回リトライ後失敗記録

## メモ

将来: 閾値を動的（曜日別）にする拡張検討。

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

生成 AI に業務プロセス仕様を作らせるときは、以下のような指示を与える。

以下のルールに従って、業務プロセス仕様（BPS） を 1 プロセス分作成してください。出力は Markdown とします。
対象は 1 つの業務プロセス（bps-xxx-xxxx）です。業務レベルの処理に限定してください。
禁止: 物理テーブル名・カラム名・SQL全文、画面操作手順、実装クラス/関数名、UIコンポーネント名などの実装詳細
本文構成は、次の見出し（日本語）をこの順序で必ず出力してください：
概要
トリガー
前提条件
入力
処理
出力
例外 / 異常系
メモ / 将来課題
先頭に YAML Frontmatter を付与し、以下の形式で記述してください（不要な項目は省略可だが、id / type / title / status は必須）：
yaml
---
id: bps-<英小文字とハイフンで構成したID> # 例: bps-low-stock-detection
type: domain
title: <業務プロセス名> # 例: 在庫不足検知
status: draft # draft / ready / deprecated のいずれか
part_of: [] # 子プロセスの場合、親プロセスIDを指定
based_on: [] # トリガーとなるイベントIDや参照する仕様IDなど
supersedes: []
---
トリガー には、起点となる業務内容と、対応する業務イベント ID（bes-xxx-xxx）を箇条書きで記述してください（例: 商品の在庫数が更新された: 在庫数更新イベント(bes-stock-amount-updated)）。
前提条件 では、プロセス開始前に真であるべき業務条件のみを列挙してください（例：「対象商品が販売中状態」など）。
入力は概念レベルの業務データで記述し、業務データ辞書にあるエンティティ・論理名を想定して書いてください。
形式の例（箇条書きで）：
エンティティ: 在庫 / 項目: 在庫数・発注点 / 用途: 発注判定の基準
エンティティ: 商品 / 項目: 販売状態 / 用途: 発注候補対象商品の絞り込み
入力は「概念データの論理名」で統一し、物理名やSQLなどの実装詳細は書かないでください。
処理は番号付きリストで 5〜9 ステップ程度 にまとめ、各ステップを短い日本語で記述してください。
条件分岐は if/else ではなく、自然な日本語条件句（例：「在庫数が発注点を下回る場合は〜」）で表現してください。
複雑なロジックを説明する必要がある場合、任意で TypeScript 風の擬似コードブロックを追加して構いませんが、業務用語ベースの説明を優先してください。
擬似コードは「イベント駆動」を前提に、イベントハンドラ（リスナー）として記述してください。
形: function <業務イベント>を処理する(event) { ... }
フロー: イベント受信 → 入力（概念データ）取得 → BR（ビジネスルール）呼び出し → 出力（イベント）発火
BR のロジックは擬似コード内に直書きせず、可能な限り 在庫不足判定(...) のように BR を関数呼び出しとして参照してください。
商品を取得する / 〜イベントを発火する などは、インフラ詳細に踏み込まず 概念レベルの名前に留めてください。
出力では、このプロセスによって生成・更新・削除される概念データ・イベント・通知を列挙してください。
イベントには bes-xxx-xxx 形式のIDを付けて記述してください（例: bes-order-candidate-generated）。
「出力（イベント）」と「出力（概念データ/状態変化）」が両方ある場合は、同一セクション内で分けて列挙してください。
例外 / 異常系 では、主要な 2〜4 ケースを挙げ、各ケースについて
何が異常か（例: 「発注点未設定」「外部APIタイムアウト」）
どう振る舞うか（例: 「スキップ」「3回リトライ後に失敗記録」「オペレーション通知」）を明確に記載してください。
メモ / 将来課題 では、既知の改善余地や将来検討事項（例: 「閾値の動的化」「並列処理の最適化」など）を簡潔に書いてください。
全体を 業務用語で統一 し、略語を使う場合は、業務用語集に存在する一般的な略語のみとし、意味が推測しづらい略語や内部コードは使用しないでください。

このテンプレートをコピーして、生成 AI のプロンプトに貼り付けて利用してください。なお、bps-instruction.mdとして別ファイルに保存しています。

概念データフロー図

データモデル

業務モデル

インターフェースモデル

共通

C4

コンテキスト図

コンテナ図

コンポーネント図

インフラ・技術選定

インフラ構成図

単体テスト

内部結合テスト

外部結合テスト

総合テスト

受入テスト

データモデル

業務モデル

インターフェースモデル

共通

C4

インフラ・技術選定

単体テスト

内部結合テスト

外部結合テスト

総合テスト

受入テスト

010-論理設計

020-物理設計

業務プロセス仕様書 作成ルール ​

1. 全体方針 ​

2. 用語定義 ​

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

4. 推奨 Frontmatter 項目 ​

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

6. 記述ガイド詳細 ​

6.1 概要 ​

6.2 トリガー ​

6.3 前提条件 ​

6.4 入力 ​

6.5 処理 ​

6.6 出力 ​

6.7 例外 / 異常系 ​

6.8 メモ / 将来課題 ​

7. 命名・記述スタイル ​

8. 階層分解ガイド ​

9. 禁止事項 ​

10. よくある誤りと対策 ​

11. サンプル（簡易） ​

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