Pega プロジェクトが失敗する7つの典型パターンと回避策

結論から：失敗の原因は技術ではなく「進め方」。しかも大半は契約前〜初期に仕込まれる

Pega プロジェクトの失敗を振り返ると、プラットフォームの技術的な限界が原因だったケースはほとんどありません。失敗の正体は、要件の立て方・体制の組み方・契約の切り方といった「進め方」の誤りです。

そしてもう一つ重要な事実があります。

失敗の種は開発の途中で突然生まれるのではなく、契約前〜プロジェクト立ち上げ期にすでに仕込まれている。だから回避の勝負どころは、発注前の準備と体制設計にある。

開発後半や稼働後に顕在化した問題を遡ると、根っこは「要件定義の方針」「体制表」「契約書」に行き着きます。本記事では、実案件で繰り返し目にしてきた7つの典型的な失敗パターンを、「兆候（こうなっていたら危険）」と「回避策」のセットで解説します。特定の企業・案件の話ではなく、一般化した教訓としてまとめていますので、自社の計画や進行中の案件のチェックリストとしてお使いください。

なぜ「技術」ではなく「進め方」で失敗するのか

Pega はケース管理・ワークフロー・意思決定を標準機能（OOTB: Out of the Box）として持つプラットフォームです。標準に沿って使う限り、技術リスクは相対的に小さい。逆に言うと、標準から外れる判断・標準を活かせない体制こそがリスクの源泉になります。これから見る7つのパターンはすべて、この「プラットフォームの前提と進め方のミスマッチ」に帰着します。

7つの失敗パターンと回避策

① 現行踏襲の要件定義 — 紙の帳票を画面に再現する

最も頻度が高いパターンです。「現行と同じであること」が要件定義のゴールになり、紙の帳票や既存システムの画面をそのまま Pega 上に再現しようとします。結果、OOTB の標準 UX から大きく外れたカスタム UI の山ができ、コストは膨らみ、業務は何も改善されません。出来上がるのは「高価な電子帳票」です。

• 兆候： 要件定義の成果物が「現行画面のハードコピー＋差分メモ」になっている。「現行と同じにしてほしい」という発言がレビューのたびに出る。帳票レイアウトのピクセル単位の再現が要求される
• 回避策： 要件を「現行の操作」ではなく「業務の目的」から立て直す（to-be 起点）。現行踏襲の要求には「その操作は何のためにあるのか」を問い直し、目的が同じなら Pega の標準 UX に業務を寄せる。詳しくは現行踏襲（as-is 移植）の罠で扱っています

② OOTB を無視した作り込み

「Pega でもスクラッチ開発と同じように作れます」という進め方です。標準機能の適合調査より先にカスタム実装の設計が始まり、カスタムコードが積み上がっていく。ローコードプラットフォームに高いライセンス費を払いながら、その価値（標準機能・アップグレード耐性・保守性）を自ら捨てる構図です。

• 兆候： 設計書にカスタム実装が並ぶ一方、「標準機能で代替できないか」の検討記録がない。ガードレール警告が累積しても誰も気に留めない。アップグレードのたびに大規模な回帰対応が必要になる
• 回避策： 「まず標準、どうしても足りないときだけカスタム」を設計原則として明文化する。カスタム実装には「なぜ標準で実現できないのか」の記録を必須にし（Pega 標準でもガードレール警告に正当化理由を記録して管理できます）、ガードレール準拠（Compliance Score）を品質ゲートとして運用する。Deployment Manager のパイプラインにはコンプライアンススコアを検査するタスクが標準で用意されており（既定のしきい値は 95）、スコアの低下をデプロイ前に機械的に止められます。詳しくはガードレールと Compliance Score の運用で扱っています

③ ウォーターフォール強行 — 全要件の確定を待つ

「すべての要件が確定してから実装に入る」計画です。業務ワークフローの要件は、動く画面を見るまで確定しません。確定を待つほどリリースは遠のき、1年後に出てきたものは「1年前の想像で作った業務」になっています。「動くケースを早く見せて直せる」という Pega の最大の強みを、計画の時点で自ら捨てるパターンです。

• 兆候： 初回リリースが契約から1年以上先に設定されている。業務部門が初めて動くものに触れるのが総合テスト。要件変更の手続きが重く、「変更させないこと」が目的化している
• 回避策： スコープを小さな業務単位に区切り、動くソフトウェアで要件を検証しながら段階的にリリースする。契約も一括請負の一発勝負ではなく、反復を許す形（フェーズ分割・準委任の併用など）を検討する

