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

Business Process Specification (BPS) Documentation Rulebook

概念データフローで定義したプロセス領域のうち、共通の起点と業務成果を持つ一連の流れについて、トリガー、前提条件、入出力、処理、例外、検証条件を業務観点で定義するためのルールです。

1. 全体方針

• 一文書は、概念データフローの一つのプロセス領域に属し、共通の起点と業務成果を持つ一連の流れを扱います。同じ領域に起点または業務成果が異なる流れがある場合は、BPS を分けます。
• CDFD の個別プロセスは BPS の処理ステップとして具体化します。プロセス領域の境界、プロセス ID、主要な入出力、データストアの名称を変更する必要がある場合は、先に CDFD を更新します。
• 業務担当者が開始条件、判断、責任、完了条件を確認でき、設計者とテスト担当者が機能設計および受入シナリオの入力として利用できる粒度にします。
• ビジネスルール、業務イベント、状態定義、データ定義は対応する仕様を正本とします。BPS には、その流れで参照する条件と利用目的だけを記載します。
• 物理テーブル、SQL、クラス、関数、画面操作、詳細 API などの実装方式は扱いません。
• 複数のプロセス領域またはプロセスグループをまたぐ順序と引き渡し条件はユースケース別 CDFD を正本とし、BPS では自文書が担う流れの入口と出口だけを記載します。

2. 位置づけと用語定義

用語	定義
BPS	一つのプロセス領域に属する一連の流れについて、開始から業務成果の確定までを記述する業務プロセス仕様
プロセス領域	固有の業務目的、主な担当、起点イベントを持つ CDFD 上の責務のまとまり
流れ	共通の起点と業務成果を持つ、複数の処理ステップのまとまり
処理ステップ	CDFD の個別プロセスを引き継ぎ、担当、入力、活動または判断、出力、完了条件を示す BPS 内の単位
トリガー	業務プロセスの開始を判定できる出来事。時刻到来、依頼受付、状態変化、業務イベントなど
前提条件	トリガー発生時に、処理を開始できるかを判定する条件
業務成果	処理の完了により確定する記録、状態変化、通知、判断結果、または次の業務への引き渡し
主要例外	正常な業務成果または後続処理の起動を妨げ、停止、差戻し、代替経路、または人による判断を必要とする業務上の事象

BPS は CDFD が定めるプロセス領域と流れを詳細化し、BES が定める業務イベント、BR が定める判断・計算、STSD が定める状態と遷移を利用します。参照先の定義を BPS 内へ複製せず、このプロセスでいつ、何のために利用するかを明らかにします。

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

• ファイル名は bps-<term>.md、成果物 ID は拡張子を除いた bps-<term> とします。<term> は対象の流れまたは業務成果を表す英小文字・数字・ハイフンのスラッグです。
• product 成果物の ID にはプロジェクト ID や authority を付けません。例: ファイル名 bps-order-candidate-generation.md、ID bps-order-candidate-generation。
• 番号や一時的な組織名、実装名を <term> に含めません。同じ業務上の責務を保つ限り、処理順や担当組織が変わっても ID を維持します。
• 一つの BPS に複数の独立した起点または業務成果を混在させません。起点または成果が独立して変更・承認される場合は、別の bps-<term> に分けます。
• 処理ステップ ID は文書内で一意な S-01 形式、主要例外 ID は E-01 形式とします。CDFD のプロセス ID がある場合は、処理表の「CDFD プロセス」列で対応させます。

4. 推奨 Frontmatter 項目

Frontmatter の共通原則はドキュメントメタ情報標準、許可される項目と型は成果物 Frontmatter スキーマを正本とします。

項目	説明	必須
id	プロジェクト修飾なしの bps-<term>	○
type	業務フロー・プロセス仕様を表す flow	○
status	draft / ready / deprecated	○
rulebook	specdojo:bps-rulebook	○
part_of	一覧または親成果物との所属関係	任意
based_on	作成時に直接確認した、依存関係上許可される先行成果物 ID	任意
supersedes	置き換える旧 BPS の ID	任意
relations	要求の充足などを表す型付き参照	任意

• SpecDojo が所有する項目は specdojo: 配下に置きます。文書名は Frontmatter ではなく H1 に記載します。
• based_on には、成果物カタログの depends_on の推移閉包に含まれ、実際に内容根拠として確認した ID だけを記載します。
• 作成中は status: draft とします。完成条件と承認を満たした後の ready への昇格は、プロジェクトの責任分担と運用に従います。

