Pega ケースライフサイクルとフローの責務分担｜ステージ設計の判断
同じ業務でも、ステージ/ステップとして高レベルに表現するか、フローの中に手続きとして書き込むかで、後々の可読性・変更容易性・再利用性がまるで違う。責務を混在させた巨大フローや、ステップ代わりのステージ乱立は典型的な負債になる。ケースライフサイクルとフローの責務分担を、分岐をどちらに持たせるかの判断まで含めて整理する。
結論から：業務のマイルストーンはステージ、手続きはフロー
Pega のケースを設計するとき、多くの人が最初に混乱するのが「この処理をステージ／ステップとして高レベルに置くのか、それともフローの中に手続きとして書き込むのか」という線引きです。どちらでも一応は動くため、深く考えずに書き始めると、業務ロジックと画面遷移の制御がフローの中で一体化した「巨大フロー」が生まれ、後から誰も全体像を追えなくなります。
結論を先に言います。
業務の到達点（マイルストーン）を表すものはステージ／ステップに置く。ステップ内の手続き上の細かい判断や順序制御だけをフローに書く。この2つの責務を混在させない。
ステージ／ステップは「業務が今どこまで進んだか」を関係者と共有するための高レベルビューであり、フローは各ステップの中身を組み立てる詳細オーケストレーションです。高さの違う2つのレイヤーだと捉えると、判断はぐっと明快になります。
ケースライフサイクルは「2つの高さ」で見る
Pega のケースライフサイクルの正式な構成要素は ステージ（Stage）・プロセス（Process）・ステップ（Step） の3つです。ステージは1つ以上のプロセスを含み、プロセスは1つ以上のステップを含みます。そしてプロセスの実体はフロー（Flow）ルールで、ステップの実行順序を制御します。
- ステージ — 業務の大きな局面（例：受付、審査、契約、完了）。ケースがどの局面にいるかを示す最上位のマイルストーン。
- プロセス／ステップ — ステージの中の作業。プロセスは一連のステップの集まりで、その中身をフローとして表現します。ステップには、情報収集（Collect information）・承認（Approval）・自動処理（Automation）・プロセス呼び出し（Call a process＝サブフロー）といった標準のステップ種別があり、これらを組み合わせて業務の到達点を宣言的に並べます。
- フロー — プロセス／ステップの中で実際に何をどの順で実行するかの手続き。画面（フローアクション）の連結や、自動処理の順序制御を担います。
設計上は、この構造を 2つの高さ で捉えると判断が明快になります。ステージとステップは「業務を上空から俯瞰した地図」、プロセスの実体であるフローは「その地点での具体的な道順」です。地図に道順の細部を描き込めば地図として読めなくなり、道順に地図全体を背負わせれば道順が肥大化します。実際、Pega 公式ドキュメントも「ステージとステップは、中央集権的で複雑な1本のフローに依存した従来の実装を置き換えられる」と述べており、この俯瞰の層を組み立てることがモダンな設計の要になります。
具体的には、かつてのように1本の巨大なフローに業務全体を詰め込むのではなく、ステージ＋ステップへ業務を分解し、細部だけをフローに委ねるのが推奨される作り方です。ステップとして並べておけば、業務の流れは開発者でなくても図で追え、順序の入れ替えや差し替えも局所的に済みます。
責務分担の原則：混ぜないことが保守性を決める
責務分担の原則は一言でいえば「混ぜない」です。ステージ／ステップは業務のマイルストーンだけを表現し、フローは手続きだけを組み立てる。この境界を守るだけで、次の3つが同時に良くなります。
- 可読性 — ケースを開けば、ステージ／ステップの並びだけで「この業務は何段階で、今どこか」が分かる。業務ロジックを追うためにフローを開いて回る必要がない。
- 変更容易性 — 「承認ステップを1つ増やす」「審査と契約の順序を入れ替える」といった要求が、ステップの並べ替えで完結する。フローの中身を切り開かずに済む。
- 再利用性 — 手続きがステップ単位・サブフロー単位で切り出されているため、他のケースタイプからも呼び出せる。
逆に責務が混ざると、たった1本のフローが業務の分岐・画面遷移・自動処理・例外処理をすべて抱え込み、変更のたびに全体を読み解く羽目になります。これが後述する「巨大フロー」というアンチパターンの正体です。
分岐はステージ側か、フロー側か
責務分担で最も判断が要るのが「分岐をどちらの層に持たせるか」です。原則はこうです。
- 業務のマイルストーンが変わる分岐 → ステージ側（ステージ遷移として持つ）
- 手続き内の細かい判断 → フロー側（フロー内の判断として持つ）
ステージ遷移で持つべき分岐
「審査に通ったら契約ステージへ、否決なら却下ステージへ」のように、次にどの業務局面へ進むかを決める分岐は、フローの中に埋めずにステージ遷移として表現します。Pega のステージ遷移には、条件を満たしたら自動で次へ進むもの、担当者の操作で手動に進めるもの、条件付きで分岐するものがあり、これらは「業務がどう進むか」というライフサイクルの語彙です。ステージ側に置けば、業務の分岐がライフサイクル図の上に見える形で残ります。
フロー内の判断で持つべき分岐
一方、「入力値が未入力なら確認画面を挟む」「金額が閾値未満なら簡易画面、以上なら詳細画面を出す」といった、1つのステップを完了させるための手続き上の細かい判断は、フロー内の判断（意思決定図形など）で持ちます。これは業務のマイルストーンを動かすものではなく、ステップという1地点の中での道順の選択にすぎないからです。
判断に迷ったら「この分岐の結果を、関係者に『業務がこう進みました』と説明するか？」を自問してください。説明する粒度ならステージ側、しないならフロー側です。
判断早見表
| 観点 | ステージ／ステップ | フロー |
|---|---|---|
| 表すもの | 業務の到達点（マイルストーン） | ステップ内の手続き |
| 見る高さ | 業務を俯瞰する地図 | 地点ごとの道順 |
| 分岐の性質 | 次の業務局面への遷移 | 手続き上の細かい判断・順序 |
| 分岐の持たせ方 | ステージ遷移（自動/手動・条件付き） | 意思決定図形などフロー内の判断 |
| 変更の単位 | ステップの追加・並べ替え | フロー内の手続き修正 |
| 再利用 | ステップ／サブフローとして共有 | サブフローに切り出して共有 |
| 関係者との共有 | 進捗として説明できる | 実装の内部、通常は共有しない |
上の層で表現できるものを下の層に埋めない——これが実務での判断の型です。
共通ステップは再利用可能なサブフローに切り出す
複数のケースタイプで同じ手続きが現れることはよくあります。たとえば「本人確認」「上長承認」「通知送信」といったまとまりです。これらを各ケースのフローに個別にコピーすると、仕様変更のたびに全箇所を直すことになります。
正解は、共通する手続きを再利用可能なプロセス（サブフロー）として切り出し、ケースタイプ間で共有することです。ステップの種別としてプロセス（Process）を選び、切り出したサブフローを呼び出す構成にすれば、定義は1つ、修正も1箇所で済みます。ケースライフサイクル上は「本人確認ステップ」という到達点として見え、その中身は共有サブフローが担う——これが責務分担と再利用を両立させた形です。
Constellation 世代での注意点
責務配置を決める前に、対象の UI と Pega のバージョンでその構成要素が使えるかを必ず確認してください。Constellation 世代では、従来の UI（Theme Cosmos などの伝統的 UI）で使えていた一部のフロー図形やスクリーンフローが、非対応だったり利用に制約があったり、あるいは別の仕組み（スクリーンフローに相当する「複数ステップフォーム＝multi-step form」など）へ置き換えられている場合があります。
たとえば「複数画面を数珠つなぎにするスクリーンフロー」を前提に責務を設計しても、対象 UI でそれが利用できなければ、ステップ分解や別の画面構成に置き換える必要が出てきます。責務分担の原則そのもの（マイルストーンはステージ、手続きはフロー）は変わりませんが、それを実装する部品の可否は版に依存するため、設計の初期に利用可否を確認してから責務を配置するのが安全です。
フロー図形やスクリーンフローの利用可否・置換先はバージョンや UI アーキテクチャによって異なるため、実装時は利用中の版の公式ドキュメントで確認してください。Constellation への移行判断そのものについては Pega Constellation UI 導入支援サービス もあわせてご覧ください。
よくある3つの失敗
ケースライフサイクル設計の失敗は、経験上ほぼ次の3方向に集約されます。
失敗1：巨大フロー／スクリーンフローに業務ロジックを詰め込む
最も多く、最も重い負債です。1本のフローに業務の分岐・画面遷移・自動処理・例外処理を全部書き込むと、ケースを開いてもライフサイクルからは何も読み取れず、フローを開いて初めて業務が分かる状態になります。業務のマイルストーンはステージ／ステップへ引き上げ、フローには手続きだけを残してください。
失敗2：ステージをステップ代わりに乱立させる
逆に、細かい作業単位まで1つずつステージにしてしまうパターンです。ステージが十数個も並ぶと、本来「大きな業務局面」であるはずのステージが単なる作業リストと化し、俯瞰の意味が失われます。作業単位はステップで表し、ステージは業務の節目に絞ります。
失敗3：宣言的に書けるものをフロー手続きで書く
計算・バリデーション・条件判定など、専用のルール（宣言式（Declare Expression）・When 条件・データ変換など）で表現できるものを、わざわざフローの中の手続きとして組み立ててしまうパターンです。宣言式のように宣言的に書けるものは宣言的に書き、ロジックは再利用可能なルールとして独立させる——そうすればフローは手続きの骨格だけになります。
迷ったら「これはマイルストーンか、手続きか、宣言か」を口に出す。この3語で仕分けるだけで、ケース設計の大半は正しい層に収まります。
まとめ
- 業務の到達点（マイルストーン）はステージ／ステップ、手続き内のオーケストレーションはフロー。 2つの高さの責務を混ぜない。
- 分岐は層で分ける。 次の業務局面への遷移はステージ側、ステップ内の細かい判断はフロー側。
- 共通の手続きはサブフローに切り出し、ケースタイプ間で再利用する。
- アンチパターンは3つ — 巨大フローへの業務ロジック詰め込み、ステージの乱立、宣言的に書けるものの手続き化。
- Constellation 世代では部品の利用可否を先に確認してから責務を配置する。
ケースライフサイクルとフローの責務分担は、Pega アプリケーションの可読性・変更容易性・再利用性の土台です。設計の初期にこの線引きを言語化し、チームで共有しておくことが、後工程での大きな手戻りを防ぎます。
Pega の設計・実装でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、ケース設計の責務分担からご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む