Pega 開発の発注形態｜準委任・請負・ラボ型の使い分けと契約の注意点

結論から：発注形態は「フェーズ」で切り替える

Pega 開発を外部に委託するとき、最初に決めるべきは「どのベンダーに頼むか」ではなく「どの契約形態で頼むか」です。ここを間違えると、ベンダーの実力に関係なくプロジェクトが硬直します。

結論を先に言うと、使い分けの目安はフェーズで決まります。

構想・PoC は準委任、MLP 構築はスコープを絞った請負または準委任、リリース後の継続改善はラボ型（チーム月額）。「全要件を最初に固定した一括請負」で全フェーズをまとめて発注しない。

理由はシンプルで、Pega の標準デリバリーアプローチである Pega Express が、MLP（Minimum Lovable Product）を最小構成で早期リリースし、フィードバックを受けて継続的に拡張するアジャイル型の進め方を前提としているからです。全要件を最初に固定する一括請負とは、進め方のレベルで構造的に相性が悪いのです。

なお、本記事は Pega 案件の実務経験に基づく契約形態の「一般的な考え方」の整理であり、法的助言ではありません。準委任・請負といった契約類型の法的な位置づけや個別の契約条件は、必ず法務・弁護士等の専門家に確認してください。

なぜ「全要件固定の一括請負」は Pega と相性が悪いのか

Pega の価値は、ローコードによって変更コストが低いことにあります。だからこそ Pega の公式方法論である Pega Express は、顧客ジャーニーを Microjourney という小さな単位に分割し、「最初に最小限（MLP）を作って現場に当て、そこで得た学びを反映しながら継続的に拡張する」ことを前提に組み立てられています。作りながら直すことが、コストではなく前提なのです。

一方、請負型の契約は一般に「あらかじめ合意した完成物を納める」ことを軸に組み立てられます。全要件を最初に固定する一括請負に Pega を流し込むと、次のことが起きます。

• 要件定義の長期化 — 変更しない前提なので、着手前にすべてを決めようとして要件定義が肥大化する。ローコードのスピードが着手前に殺される
• 学びが「仕様変更」として摩擦になる — MLP 後に得られるはずの現場フィードバックが、契約上は変更契約・追加費用の交渉事項になり、反映されずに凍結される
• 「仕様書どおり」への最適化 — ベンダーの合理的行動が「価値を出す」ではなく「合意文書どおり納める」になり、現行業務の As-Is 再現に寄っていく

誤解のないように補足すると、請負契約そのものが悪いわけではありません。問題は「全要件固定 × 長期一括」の組み合わせです。範囲を十分に絞れば、請負は予算の予見性という強みを発揮します。

フェーズ別の使い分け

構想・PoC フェーズ：準委任

この段階の成果物は「動くシステム」ではなく判断材料です。実現可能性、標準機能とのフィット＆ギャップ、概算工数——つまり「まだ何を作るか決まっていない」段階なので、完成物を事前定義する請負とは構造的に噛み合いません。

準委任で期間と体制を決め、PoC の成功基準（Exit Criteria）を開始前に定義して探索を回すのが定石です。成功基準がないと PoC が延々と続く「PoC 沼」に入るため、この設計は契約形態と同じくらい重要です（詳細は PoC 成功基準の設計 を参照）。

MLP 構築フェーズ：スコープを絞った請負、または準委任

ここは分岐があります。判断の軸は「スコープを最小限に絞り切れるか」です。

• 絞り切れるなら、請負も機能する — MLP の範囲を明確に固定し、途中で気づいた改善は我慢して次フェーズ（継続改善）に回す、という規律を発注側が守れるなら、費用固定の請負は稟議も通しやすく合理的です
• 作りながら優先順位を見直したいなら、準委任 — その代わり、進捗・品質のハンドリング責任は発注側に寄ります。後述するプロダクトオーナーとレビュー体制が機能していることが条件です

どちらを選ぶにせよ、前提は「MLP を最小に切る」ことです。スコープの切り方自体が設計論点になります（MLP スコープ設計 参照）。

継続改善フェーズ：ラボ型（チーム月額）

リリース後は、大小の改善要望がバックログとして継続的に発生します。これを案件ごとに「見積 → 契約 → 開発 → 検収」で回すと、1 件あたりのリードタイムと事務コストが改善スピードを殺します。

そこで有効なのがラボ型——一定規模のチームを月額で確保し、何を作るかはバックログの優先順位で発注側が決める形態です。Pega の「継続拡張が前提」という性質に最も素直に合う契約で、体制の学習効果（アプリケーションへの習熟）も保てます。ベロシティと品質指標を継続的に測り、「チームが機能しているか」を確認しながら運用するのが健全な形です。

判断早見表

観点	準委任	請負	ラボ型（チーム月額）
向くフェーズ	構想・PoC、要件が流動的な構築	スコープを固定できる MLP 構築	リリース後の継続改善
スコープ	流動的（都度見直せる）	契約時に固定	バックログで随時入れ替え
費用の性質	稼働ベース	固定（変更は追加費用）	月額固定
仕様変更への強さ	強い	弱い（変更契約の摩擦）	強い
発注側に必要なもの	方向づけと受入判断	検収基準の明確化	PO による優先順位付けと成果測定

