ビジネスルールを発見する

はじめに

前回記事「業務概念を型として表現する」では、業務概念をプログラミング言語の型として表現する判断軸を整理しました。本記事はその前段にあたります。型として表現する対象となる業務概念には、その内側にビジネスルールが宿っています。これらのルールをどう発見し、どう整理するか、というのが本記事の主題です。

ビジネスルールという言葉は、エヴァンス氏の『エリック・エヴァンスのドメイン駆動設計』や増田亨氏の『現場で役立つシステム設計の原則』でも繰り返し登場します。ただ、書籍の中では「発見する」という作業そのものに焦点が当てられることは少なく、現場で実際にルールを掘り起こす作業は実装者の経験に委ねられている部分が多いと感じます。

本記事で扱うのは、ビジネスルールを業務ドメインの中から発見する作業の体系化です。
具体的にはビジネスルールの種類を整理し、それぞれの発見手法を実例とともに展開します。題材は前回と同じ会員制サービスのリプレイス案件です。

想定読者はテックリード・アーキテクト層です。ドメインモデリングの基本概念は把握している前提で、筆者の現場での具体的な判断を提示します。
本記事はドメインモデル3部作の2本目で、3部作の最後は「ドメインモデルとは何か」を扱う予定です。

---

第1部: 概念の整理

第1章: ビジネスルールとは何か

ビジネスルールという言葉は広い意味で使われます。本記事の出発点として、この言葉の意味を整理します。

ビジネスルールとは、業務ドメインの中で満たされるべき条件や、従うべき手順のことです。
たとえばECサイトなら「在庫がない商品は注文できない」「同じ商品を複数注文できる」「配送料は購入金額に応じて変動する」といったルールがあります。これらはシステムが扱うべき業務上の制約や手順であり、コードの中で正しく表現されなければサービスとして成立しません。

なお本記事では、業務ドメインに関わる規範を総称して「ビジネスルール」と呼びます。前回記事で使った「業務ルール」「業務上の制約」「業務上の手順」も同じ規範を指す表現で、本記事ではこれらをビジネスルールの下位分類として扱います。具体的には業務上の制約・業務上の手順といった性質の違いは、第2章のタイプ分類の中で整理し直します。

ビジネスルールは、業務概念と密接に結びついています。
過去記事では業務概念を型として表現する判断軸を扱いましたが、業務概念そのものはルールを伴います。たとえば「会員ランク」という業務概念には「定義された区分のいずれか」というルールが伴い、「特典有効期限」という業務概念には「現在時刻より未来であるべき」というルールが伴います。業務概念とビジネスルールは表裏一体の関係にあります。

ビジネスルールがコードの中で語られていない状態は、過去記事で扱った業務ルールの暗黙化と同じ問題を生みます。
ルールがコードのあちこちに散在し、業務上の意味が読み取れなくなる。新しいメンバーがコードを読んでも、それがビジネスルールなのか、たまたまその場のロジックなのかが区別できない。この状態を避けるには、まずルールを発見することが出発点になります。発見されないルールは、型にもオブジェクトにも閉じ込められません。

ここで重要なのは、ビジネスルールは最初から明示的に存在しているわけではないということです。ドメインエキスパートの頭の中に暗黙知として存在する、業務ドキュメントに断片的に書かれている、既存システムのコードに埋め込まれている、運用の現場で例外処理として発生している、というように、ルールの居場所はさまざまです。これらを掘り起こし、整理し、コードで表現できる形に翻訳する作業が、本記事で扱う「発見する」作業です。

第2章: ビジネスルールの分類

ビジネスルールを発見しようとするとき、まず役立つのがルールの種類による分類です。種類が違えば発見手法も違います。本章では4つのタイプに分けて整理します。

本章で扱う4タイプの全体像を先に示します。

