Pega 保守ベンダーの乗り換えガイド｜引き継ぎで失敗しないための段取り

結論から：乗り換えは可能。成否は「資産の確認」と「並走期間」で決まる

「今の Pega 保守ベンダーに不満がある。でも Pega は特殊なプラットフォームだから、他社に引き継げるのか分からない」——Pega アプリケーションを運用する企業から、実際によく聞く悩みです。

結論を先に言います。

Pega はルール（設定）がプラットフォーム内に一元管理されるため、コードが散逸しがちなスクラッチ開発よりも引き継ぎの成立性は高い。ただし成功の条件は「乗り換えサインの見極め → 引き継ぎ資産の確認 → 並走期間を挟んだ段階移行」という段取りを省略しないこと。

「不満がある＝即乗り換え」でも「Pega だから引き継げない」でもありません。判断は次のフローで整理できます。

以下、フローの各ステップを順に解説します。

乗り換えを検討すべき4つのサイン

まず、いまの不満が「乗り換えで解決する種類のものか」を見極めます。実務でよく見る代表的なサインは次の4つです。

サイン1：提案が保守的すぎる

改修を相談するたびに「影響範囲が大きいのでできません」「リスクがあるのでお勧めしません」という回答ばかりで、代替案や改善提案が出てこない状態です。Pega はもともと業務の変化に追従することを前提としたプラットフォームで、Pega 社自身が「Build for Change」を掲げています。「何もできない」が続く場合、それはプラットフォームの制約ではなく体制側のスキル不足であることが多いです。

サイン2：LSA / SSA 有資格者が体制にいない

Pega には SSA（Certified Senior System Architect）、その上位の LSA（Certified Lead System Architect）という認定資格体系があります。LSA は SSA 認定の保有と一定の実務経験を前提とした、システムアーキテクト系トラックの最上位資格です。保守体制にこのクラスの有資格者がいない場合、日々の運用は回っていても、設計判断を伴う改修——性能問題の根本対処、アーキテクチャ変更、バージョンアップ計画——で行き詰まりやすくなります。体制表で客観的に確認できる指標なので、まず確認する価値があります。

サイン3：バージョンアップの提案が一度もない

Pega Platform は継続的にアップデートされています。公式のメンテナンス方針では、新バージョンはおおむね9〜12ヶ月ごと、パッチはより高い頻度でリリースされ、各バージョンには GA 時期に応じたサポート区分（Standard / Extended Support）が設定されています（ポリシーの詳細は Pega 公式ドキュメントで最新を確認してください）。数年間バージョンアップの提案が一度も出てこない場合、放置されたバージョン差はそのまま将来の移行コストとサポート面のリスクとして積み上がっていきます。「動いているから触らない」は保守ではなく先送りです。

サイン4：単価と品質が釣り合わない

単価が高いこと自体は問題ではありません。問題は、高い単価に対して上記のような提案力・技術力が伴っていない状態です。逆に「安いが品質も低い」も同様に見直しの対象です。

ただし重要な注意があります。**サインに該当しても、即乗り換えではありません。**まず現行ベンダーに改善要請（有資格者のアサイン、体制変更など）を行うのが先です。それで改善するなら、引き継ぎ期間や関係再構築という乗り換えコストを払わずに済みます。改善要請への反応そのものが、継続可否を判断する材料にもなります。

そもそも Pega は他社に引き継げるのか

不安の核心はここだと思います。答えは「一般的なスクラッチ開発よりも引き継ぎやすい構造を持っている」です。

Pega では、アプリケーションを構成するルール——ケースタイプ、フロー、UI、決定ロジックなどの設定——がすべてプラットフォーム内に保存され、ルールセットという単位でバージョン管理されます。アプリケーションが参照するルールセットの一覧やバージョンも、プラットフォーム上で確認できます。コードがリポジトリ・ビルド設定・担当者個人のノウハウに散逸しがちなスクラッチ開発と比べると、「何が作られているか」を受け入れ側が追跡しやすい構造です。ドキュメントが不十分でも、ルールを読めばアプリケーションの実体には到達できます。

ただし限界も正直に書いておきます。ルールを読めば「何が作られているか」は分かりますが、「なぜその設計にしたか」までは読み取れません。ケースの分割方針やデータの持ち方といった設計思想を読解するには、Pega の設計原則を理解した有資格者の目が必要です。受け入れ側のベンダーに LSA / SSA クラスの技術者がいるかを確認すべき理由は、まさにここにあります。

引き継ぎ資産チェックリスト

乗り換えを決める前に、次の5つの資産を確保できるかを確認します。

