Pega 用語集

環境の稼働状況、リクエスター、バックグラウンド処理（キュープロセッサやジョブスケジューラー）などを監視・管理する運用者向けのワークスペースです。

なぜあるか運用担当者が、開発用の画面を使わずに環境の状態を管理できるようにするためです。

詳しい解説記事

ケースタイプ、データ、画面、利用者などをローコードで設定するための開発ワークスペースで、業務担当者と開発者の共同作業を想定しています。

なぜあるか業務を理解している人が、設計と構築に直接参加できるようにするためです。

注意App Studio で扱えない設定も多いため、どこから Dev Studio で作業するかの線引きを決めておく必要があります。

詳しい解説記事

すべてのルールとデータを直接扱える開発者向けのワークスペースで、クラス設計、連携、性能の調整など、App Studio では扱えない設定を行います。

なぜあるかローコードの画面では表現しきれない設定を、開発者が細かく行えるようにするためです。

詳しい解説記事

Pega が運用を担うマネージドのクラウドサービスで、基盤の保守やアップデートを Pega が実施します。

なぜあるか利用企業が基盤の運用ではなく、業務アプリケーションの開発に集中できるようにするためです。

注意利用企業が自らインフラを管理する形態（クライアント管理クラウドやオンプレミス）とは、運用の責任範囲が異なります。

コンタクトセンター業務向けの Pega の業務アプリケーションです。顧客との接点（インタラクション）と、その中で発生する手続き（サービスケース）を分けて管理します。

なぜあるか応対の記録と業務の処理を結び付け、応対から手続きの完了までを一貫して扱うためです。

詳しい解説記事

Pega Platform と、その上で動く業務アプリケーション（Customer Service、Customer Decision Hub など）を含む製品群全体の名称です。近年のバージョンは「Pega Infinity '24」のように年で表記されます。

なぜあるか基盤と業務アプリケーションを、共通の版で管理・提供するためです。

ナレッジ記事を作成・承認・公開・検索するためのアプリケーションです。サービスケースやそのステップに関連する記事を紐づけて表示できます。

なぜあるかオペレーターが応対中に、必要な手順や回答をすぐに参照できるようにするためです。

ケースマネジメント、業務ルール、画面、連携、意思決定をローコードで構築・実行する Pega の基盤製品です。

なぜあるか業務プロセスとその判断ロジックを、一つの基盤でまとめて構築・変更できるようにするためです。

詳しい解説記事

複数の Pega アプリケーションや他のシステムに分散した作業を、横断的に接続・統合するための仕組みです。中心となる Pega Process Fabric Hub は、各アプリケーションのアサインメントを一か所に集約して表示します。

なぜあるか利用者が複数のアプリケーションを行き来せずに、自分の作業をまとめて処理できるようにするためです。

Pega Customer Service で、電話やチャットなど顧客との1回の接点を表すケースです。

なぜあるか「誰が・いつ・どのチャネルで接触したか」を、実際の手続きとは分けて記録するためです。

詳しい解説記事

一定の間隔でバックグラウンド処理を実行する従来の仕組みです。現在は、キュープロセッサとジョブスケジューラーへの置き換えが推奨されています。

なぜあるか定期処理や非同期処理を、利用者の操作と切り離して実行するためでした。

注意生成 AI の文脈でいう「エージェント」とは別のものです。

処理の依頼をキューに積み、バックグラウンド処理用のノードで非同期に実行する仕組みです。内部ではストリームサービス（Kafka）を使います。

なぜあるか外部連携や重い処理を利用者の操作から切り離し、失敗時の再試行も管理するためです。

注意非同期にすると利用者の画面では結果をすぐに確認できないため、処理状況の見せ方も併せて設計する必要があります。

詳しい解説記事

インタラクションの中で起票される住所変更や問い合わせ対応などの手続きです。インタラクションが終わった後も、独立して処理を続けられます。

なぜあるか応対中に終わらない手続きも、確実に完了まで追跡するためです。

