Pega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
結論から：保守費は「金額」ではなく「構造」で見る
Pega アプリケーションを数年運用していると、ほぼ必ず「保守費が高いのではないか」という議論が起こります。このとき最初にやるべきことは、値引き交渉ではありません。保守費の内訳を分解し、どの構成要素が・どの構造要因で膨らんでいるかを特定することです。
結論を先に言うと、次のとおりです。
保守費の高さの正体は、金額そのものではなく「カスタム過多」「有識者の属人化」「手動テスト依存」という構造要因にある。構造を変えないまま金額だけ削ると、品質と改善スピードが先に壊れる。逆に構造を変えれば、同じ費用でも消化できる改善量が増え、結果として単位コストが下がる。
本記事では、保守費の内訳を 4 つの構成要素に分解したうえで、高くなる構造要因と削減の実践アプローチを、実案件での設計判断として整理します。
Pega 保守費の内訳 — 4 つの構成要素
まず「保守費」と一括りにされている費用を分解します。Pega に限らずエンタープライズシステムの保守費は、おおむね次の 4 つで構成されます。
| 構成要素 | 内容 | 費用の性質 |
|---|---|---|
| 定常体制の維持 | 人月 × 単価で決まる常駐・専任チームの費用 | 固定費。契約体制を変えない限り下がらない |
| 障害・問い合わせ対応 | インシデントの調査・復旧、ユーザー問い合わせ対応 | 変動費。アプリの品質と運用の成熟度に依存 |
| 小規模改善 | 画面修正・ルール変更・帳票追加などの軽微改修 | 変動費。改修 1 件あたりの単価が「構造」で決まる |
| バージョンアップ対応 | 定期的なプラットフォーム更新への追随・検証 | 周期的に発生する山。カスタムの量に比例して膨らむ |
金額の水準は体制規模や契約形態によって大きく変わるため、ここで断定はしません。重要なのは、このうちどれが支配的で、それが何によって膨らんでいるかを自社の請求内訳と突き合わせて特定することです。「高い」と感じる案件の多くは、定常体制（固定費）が大きいのに消化される改善件数が少ない、つまり改修 1 件あたりの単位コストが高い状態にあります。
なぜ高くなるのか — 3 つの構造要因
要因 1：カスタム過多 — 1 箇所直すと影響調査が膨らむ
Pega は標準機能の範囲で作っている限り、バージョンアップ耐性も保守性も高いプラットフォームです。これは経験則にとどまらず、Pega 公式がガードレール（再利用性・保守性・性能を担保する設計ベストプラクティス）として明文化し、準拠度をコンプライアンススコアとして数値で可視化する仕組みまで製品標準で備えている方針です。保守費を押し上げるのは、導入時に積み上がった標準から外れたカスタム実装です。
カスタムが多いアプリケーションでは、たとえば「ドロップダウンの選択肢を 1 つ追加する」だけの改修でも、そのルールがどこから参照され、どの画面・どの処理に波及するかの影響範囲調査から始めることになります。改修そのものは数時間でも、調査と検証で数日かかる——この「調査税」が改修 1 件ごとに課され、小規模改善の単価を静かに押し上げます。さらにバージョンアップのたびに、カスタム部分は 1 つずつ動作確認・修正が必要になり、周期的な山も高くなります。
要因 2：有識者の属人化 — 体制を見直せなくなる
初期構築メンバーが数名だけ残り、「この画面はあの人しか触れない」という状態です。属人化が進むと、実際の作業量にかかわらずその人を確保し続けるための定常体制が必要になり、固定費が下がらなくなります。体制縮小の提案が出ても「何かあったとき対応できない」という理由で見送られ、結果として稼働率の低い常駐体制が温存されます。これは委託先の問題というより、ドキュメントとナレッジ移転を成果物として要求してこなかった発注側の構造問題でもあります。
要因 3：改修のたびの手動テスト
自動テストが整備されていないと、どんな小さな改修でも「壊れていないことの確認」を手動の回帰テストで担保することになります。改修の規模にかかわらず毎回ほぼ一定の検証工数が乗るため、軽微改修ほど単価が割高になります。「たったこれだけの修正になぜこの見積り？」という違和感の正体は、多くの場合この手動テスト分です。
削減の実践アプローチ — どこから手を付けるか
3 つの構造要因に対応する形で、実践アプローチは次の 4 つです。着手順と効く先を整理します。
| アプローチ | 主に効く内訳 | 着手の目安 |
|---|---|---|
| 標準機能への回帰 | バージョンアップ対応・小規模改善 | バージョンアップ計画と同時に実施 |
| 自動テストの整備 | 小規模改善・障害対応 | 改修が定常的に発生しているなら即着手 |
| 軽微改修の内製化 | 小規模改善 | 自動テストと運用ドキュメントが揃ってから |
| 体制のメリハリ | 定常体制の維持 | 障害が安定し、稼働実績を可視化できてから |
1. 標準機能への回帰 — バージョンアップ時に「作り込みを捨てる」
構築当時は標準機能で実現できなかったため作り込んだ機能が、現在のバージョンでは標準提供されている——リリースごとに機能拡張が続く Pega では、実案件でもたびたび遭遇するパターンです。どの作り込みが標準機能で置き換えられるかはバージョンによって異なるため、移行先バージョンのリリースノート・公式ドキュメントでの確認が前提になります。バージョンアップの際にカスタムをそのまま延命するのではなく、標準機能に置き換えてカスタムを捨てる判断を計画に組み込みます。カスタムが減れば、影響調査・バージョンアップ検証・テストのすべてが軽くなり、以降の保守費の傾きそのものが変わります。
2. 自動テストの整備 — 改修 1 件の固定費を下げる
主要な業務シナリオの回帰テストを自動化し、「壊れていないことの確認」を機械に任せます。Pega Platform には、ルール単位で入出力を検証する単体テスト（PegaUnit テストケース）と、UI 操作を記録・再生するシナリオテストが標準機能として備わっており、外部ツールを追加しなくても回帰テストの自動化を始められます。これにより軽微改修の単価が下がるだけでなく、改修に対する心理的ハードルが下がり、改善が回る組織になります。テスト整備自体は投資ですが、改修が定常的に発生しているアプリケーションでは早期に回収できます。
3. 軽微改修の内製化 — 全部ではなく「軽微」から
Pega はローコードプラットフォームであり、画面の文言修正・選択肢の追加・簡単なルール変更といった軽微改修は、訓練を受けた社内メンバーでも十分担えます。Pega 公式も、業務部門側の作り手（シチズンデベロッパー）向けのローコード開発環境として App Studio を位置づけており、軽微改修の内製化はプラットフォームの設計思想に沿った使い方です。進め方の全体像は Pega 内製化の進め方 で詳しく解説しています。すべてを内製化する必要はありません。難易度で線を引き、軽微改修だけを内製に移すだけでも、外部委託する改修の件数が減り、変動費が直接下がります。前提条件は、自動テスト（安全網）と運用ドキュメントが先に整っていることです。
4. 体制のメリハリ — 常駐からオンデマンドへ
障害が安定し、問い合わせが減ってきた運用フェーズでも、構築直後と同じ常駐体制を続けているケースは少なくありません。稼働実績を可視化し、平常時は縮小した体制＋必要時にオンデマンドで専門家を呼ぶ構成に切り替えることで、固定費を実態に合わせられます。ただし属人化が残ったままこれをやると事故になるため、順序としてはナレッジ移転・ドキュメント整備が先です。
「安くする」だけが目的ではない — 単位コストという視点
保守費の見直しを「金額を下げる交渉」と捉えると、削れるのは体制の頭数だけになり、品質と改善スピードが犠牲になりがちです。もう 1 つの選択肢は、同じ費用のまま、消化できる改善量を増やすことです。
カスタム削減と自動テストで改修 1 件あたりの工数が下がれば、同じ月額でこなせる改善件数は増えます。総額は変わらなくても改修 1 件あたりの単位コストは下がっている——これは実質的なコスト削減であり、かつ業務側から見れば「要望が通るようになった」という体感改善を伴います。経営層への説明でも、「保守費を◯％削る」より「同じ費用で改善スループットを◯倍にする」のほうが、システムを成長させたいフェーズでは合理的な目標設定になることが多いはずです。
見直しのベストタイミングはバージョンアップ計画と同時
保守費の構造改革には「作り込みを捨てる」「テストを整備する」「体制を組み替える」という、単独では稟議を通しにくい施策が含まれます。これらを最も効率よく実行できるのがバージョンアップ計画のタイミングです。
そもそも「バージョンアップをしない」という選択肢は実質ありません。執筆時点の Pega 公式サポートポリシーでは、新バージョンはおおむね 9〜12 か月ごとにリリースされ、各バージョンの標準サポート期間は GA（一般提供開始）から 18 か月、有償の延長サポートを含めても最長 36 か月です。追随が前提である以上、その機会を構造改革に使わない手はありません。
- バージョンアップでは全カスタムの棚卸しと検証がどのみち必要になる。棚卸しのついでに「捨てる判断」ができる
- 検証工数が必要なら、その工数を自動テスト整備として資産化できる（手動で 1 回検証して終わりにしない）
- 体制もプロジェクト期間中は一時的に厚くなるため、終了後の定常体制を再設計する自然な区切りになる
バージョンアップを「追随作業」として最小コストで済ませるか、「保守費構造を作り替える機会」として使うか。ここが数年単位の保守費を分ける判断分岐です。
よくある失敗
失敗 1：内訳を見ずに一律の値引き交渉をする
構造要因を放置したまま金額だけ削ると、委託側はテスト工数や調査工数を圧縮して帳尻を合わせるしかなく、品質低下や障害増加として跳ね返ります。数ヶ月後に障害対応費で相殺される、典型的な失敗パターンです。交渉の前に、まず内訳の開示と構造の分析です。
失敗 2：属人化を残したまま体制を縮小する
固定費削減を急ぎ、ナレッジ移転が済んでいない段階で常駐を減らすパターンです。次の障害発生時に「わかる人がいない」状態に陥り、復旧の長期化と、割高な緊急支援費用を招きます。体制のメリハリは有効な施策ですが、順序はドキュメント整備・ナレッジ移転が必ず先です。
失敗 3：カスタムを温存したままバージョンアップを繰り返す
「動いているものは触らない」方針でカスタムを延命し続けると、バージョンアップのたびに検証・修正コストが積み上がり、山が回を追うごとに高くなります。作り込みを捨てる判断は先送りするほど高くつきます。バージョンアップは標準回帰の機会と位置づけるべきです。
まとめ
- 保守費は定常体制・障害対応・小規模改善・バージョンアップ対応の 4 つに分解して見る。「高い」の正体は多くの場合、改修 1 件あたりの単位コストの高さ
- 押し上げる構造要因はカスタム過多・有識者の属人化・手動テスト依存の 3 つ。金額交渉ではなく構造への対処が本質
- 実践アプローチは標準機能への回帰・自動テスト整備・軽微改修の内製化・体制のメリハリ。着手には順序があり、ナレッジ移転と自動テストが先行条件
- 「安くする」だけでなく、同じ費用で改善量を増やす＝単位コストの改善という目標設定も選択肢に入れる
- 構造改革の最良のタイミングはバージョンアップ計画と同時。棚卸し・検証・体制再編を一度に済ませられる
Pega アプリケーションの保守費見直し・バージョンアップ計画・内製化のロードマップ策定でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。当社は実案件での構築・保守の両面の経験に基づき、費用構造の分析から実行までご支援します。
関連リンク
関連記事
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 親子ケース設計｜子ケースに分割すべきかの判断基準と失敗例
業務を子ケースに切り出すべきか、それとも親ケースのステージ/ステップに収めるべきか。判断を誤ると、独立追跡できずに再設計になったり、逆にケースインスタンスが増えすぎて運用とレポートが破綻したりする。この記事では、親子ケースに分割する境界線を「独立したライフサイクルを持つか」を軸に、待ち合わせ(依存)設計まで含めて解説する。
記事を読む