タイプ	性質	典型例
不変条件タイプ	常に成り立つべきルール	会員ランクは定義された区分のいずれか
業務制約タイプ	特定の条件下で成り立つルール	特典の有効期限を過ぎた会員は利用不可
業務プロセスタイプ	時間軸を持つルール	ランク判定は月次バッチで実行される
業務上の例外処理タイプ	通常から外れる状況のルール	不正利用検出時はランクを強制リセット

各タイプの詳細は順に展開します。

タイプ1: 不変条件タイプ

業務概念にとって常に成り立つべきルールです。
たとえば「会員ランクは定義された区分のいずれか」「ポイントは0以上の整数」「特典の有効期限は現在時刻より未来」といったルールが該当します。これらは業務概念が存在する時点で常に満たされるべき条件で、満たされない状態は業務上ありえません。

不変条件タイプは、Value Objectのコンストラクタチェックや、Entityの状態遷移の制約として実装されることが多くなります。型として表現する判断と相性が良いタイプです。なお、Value Objectは不変であることが前提です。生成後に値が変更可能だと、コンストラクタでの検証が後から崩れる可能性があるためです。詳細は前回記事「業務概念を型として表現する」を参照してください。

タイプ2: 業務制約タイプ

特定の条件下で成り立つルールです。
たとえば「特典の有効期限を過ぎた会員はその特典を利用できない」「ランクごとに利用可能な特典の範囲が異なる」「ランクごとにポイント還元率が異なる」といったルールが該当します。これらは複数の業務概念にまたがる関係性のルールで、ある条件が成り立つときに別の条件を満たすべき、という構造を持ちます。

業務制約タイプは、複数の業務概念を参照する判定処理として実装されます。過去記事で扱った業務概念間の関連メソッドや、それでも帰属させにくい場合のドメインサービスとして実現されることが多いタイプです。順序としては業務概念間の関連メソッドを優先し、それでも難しい場合にドメインサービスを採用するのが望ましいです。これは前回記事で確立した、ドメインサービスは業務ロジックを業務概念に集約しきれない場合の選択肢として位置付けるという方針と整合します。

タイプ3: 業務プロセスタイプ

時間軸を持つルールです。
たとえば「会員が新規登録すると初期ランク(ブロンズ)が付与される」「ランク判定は月次で実行される」「ポイントには有効期限があり、期限切れで失効する」といったルールが該当します。これらは業務上の手順や、時間経過によって発生するイベントに紐づくルールです。

業務プロセスタイプは、業務概念のライフサイクルや、バッチ処理、イベント駆動の仕組みとして実装されます。時間軸という性質上、業務概念単体には閉じにくく、複数の業務概念にまたがる処理として実現されることが多いタイプです。

タイプ4: 業務上の例外処理タイプ

通常の業務フローから外れる状況のルールです。
たとえば「不正利用が検出された場合、会員ランクを強制的にブロンズに戻す」「システム障害時のポイント付与は手動で補正する」「退会した会員のポイントは残らない」といったルールが該当します。これらは業務の主軸ではないが、運用上必ず発生する例外的な状況のルールです。

業務上の例外処理タイプは、最も発見されにくいタイプです。ドメインエキスパートとの対話でも見落とされやすく、運用の現場で初めて顕在化することも多くあります。発見の作業として最も丁寧に扱う必要があるタイプです。

第3章: なぜルールの分類が発見作業に効くのか

第2章で4つのタイプを整理しました。なぜタイプ別に整理することが、発見の作業に効くのか、本章で説明します。

理由の一つ目は、タイプごとにルールの居場所が違うことです。
不変条件タイプはドメインエキスパートにとって「言うまでもない前提」として頭の中にあります。明示的に語られないため、ヒアリングの中で意識的に問いかけないと出てきません。一方、業務プロセスタイプは業務ドキュメントや運用手順書に書かれていることが多く、ドキュメント調査で発見できます。タイプごとに探す場所を変えることで、発見の漏れを減らせます。

