Pega 内製化の進め方｜SIer 依存から自走できる組織への移行ロードマップ
Pega 内製化のロードマップを「役割とスキル・育成・段階的な移管設計」の観点で解説。SIer 依存から自走できる組織への移行手順を整理します。
結論から：内製化は 0/100 ではなく「役割分担の再設計」
Pega を導入した企業から最も多くいただく相談のひとつが、「SIer に任せきりの運用を、自社で回せるようにしたい」というものです。ライセンス費に加えて改修のたびに外部委託費がかかる、簡単な文言変更にも数週間かかる——この状態を変えたい、という動機は自然です。
ただし、結論を先に言うと、内製化は「全部自社でやるか、全部外注か」の二択ではありません。
日々の改善・小規模開発は内製チーム（SA）が担い、大規模改修とアーキテクチャの設計レビューは外部の LSA 相当のパートナーに残す。移管は「軽微改修 → 新規の小機能 → ケース型の追加」の順に段階を踏む。
これが実案件で機能する現実解です。「改善は内製・設計レビューは外部」という役割分担を設計できるかどうかが、内製化の成否を分けます。本記事では、必要な役割とスキル、Pega Academy を使った育成、段階的な移管設計まで、実務の手順に落とし込みます。
どこまで内製し、何を外部に残すか
内製化でまず決めるべきは「作業単位の仕分け基準」です。実案件では、次の 2 つの問いで判断すると迷いません。
ポイントは、「はい」に当たる作業を無理に内製へ取り込まないことです。アプリ全体に影響する変更や前例のない設計判断は、判断を誤ったときの手戻りが桁違いに大きく、経験の浅いチームが抱えると事故につながります。逆に、両方「いいえ」の作業——文言変更、項目追加、既存パターンを踏襲した機能追加——は、外部に出すほうがむしろ非効率です。ここから内製に取り込みます。
内製化に必要な 3 つの役割
「Pega 技術者を採用すれば内製化できる」と考えると失敗します。必要なのは個人ではなく、次の 3 つの役割が揃ったチームです。
| 役割 | 主な責務 | 目安となるスキル・資格 | 内製 / 外部 |
|---|---|---|---|
| ビジネスアナリスト | 要件整理、業務部門との橋渡し、改善案件の起案 | 業務知識 + Pega Academy の BA 向けコース（認定資格 Certified Pega Business Architect もこの系統） | 内製（業務部門から登用可） |
| システムアーキテクト（SA） | 日々の実装・改善・保守 | CSA →（実務を積んで）CSSA | 内製。まず 2 名以上 |
| リード（レビュー役） | アーキテクチャ設計、設計レビュー、大規模改修の主導 | LSA 相当の設計経験 | 当面は外部パートナー |
実務上の要点は 2 つです。
- SA 資格者はまず 2 名以上を目指す。 1 名体制は属人化と退職リスクがそのまま事業リスクになります。2 名いれば相互レビューが成立し、休暇や離任にも耐えられます。
- リード（LSA 相当のレビュー役）は最初から内製しようとしない。 この役割は資格取得ではなく設計経験の蓄積で育つため、内製で立ち上がるまで数年単位かかります。実際、Pega 公式もアーキテクト系資格の最高位 CLSA の受験前に、36 ヶ月以上の実務経験を積むことを推奨しています。それまでは外部パートナーの設計レビューを「品質ゲート」として組み込むのが現実的です。
育成：Pega Academy の無償コンテンツ + 実案件 OJT
育成の教材は、実はほぼ無償で揃います。Pega Academy には CSA（Certified Pega System Architect）取得までの学習コンテンツが無償で公開されており（System Architect ミッションは合計 40 時間強の自習コンテンツ。無料アカウント登録で利用可能）、座学部分に高額な研修投資は不要です。認定試験の受験自体は有償ですが、学習コストの大半は時間の投資です。
ただし、資格取得はスタートラインであってゴールではありません。実案件で機能するチームにするには、次のサイクルを回します。
- Pega Academy で学習し、CSA を取得する（目安：業務と並行して 2〜3 ヶ月）
- 小さな改善案件を 1 つ任せる——文言変更、項目追加、バリデーション追加など、失敗しても影響が限定的なもの
- 外部パートナーがレビューする——「動くか」ではなく「Pega らしい作り方（ガードレールの中でのローコード開発）になっているか」を見る
- 少しずつ大きい案件へ——レビュー指摘が減ってきたら、次の段階の作業を任せる
このサイクルの肝は 2 と 3 です。CSA を取得しただけのメンバーに OJT の場を用意しないと、知識は数ヶ月で風化します。逆に、レビューなしで実案件に投入すると、独自流の作り込み（過剰なカスタム実装）が蓄積し、後の保守コストに跳ね返ります。
移管は 3 段階で設計する
外部パートナーから内製チームへの移管は、いきなり全面移管せず、作業の難易度に応じて段階を踏みます。
| 段階 | 内製チームが担う範囲 | 外部に残す範囲 | 次へ進む目安 |
|---|---|---|---|
| 第 1 段階：軽微改修 | 文言・画面項目の変更、簡単なロジック修正 | それ以外すべて | レビュー指摘が定型的なものだけになる |
| 第 2 段階：新規の小機能 | 既存ケース型への機能追加、レポート作成 | 新規ケース型の設計、共通基盤 | 設計書を内製チームが書けるようになる |
| 第 3 段階：ケース型の追加 | 新しい業務のケース型を設計・実装 | 設計レビュー、大規模改修、性能設計 | （以降もレビューラインは維持） |
たとえば「申請業務のアプリに承認ステップを 1 つ追加する」は第 2 段階の仕事ですが、「新しい業務のケース型をゼロから設計する」はケースとデータの分割、ステージ設計、他システム連携の方式選定といった上流の設計判断を含むため、第 3 段階まで任せるべきではありません。この順序を飛ばして「来期から全部お願いします」とやると、設計品質の劣化が数ヶ月遅れで障害・保守コストとして表面化します。
App Studio と Dev Studio で「誰が触れるか」の線を引く
Pega Platform には、役割別のワークスペース（スタジオ）が 4 つ用意されています。ローコードの App Studio、高度な設定まで扱える Dev Studio、AI モデルを扱う Prediction Studio、運用管理の Admin Studio です。内製化の役割分担にそのまま使えるのは、アプリケーション開発の中心となる App Studio と Dev Studio の線引きです。
- App Studio の範囲（画面レイアウトの調整、簡単なフィールド追加、ケースのステップ調整など）— ガードレールが効いたローコード領域です。Pega 公式も App Studio を「ビジネスアーキテクト、シチズンデベロッパー、システムアーキテクトのためのローコードワークスペース」と位置づけており、IT 部門だけでなく業務部門の担当者も担える余地があります。ビジネスアナリスト役の育成先としても有効です。
- Dev Studio の範囲（共通ルール、複雑なシステム連携、セキュリティ設定、性能に関わる実装など）— 影響範囲が広いため、IT 側の SA に限定します。なお、簡単な外部データ接続は近年のバージョンでは App Studio からも構成できるため、この線引きは「機能的にできるか」ではなく統制の観点で決めます。App Studio で扱える範囲はバージョンにより異なるため、線引きの際は公式ドキュメントで確認してください。
補足すると、Pega 公式のガイドでも「必要な機能が App Studio に無い場合を除き、SA も App Studio で作業する」ことが推奨されています。App Studio 優先はガードレール遵守（＝標準に沿った保守しやすい作り）を自然に強制するため、内製チームの品質底上げにも効きます。
「業務部門にも触らせるのは怖い」という声はよく聞きますが、線引きを曖昧にして全部 IT に集約するほうが、結局ボトルネックが SIer から情シスに移るだけで、内製化の目的（変更のリードタイム短縮）を達成できません。触れる範囲をワークスペースの機能で区切るのが Pega らしい統制の効かせ方です。
よくある失敗
失敗 1：いきなり全面移管する
契約更改のタイミングで「来期から保守は全部内製で」と切り替えるパターンです。第 1〜2 段階を経ていないチームに大規模改修や新規設計まで渡すと、表面上は動いても設計品質が劣化し、半年〜1 年後に性能問題や保守困難という形で表面化します。移管は作業単位で段階的に、が原則です。
失敗 2：資格だけ取らせて実践の場を作らない
「まず全員 CSA を取ろう」で止まるパターンです。取得後 3 ヶ月以内に小さな改善案件を任せる計画とセットでなければ、投資した学習時間は回収できません。育成計画は「資格 → 案件アサイン → レビュー」まで含めて 1 つの設計です。
失敗 3：設計レビューのラインまで切ってしまう
内製が軌道に乗り始めた頃に、コスト削減で外部パートナーとの契約を完全に打ち切るパターンです。日々の改善は回っていても、新規ケース型の設計やバージョンアップ対応のような「たまにしか来ないが難易度の高い判断」は、内製チームだけでは品質を担保できないことが多い。外部に残すのは工数ではなくレビューという品質ゲートなので、金額的には小さくても最後まで残す価値があります。
まとめ
- 内製化は 0/100 ではない。「改善は内製・大規模改修と設計レビューは外部 LSA」という役割分担が現実解
- 体制は**ビジネスアナリスト / SA / リード（レビュー役）**の 3 役。まず SA 資格者 2 名以上から始める
- 育成は Pega Academy の無償コンテンツ + 実案件 OJT。CSA 取得 → 小さな改善案件、のサイクルを回す
- 移管は軽微改修 → 新規の小機能 → ケース型の追加の 3 段階。いきなり全面移管は事故のもと
- App Studio は業務部門も担える領域、Dev Studio は IT 側に残す領域として線を引く（線引きは機能ではなく統制の観点で）
内製化は「外注をやめること」ではなく、変更のリードタイムを短くし、Pega を業務改善のスピードに追従させるための体制づくりです。自社の現状に合わせた移管ロードマップの設計から、伴走できるパートナーとともに始めることをおすすめします。
Pega の内製化・体制づくりでお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、育成計画と移管設計からご支援します。
関連リンク
関連記事
Pega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読むPega プロジェクトが失敗する7つの典型パターンと回避策
Pega プロジェクトの典型的な失敗パターン7つ(現行踏襲・作り込み過多・体制空洞化など)と、それぞれの回避策を実例の教訓から率直に解説します。
記事を読むPega 人材の採用・面談での見極め方｜有資格者でも当たり外れがある理由
Pega 人材の実力を採用・案件面談で見極める方法を解説。レベル別の質問例・資格の読み方・経歴書で確認すべきポイントを整理します。
記事を読む