5. 本文要件

見出し順、表の列、記入欄の骨組みは Frontmatter で宣言した template を正本とします。BPS は、骨組みを埋めた結果として次の意味要件を満たさなければなりません。

要件群	必須	目的と記載要件
起点・目的・境界	○	対象の流れ、観測可能な起点、確定する業務成果、対象者、主担当、開始・終了、対象外を定義する
開始可否	○	トリガーの発生元・受領情報・開始条件と、開始前に確認する条件、不成立時の扱いを定義する
入力と正本	○	入力情報、入手元、利用目的、必須性、業務上の正本を定義する
処理と責任	○	処理ステップ、担当、活動または判断、入出力、完了条件、CDFD プロセスとの対応を定義する
業務成果と引き渡し	○	正常終了と条件付き終了の成果、受け手、確定条件、正本、後続処理を定義する
主要例外	○	業務成果または後続処理を変える例外について、検出条件、停止範囲、担当、処置、再開条件または代替成果を定義する
検証可能性	○	正常系・条件付き・例外系について、第三者が結果を判定できる入力条件、期待する業務成果、確認可能な記録を定義する
未決論点の追跡	条件付き	調査または意思決定が未了の論点、影響、区分、決定者、決定時期を記載する。未決事項がある場合だけ扱う

処理は操作の羅列ではなく、各ステップの業務目的と完了条件を含めます。検証条件はテストケースの実装ではなく、業務成果を受け入れられる条件を定義します。

6. 記述ガイド

6.1. 導入文と概要

• 導入文は「在庫数更新を受け、補充が必要な商品について発注候補を確定する」のように、起点、対象、業務成果を一文で示します。
• 「概要」は、業務目的、対象者、対象範囲、対象外、主担当、開始点、終了点を箇条書きまたは表で示します。対象外には前後のプロセス、横断フロー、実装方式を明記します。
• CDFD のプロセス領域名と対象の流れを示し、同じ領域にある他の流れとの境界を説明します。領域の分割そのものは BPS で変更しません。

6.2. トリガーと前提条件

• トリガーは「必要になった」ではなく、発生時点を観測できる出来事で記述します。BES がある場合は業務イベント ID と名称を併記し、イベント契約は BES を正本とします。
• 複数のトリガーが同じ流れを起動する場合は、すべてが同じ業務成果へ収束することを確認します。成果が異なる場合は BPS を分けます。
• 前提条件は yes / no で判定できる文にし、不成立時に開始しない、差し戻す、または「例外・代替経路」のどれを適用するかを示します。

推奨するトリガー表は次の列で構成します。

列	記載内容
トリガー ID	文書内で一意な T-01 形式
出来事	発生時点を判定できる業務上の出来事
発生元	人、組織、外部主体、または業務イベント
受領情報	開始判断に使用する情報
開始条件	処理開始を yes / no で判定できる条件
不成立時の扱い	非起動、差戻し、または主要例外 ID

6.3. 入力

• 入力は業務上の論理名で記載し、入手元、利用目的、必須性、正本を示します。物理テーブル名、ファイル内部の列名、API の詳細項目へ展開しません。
• イベントの付帯情報は BES、データ項目の意味は BDD または CDSD、判断に使う条件は BR を正本とし、BPS ではこの流れで使う範囲を示します。
• 入力が欠けた場合に処理を開始できないか、既定値や代替情報を使えるかを前提条件または主要例外と対応させます。

6.4. 処理

• 正常な順序に沿って S-01 から処理ステップを並べます。分岐は分岐条件と合流先または終了先を明示し、条件付きステップは必須性を示します。
• 一つのステップには、一人または一つの責任主体が完了を判断できる活動または判断を置きます。複数主体の承認や引き渡しはステップを分けます。
• 判断式や計算式の正本が BR にある場合は BR の ID と利用結果だけを記載し、ルール本文を複製しません。
• CDFD の個別プロセス ID がある場合は各ステップに対応付けます。一つの CDFD プロセスを複数ステップに分ける場合も、対応する ID を各行へ記載します。

推奨する処理表は次の列で構成します。

列	記載内容
ステップ ID	文書内で一意な S-01 形式
CDFD プロセス	対応する CDFD の個別プロセス ID
担当	実施または判断の責任主体
入力	このステップが使用する入力または直前ステップの成果
活動・判断	業務用語で表した活動、または参照する BR と判断結果
出力・完了条件	次のステップへ渡す成果と、完了を判定できる条件
例外	該当する主要例外 ID。なければ -