詳しい解説記事

決められた日時や間隔で、定期的な処理（アクティビティ）を実行する仕組みです。

なぜあるか夜間の一括処理などの定期処理を、ノード構成を踏まえて実行するためです。

Pega Platform が動作するサーバー（JVM）の単位です。Web 処理用、バックグラウンド処理用、ストリーム処理用など、役割（ノードタイプ）を分けて構成できます。

なぜあるか利用者の操作と重い裏側の処理を分け、それぞれ独立して拡張できるようにするためです。

Pega に処理を依頼する主体（ブラウザの利用者、サービスの呼び出し、バックグラウンド処理など）ごとに作られる実行コンテキストです。スレッドはその中の個別の処理単位です。

なぜあるか利用者や処理ごとに、データと状態を分けて保持するためです。

Pega のケースやデータを、BLOB を展開した形で XML・CSV・データベースへ一括抽出する仕組みです。

なぜあるかデータウェアハウスなど外部の分析基盤へ、Pega のデータを定期的に渡すためです。

詳しい解説記事

Pega がインスタンスのプロパティをまとめて圧縮し、1つの列（pzPVStream）に格納する方式です。

なぜあるかクラス構造を変更するたびにテーブル定義を変えずに済むようにするためです。

注意BLOB 内の値で絞り込むレポートは性能が出にくいため、検索条件に使う項目は公開列にします。

詳しい解説記事

プロパティの値を、他のプロパティからの計算式として宣言的に定義するルールです。入力値が変わると自動的に再計算されます。

なぜあるか合計や判定結果などの計算値を、計算のタイミングを意識せずに常に整合した状態に保つためです。

注意多段の依存関係を持つ宣言式を大量に置くと、1回の入力変更で多くの再計算が走ります。

詳しい解説記事

ページリストなどの繰り返しデータを、検索やレポートで扱えるよう別テーブル（Index- クラスのインスタンス）に書き出すルールです。

なぜあるかBLOB の中にある繰り返しデータは、SQL で直接条件に使えないためです。

詳しい解説記事

特定クラスのインスタンスがデータベースに保存・削除されたときに、指定したアクティビティを実行するルールです。

なぜあるか保存や削除をきっかけにした処理を、各処理箇所に書かずに一か所で定義するためです。

注意処理が暗黙的に走るため、多用すると処理の流れを追いにくくなります。

解決済みのケースを一定期間後に二次ストレージへ移す（アーカイブ）、または削除する（パージ）仕組みです。

なぜあるか運用中のテーブルの肥大化を防ぎ、性能と保管コストを保つためです。

注意保存期間や法定保管義務を業務側と合意しないまま設定すると、必要なデータを失うおそれがあります。

詳しい解説記事

Constellation のアプリケーションで、データの照会結果を表やグラフとして保存・共有するルールです。データ探索（Explore Data）画面から作成し、ダッシュボードやケースのビューに配置できます。

なぜあるか業務担当者が、開発者に依頼せずにデータを分析・共有できるようにするためです。

詳しい解説記事

リスト型のデータページに検索キーを定義し、一度読み込んだ一覧から特定の1件をキーで取り出せるようにしたものです。

なぜあるか1件ごとに再取得せず、読み込み済みの一覧を使い回すためです。

リクエスターごとに実行時データ（ページ）を保持するメモリ領域です。その内容を確認する開発ツールの名称でもあります。

なぜあるか処理中のデータの状態を保持し、開発時にはその中身を確認できるようにするためです。

ルールではなくデータとして保存されるレコードです。オペレーター、アクセスグループ、データタイプのレコードなどが該当します。

なぜあるか環境ごとに値が変わりうる情報を、ルールのバージョン管理とは別に扱うためです。

注意ルールセットに属さないため、環境間の移送では製品ルールで明示的に含める必要があります。

Data- を継承するクラスで、顧客・商品などの業務データの構造を定義します。