理由の二つ目は、タイプごとに発見の問いかけが違うことです。
不変条件タイプを発見するには「この値は常に何を満たすべきか」「ありえない状態はどんなものか」と問うのが有効です。業務制約タイプを発見するには「どんな条件のとき、どんな結果になるか」「Aが成り立つとき、Bは何を満たすべきか」と問うのが有効です。業務プロセスタイプは「いつ何が起きるか」「時間が経つと何が変わるか」、業務上の例外処理タイプは「通常のフローから外れる状況はどんなときか」「失敗したらどう戻すか」と問うのが有効です。タイプを意識すると、ドメインエキスパートへの質問が具体的になります。

理由の三つ目は、タイプごとに実装の落としどころが違うことです。
発見されたルールが、最終的にどこに集約されるかは、タイプによって変わります。これは前回記事「業務概念を型として表現する」で扱った内容と接続します。不変条件タイプはValue ObjectやEntityの内側に集約されやすく、業務制約タイプは業務概念間の関連メソッドや、必要に応じてドメインサービスに集約されます。発見の段階でタイプを意識することで、実装段階での集約先も見えやすくなります。

ここまでの3つの理由を、表として整理します。

タイプ	主な居場所	有効な問いかけ	主な集約先
不変条件	ドメインエキスパートの頭の中(暗黙の前提)	「常に何を満たすべきか」「ありえない状態は何か」	Value Object、Entityのコンストラクタ
業務制約	業務シナリオ、ドキュメント	「Aが成り立つとき、Bは何を満たすべきか」	業務概念間の関連メソッド、必要に応じてドメインサービス
業務プロセス	業務ドキュメント、運用手順書	「いつ何が起きるか」「時間が経つと何が変わるか」	業務概念のライフサイクル、ドメインサービス
業務上の例外処理	運用記録、運用担当者の頭の中	「通常のフローから外れる状況は何か」「失敗したらどう戻すか」	業務概念の状態遷移メソッド、専用処理

ここで重要な視座を一つ加えます。ビジネスルールが発見されないまま実装に入ると、業務ロジックがサービスクラスや手続き的なコードに散在する構造、いわゆるトランザクションスクリプトパターンを生みます。
ファウラー氏の『エンタープライズ アプリケーション アーキテクチャ パターン』で整理されているこのパターンは、業務ロジックが業務概念に集約されず、長い手続き的な処理の中に書き連ねられる構造です。短期的には書きやすいですが、変更に弱く、業務ルールの所在が曖昧になります。
ここで重要なのは、トランザクションスクリプトパターンと業務ロジックを業務概念に集約するアプローチは、対立する設計思想だという点です。前者は業務ロジックを手続き的な処理の中に書き連ねるアプローチ、後者は業務ロジックをオブジェクトの中に閉じ込めるアプローチで、両者は異なる方向を向いています。
ビジネスルールを発見し、業務概念に集約する作業は、トランザクションスクリプトパターンを避け、増田氏が『現場で役立つシステム設計の原則』で繰り返し主張する業務ロジックを業務概念に集約するという設計思想を実現するための前提です。

---

第2部: 実例

第4章: 会員制サービスのビジネスルールを発見する

ここからは過去に関わった会員制サービスを題材に、ビジネスルールの発見作業を具体的に再現します。筆者が現場で実際に行った発見の記録を、可能な範囲で再現します。

会員制サービスの業務概念は過去記事で整理した通りです。会員、利用履歴、特典マスタ、ポイント残高がEntity、会員ランク、ポイント、特典有効期限などがValue Object、ランク判定プロセスなどがドメインサービスとして識別されました。本章では、これらの業務概念に紐づくビジネスルールをどう発見していったかを、タイプ別に展開します。

発見作業の全体の流れを先に示します。

タイプごとに発見の手法と情報源が違うことが、図から読み取れます。ここから先は、タイプ別に発見の物語を展開します。