6.5. 出力

• 出力は記録、状態変化、通知、判断結果、または次の業務への引き渡しとして記載し、受け手、確定条件、正本を示します。
• 状態変化がある場合は STSD の状態名と遷移を参照し、BPS で状態の意味や許可遷移を再定義しません。
• 業務イベントを発行する場合は BES の ID を示し、発行条件とこのプロセスの責任だけを記載します。イベントの項目定義や購読先は BES を正本とします。

6.6. 例外・代替経路

• 主要例外は、業務成果または後続処理を変えるものに限定します。内部エラー、ログ文言、技術的な例外クラスを網羅しません。
• 表は「例外 ID」「対象ステップ」「検出条件」「停止範囲」「担当」「処置」「再開条件・代替成果」で構成します。
• 再試行回数などの運用値を BPS で決める場合は業務上の根拠を示します。技術的なリトライ方式や監視設定は運用設計または外部インターフェース仕様へ委ねます。
• 主要例外がない場合も章は残し、正常系、条件付き処理、入力不足、出力確定失敗を確認した範囲と、業務成果を変える例外がないという結論を記載します。

6.7. 検証・受入観点

• 正常系、条件付き処理、主要例外について、入力条件、期待する業務成果、確認可能な記録を対応付けます。
• 「正しく処理される」ではなく、「対象商品の発注候補が一件確定し、数量の根拠と判断に用いたルール ID を確認できる」のように判定可能な条件を記述します。
• 業務受入条件やテスト仕様に詳細を委ねる場合も、BPS 自体の完了条件を空にせず、後続文書が確認すべき業務成果を残します。

6.8. 未決事項

• 調査で解消する情報不足は _TODO_、意思決定待ちは _UNDECIDED_、仮置きする前提は _ASSUMPTION_ として区別します。
• 表は「論点」「影響する章・ステップ」「区分」「決定者」「決定時期」で構成し、本文中のラベルと対応させます。
• ready へ昇格する前に _TODO_ を解消します。_UNDECIDED_ を残す場合は、業務成果の受入可否に影響しないことと決定の追跡先を確認します。

6.9. 完成判定

• Frontmatter に id、type、status、rulebook があり、ファイル名、ID、type: flow が本ルールと一致しています。
• 対象が一つのプロセス領域に属する一連の流れであり、起点、業務成果、対象外を説明できます。
• トリガー、前提条件、入力、全処理ステップ、出力、主要例外を開始から終了まで追跡でき、CDFD のプロセス ID と名称に矛盾がありません。
• 各処理ステップに担当、入力、活動または判断、出力、完了条件があり、分岐先と例外の対応を確認できます。
• BR、BES、BDD、CDSD、STSD などの参照先を正本として扱い、定義を複製していません。
• 正常系、条件付き処理、主要例外の受入条件が第三者に判定可能で、確認可能な記録または業務成果を示しています。
• 物理データ構造、詳細 API、画面操作、実装クラスなどの実装方式が混在していません。
• _TODO_ が残っていません。_UNDECIDED_ がある場合は「未決事項」に決定者と決定時期があります。

7. 禁止事項

• 複数のプロセス領域を一つの BPS に混在させたり、独立した起点または業務成果を「関連するから」という理由だけで一文書にまとめたりしません。
• CDFD のプロセス領域、プロセス ID、データストア名を BPS だけで追加、削除、改名しません。
• BR の判断式、BES のイベント契約、BDD・CDSD のデータ定義、STSD の状態定義・遷移表を複製しません。
• 処理ステップを画面のクリック順、CLI コマンド列、API 呼び出し順、クラスや関数の呼び出し順として記載しません。
• 物理テーブル、物理カラム、SQL、詳細 API 項目、実装クラス、ログ文言、秘密情報を記載しません。
• 担当、完了条件、分岐先、再開条件を空欄にしたり、「適切に処理する」「問題がなければ完了」のような判定不能な表現だけで済ませたりしません。
• 正常な非起動条件を主要例外として扱ったり、業務成果を変えない内部エラーを網羅的に列挙したりしません。
• 作成状況やレビュー状態を本文で管理しません。進捗と判断履歴は登録簿やレビュー結果で追跡します。