なぜあるかケースの外で独立して管理・再利用されるデータを表すためです。

注意保存先テーブルのキー設計を後から変えるのは難しいため、業務キーか代替キーかを最初に決めておく必要があります。

詳しい解説記事

データページの読み込み方法で、コネクター、レポート定義、ルックアップ（キー指定で1件取得）、データトランスフォーム、アクティビティなどから選びます。取得結果はデータトランスフォームでマッピングします。

なぜあるかデータの取得先が変わっても、データページを参照する側を変更せずに済むようにするためです。

App Studio から見たデータの管理単位で、データモデル、データの保存先（Pega 内か外部システムか）、データページをまとめて扱います。

なぜあるかデータの構造と取得方法を、業務担当者にも分かる単位で管理するためです。

詳しい解説記事

プロパティへの値の設定、ページ間のコピー、JSON との変換などを、表形式の手順で定義するルールです。

なぜあるかアクティビティを書かずに、データの初期化とマッピングを行えるようにするためです。

注意常に最新の計算結果を保ちたい値をデータトランスフォームで設定すると、入力値が変わった後に古い値が残ります。

詳しい解説記事

外部システムやデータベースのデータを必要時に読み込み、スコープに応じてメモリ上にキャッシュするルールです。プロパティから参照された時点で自動的に読み込まれます。

なぜあるかデータの取得方法と利用箇所を分離し、同じデータの重複取得を減らすためです。

詳しい解説記事

データページを共有する範囲で、スレッド（個々の処理単位）、リクエスター（利用者のセッション）、ノード（サーバー全体）の3種類があります。

なぜあるかデータの共有範囲とキャッシュの寿命を、データの性質に合わせて選べるようにするためです。

注意利用者ごとに異なるデータや権限に依存するデータをノードスコープにすると、他の利用者と共有されてしまいます。

詳しい解説記事

データページの扱い方を決める設定で、読み取り専用・編集可能・保存可能（Savable）の3種類があります。保存可能データページでは、データの書き戻し方法も定義します。

なぜあるか参照専用のデータと、更新して保存するデータを区別して扱うためです。

ケースタイプやデータタイプが持つフィールドとその型の定義です。Constellation では、ビューに配置できる項目の範囲もデータモデルで決まります。

なぜあるか画面より先にデータ構造を固め、画面・処理・連携の土台をそろえるためです。

ケースにはキーだけを保持し、表示や処理のたびにデータページから最新の値を参照する方式です。

なぜあるかマスタの変更を、各ケースにコピーし直さずに反映するためです。

詳しい解説記事

パラメーターを受け取って読み込むデータページで、パラメーター値の組み合わせごとに別のインスタンスとして保持されます。

なぜあるか検索条件などに応じたデータを、同じ定義で取得できるようにするためです。

注意パラメーター値の種類が多いとインスタンスが増え、メモリ消費が大きくなります。

フィールドの選択肢を定義する方式で、固定の値を並べる方法と、データページから取得する方法があります。

なぜあるか入力値を決められた選択肢に限定し、表記ゆれを防ぐためです。

注意選択肢が業務で頻繁に増減する場合は、固定値よりデータとして管理する方が保守しやすくなります。

詳しい解説記事

クラスに属するデータ項目の定義です。単一値・ページ・ページリスト・ページグループなどのモードを持ちます。App Studio ではフィールドと呼ばれます。

なぜあるかデータ項目の型や扱いを一か所で定義し、画面・処理・レポートで共有するためです。

実行時にメモリ上に保持される、構造を持ったデータのまとまりです。ケースやデータレコードは、処理中はページとして扱われます。

なぜあるか階層構造を持つ業務データを、処理中にまとめて読み書きできるようにするためです。

データページをいつ再読み込みするかの設定です。一定時間の経過で再読み込みする、条件が成り立つ間は再読み込みしない、インタラクションごとに再読み込みする、などを指定します。

なぜあるかデータの鮮度と取得コストの釣り合いを、データごとに調整するためです。