④ 業務有識者の不在

Pega はビジネスと IT が一緒に作ることを前提としたプラットフォームです。業務の問いにその場で答えられる人がチームにいないと、開発側は推測で作り、レビューでひっくり返り、を延々と繰り返します。要件の質問が数週間滞留した時点で、反復開発のリズムは崩壊しています。

• 兆候： 業務側の関与が「月1回のレビュー会」だけ。業務への質問の回答に数週間かかる。会議に出てくるのは伝言役で、仕様を決められる人がいない
• 回避策： 意思決定権限を持つ業務有識者の専任（またはそれに近い稼働率での）参画を、契約前の体制設計の段階で合意する。参画できないなら、その時点でスコープか時期を見直すべきシグナルです

⑤ 有資格者ゼロの体制

Pega は自由度が高いからこそ、ガードレールを理解したリードが不可欠です。認定資格・設計経験を持つアーキテクトが一人もいない体制では、②の作り込みや誤ったケース設計が誰にも止められないまま横行し、後から直せない構造的な負債が静かに積み上がります。

• 兆候： 提案書・体制図に認定資格保有者の明記がない。設計レビューの仕組みも、レビューを担う役割も存在しない。「Java 経験者が揃っているので問題ありません」という説明がされる
• 回避策： 設計をリードできる認定アーキテクトを最低1名、設計レビューの仕組みとセットで確保する。発注側もベンダー任せにせず、提案時に体制表の資格・実務経験を必ず確認する

⑥ テスト自動化ゼロ — 改修が怖くなる

手動テストだけで積み上げていくパターンです。初回リリースまでは何とかなりますが、問題はその後。改修のたびにリグレッションテストで数週間かかるため、次第に「動いているから触らない」文化が生まれます。変化への追従こそが Pega を選ぶ理由なのに、その価値が死にます。

• 兆候： テスト成果物が手動実行のスクリーンショット集になっている。小さな改修の見積もりに大きなリグレッション工数が乗り始める。リリース頻度が回を追うごとに落ちている
• 回避策： 自動テスト（PegaUnit によるユニットテスト・UI を通して検証するシナリオテスト）の整備を初回リリースのスコープに含め、テストカバレッジを品質ゲートとして CI/CD パイプラインに組み込む（ユニットテストとシナリオテストの使い分け・カバレッジゲートの設計参照）。経験上、「稼働後に整備する」はまず実現しません——最初から計画に入れることが唯一の対策です

⑦ 稼働後の改善予算ゼロ — 塩漬け化

稼働をゴールとする予算計画です。初回リリースで予算が尽きてプロジェクトが解散し、改善バックログは放置され、初回リリースの粗さが直らないまま現場の信頼を失い、数年後には「使われないシステム」として塩漬けになります。投資回収の観点で最も損なパターンです。

• 兆候： 予算計画が「開発費＋障害対応の保守費」しかない。稼働日がプロジェクト解散日と同義になっている。稼働後のバックログに持ち主（プロダクトオーナー）がいない
• 回避策： 稼働後の反復改善を前提に、予算と体制を最初の投資計画（稟議）に含める。小さく出すアプローチを採るなら、稼働後こそが価値回収の本番です。「初回リリースはゴールではなく計測開始点」という位置づけを経営層と発注前に合意しておく

7パターン早見表

#	パターン	仕込まれる時期	典型的な兆候	回避策の要点
①	現行踏襲の要件定義	契約前〜要件定義	現行画面のコピーが要件書になる	to-be 起点、標準 UX に業務を寄せる
②	OOTB 無視の作り込み	提案〜設計初期	標準機能の検討記録がない	「まず標準」を原則化、Compliance Score をゲートに
③	ウォーターフォール強行	契約・計画時	初回リリースが1年以上先	小さく区切って反復、契約も反復前提に
④	業務有識者の不在	体制設計時	質問の回答に数週間かかる	決定権ある有識者の専任参画を契約前に合意
⑤	有資格者ゼロの体制	体制設計時	体制表に資格記載がない	認定アーキテクトのリード配置＋設計レビュー
⑥	テスト自動化ゼロ	開発初期	手動テストの消化が常態化	初回スコープから自動テスト、カバレッジをゲートに
⑦	稼働後の改善予算ゼロ	投資計画時	稼働日＝解散日	「育てる」予算と体制を稟議に含める

