Pega PoC の設計方法｜「動いた」で終わらせない検証項目と成功基準

結論から：PoC は「何を検証するか」を 3 つに分解してから設計する

Pega の PoC（Proof of Concept）で最も多い結末は、「デモは動いた。感触も良かった。でも導入判断にも次工程にも繋がらなかった」というものです。原因は作り方ではなく、始める前の設計にあります。何を検証する PoC なのかを決めずに作り始めているのです。

結論を先に言います。

PoC の目的を「技術検証（作れるか）」「業務適合検証（業務に合うか）」「体制検証（回せるか）」の 3 つに分解し、今回の PoC でどれをやるのかを先に決める。成功基準は定量で事前に合意し、作ったケース型・データモデルは MLP（最初の本番リリース）へ引き継ぐ前提で作る。

この 3 分解と 2 つのルール（定量基準の事前合意・資産の引き継ぎ設計）だけで、PoC の質は大きく変わります。本記事では、それぞれを実務の判断に落とし込みます。

なぜ「デモが動いた」で終わるのか

Pega はローコードプラットフォームなので、数週間あればそれらしいデモは作れてしまいます。ここが落とし穴です。「動くこと」自体は、Pega の PoC では何も証明しません。 動くのは前提であり、確かめるべきはその先——自社の業務・システム・体制に対して Pega が成立するか——です。

ところが目的を決めずに始めた PoC には評価軸がありません。評価軸がなければ、デモを見た後に残るのは「感触が良い/悪い」だけです。感触では投資判断（Go/No-Go）は下せず、PoC はもう一周、もう一周と延びていきます。

目的を 3 つに分解する

実案件で PoC を設計するとき、目的は次の 3 つに分解できます。

技術検証：「作れるか」

自社固有の技術リスクが潰せるかを確かめます。典型的には次の 2 点です。

• 基幹システムとの連携を 1 本、実データ相当で通す — 認証方式・データ量・レスポンス形式など、机上では見えない障害はここで出ます
• 非機能の「当たり」を取る — 想定の同時接続数で応答時間がどの水準に収まるか、精密な性能試験ではなく桁感の確認をする

業務適合検証：「業務に合うか」

代表ケースを 1 つ選び、そのライフサイクルを開始から完了まで再現します。ポイントは正常系だけで終わらせないこと。差し戻し・例外・取り下げといった、現場の実務者が最初に「この場合はどうなるの？」と聞いてくる分岐を含めて、実務者自身に触ってもらいます。

体制検証：「回せるか」

導入後に誰が作り、誰が保守するのか。自社（または SIer）メンバーの習得速度を PoC の中で実測します。PoC を「教材」として使い、期間終了時にメンバーがケース型を自力で修正できるか、MLP 以降の開発を担える見込みがあるかを見極めます。内製化を目指す企業ほど、この検証を飛ばしてはいけません。

3 つを 1 回の PoC で全部やろうとするのは典型的な設計ミスです。導入判断そのものが目的なら業務適合検証を軸に、特定の技術リスク（連携・性能）が懸念なら技術検証を軸に、内製化が経営目標なら体制検証を軸に——どれを主目的にするかを計画書の 1 行目に書くのが実務の型です。

3 つの検証の比較表

観点	技術検証	業務適合検証	体制検証
確かめる問い	作れるか	業務に合うか	自分たちで回せるか
代表的な検証項目	基幹との連携 1 本／応答・同時接続の当たり	代表ケースのライフサイクル再現（例外・差し戻し含む）	自社メンバーの習得速度／MLP 以降の開発体制
成功基準の例	実データ相当で連携が往復し応答 N 秒以内	対象業務の処理時間 X% 短縮の見込みが立つ	終了時に自社メンバーがケース型を自力で修正できる
よくある失敗	スタブだけで「繋がった」と言う	きれいな正常系デモだけ見せる	ベンダー任せで誰も学ばない

検証項目は「代表 1 点」に絞る

検証項目を網羅的に並べるのも失敗パターンです。連携が 10 本あっても PoC で通すのは 最もリスクが高そうな 1 本。ケース型が 5 つ想定されても、再現するのは業務量・複雑さの点で代表的な 1 つです。

例えば「申請 → 審査 → 承認 → 通知」型の社内審査業務を対象にするなら、

1. 代表ケース（例：最も件数の多い申請種別）のライフサイクルを最初から最後まで再現する
2. 審査時に参照する基幹データの照会連携を 1 本だけ本物に繋ぐ
3. 想定オペレーター数での画面応答の当たりを取る
4. 自社メンバー 1〜2 名を開発に入れて習得速度を測る

——この 4 点で、技術・業務適合・体制のリスクは一通り顔を出します。PoC は網羅ではなくサンプリングです。「代表 1 点で成立したものは横展開できる」という論理が立つ選び方をすることが、項目設計のすべてです。

成功基準は定量で「先に」合意する

「感触が良い」は成功基準になりません。 PoC 開始前に、発注側・実施側で定量の基準を合意します。

• 対象業務の処理時間を X% 短縮できる見込みが立つ（現行の処理時間を事前に測っておく）
• 基幹連携が実データ相当で往復し、応答 N 秒以内に収まる
• 自社メンバーが期間内にケース型の修正を自力で完了できる