不変条件タイプの発見

不変条件タイプのルールは、ドメインエキスパートとの初期ヒアリングで意識的に問いかけることで発見できました。
「会員ランクが取りうる値は何か」「ポイントが負の数になることはあるか」「特典有効期限が過去になることはあるか」といった問いかけを順に繰り返しました。ドメインエキスパートにとっては当たり前の前提ですが、明示的に問いかけることで言語化されました。

このフェーズで発見できたルールの一部です。

• 会員ランクはブロンズ・シルバー・ゴールド・プラチナのいずれか
• ポイントは0以上の整数
• 特典有効期限は付与日より未来
• 会員の生年月日は会員登録日より前

発見の作業として印象に残っているのは、ドメインエキスパートが「言うまでもないので説明しなかった」というルールが多くあったことです。明示的に問いかけなければ言語化されないルールは、コードの中で暗黙化しがちです。

業務制約タイプの発見

業務制約タイプは、業務シナリオを具体的に追うことで発見できました。
「会員がサービスを利用するときに、特典が適用されるかをどう判定するか」「ランクごとに利用可能な特典は何か」「ポイント還元率はどう決まるか」といった具体的なシナリオをドメインエキスパートと一緒にトレースしました。

このフェーズで発見できたルールの一部です。

• 特典の有効期限を過ぎた会員はその特典を利用できない
• ランクごとに利用可能な特典の範囲が異なる(ブロンズは基本特典のみ、シルバー以上は応用特典も利用可)
• ポイント還元率はランクごとに異なる(ブロンズ1%、シルバー2%、ゴールド3%、プラチナ5%)
• 同じ特典は1会員あたり月1回までしか利用できない

ここで「ランクごとに利用可能な特典の範囲が異なる」「ポイント還元率はランクごとに異なる」というルールは、前回記事で扱った区分オブジェクト(会員ランク)の典型的な業務ルールに該当します。区分ごとに振る舞いが変わるルールは、業務概念に区分オブジェクトとして表現されるべき内容を、ビジネスルールの側から発見した結果です。

業務制約タイプは複数の業務概念にまたがるため、「Aが成り立つとき、Bは何を満たすべきか」という構造で問いかけることが効果的でした。

業務プロセスタイプの発見

業務プロセスタイプは、業務ドキュメントと運用手順書の調査で多くを発見できました。
ドメインエキスパートとの対話だけでなく、既存システムの設計書やバッチ処理のスケジュール定義も並行して調査しました。

このフェーズで発見できたルールの一部です。

• 会員が新規登録すると、初期ランク(ブロンズ)が付与される
• ランク判定は月次バッチで実行され、その月の利用実績を基に翌月のランクが決まる
• ポイントには付与日から1年の有効期限があり、期限切れで失効する
• ランクが変動した場合、変動を会員に通知する

業務プロセスタイプは時間軸を持つため、「いつ何が起きるか」「時間が経つと何が変わるか」という問いかけで掘り下げました。

業務上の例外処理タイプの発見

業務上の例外処理タイプは、最も発見が難しいタイプでした。
ドメインエキスパートとの初期ヒアリングでは出てこず、業務シナリオを追っている中でも見落としやすい性質を持ちます。発見できたきっかけは、運用記録の調査と、運用担当者との対話でした。

このフェーズで発見できたルールの一部です。

• 不正利用が検出された場合、会員ランクを強制的にブロンズに戻す
• システム障害時のポイント付与は手動で補正する
• 退会した会員のポイントは残らない(退会と同時に失効する)
• ランクダウンの判定で利用がない期間が一定を超えた場合、ランクを段階的に下げる

これらのルールは、運用担当者が日々対処している業務の中に埋め込まれていました。実装担当者だけがドメインエキスパートと対話していても発見できないルールが、運用担当者との対話で初めて出てきました。

第5章: 発見されたビジネスルールを業務概念に集約する

