Pega 運用体制の設計｜保守・監視・継続改善を回す組織と役割分担
Pega 本番稼働後の運用体制を設計する方法を解説。保守・監視・継続改善それぞれに必要な役割と、内製と外部委託の分担パターンを整理します。
結論から：運用は「保守・監視・継続改善」の3機能で設計し、改善枠を最初から組み込む
Pega アプリケーションが本番稼働すると、多くのプロジェクトが「保守契約を結んで開発チームを解散する」という流れに入ります。しかしこれは、Pega に限って言えば最も投資対効果を毀損しやすい選択です。
結論を先に言います。
Pega の運用体制は、保守（インシデント対応）・監視（PDC）・継続改善（エンハンス）の3機能で設計する。特に「継続改善」の枠を、最初から体制と予算に組み込む。障害対応だけの「塩漬け運用」は、Pega を選んだ意味を失わせる。
Pega はローコードプラットフォームであり、業務の変化に合わせてアプリケーションを速く・安全に変更できることが最大の強みです。つまり Pega の投資対効果は稼働後にどれだけ改善を回せるかで決まります。運用体制の設計とは、この改善サイクルを回すための組織設計にほかなりません。
運用の3機能を分解する
保守：インシデント対応と問い合わせ
障害の検知・切り分け・復旧、およびエンドユーザーからの問い合わせ対応です。「画面でエラーが出た」「この申請が進まない」といった日々の対応窓口で、どのシステム運用にも共通する機能です。重要なのは、保守は現状を維持する活動であって、価値を増やす活動ではないという位置づけの理解です。
監視：PDC を起点にした予防的運用
Pega には PDC（Pega Diagnostic Center、旧称 Predictive Diagnostic Cloud） という監視・診断サービスがあります。SaaS として提供され、実行中の Pega アプリケーションからアラート・例外などのテレメトリを収集して、本番環境の健全性を集中的に確認できます。Pega Cloud 環境だけでなく、オンプレミス環境も設定により監視対象にできます。障害が起きてから動くのではなく、悪化の兆候を先に捉えるのが監視の役割です（詳細は後述します）。
継続改善：業務部門の要望を随時リリースする
稼働後に業務部門から上がってくる「この項目を追加してほしい」「この承認は不要になった」「この業務もケース化したい」という要望を、優先順位を付けて継続的にリリースしていく機能です。Pega では App Studio を中心としたローコード開発により、この種の変更を比較的小さいコストで回せます。この機能こそが Pega 運用の本体です。
なぜ「塩漬け運用」が失敗なのか
保守契約だけを結び、改善の枠を持たない運用を、当社は「塩漬け運用」と呼んでいます。塩漬け運用が失敗する理由は明確で、次の悪循環に入るからです。
- 業務部門の改善要望に応える枠がなく、要望が積み上がる
- 現場が「言っても直らない」と学習し、Excel やメールでの回避運用が始まる
- システムと実業務が乖離し、利用率とデータの正確性が下がる
- 「高い割に使えないシステム」という評価が定着し、次の投資判断が通らなくなる
変更コストが高い従来型システムなら「作って数年凍結」にも一定の合理性があります。しかし Pega は変更コストの低さにプレミアムを払って採用するプラットフォームです。改善を回さないなら、そのプレミアムは丸ごと無駄になります。だからこそ、改善のための工数枠（月あたりの人日）を稼働初日から確保し、要望のバックログ管理と定期リリースのリズムを体制に組み込むことが、運用設計の第一の要件になります。
必要な役割と人数感
実案件でうまく回る体制は、おおむね次の3つの役割に整理できます。
| 役割 | 主な責務 | 求められるスキル | 人数感の目安 |
|---|---|---|---|
| 運用リード | 全体統括・PDC 監視・インシデント管理・リリース管理 | Pega 運用経験（SSA 相当が理想） | 1名 |
| SA（改善実装） | エンハンスの設計・実装・テスト | CSA〜SSA | 1〜2名（要望の流量による） |
| 業務側プロダクトオーナー（PO） | 要望の集約・優先順位付け・受入判断 | 業務知識（Pega スキルは不要） | 1名（業務との兼務可） |
※ 本記事の CSA / SSA / LSA は Pega 認定資格の略記です（正式名称はそれぞれ Certified System Architect / Certified Senior System Architect / Certified Lead System Architect）。
ポイントは、業務側 PO を「役割」として明示的に置くことです。改善サイクルが止まる原因の多くは技術ではなく、「どの要望からやるかを決める人がいない」ことにあります。PO は専任である必要はありませんが、不在は許されません。
小規模なら兼務で始めてよい
ケースタイプ数が少なく利用部門も限られる小規模案件なら、「運用リード兼 SA」1名＋業務側 PO（兼務）1名という最小構成でも回ります。その場合、常勤では抱えにくい高度な設計判断——たとえばケース構造の変更やパフォーマンス改修の設計妥当性——は、外部の LSA（Lead System Architect）によるスポットの設計レビューで補完するのが現実的です。逆に、複数部門・複数ケースタイプにまたがる中規模以上では、監視・インシデント管理と改善実装を1人に兼務させると改善側が必ず後回しになるため、役割を分離すべきです。
監視は PDC を起点に設計する
監視設計は、まず PDC を毎週見る習慣を作るところから始めます。入門として最低限押さえるべき指標は次の3つです。
- 応答時間 — 画面操作や処理の応答時間の傾向。PDC の性能分析画面で悪化トレンドが見えたら、データ量の増加や非効率なデータ取得（重いレポート・大量件数の読み込み）を疑います
- キュー滞留 — Queue Processor などの非同期バックグラウンド処理の未処理件数。PDC には Queue Processor 専用のランディングページがあり、滞留や処理遅延（PEGA0102 などのアラート）を確認できます。滞留が増え続けている場合、処理エラーの繰り返しや処理能力の不足が疑われ、放置すると「バッチが終わらない」「通知が届かない」という業務影響に直結します
- 例外（エラー） — 例外の発生傾向。PDC の Event Viewer では各ノードのイベントをほぼリアルタイムに確認できます。件数の絶対値よりも「新種の例外が出ていないか」「特定の処理に集中していないか」を見ます
運用のリズムとしては、緊急性の高いイベントは PDC のイベントベース通知（メール等）で即時に検知し、週次で運用リードが PDC をレビューして傾向を確認するという2段構えが基本形です。PDC には主要指標をまとめたデイリーダイジェスト通知もあり、週次レビューの補助として使えます。監視は「ダッシュボードを作って終わり」になりやすい領域ですが、見る人と見る頻度を決めて初めて機能します。なお PDC は SaaS として継続的に更新されるため、画面構成や機能名は変わることがあります。最新の仕様は公式ドキュメントで確認してください。
内製と外部委託の分担パターン
すべて内製・すべて委託の二択ではなく、機能ごとに分担を設計します。実案件でよく機能する分担例は次のとおりです。
| 機能 | 推奨分担 | 理由 |
|---|---|---|
| 一次受付（問い合わせ・障害受付） | 内製 | 業務文脈の理解が必要で、速度が価値。外部化すると伝言ゲームになる |
| 監視・アラート対応 | 内製中心（仕組み構築は外部支援） | 日々の確認は内製が低コスト。閾値設計や通知連携の初期構築は外部の知見を借りる |
| 改善実装 | 混成（内製 SA＋外部 SA） | ナレッジを社内に蓄積しつつ、要望量の変動を外部で吸収する |
| 設計レビュー | 外部 LSA | 最高難度のスキルを常勤で抱えるより、スポットで品質を担保する方が合理的 |
具体的な回し方のイメージはこうです。問い合わせは内製の一次受付が切り分け、障害は運用リードが指揮して復旧。改善要望は業務側 PO がバックログとして管理し、月次のリリースサイクルで混成チームが実装。四半期に一度、外部 LSA が設計レビューを行い、改修の積み重ねでアーキテクチャが劣化していないかを点検する——この形なら、内製化の度合いを段階的に高めながら品質の底を外部で支えられます。
よくある失敗
失敗1：改善枠ゼロの保守契約（塩漬け運用）
最も多い失敗です。「安定稼働しているから保守だけでよい」という判断は、前述の悪循環の入口です。改善枠は「余裕があれば」ではなく、運用費の一部として最初から予算化してください。
失敗2：業務側プロダクトオーナーの不在
改善枠と実装チームがあっても、要望の優先順位を決める人がいなければリリースは止まります。「IT 部門が業務部門にヒアリングして回る」体制は、要望の翻訳コストが高く長続きしません。優先順位の決定権を持つ PO を業務側に置くことが、改善サイクルの前提条件です。
失敗3：アラートが来てから動く（PDC を見ない）
監視ツールはあるのに誰も見ておらず、ユーザーからの「遅い」という申告で初めて性能劣化に気づくパターンです。キュー滞留や応答時間の悪化は、業務影響が出る前に PDC 上で兆候が見えていることがほとんどです。週次レビューの定例化で防げます。
失敗4：改善実装の全部外部任せ
改善を回せてはいるものの、実装をすべて外部に委託しているため、社内に「なぜこの設計なのか」が残らないパターンです。数年後のベンダー交代や大型改修のたびに調査コストを払い続けることになります。少なくとも1名の内製 SA を混成チームに入れ、設計判断の理由を社内に蓄積してください。
まとめ
- Pega の運用体制は保守・監視・継続改善の3機能で設計する。継続改善こそが Pega の投資対効果の源泉
- 改善の工数枠を稼働初日から予算化する。塩漬け運用は「変更コストの低さ」というプレミアムを捨てる行為
- 役割は運用リード／SA（改善実装）／業務側 PO の3つ。小規模なら兼務でよいが、PO の不在だけは許されない
- 監視は PDC を起点に、応答時間・キュー滞留・例外の3指標から。イベント通知での即時検知＋週次レビューの2段構え
- 委託分担は一次受付＝内製、改善実装＝混成、設計レビュー＝外部 LSA が基本形。ナレッジは社内に残す
運用体制は稼働後に考え始めるものではなく、開発フェーズの終盤には設計しておくべきものです。体制の立ち上げから改善サイクルの定着までを見据えて、早めに検討を始めることをおすすめします。
Pega の運用体制設計・稼働後の継続改善でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、体制設計から設計レビューまでご支援します。
関連リンク
関連記事
Pega データページの種類とスコープ設計｜Thread / Requestor / Node の使い分け
「なんとなく Thread スコープ」で作られたデータページが、外部連携の呼び出し回数を無駄に増やしていませんか。本記事ではデータページの種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の組み合わせを、キャッシュ範囲・データ鮮度・再読み込みの観点から使い分ける判断軸を、LSA 目線で整理します。
記事を読むPega DX API で独自フロントを作る判断｜標準 Constellation UI との使い分け
Constellation は DX API 経由で UI メタデータを受け取りクライアントで描画する。この API は独自フロントの構築にも開放されているが、わずかな見た目調整のために独自フロントへ踏み込むと保守とアップグレードの負担が跳ね上がる。どこまで OOTB で、どこから DX API か——設計判断の分岐点を扱う。
記事を読むPega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む