表を見れば分かるとおり、7つのうち5つ（①③④⑤⑦）は開発が始まる前に仕込まれます。開発中に生まれる②⑥も、体制（⑤）と計画（③）の帰結であることがほとんどです。開発中に頑張って挽回できる余地は、思われているよりずっと小さいのです。

Pega Express / MLP はこれらの失敗への「公式の回答」である

重要なのは、これらの失敗パターンが Pega 側にとっても既知だということです。Pega が公式に掲げるデリバリーアプローチ Pega Express は、Discover → Prepare → Build → Adopt という4フェーズ構成で、業務ジャーニー（Microjourney）を中心に据え、MLP（Minimum Lovable Product） を短期間——公式教材が示す目安では 60〜90 日以内——で稼働させ、ベストプラクティスに沿って段階的に育てる進め方です。7つのパターンのちょうど裏返しとして読めます。

• ①②（現行踏襲・作り込み）への回答 — 業務の成果から出発するジャーニー中心の設計と、標準機能・ガードレールへの準拠。現行の再現ではなく「あるべき業務」を最初の論点にする
• ③⑦（ウォーターフォール・塩漬け）への回答 — MLP を 60〜90 日程度で稼働させ、稼働後も反復で育てる計画。「全部作ってから出す」のでも「出して終わり」でもない。MLP の切り方はMLP スコープ設計で詳しく扱っています
• ④（有識者不在）への回答 — ビジネスと IT が動く画面を見ながら一緒に決める、協働前提の進め方
• ⑤⑥（体制・品質）への回答 — 適切なスキルを持つチーム構成と、品質を継続的に作り込むプラクティス

つまり「Pega Express に従うかどうか」は方法論の好みの問題ではなく、既知の失敗パターンを踏むかどうかの問題です。発注側がこの考え方を理解しておくと、ベンダー提案が「Pega らしい進め方」になっているかを目利きできるようになります。

よくある失敗：パターンは単独では来ない

実際の失敗プロジェクトでは、これらのパターンは複合して現れます。

• ①×③（現行再製造）： 現行踏襲の要件を全件確定させてから作る——これは「現行システムをより高いコストで再製造する」プロジェクトです。得られるのは、新しい技術スタックに載った古い業務です
• ⑤×②（止める人のいない作り込み）： ガードレールを知る人がいない体制で作り込みが始まると、誰にも止められないまま技術的負債が最速で蓄積します
• ⑥×⑦（触れないシステム）： テストがなく改修が怖い、しかも改善予算もない——稼働後1年で「動いているが誰も触れないシステム」が完成します

複合が始まると立て直しのコストは跳ね上がります。単独のパターンの兆候が見えた時点で手を打つことが重要です。

まとめ：勝負は発注前に決まっている

• Pega プロジェクトの失敗は技術ではなく進め方に起因する。7パターンのうち5つは開発開始前に仕込まれる
• 各パターンには早期に観測できる兆候がある。兆候の段階で気づけば修正コストは最小で済む——本記事をチェックリストとして使ってほしい
• Pega Express / MLP は既知の失敗への公式の回答。従来型 SI の進め方をそのまま持ち込むこと自体が最大のリスク要因
• 発注前に確認すべきは4点——スコープ方針（小さく区切って反復する計画か）、体制（業務有識者の専任参画と認定アーキテクトのリードがいるか）、契約（反復を許す形か）、稼働後（育てる予算と体制があるか）

失敗パターンはどれも、渦中にいると気づきにくく、外から見ると明白です。だからこそ、RFP・提案書・体制図の段階で第三者の目を入れる価値があります。兆候の多くは、契約書にサインする前の資料の中にすでに現れています。

---

Pega プロジェクトの立ち上げ・立て直しをご検討の際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、発注前の計画レビュー・体制設計からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega DevOps・CI/CD 支援
• Pega 導入の現行踏襲という罠｜as-is 移植と to-be 再設計の判断基準
• Pega の MLP スコープ設計｜Minimum Lovable Product の切り方と失敗回避
• Pega のガードレールと Compliance Score の運用
• Pega のユニットテストとシナリオテストの使い分け
• 無料相談に申し込む