第4章で発見したビジネスルールを、どう業務概念に集約していったかを本章で扱います。発見しただけでは、ルールはコードの中で機能しません。集約の作業が必要です。

集約の作業で意識していたのは、業務ロジックを業務概念に集約するという設計思想でした。これは増田氏が『現場で役立つシステム設計の原則』で繰り返し主張する考え方で、サービスクラスや手続き的なコードに業務ロジックを書き散らすのではなく、業務概念を表すオブジェクトの中に業務ロジックを集約する、というものです。

集約の落としどころは、ルールのタイプによって変わりました。

不変条件タイプの集約先

不変条件タイプのルールは、Value ObjectやEntityのコンストラクタチェックとして集約しました。
「会員ランクはブロンズ・シルバー・ゴールド・プラチナのいずれか」というルールは、MemberRankValue Objectのコンストラクタで定義済み区分を検証する形で実装しました。「ポイントは0以上の整数」も同様に、PointValue Objectのコンストラクタで範囲を検証しました。

業務制約タイプの集約先

業務制約タイプのルールは、関連する業務概念のメソッドとして集約することを優先しました。
「特典の有効期限を過ぎた会員はその特典を利用できない」というルールは、BenefitEntityに「利用可能か」を判定するメソッドを持たせる形で実装しました。「ランクごとに利用可能な特典の範囲が異なる」というルールは、MemberRankValue Objectに「利用可能な特典タイプ」を返すメソッドを持たせました。

ここで意識したのは、ルールの帰属先を慎重に選ぶことでした。複数の業務概念にまたがるルールでも、どちらか一方に帰属させられないか、まず検討しました。それでも帰属先が決まらない場合に、最後の手段としてドメインサービスを採用するアプローチを取りました。

業務プロセスタイプの集約先

業務プロセスタイプのルールは、業務概念のライフサイクルや、ドメインサービスを介して集約しました。
「会員が新規登録すると、初期ランク(ブロンズ)が付与される」というルールは、MemberEntityのファクトリメソッドの中に集約しました。「ランク判定は月次バッチで実行される」というルールは、ランク判定プロセスをドメインサービスとして実装し、バッチ処理から呼び出す構造にしました。

ただしここで反省点が一つあります。ランク判定プロセスをドメインサービスとして実装する際、責務が肥大化しないように分割する努力が不十分でした。これは過去記事の反省点としても触れた論点で、現時点の筆者であれば、業務概念への集約をより深く検討するアプローチを取ります。

業務上の例外処理タイプの集約先

業務上の例外処理タイプのルールは、業務概念の状態遷移メソッドや、専用の処理として集約しました。
「不正利用が検出された場合、会員ランクを強制的にブロンズに戻す」というルールは、MemberEntityに「ランクをリセットする」メソッドを持たせる形で実装しました。「退会した会員のポイントは残らない」というルールは、退会処理の中でポイント残高をクリアする処理として集約しました。

ここまでの集約の判断を、本章で扱った具体的なルールごとに整理します。

発見したルール	タイプ	集約先
会員ランクは定義された区分のいずれか	不変条件	MemberRankValue Objectのコンストラクタ
ポイントは0以上の整数	不変条件	PointValue Objectのコンストラクタ
特典の有効期限を過ぎた会員は利用不可	業務制約	BenefitEntityの「利用可能か」判定メソッド
ランクごとに利用可能な特典の範囲が異なる	業務制約	MemberRankValue Objectの「利用可能な特典タイプ」メソッド
新規登録時に初期ランクが付与される	業務プロセス	MemberEntityのファクトリメソッド
ランク判定は月次バッチで実行される	業務プロセス	ランク判定プロセスのドメインサービス+バッチ処理
不正利用検出時にランクをリセット	業務上の例外処理	MemberEntityの「ランクをリセットする」メソッド
退会した会員のポイントは残らない	業務上の例外処理	退会処理内のポイント残高クリア処理