注意「インタラクションごとに再読み込み」はスレッドとリクエスタースコープでのみ使え、他の再読み込み条件とは併用できません。

クラスを対象に、列・条件・並び順・集計を定義して SQL を生成するルールです。一覧表示やデータページの取得元としても使われます。

なぜあるかデータ取得の条件を SQL を直接書かずに定義し、再利用できるようにするためです。

注意結合やサブレポートを重ねると、生成される SQL が重くなりやすい点に注意が必要です。

詳しい解説記事

BLOB 内のプロパティを、テーブルの独立した列として持たせたものです。「レポート用に最適化」の操作などで作成します。

なぜあるかレポートや検索で、その項目を SQL の条件や並べ替えに直接使えるようにするためです。

注意列を増やしすぎると、保存処理やテーブル保守の負担が増えます。

詳しい解説記事

入力となるプロパティが変わった時点で、それに依存する値を自動的に再計算する方式です。宣言式の既定の動作です。

なぜあるか参照する時点では常に最新の計算結果がそろっているようにするためです。

注意依存関係が広がると、入力のたびに多くの計算が発生して性能に影響します。

詳しい解説記事

ケースの中にデータのコピーを保持する方式です。保存した時点の値がケースに残ります。

なぜあるか申込時点の住所や価格など、後から変わってはいけない値をケースに固定するためです。

詳しい解説記事

値が参照された時点で、必要に応じて計算を行う方式です。宣言式で「使用時に計算する」系の設定を選ぶと、この動作になります。

なぜあるか参照されない値の計算を省き、処理量を抑えるためです。

詳しい解説記事

Pega の現行の UI アーキテクチャとデザインシステムです。React ベースのフロントエンドが DX API を通じてサーバーと通信し、ビューの設定から画面を生成します。

なぜあるか画面を個別に作り込まず標準部品の設定で構築し、バージョンアップ時の改修を減らすためです。

注意Traditional UI のセクションはそのまま移行できず、多くの場合はビューとして作り直しになります。

詳しい解説記事

Constellation の標準部品では足りない場合に、React で作成して追加するカスタムの UI 部品です。

なぜあるか標準部品で表現できない要件にだけ、限定的に独自の UI を加えるためです。

注意作る数が増えるほど、プラットフォーム更新のたびに検証・保守する対象が増えます。

詳しい解説記事

Traditional UI（セクションベース）のアプリケーション向けの標準 UI ライブラリで、テンプレートと既製の部品を中心に画面を構成します。

なぜあるか標準に沿った一貫性のある画面を、少ない作り込みで実現するためです。

詳しい解説記事

セクション・ハーネス・フローアクションなどのルールで画面を組み立てる、Constellation より前の UI アーキテクチャです。

なぜあるか画面の細部まで設定で作り込めるようにするためです。

注意作り込みの自由度が高い分、独自の画面が増えるほど、バージョンアップ時の確認や改修の負担が大きくなります。

詳しい解説記事

Traditional UI 向けに、テンプレート・スキン・アイコンなどの標準 UI 部品をまとめたルールセットです。

なぜあるか標準の画面部品を共通の土台として提供し、アプリケーションごとの作り込みを減らすためです。

注意ロックされたルールセットとして提供されるため、変更する場合は自分のルールセットにコピーして行います。

Constellation の画面（ケースの処理画面やランディングページ）を、Web コンポーネントとして既存の Web サイトに埋め込む仕組みです。

なぜあるか既存の Web サイトを作り替えずに、Pega の業務処理を組み込めるようにするためです。

注意埋め込み先の見た目に合わせられる範囲は、用意されたテーマ設定の範囲に限られます。

Traditional UI で画面の部品を定義するルールで、レイアウト・項目・コントロールを配置します。

なぜあるか画面の部品を、複数の画面で再利用できる単位にするためです。

ビューの配置パターン（1列、2列、詳細表示など）を定めた標準の型です。項目を選んで当てはめるとレイアウトが決まります。