重要なのは「先に」の部分です。基準を後から決めると、出来上がったものに合わせて基準の方が動きます。事前に固定してあるからこそ、PoC 終了時に Go/No-Go の判断が機械的に下せます。基準に届かなかった場合も「何がどれだけ足りないか」が数字で残るため、次の打ち手（スコープ変更・アーキテクチャ見直し・見送り）に直結します。基準（Exit Criteria）自体の設計をさらに掘り下げたい方は、Pega の PoC 成功基準の設計 も参照してください。

Pega Blueprint で立ち上げを高速化する

PoC の初速には Pega Blueprint（旧称：Pega GenAI Blueprint）が有効です。生成 AI と Pega のベストプラクティスを組み合わせた設計用のワークスペースで、業務の説明を与える（または業種別テンプレートを選ぶ・既存の要件文書をアップロードする）と、ケース型・ケースライフサイクルの草案・データオブジェクト・ペルソナといったアプリケーション設計の叩き台を自動生成してくれます。従来は数週間のワークショップを要していた「最初の骨格づくり」を大幅に短縮できます。なお名称や機能は更新が続いているため（本記事執筆の 2026 年時点の公式名称は Pega Blueprint）、最新の仕様は公式ドキュメントで確認してください。

ただし Blueprint の出力は出発点であって成果物ではありません。実務での使いどころはむしろ、生成された草案と自社業務の差分を実務者と一緒に洗い出すことです。「この草案のこのステップはうちには無い」「この分岐が抜けている」という指摘が集まるプロセスそのものが、業務適合検証の中身になります。草案をそのまま実装して「動きました」と見せるのは、検証を省略しているだけです。AI 生成設計をどこまで信頼し、どこから上書きするかの判断は Pega GenAI Blueprint の使いどころ で詳しく解説しています。

捨てる PoC にしない：MLP への引き継ぎを設計する

Pega の公式デリバリー方法論である Pega Express では、アプリケーションのリリースを MLP（Minimum Lovable Product）という単位に束ね、最初の本番リリースを小さく切り出します。MLP は優先度付けした 1 つ以上の Microjourney で構成され、60〜90 日以内で技術的に成立するリリースを目指すのが公式の目安です。ここで PoC を作り捨てにすると、同じものを二度作ることになり、PoC の工数が純粋なコストに変わります。

引き継ぐもの・捨てるものを PoC 計画時に線引きしておきます。

• 引き継ぐ資産：ケース型（ステージ・ステップ構成）とデータモデル。 この 2 つはアプリケーションの骨格であり、PoC の段階から本番を見据えた粒度・命名で作っておけば、MLP でそのまま育てられます
• 捨てる前提で割り切るもの：デモ用の UI 作り込み・ダミーデータの投入処理・スタブ連携。 ここに時間をかけない判断が、PoC のスピードを生みます

「PoC の成果物のうち、どれが MLP の初期資産になるか」を報告書に明記する——これだけで、PoC は使い捨てのデモから MLP のフェーズ 0 に変わります。MLP 自体のスコープをどう切るかは Pega の MLP スコープ設計 にまとめています。

よくある失敗

失敗 1：目的を決めずに「とりあえず作ってみる」

3 分解のどれをやるのか決めずに始めるパターン。評価軸がないため、どれだけ作り込んでも結論が出ず、期間だけが延びます。対策は単純で、主目的 1 つと定量基準を決めるまで着手しないことです。

失敗 2：きれいな正常系デモだけを見せる

意思決定層向けのデモを意識するあまり、例外・差し戻しのない一本道だけを作るパターン。業務適合は例外系でこそ判明するため、これでは適合検証をしたことになりません。現場の実務者に触らせ、「この場合は？」への回答をデモで返せる状態を目指します。

失敗 3：デモ専用の作り捨て実装

ハードコードとダミー画面で固めた「見せるためだけ」の実装。PoC 通過後、MLP でゼロから作り直しになり、しかも PoC で確かめたはずの実現性が本実装では再現しない（スタブだったから動いていただけ）というリスクまで抱えます。ケース型とデータモデルだけは本番粒度で作る、という規律で防げます。

まとめ

• PoC の目的は**技術検証（作れるか）・業務適合検証（業務に合うか）・体制検証（回せるか）**に分解し、どれをやるのかを先に決める
• 検証項目は網羅せず代表 1 点に絞る——代表ケースのライフサイクル再現・連携 1 本・非機能の当たり・習得速度
• 成功基準は定量で開始前に合意する。「感触が良い」は基準ではない
• Pega Blueprint（旧称 GenAI Blueprint）で骨格づくりを高速化し、草案と現実の差分を業務適合検証の材料にする
• ケース型・データモデルは MLP へ引き継ぐ資産として作り、捨てる PoC にしない

PoC は「Pega が動くことの証明」ではなく、「自社で Pega が成立することの検証」です。設計の質は、作り始める前の 1〜2 週間でほぼ決まります。

---

Pega の PoC 設計・導入判断でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。実案件での PoC 設計から MLP の立ち上げまで、実装経験に基づいてご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Constellation UI 導入支援サービス
• Pega の PoC 成功基準の設計｜Exit Criteria と『PoC 沼』の回避
• Pega GenAI Blueprint の使いどころ｜AI 生成設計をどこまで信頼し上書きするか
• Pega の MLP スコープ設計｜Minimum Lovable Product の切り方と失敗回避
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• 無料相談に申し込む