集約の作業を通じて、ビジネスルールが業務概念の中に閉じ込められると、コードを読むだけで業務ルールが追えるようになります。これは業務ルールの暗黙化を避けるための実装上の本道です。

---

第3部: 判断

第6章: ビジネスルールを発見するための判断軸

第4章・第5章で扱った具体例から、ビジネスルールを発見する作業の判断軸を整理します。筆者が現場で使ってきた判断軸を、ここでは5つに分けて言語化します。

5つの判断軸の関係性を先に示します。

判断軸は順序として進んでいくものではなく、発見作業の中で循環的に行き来するものです。情報源を選び、問いかけ、検証し、矛盾に出会えば対処し、暗黙のルールを言語化する、というプロセスを繰り返します。

判断軸1: どこから発見するか

ビジネスルールの居場所は一箇所ではありません。発見作業の最初の判断は、どの情報源を使うかです。

主な情報源は次の通りです。

• ドメインエキスパートとの対話(暗黙の前提を引き出す)
• 業務ドキュメント(明示的に文書化されたルール)
• 既存システムのコード(実装に埋め込まれたルール)
• 運用記録・運用手順書(運用の現場で発生するルール)
• テストケース(過去に発見された境界条件)

すべての情報源を使うのが理想ですが、現場の制約で全部にアクセスできるとは限りません。情報源の優先順位を、ルールのタイプで判断するのが有効です。不変条件タイプはドメインエキスパートとの対話、業務プロセスタイプは業務ドキュメント、業務上の例外処理タイプは運用記録、というように使い分けます。

判断軸2: どう問いかけるか

ドメインエキスパートへの問いかけの仕方が、発見できるルールの質を決めます。
オープンな問い(「業務上のルールを教えてください」)では、ドメインエキスパートにとって明示的に意識しているルールしか出てきません。クローズドな問い(「会員ランクが取りうる値は何ですか」「ありえない状態はどんなものですか」)では、暗黙の前提が言語化されやすくなります。

タイプ別の問いかけ例を再掲します。

• 不変条件タイプ: 「常に何を満たすべきか」「ありえない状態は何か」
• 業務制約タイプ: 「Aが成り立つとき、Bは何を満たすべきか」
• 業務プロセスタイプ: 「いつ何が起きるか」「時間が経つと何が変わるか」
• 業務上の例外処理タイプ: 「通常のフローから外れる状況は何か」「失敗したらどう戻すか」

問いかけの粒度を意識的に変えることで、発見の深さが変わります。

判断軸3: 発見したルールをどう検証するか

発見したルールが正しいかは、最初の対話だけでは判断できません。複数の情報源で裏取りするのが現実的です。
ドメインエキスパートから聞いたルールを、業務ドキュメントで確認する。業務ドキュメントに書かれたルールを、既存システムのコードで確認する。コードに埋め込まれたルールを、運用記録で確認する。情報源を横断して整合性を確認することで、発見されたルールの精度が上がります。

複数の情報源で食い違いがあった場合、それ自体が発見の材料になります。ドメインエキスパートの認識と実装が違うなら、どちらが正しいルールかを判断する必要があります。これは業務側との合意形成が必要な論点です。

判断軸4: ルールが矛盾するときの対処

発見作業を進めると、ルール同士が矛盾するケースに出会います。
「ランクは利用実績で決まる」というルールと「不正利用検出時はランクをブロンズに戻す」というルールは、状況によっては矛盾します。月次のランク判定で本来ゴールドになるはずの会員が、不正利用検出で強制的にブロンズに戻る、というケースです。

矛盾の対処は、ドメインエキスパートとの合意形成が必要です。優先順位を明確にし、どちらのルールが優先されるかを言語化します。発見の作業の中で、矛盾を見つけ、解決の合意を形成することも、発見作業の一部です。