なぜあるか画面ごとに配置やスタイルを作り込まず、一貫した操作性を保つためです。

詳しい解説記事

Traditional UI で画面全体の枠組みを定義するルールで、セクションを組み合わせてケースの表示画面やポータルを構成します。

なぜあるか画面全体の構成と、個々の部品を分けて管理するためです。

Constellation で画面の内容を定義する単位です。フォーム、詳細、一覧などの種類があり、ケースのステップごとに既定のフォームビューが作成されます。

なぜあるか画面を、データモデルの項目を並べる設定として定義できるようにするためです。

詳しい解説記事

アサインメントで利用者が選べる操作（承認・差戻しなど）を定義するルールで、表示する画面、前後の処理、入力検証を紐づけます。

なぜあるか画面と、その画面から進む先の処理をひとまとまりで扱うためです。

利用者の役割ごとに用意される作業画面全体で、ナビゲーション、ダッシュボード、ワークリストなどで構成されます。利用できるポータルはアクセスグループで指定します。

なぜあるか役割に応じて、必要な機能だけを見せる入口を用意するためです。

あるロールが特定のクラスのインスタンスに対して、開く・変更する・削除する・レポートを実行するなどの操作を許可するかを定義するルールです。許可の条件は数値のレベルや Access When で指定します。

なぜあるかクラス単位のアクセス権を、ロールごとに細かく定義するためです。

詳しい解説記事

「自分が担当するケースのみ」のような条件を定義し、ARO などでアクセスの可否を判定するために使うルールです。

なぜあるかインスタンスの内容に応じた条件付きの権限を表現するためです。

オペレーターが利用できるアプリケーション、ロール、ポータル、ワークプールなどをまとめて指定する設定です。

なぜあるか利用者の役割に応じた環境を、まとめて割り当てるためです。

注意利用者の細かな違いごとにアクセスグループを作ると、数が増えて管理が難しくなります。

詳しい解説記事

権限のまとまりを表す名前で、クラスごとの権限設定（ARO）を束ねます。1つのアクセスグループに複数のロールを割り当てられます。

なぜあるか職務に応じた権限を部品として組み合わせられるようにするためです。

詳しい解説記事

ABAC で、どのクラスに対してどの操作（Read、Update、Delete、Discover、PropertyRead など）を制限するかを定義するルールです。条件はアクセス制御ポリシー条件ルールで指定します。

なぜあるか属性に基づく制限を、ルールとして宣言的に管理するためです。

注意複数のポリシーが該当する場合は、すべての条件を満たしたときだけアクセスが許可されます。

詳しい解説記事

特定のロールに対して、クラス単位の操作を明示的に禁止するルールです。

なぜあるか他のロールで許可されていても、確実に禁止したい操作を定義するためです。

注意拒否は許可より優先されるため、複数のロールを持つ利用者で意図せず操作できなくなることがあります。

Pega にログインする利用者のアカウントを表すデータインスタンスで、所属するアクセスグループ、組織、ワークグループなどを持ちます。

なぜあるか利用者ごとの権限や所属を、一か所で管理するためです。

顧客など本人が自分の個人データの閲覧・訂正・削除を求める権利に対応するため、個人データの所在をクラスごとに定義して管理する仕組みです。

なぜあるかGDPR などのデータ保護規制への対応を支援するためです。

本番稼働の前に確認すべきセキュリティ設定の項目を Pega が一覧化したもので、Dev Studio から対応状況を管理できます。

なぜあるか設定漏れによる脆弱性を、稼働前に体系的に確認するためです。

詳しい解説記事

指定したプロパティについて、変更前後の値を記録する機能です。

なぜあるか重要な項目が、いつ・誰によって・どう変更されたかを追えるようにするためです。

注意対象を広げすぎると、記録量が増えて保存領域と性能に影響します。

詳しい解説記事