引き継ぎ資産	確認するポイント	欠けている場合の対処
アプリケーション構成とルールセット	ルールセットの一覧・依存関係・バージョン状況を提示できるか	プラットフォーム内から受け入れ側が調査可能（時間はかかる）
設計ドキュメント	ケース設計・データモデル・連携仕様の文書が現物と一致しているか	ルールから復元可能（文書自動生成機能あり）だが、設計意図の読解に有資格者が必要
環境アクセス	開発・検証・本番の各環境のアクセス権限を移管できるか	**移管できないと引き継ぎ自体が成立しない。**最優先で確認
デプロイパイプライン	リリース手順・自動化の仕組み（Pega 標準の Deployment Manager か、外部 CI/CD か）が誰の管理下にあるか	現行ベンダー専有の仕組みなら再構築の工数を見込む
既知課題リスト	未解決の障害・技術的負債・回避策の一覧があるか	無いと受け入れ後に「再発見」するコストが発生する

ポイントは、ドキュメントの欠落は致命傷ではない（ルールセットから実体に到達できる）一方、環境アクセスとデプロイパイプラインの欠落は致命傷になり得ることです。契約や運用の都合で現行ベンダーが環境を専有している場合、ここの移管条件を先に固める必要があります。

補足として、Pega にはルール定義からアプリケーション文書を自動生成する機能（Dev Studio の Application Document 生成）が標準で用意されています。設計書が失われていても、現物のルールを起点にドキュメントを再整備する出発点にできます（生成手順や出力の粒度はバージョンにより異なるため、利用時は公式ドキュメントを確認してください）。

あわせて、現行契約の引き継ぎ協力義務を確認してください。引き継ぎ資料の提供・質疑対応・並走期間への協力が契約に定められているか。定めが無い場合は、解約を通知する前に協力条件を合意しておくのが安全です。解約通知後では交渉力が大きく下がります。

移行の段取り：並走期間 → 軽微改修 → 本格移管

資産が確保できると判断したら、移行は3フェーズで進めます。

フェーズ1：並走期間（1〜3ヶ月が目安）

現行ベンダーと新ベンダーが並走する期間です。新ベンダーはルールセットと設計を読解し、環境とリリース手順を習得します。現行ベンダーは通常の保守を継続しつつ、質疑に対応します。期間はアプリケーションの規模と資産の充実度によりますが、1〜3ヶ月が目安です。

フェーズ2：軽微改修で習熟する

画面の文言変更や小さなロジック修正など、影響範囲の小さい改修から新ベンダーが実施します。設計思想の理解を「読んで分かったつもり」ではなく「実際に変更してリリースできる」レベルで検証するフェーズです。ここでの品質とスピードが、新ベンダーの実力を測る試金石にもなります。

フェーズ3：本格移管

定常保守と障害対応の一次責任を新ベンダーへ移します。現行ベンダーは契約に応じて一定期間の後方支援（質疑対応のみ等）に回り、完了です。

よくある失敗

失敗1：並走期間を置かず一斉切り替えする

契約を重複させたくない気持ちは分かりますが、切り替え翌日に障害が起きたとき「アプリケーションの内部を知る人が誰もいない」状態になります。1〜3ヶ月の並走コストは、この最悪ケースに対する保険料です。ここを削るのが最大のリスクです。

失敗2：資産の確認前に現行契約を解約してしまう

解約を通知した後では、引き継ぎ協力を得るのは難しくなります。環境アクセスやデプロイパイプラインが渡らないまま契約が切れると、新ベンダーは調査からやり直しです。資産確認と協力条件の合意が先、解約通知は後。順番を間違えないことが重要です。

失敗3：受け入れ側の技術力を確認しない

「今より安いから」だけで新ベンダーを選ぶと、同じ不満が再発します。乗り換えサインとして挙げた基準——LSA / SSA 有資格者の有無、バージョンアップの提案実績——は、新ベンダーの選定基準としてそのまま使えます。現行に当てた物差しを、受け入れ側にも同じように当ててください。

まとめ

• 乗り換えサインは4つ——保守的すぎる提案・有資格者不在・バージョンアップ提案なし・単価と品質の不均衡。ただし即断せず、まず改善要請
• Pega はルールがプラットフォーム内に一元管理されるため引き継ぎの成立性は高い。ただし設計思想の読解には有資格者が必要
• 移行前に5つの資産（ルールセット・設計書・環境アクセス・パイプライン・課題リスト）と契約上の引き継ぎ協力義務を確認する
• 段取りは並走期間（1〜3ヶ月目安）→ 軽微改修で習熟 → 本格移管の3フェーズ
• 失敗パターンは「並走の省略」「解約先行」「受け入れ側の力量未確認」の3つ

保守ベンダーの乗り換えは、正しい段取りを踏めば過度に恐れる必要のない選択肢です。逆に段取りを省略すると、不満の解消どころか運用リスクを抱え込むことになります。この記事のフローとチェックリストが、冷静な判断の助けになれば幸いです。

---

Pega 保守体制の見直し・引き継ぎの実務でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、引き継ぎ資産の評価からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Constellation UI 導入支援サービス
• Pega Constellation UI と Cosmos の違いを徹底比較
• 無料相談に申し込む