業務ルール

業務ルールは、組織が必須・禁止・必然と認める関係を表す

業務ルールの主な種類

業務ルールというと、金額を超えたら承認を上げる条件だけを想像しがちです。実際には、用語の定義、対象が有効になる条件、行動できる役割、事実不足時の扱いもルールです。種類を分けると、誰に確認し、どの方式で実装するかを判断しやすくなります。

管理可能な一つの業務ルールに記録する事項

もっともらしい一文でも、そのまま安全に実装できるとは限りません。根拠、適用対象、必要な事実、例外、過去判断の再現方法まで分かって初めて、長期的に保守できるルールになります。

実際の業務ルールを発見し、確認する方法

ルールが一つの文書に整然と集まっていることはまれです。規程には原則、権限表には限度額、担当者には例外、旧システムには過去の判断が残っています。これらを突き合わせ、実際に権限を持つ人が意味を確定する作業が必要です。

1. 判断と業務対象を特定する

   適格性、金額、状態、経路、制限について一貫して答えるべき問いと責任者を列挙します。DB項目や既存コードから始めません。

2. 権威ある資料を集める

   法令、契約、規程、権限表、製品方針、帳票、手順、過去判断を確認し、版、適用範囲、解釈権限者を記録します。

3. 実務・統制担当者へ聞く

   担当者、承認者、コンプライアンス、財務、運用、監査から通常判断、例外、異議、是正を聞き、正式ルール、慣行、個人習慣、システム制約を区別します。

4. 事例と運用記録を観察する

   承認、拒否、差戻し、上申、取消し、例外を抽出します。同じ事実で結果が違えば、隠れたルール、データ不良、未承認のばらつきを疑います。

5. 業務語彙を統一する

   申請、有効な権限、営業日、金額、顧客状態などを定義し、同義語と同名異義を解消してからルールを書きます。

6. 根拠付きの原子ルールを書く

   複合文章を単一判断へ分け、根拠と業務理由を紐付けます。不明点は確認待ちとし、コードで勝手に選びません。

7. 例・反例・境界を再生する

   典型、閾値、欠損、競合、例外の事実を権限者に判断してもらい、唯一の結論または明示的な判断不能になることを確認します。

8. 基準版と保守責任を承認する

   有効ルール群、優先関係、発効日、承認者、変更入口を記録し、意味の所有、管理、技術実装の責任を分離します。

デシジョンテーブルは論理を点検するが、ガバナンスを代替しない

条件が増えると、文章だけでは組合せの抜け、重なり、矛盾が見えにくくなります。表は入力と結論を並べて点検できますが、閾値や優先順位が正式に承認されたことまでは証明しません。論理の問題を探す道具であり、業務責任の代わりではありません。

1. 入力列は安定した事実か

   各入力に名称、型、許容値、出所、時間意味があり、自由文や未確認のモデル出力を条件へ直結させません。

   確認：業務用語集、データ定義。

2. 行を区別できるか

   複数行が矛盾する結論へ同時一致しないかを調べ、複数一致時のヒット方針を明示します。

   確認：重複分析、ヒット方針。

3. 全組合せに結果があるか

   欠落には既定、資料不足、判断不能、人手確認を明示し、偶然最初の行やnullへ落としません。

   確認：完全性分析、未一致テスト。

4. 境界と単位は正確か

   超過、以上、締切日時、タイムゾーン、通貨、丸め、nullを明確にし、境界値でシステム間の判断を揃えます。

   確認：境界値・単位テスト。

5. 出力は結論か動作か

   表が「合議必要」と判断しても、タスク、通知、書込みにはプロセス、権限、エラー処理が別途必要です。

   確認：判断―プロセス―動作対応。

6. 根拠・版・説明を残せるか

   論理をルールIDと権威へ追跡し、実行ごとにルール群の版、入力、適用経路を記録します。

   確認：判断ログ、版台帳。

構成例：調達承認ルール群

以下の顧客と無関係な構成例で、これまでの要素をつなげます。特定の金額や制度を推奨するものではありません。定義、職務分離、事実不足、優先関係が一つの判断を作り、その判断がシステム動作の完了とは別であることが要点です。

監査・変更可能なルール基準を作る

方針、製品、組織責任が変わればルールも変わります。重要なのは、どの案件をどの版で扱ったかを後から説明できることです。基準版があれば、見積り、実装、検収、本番運用が同じ参照点を持ち、過去判断も当時の条件で確認できます。

1. ルール台帳と用語集を管理する

   ID、記述、種別、用語、権威、所有者、範囲、版、状態、依存、テスト、実装箇所を一元化し、規程、表計算、設定、コードの分岐を防ぎます。

2. 業務所有と技術実装を分ける

   業務・コンプライアンス権限者が意味を承認し、技術側は確実に実装して制約を報告します。設定権限だけで政策判断の所有者にはなりません。

3. 識別可能なルール群を承認する

   見積り、設計、検収、本番で、出所スナップショット付きの版を指定し、再現不能な「現在のオンラインロジック」を基準にしません。

4. 複数実装の整合を保つ

   画面案内、バックエンド検証、バッチ、帳票、AIツールは、一つの権威サービスまたは自動整合性検査を使用します。

5. 変更前に影響を分析する

   過去・処理中案件、インターフェース、権限、通知、教育、テスト、価格、AI評価、ロールバック、旧案件への適用版を評価します。

6. リリース、監視、復元を行う

   境界・履歴再生後に承認と発効時刻を記録し、判断分布、未一致、競合、上書きを監視し、承認済み版へ戻せるようにします。

7. 判断説明を保存する

   個人情報・保存方針の範囲で、入力事実、ルール版、適用経路、上書き者・理由を保持し、異議申立て、監査、障害再現に備えます。

範囲・プロセス・システム・検収への接続

業務ルールは要件工程だけの付属資料ではありません。必要データ、プロセス分岐、連携失敗時の扱い、検収の境界条件、運用責任まで影響します。各工程が別の版を参照すれば、個々の機能が動いても業務結論は一致しません。

企業AIの業務ルールをプロンプト内の数行へ退化させない

モデルが規程を読み、ルールを説明できることには価値があります。しかし「だいたい理解している」ことは安定した執行ではありません。出力はプロンプト、文脈、モデル版で変わるため、権限、金額、禁止、不可逆操作では説明支援と最終統制を分けます。

業務ルールと混同しやすい概念

方針、プロセス、データ検証、コード条件は、それぞれルールの一部を担うことがあります。そのため会話では同じものとして扱われがちです。実装方式をルールそのものと誤認すると、意味を承認できる人が分からず、システム交換後にも残すべき制約を失います。