契約時に押さえる 4 つの注意点

形態を選んだあと、契約条件で押さえるべきポイントが 4 つあります。いずれも Pega 案件で実際に揉めやすい箇所です。

1. 成果物の定義 — 「ルールセット＋ドキュメント」を明文化する

Pega の納品物は一般的なソースコード一式ではなくルールセットです。「どのルールセット（バージョン）を納めるのか」「設計ドキュメント・テスト資産・運用手順書は含むのか」を契約で具体的に定義しておかないと、検収の段階で「何をもって納品完了か」が曖昧になります。

2. 知財とルールの帰属

開発したルールや共通部品の帰属、ベンダーが持ち込む既存資産（アクセラレータ・共通コンポーネント等）の扱い、それらの他案件への再利用可否は、着手前に合意しておくべき論点です。とくに長期の継続改善を見据えるなら、将来の内製化やベンダー交代の可能性まで含めて、帰属条件を専門家を交えて確認しておくことを推奨します。

3. 体制変更の柔軟性

アジャイルに進める以上、必要なスキルと人数はフェーズで変わります。増員・縮小・スキルの入れ替えの条件（予告期間、単価テーブル、最低継続期間）をあらかじめ決めておくと、体制がボトルネックになりません。ラボ型では特に重要です。

4. 検収・完了基準に品質指標を入れる

「画面が動けば合格」にしないことです。Pega にはガードレール Compliance Score というプラットフォーム標準の品質指標があり、「スコア○○以上を維持すること」を検収・完了条件に組み込むことで、品質の議論を主観ではなく数値で行えます。Pega の CI/CD ツールである Deployment Manager にも、指定スコア（既定値 95、変更可能）を下回るとパイプラインを止める Check guardrail compliance タスクが標準で用意されており、契約上の基準をそのまま機械的なゲートに落とし込めます。ただし Compliance Score が測るのは保守性（ベストプラクティス準拠度）であり、性能・セキュリティはテストカバレッジ等の別指標・別検証と組み合わせて基準化します（運用の詳細は ガードレール Compliance Score の品質ゲート化 参照）。

よくある失敗

失敗 1：全フェーズを一括請負で発注する

冒頭のとおり最も典型的な失敗です。要件定義に長期間を費やして仕様を凍結し、そのとおりに作った結果、現行業務の As-Is 再現になって効果が出ない——Pega の変更容易性という価値を契約構造が打ち消してしまうパターンです。

失敗 2：発注側がプロダクトオーナーを立てずに丸投げする

どの契約形態を選んでも、プロダクトオーナー（PO）は発注側に必須です。優先順位の決定、受入判断、業務部門との調整は、業務の当事者にしかできず、ベンダーに委譲できません。PO 不在のまま丸投げすると、出来上がるのは「業務にとって価値のあるもの」ではなく「ベンダーが作りやすいもの」になります。準委任・ラボ型は発注側の関与を前提とした形態なので、丸投げとの組み合わせはとりわけ危険です。

失敗 3：ラボ型が「常駐要員の月額払い」に形骸化する

ラボ型は柔軟な反面、請負のような検収の区切りがありません。バックログ管理も成果測定もないまま月額だけ払い続けると、チームは受け身のタスク消化型になります。ベロシティ・品質指標・四半期ごとの成果レビューをセットで運用し、「何がどれだけ良くなったか」を定点観測することが、ラボ型を機能させる条件です。

まとめ

• 発注形態はフェーズで切り替える — 構想・PoC は準委任、MLP 構築はスコープを絞った請負または準委任、継続改善はラボ型
• 全要件固定の一括請負は避ける — MLP → 継続拡張が前提の Pega（Pega Express）と構造的に相性が悪い。請負を使うなら「範囲を絞る」ことが条件
• 契約条件は 4 点を明文化 — 成果物の定義（ルールセット・ドキュメント）、知財とルールの帰属、体制変更の柔軟性、品質指標（ガードレール Compliance Score 等）を入れた検収基準
• PO は発注側に必須 — 丸投げはどの契約形態でも失敗する
• 契約類型の法的な詳細は、必ず法務・弁護士等の専門家に確認する

契約形態は「調達の事務手続き」ではなく、プロジェクトの進め方そのものを規定する設計判断です。Pega の強みを活かせる契約構造を最初に組んでおくことが、導入効果の土台になります。

---

Pega 開発の進め方・体制設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、フェーズ設計から契約時の技術的な論点整理までご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Customer Service 導入支援
• Pega の MLP スコープ設計｜Minimum Lovable Product の切り方と失敗回避
• Pega の PoC 成功基準の設計｜Exit Criteria と『PoC 沼』の回避
• Pega 内製化と SIer 委託の線引き｜共同ソーシングでどこを内製に残すか
• 無料相談に申し込む