利用者やデータの属性（部署、地域、機密区分など）に基づいて、行単位・項目単位でアクセスを制御する仕組みです。ロールベースのアクセス制御と併用されます。

なぜあるかロールだけでは表現しにくい、データの内容に応じた制限を行うためです。

詳しい解説記事

フローアクションやレポートなど、特定のルールの実行に必要な権限を名前付きで定義するものです。ARO を通じてロールに付与します。

なぜあるかクラス単位よりも細かい操作単位で、実行できる人を制限するためです。

SAML 2.0、OpenID Connect、Basic などのログイン方式と、ログイン後のオペレーターの割り当て方法を定義する設定です。

なぜあるか社内の ID 基盤と連携したシングルサインオンなど、組織に合った認証を構成するためです。

詳しい解説記事

顧客ごとに次に取るべき最適な行動（Next-Best-Action）を、全チャネル共通の判断基盤でリアルタイムに決める Pega の製品です。

なぜあるかチャネルごとに分かれていた施策の判断を一か所に集め、顧客にとっての関連性と事業上の価値を両立させるためです。

ビジネス構造、エンゲージメントポリシー、アービトレーション、チャネルなどを画面上で設定し、意思決定のストラテジーを生成するツールです。

なぜあるか意思決定の設計を、ストラテジーを一から組まずに標準の型に沿って行えるようにするためです。

予測、適応モデル、予測モデル、テキスト分析などを作成・監視するためのワークスペースです。

なぜあるかデータサイエンティストがモデルの作成と運用を一か所で行えるようにするためです。

顧客に提示する候補（商品の提案、サービスの案内、注意喚起など）の単位です。

なぜあるか提示しうる対応を、共通の形式で管理し比較できるようにするためです。

候補となったアクションを、傾向（Propensity）、コンテキストの重み（Context weighting）、ビジネス価値（Value）、ビジネスレバー（Levers）を掛け合わせた優先度で順位付けする処理です。

なぜあるか顧客にとっての関連性と、事業上の優先度を一つの基準で比較するためです。

注意ビジネスレバーを大きくしすぎると、顧客の反応の見込みが順位にほとんど反映されなくなります。

どの顧客にどのアクションを提示し、どう反応したかを記録するデータです。適応モデルの学習やコンタクトポリシーの判定に使われます。

なぜあるか提示と反応の記録を、学習と抑止の両方に生かすためです。

アクションを提示してよいかを、適格性（Eligibility）、適用性（Applicability）、適合性（Suitability）の3種類の条件で判定する設定です。

なぜあるか法令・社内規定・顧客の状況に合わない提案を、順位付けの前に除外するためです。

一定期間内に同じアクションを何回まで提示するか、反応がない場合にいつ提示を控えるかなどを定める設定です。

なぜあるか同じ提案の繰り返しで、顧客体験を損なわないようにするためです。

データの取り込み、絞り込み、予測、優先順位付けなどの部品を組み合わせ、意思決定の流れを図として定義するルールです。

なぜあるか複雑な意思決定の手順を、目で追える形で設計・保守するためです。

アクションをチャネルごとにどう見せるか（メールの文面、Web のバナーなど）を定義したものです。

なぜあるか同じアクションを、チャネルに合った表現で届けるためです。

顧客との接点ごとに、提案・サービス・引き留めなどの候補から最適な行動を選んで提示する考え方と、その仕組みです。

なぜあるか一律のキャンペーンではなく、その時点の顧客の状況に合った対応を選ぶためです。

アクションを、イシュー（営業、引き留めなど）とグループ（商品カテゴリなど）の階層で整理する分類です。

なぜあるか多数のアクションを、事業上の目的ごとに管理するためです。

過去のデータから事前に作成した機械学習モデルを取り込み、スコアを算出するルールです。Pega 上で作成したモデルのほか、PMML 形式などの外部モデルも利用できます。

なぜあるか解約予測やリスク評価など、事前に検証した予測を意思決定に組み込むためです。

