Pega の MLP スコープ設計｜Minimum Lovable Product の切り方と失敗回避
「最初のリリースに何を入れ、何を後回しにするか」——Pega の MLP はこの判断が肝。機能の網羅ではなく成果（アウトカム）で切り、単一マイクロジャーニーを端から端まで通すのが定石だ。スコープを膨らませてしまう典型パターンと回避策を解説する。
結論から：初回リリースは MVP ではなく MLP。1 つのマイクロジャーニーを端から端まで通す
Pega プロジェクトを立ち上げるとき、最初に決めなければならないのは「最初のリリースに何を入れ、何を後回しにするか」です。ここでスコープを盛り込みすぎると、リリースは遅れ、価値の検証も遅れ、プロジェクト全体が失速します。
Pega はこの初回リリースを MVP（Minimum Viable Product）ではなく MLP（Minimum Lovable Product） と位置づけます。結論を先に言うと、判断の型はシンプルです。
1 つのマイクロジャーニー（＝原則 1 つのケースタイプ）を選び、その「ハッピーパス」を端から端まで通す。ユーザーが価値を感じる最小単位だけを初回に入れ、例外・別チャネル・追加ジャーニーは後続リリースへ送る。
「動くかどうか」ではなく「ユーザーが価値を感じる（lovable）かどうか」で最小単位を切る——これが MLP の核心です。以下、この判断を具体的な分岐に落とし込みます。
MVP ではなく MLP —「動く最小」ではなく「愛される最小」
一般的なアジャイル文脈でよく使われる MVP（Minimum Viable Product）は、直訳すれば「成り立つ最小限」です。しかし「動きはするが、使っていて価値を感じられない」プロダクトは、たとえリリースできても現場に定着せず、フィードバックも前向きなものになりません。
Pega が初回リリースを MLP（Minimum Lovable Product） と呼ぶのは、この一語で狙いを変えるためです。目指すのは「最小限で動く」ことではなく「最小限でユーザーが価値を感じる（lovable）」ことです。つまり、スコープを削るときの判断基準が「動作に必要か」ではなく「利用者がその成果に価値を感じるために必要か」に変わります。
この違いは、スコープに何を残すかの意思決定を根本から変えます。「あってもなくても動く」機能は削る候補ですが、「無いとユーザーが価値を感じられない」核心部分は、たとえ実装が重くても MLP に残します。lovable を基準にすると、削るべきものと残すべきものの線引きが明確になります。
MLP は 1 つのマイクロジャーニーで切る
MLP をスコープする単位は、1 つ（少数）のマイクロジャーニーです。マイクロジャーニーとは、ユーザーが 1 つの目的を達成するまでの一連の流れ——Pega の定義では「ケースタイプを用いて成果（アウトカム）を実現する業務トランザクション」であり、多くの場合、1 つのケースタイプをエンドツーエンドで通す単位に対応します。
Pega Express の定義上、1 つの MLP は 1 つ以上のマイクロジャーニーで構成され得ます。ただし初回リリースでは価値提供までの速さ（Pega が目安とする 60〜90 日でのデリバリー）を最優先し、原則 1 つ（多くても少数）に絞り込むのが定石です。詰め込むほど価値検証は遅れます。
ここで最も重要な原則は、複数のマイクロジャーニーを初回に同時に詰め込まないことです。Pega アプリケーションは複数のケースタイプ・複数の業務プロセスを扱えますが、それらを一度にすべて MLP に入れると、スコープは指数的に膨張し、リリースは遠のきます。
正しいのは、最も価値が高く、かつ端から端まで通せる 1 つのジャーニーを選び、それだけを完成させることです。たとえば「融資申込」を MLP にするなら、申込 → 審査 → 承認 → 実行という一連の流れをハッピーパスで通し切ります。同じ業務領域に「期中変更」「解約」といった別ジャーニーがあっても、それらは初回には入れません。
「1 つのジャーニーを端から端まで」が「複数のジャーニーを中途半端に」より優れているのは、前者は実際にユーザーが業務を完遂でき、価値を検証できるからです。後者はどのジャーニーも完結せず、価値を測れないまま工数だけを消費します。
スコープは「機能一覧」ではなく「成果（アウトカム）」で定義する
スコープ設計でありがちな誤りが、MLP を「機能の一覧」で定義してしまうことです。「この画面」「あの帳票」「この連携」と機能を並べ始めると、際限なく積み上がり、どれも「あったほうがいい」ので削る根拠を失います。
MLP は達成すべきビジネス成果（アウトカム）で定義します。「融資担当者が申込を受け付けてから承認判断を下すまでを、システム上で完結できる」といった成果を先に定め、その成果に直結する要件だけをスコープに入れます。成果に紐づかない機能は、どれだけ魅力的でも初回には入れません。
成果で定義すると、スコープの議論が「この機能は要る／要らない」から「この機能はゴールの達成に必要か」に変わります。判断軸が主観（あると便利）から客観（成果に直結するか）へ移るため、削る意思決定が下しやすくなります。
MVP 発想と MLP 発想の違い
| 観点 | MVP 的な発想 | MLP 的な発想（Pega の定石） |
|---|---|---|
| 狙い | とにかく動く最小限 | ユーザーが価値を感じる最小限 |
| スコープの単位 | 機能の寄せ集め | 1 つのマイクロジャーニー（≒ 1 ケースタイプ） |
| 定義の仕方 | 機能一覧 | 達成すべき成果（アウトカム） |
| ジャーニーの扱い | 複数を薄く広く | 1 つを端から端まで |
| 例外・エッジケース | 初回から作り込みがち | 後続リリースへ |
| 削る基準 | 動作に不要なもの | 価値に不要なもの |
後続リリースへの段階的追加を前提に計画する
MLP は「作って終わり」ではなく、後続リリースで段階的に広げていく前提で計画します。初回は 1 つのジャーニーのハッピーパスに集中し、後続で次の要素を足していきます。
拡張の典型的な順序は次のとおりです。
- 初回（MLP） — 選んだ 1 ジャーニーのハッピーパスを端から端まで
- 後続 1 — そのジャーニーの主要な例外フロー・エッジケース
- 後続 2 — 別チャネル（モバイル、外部連携、セルフサービス等）への展開
- 後続 3 — 2 つ目、3 つ目のマイクロジャーニーの追加
この順序が重要なのは、ハッピーパスを先に固めることで、例外を後から素直に足せるからです。逆に、初回から例外まで作り込むと、まだ検証されていない土台の上に複雑な分岐を積むことになり、手戻りが大きくなります。「まず幸せな道を通し、そのあとで枝葉を足す」——この順序を守ることが、健全な増分開発の前提です。
DCO と一体でスコープを握る（Backlog への線引き）
MLP のスコープは、要件を集めてから削るのではなく、目標を直接捉えて検証していく DCO（Directly Capture Objectives）の営みと一体で握るのが要点です。DCO は Pega Express における協働の作法で、目標・マイクロジャーニー・ケースの構造を、ドキュメントを先に作り込むのではなく Pega Platform 上で直接捉えながら検証していきます。ワークショップで洗い出した要件を、その場で「MLP に入れる／Backlog へ送る」に仕分けていきます。
失敗を避ける鍵は、価値の低い要件を早期に Backlog へ送る線引きを、設計者（LSA / リードアーキテクト）が主導して握ることです。ステークホルダーは往々にして「あれもこれも初回に」と要望を膨らませます。そこで前掲のフロー（ハッピーパスに必要か／成果に直結するか／無いと価値を感じないか）を共通言語として使い、当てはまらない要件を Backlog に送る合意を、その場で形成します。
ここを曖昧にしたまま実装に進むと、スコープは静かに膨張し、気づいたときには初回リリースが手に負えない規模になっています。スコープの線引きは実装より前、DCO（目標と要件を捉える場）で決着させる——これが膨張を防ぐ最大のレバレッジです。
よくある失敗
MLP スコープ設計の失敗は、経験上ほぼ 3 つのパターンに集約されます。
失敗1：例外・エッジケースを初回に盛り込みすぎる
最も多い膨張パターンです。「この例外も想定される」「あのイレギュラーも起こりうる」と、まだ検証されていないハッピーパスの上に、例外分岐を初回から積み上げてしまう。結果、実装量は数倍になり、しかもその大半は稀にしか起きないケースの作り込みです。初回はハッピーパスに絞り、例外は後続へ——これが原則です。
失敗2：複数のマイクロジャーニーを同時に詰め込む
「せっかくだから関連ジャーニーもまとめて」と、2 つ、3 つのジャーニーを初回に並行で作ろうとするパターン。どのジャーニーも完結しないまま工数を消費し、リリースが遠のきます。MLP は 1 ジャーニー。他は端から端まで通せる最初の 1 本を出してから足します。
失敗3：機能一覧でスコープを定義し、削る根拠を失う
MLP を機能の羅列で定義した結果、どの機能も「あったほうがいい」ので削れなくなるパターン。成果（アウトカム）を先に定義していないため、優先順位の客観的な根拠がありません。成果で定義し、成果に直結しない要件は落とす。この順序を守るだけで、削る意思決定が格段に楽になります。
まとめ
- Pega の初回リリースは MVP ではなく MLP（Minimum Lovable Product）。基準は「動く」ではなく「ユーザーが価値を感じる」
- MLP は 1 つのマイクロジャーニー（≒ 1 ケースタイプ）を端から端まで通す単位でスコープする。複数ジャーニーの同時投入は禁物
- スコープは**機能一覧ではなく成果（アウトカム）**で定義する。成果に直結しない要件は初回に入れない
- ハッピーパス優先。例外・別チャネル・追加ジャーニーは後続リリースへ段階的に足す前提で計画する
- スコープの線引きは DCO（Directly Capture Objectives）と一体で握り、価値の低い要件は早期に Backlog へ送る
- 失敗は 3 方向——例外の盛り込みすぎ / 複数ジャーニーの同時投入 / 機能一覧での定義。いずれもフローに立ち返れば避けられる
初回スコープをどう切るかは、Pega プロジェクトの立ち上がりの速さと、その後の増分開発のしやすさを大きく左右します。「愛される最小単位」を最初に正しく切り出すことが、後工程での手戻りを防ぎます。
Pega のプロジェクト立ち上げやスコープ設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、初回スコープの切り出しからご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む