判断軸5: 暗黙のルールをどう言語化するか

ドメインエキスパートにとって「言うまでもない前提」のルールは、最も言語化が難しいタイプです。
言語化のコツは、具体例を使うことです。抽象的に「ルールはありますか」と問うのではなく、「会員Aさんがブロンズランクで、特典Xを使おうとしたらどうなりますか」と具体例で問う。具体例の中で違和感が出てきたら、その違和感の原因がルールです。

筆者の現場では、ドメインエキスパートと一緒にホワイトボードでシナリオを描きながら、ルールを言語化していくスタイルが効果的でした。一人で文章として書き起こすより、対話の中で具体例を追う方が、暗黙のルールが浮かび上がります。

---

第4部: 反省

第7章: 振り返ると、見落としていたビジネスルール

会員制サービスのリプレイス案件を振り返ると、ビジネスルールの発見作業は完璧ではありませんでした。発見しきれなかったルールがいくつもあります。本章ではその反省を率直に書きます。

反省点の一つ目は、業務上の例外処理タイプの発見が浅かったことです。
第4章で書いた通り、このタイプは運用担当者との対話で多くを発見しましたが、実装後に運用が始まってから初めて気づいたルールもありました。たとえば「キャンペーン期間中の特殊なポイント付与ルール」「過去のシステム障害時の手動補正の履歴」といったルールは、運用が回り始めてから発見されました。実装段階で発見できなかったため、後から修正が必要になりました。

反省点の二つ目は、ドメインエキスパートの認識が部分的だったことです。
書き手が対話したのは、業務側の代表者数名でした。しかし会員制サービスのような大きな業務には、複数の関係者が関わります。マーケティング担当、カスタマーサポート、法務など、それぞれが異なるルールを認識していました。代表者数名との対話だけでは網羅できないルールが、後から他の関係者から指摘されることがありました。

反省点の三つ目は、ルールの背景の言語化が不十分だったことです。
たとえば「ランクダウンは前回利用から一定期間経過後に発生する」というルールを発見しましたが、なぜその期間なのかという背景の言語化はできていませんでした。背景が言語化されていないと、後でルールを見直すときの判断材料が失われます。これは過去記事でも反省点として触れた論点です。

これらの反省は、現時点の筆者であれば違うアプローチを取れる箇所が多くあります。運用担当者との対話を実装前に組み込む、業務側の関係者を網羅的に洗い出す、ルールの背景もコードのコメントや設計書で表現する、などです。
ただし、当時の筆者の知識と経験では、上記の判断が現実的な落とし所だったとも感じています。ビジネスルールの発見は一度の作業で完結するものではなく、運用を通じて継続的に更新されていくものでもあります。

筆者のビジネスルールの発見作業は、この案件で完成したわけではなく、今も続いています。本記事を書くこと自体が、過去の発見作業を振り返り、次の現場で活かす機会になっています。

---

第8章: シリーズ主軸との接続と、次回予告

本記事ではビジネスルールを発見する作業を、筆者の現場経験を題材に体系化しました。

シリーズ全体を通じて書いてきた「設計判断は人間に残る」という主張は、本記事の領域でも当てはまります。
ビジネスルールを発見する判断、どの情報源を使うかの判断、矛盾するルールの優先順位の判断、これらはすべて筆者と業務関係者が業務ドメインの理解に基づいて行うものです。発見の作業は機械的な処理ではなく、人間同士の対話と合意形成の積み重ねです。

ドメインモデル3部作の最終回は「ドメインモデルとは何か」を扱う予定です。本記事と過去記事で扱った業務概念とビジネスルールを統合し、ドメインモデルという概念そのものをエヴァンス氏らの古典を参照しながら現代の実装文脈で読み直す試みになります。

ビジネスルールの発見は、筆者にとって今も学び続けている領域です。本記事で書いた判断軸も、今後の現場経験の中で更新されていくはずです。