顧客がそのアクションに反応する確率の予測値です。主に適応モデルによって算出されます。

なぜあるか顧客が受け入れそうな提案を、データに基づいて見積もるためです。

顧客の反応（受諾・拒否など）を受け取るたびに自動で学習し、傾向スコアを更新する機械学習モデルです。Adaptive Decision Manager（ADM）が管理します。

なぜあるか人手で再学習しなくても、顧客の反応の変化に追従できるようにするためです。

注意学習データが少ない初期の段階では、予測の精度が十分でないことがあります。

Pega GenAI Blueprint で作成した設計を起点に、Blueprinting、Authoring、Value Activation の3つのフェーズで開発を進める Pega の導入方法論で、Pega Express の後継に位置付けられています。

なぜあるか業務の意図が会話から文書、実装へと渡る過程で失われる「翻訳ロス」を減らすためです。

Pega のシステムアーキテクト向け認定資格のうち、開発の基礎を対象とする最初の段階の資格です。

なぜあるかPega の基本的な開発スキルを、共通の基準で示せるようにするためです。

詳しい解説記事

CSA の上位にあたるシステムアーキテクト向け認定資格で、より高度な設計と実装を対象とします。

なぜあるか実務で設計を担える水準のスキルを示せるようにするためです。

詳しい解説記事

組織内で Pega の活用に関する標準、ガバナンス、再利用資産、人材育成を担う専門チームです。

なぜあるか部署ごとにばらばらな作り方が広がるのを防ぎ、知見を組織に蓄積するためです。

詳しい解説記事

業務部門と IT 部門が最初から同じ場で、Pega の画面を見ながら要件を捉え、設計・構築・検証を短いサイクルで繰り返す進め方です。

なぜあるか要件の伝達漏れや認識のずれを、早い段階で見つけるためです。

システムアーキテクト向け認定資格の最上位で、アプリケーション全体のアーキテクチャ設計を担う力を対象とします。

なぜあるか大規模な Pega 導入で設計の責任を担える水準を示せるようにするためです。

詳しい解説記事

利用者が価値を実感でき、継続して使いたいと思える最小限の製品範囲です。Pega の方法論では、最初のリリースの範囲を MLP として定義します。

なぜあるか動くだけの最小限ではなく、実際に業務で使われる範囲から始めるためです。

注意「最小」を機能を削ることだけで捉えると、業務で使えない中途半端なリリースになりがちです。

詳しい解説記事

Pega の公式オンライン学習サイトで、役割別のコースや認定試験の準備のための教材を提供しています。

なぜあるかPega の製品知識と設計の考え方を、体系的に学べるようにするためです。

詳しい解説記事

デザイン思考とスクラムを組み合わせ、MLP を短期間で届けることを目指した Pega の導入方法論です。Discover、Prepare、Build、Adopt の4つのフェーズで構成されます。

なぜあるか業務部門と IT 部門が協力し、価値の出る範囲から早くリリースするためです。

注意Pega は後継として Blueprint Delivered への移行を案内しています。

共通の部分を中央の層で定義し、地域・商品・顧客セグメントなどの違いだけを上の層で特化させる、Pega アプリケーションの階層構造の考え方です。

なぜあるか共通部分の重複と、組織ごとのサイロ化を避けるためです。

チャネル（画面や窓口）ごとに業務ロジックを作るのではなく、業務ルールとプロセスを中央に置き、あらゆるチャネルから共通に使う設計の考え方です。

なぜあるかチャネルごとのロジックの重複と不整合をなくすためです。

アプリケーションを利用する人物像（顧客、担当者、管理者など）です。Pega では、ペルソナごとに使うチャネル、権限、ポータルを設計します。

なぜあるか誰がどの画面で何をするかを、設計の最初に明確にするためです。

顧客ジャーニーを、特定の目的を達成する小さな単位（例: 住所変更の依頼から完了まで）に分けたものです。

なぜあるか大きな業務を一度に作らず、価値の出る単位から順にリリースするためです。