Pega 人材の採用・面談での見極め方｜有資格者でも当たり外れがある理由
Pega 人材の実力を採用・案件面談で見極める方法を解説。レベル別の質問例・資格の読み方・経歴書で確認すべきポイントを整理します。
結論から：「Pega 歴 N 年」では実力は測れない——見るべきは「どの帯の仕事をしてきたか」
Pega のプロジェクトで人材を採用・アサインするとき、経歴書に「Pega 経験 5 年」と書いてあれば安心でしょうか。結論を先に言うと、年数だけでは実力はほぼ判断できません。
Pega 経験者の実力は「画面・フロー設定ができる」から「アプリ全体のアーキテクチャを設計できる」まで大きな幅がある。見るべきは年数ではなく「どの帯の仕事を、どの役割で担ってきたか」。それを露呈させるのは、知識クイズではなく“正解のない判断系の質問”である。
Pega はローコードプラットフォームであるがゆえに、「用意された設計の上で画面を組む」ことは比較的短期間でできるようになります。一方で、ケースとデータの分割・外部連携・再利用レイヤーといった設計判断を誤ると、後から取り返しのつかない技術的負債になります。つまり「動くものを作れる人」と「正しく設計できる人」の差が、他の技術スタック以上にプロジェクトの成否に直結します。本記事では、この幅をどう見極めるかを、資格の読み方・質問例・経歴書のチェックポイントに分解して解説します。
Pega 経験者の実力には「帯」がある
Pega 経験者の実力は、おおまかに次の 3 つの帯に分かれます。
- 画面・フロー設定（App Studio 圏） — 誰かが設計したデータモデル・ケース構造の上で、画面レイアウトやフローを設定できる。Pega のローコードの恩恵を最も受ける領域で、参入障壁は比較的低い
- データモデル・連携設計 — ケースとデータの分割、Data Page や外部システム連携（REST 連携等）の設計を独力で行い、アプリケーションを一通り構築できる
- アプリ全体のアーキテクチャ設計（LSA 圏） — 再利用レイヤーの構成、複数アプリケーション間の共通化戦略、セキュリティ・性能といった非機能要件まで含めて、設計責任者としてプロジェクトを引っ張れる
問題は、経歴書の「Pega 経験 5 年」という一行からは、この帯の違いがまったく見えないことです。5 年間ずっと保守案件で画面修正だけを担当してきた人と、2 年でも設計フェーズからアーキテクチャ判断を積んできた人では、任せられる仕事が根本的に違います。だからこそ、資格・質問・経歴書という 3 つの手掛かりを組み合わせて帯を特定する必要があります。
資格の読み方：CSA・CSSA・LSA
Pega には公式の認定資格体系があり、実力の帯を推定する第一の手掛かりになります（正式名称は Certified Pega System Architect のように “Pega” を冠しますが、本稿では通称の CSA/CSSA/LSA で表記します）。ただし「読み方」を間違えると誤判定します。
| 資格 | 位置づけ | 採用側の読み方 |
|---|---|---|
| CSA (Certified System Architect) | 基礎知識の証明。認定パスの最初のレベル | 「Pega の概念を知っている」であって「作れる」ではない。エントリーの足切りに使う |
| CSSA (Certified Senior System Architect) | 独力でアプリケーションを構築できる目安。CSA 保有が受験の前提 | 実装の中核メンバー候補。ただし設計責任者級とはまだ言えない |
| LSA (Lead System Architect) | 設計責任者級。CSSA 保有が前提で、筆記（Architecture 試験）に加え、実際にアプリケーションを設計・構築する実技（Application Design & Build）の 2 段階からなる難関 | アーキテクチャ判断を任せられる可能性が高い。国内保有者は少ない |
読み方のポイントは 3 つあります。
- CSA は「知っている」の証明であって「できる」の証明ではない。 Pega Academy 自身が CSA を「アプリケーション開発知識のベースライン測定」と位置づけています。CSA 保有＝即戦力と読むのは誤りです。
- CSSA が「独力で構築できる」の目安ライン。 公式の定義では「複数の業務ラインにまたがる再利用を見据えて設計・構築する能力」を認定するもので、実装チームの中核を任せる最低ラインとして機能します。
- 取得年とバージョンを必ず見る。 Pega の資格試験は受験時のプラットフォームバージョンに紐づいて提供されます（本稿執筆時点の現行試験は Infinity ‘25 版）。取得が古い場合、たとえば UI が Constellation 世代に移行した現在のベストプラクティスを追えているかは別途確認が必要です。「LSA 保有、ただし取得は数世代前で以後は保守のみ」というケースもあります。
そして最も重要なのは、資格は帯の「目安」でしかないことです。資格試験は模範解答のある世界ですが、実案件の設計判断には正解がありません。有資格者でも当たり外れがあるのはこのためで、最終的な見極めは次の「判断系の質問」で行います。
面談での見極め質問：正解のない「判断系」を聞く
知識クイズ（「Data Page のスコープの種類は？」のような質問）は暗記で答えられるため、帯の判定にはほとんど役立ちません。実力を露呈させるのは、正解が一つに定まらない設計判断の質問です。実際に使える質問を 2 つ挙げます。
質問例1：「ケースとデータの分け方を、どう判断していますか？」
Pega 設計で最初に直面する分岐であり、回答にその人の設計観がそのまま表れます。
- 良い回答の例 — 「独立したライフサイクルを持つか、割当・承認・SLA といった進行管理が要るかで判断する。大量・短命なものはケースにせずデータで持つ」のように、自分の判断軸を具体例つきで言語化できる
- 要注意の回答 — 「業務上重要なものをケースにする」「前の案件のやり方に従っていた」など、判断を他人に委ねてきたことがうかがえる回答
この質問の詳しい論点は ケースとデータインスタンスの使い分け で解説しているとおり、経験者なら必ず一度は悩んでいるはずのテーマです。悩んだ形跡が語れない人は、設計フェーズを経験していない可能性が高いと判断できます。
質問例2：「作り込みすぎを防ぐために、何をしていますか？」
Pega 導入の代表的な失敗が、標準機能で足りるところをカスタム実装で塗り固め、アップグレードを困難にするパターンです。これを防ぐ習慣があるかを問います。
- 良い回答の例 — 「まず標準機能でどこまで実現できるかを確認し、要件側を標準に寄せる交渉をする」「カスタム実装には理由の文書化とレビューを必須にする」など、標準優先の規律と、それをチームに効かせる仕組みを語れる
- 要注意の回答 — 「要件どおりに作る」。要件を無批判に実装する姿勢は、ローコード基盤では負債製造機になりかねません
どちらの質問も、深掘りとして「実際にその判断で失敗した経験は？」まで聞くと効果的です。判断系の質問に失敗談で答えられる人は、実際にその判断の責任を負った経験がある人です。
経歴書のチェックポイント
面談の前段として、経歴書では次の 3 点を確認します。
- 担当フェーズ — 要件定義・設計・実装のどこを担当したか。「実装のみ」が続く経歴なら、設計判断の経験は面談で慎重に確認する必要があります
- チーム内の役割 — 何名体制のどのポジションだったか。10 名チームの 1 メンバーと、3 名チームの設計リードでは、同じ「参画」でも経験の質が違います。「設計をしたのは誰か」を面談で具体的に聞ける材料になります
- Constellation 経験の有無 — Pega の UI アーキテクチャは、従来のセクションベース UI（Theme-Cosmos 世代）から Constellation へ世代交代が進んでいます。新規案件で人材を探すなら、Constellation（および DX API 前提の設計）の経験有無は明示的に確認すべき項目です。両者の違いは Constellation UI と Cosmos の比較記事 で詳しく解説しています
よくある失敗
採用・面談側のよくある失敗も、パターンは決まっています。
- 資格と年数だけで決める — 「CSA 保有・経験 3 年」という文面で即決し、参画後に「画面設定しか経験がなかった」と判明するパターン。資格は帯の目安、年数は帯を示さない、という原則に戻るべきケースです
- 知識クイズしか聞かない — 用語の定義を答えられても設計はできません。判断系の質問を最低 1 つは入れるべきです
- 有識者不在のまま面談する — 判断系の質問は、回答の良し悪しを評価できる人が聞いて初めて機能します。自社に Pega 有識者がいない状態で面談しても、流暢に話せる人を選んでしまうだけになりがちです
3 つ目は構造的な問題で、Pega 案件の立ち上げ期には特に起こりがちです。この場合は、面談への外部有識者の同席や、候補者評価の外部レビューという選択肢があります。当社でも、LSA 保有者による採用面談の同席・技術評価のセカンドオピニオンをご支援しています。社内に評価者が育つまでの期間だけ外部の目を借りる、という使い方が現実的です。
まとめ
- 「Pega 歴 N 年」では実力は測れない。 実力は「画面・フロー設定」「データモデル・連携設計」「全体アーキテクチャ（LSA 圏）」の 3 つの帯で捉える
- 資格は帯の目安。 CSA＝基礎知識、CSSA＝独力構築の目安、LSA＝設計責任者級。取得年とバージョンまで読む
- 見極めの本命は判断系の質問。 「ケースとデータの分け方」「作り込みすぎの防ぎ方」——正解のない問いへの答え方に実力が出る
- 経歴書は担当フェーズ・役割・Constellation 経験を見る
- 評価できる人がいないなら外部の目を借りる。 有識者不在の面談は機能しない
Pega プロジェクトの成否は、初期の設計判断を誰が下すかでほぼ決まります。人材の見極めはその最初の一手です。
Pega 人材の採用・体制構築でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA を保有するコンサルタントが、面談同席・技術評価から設計支援までご支援します。
関連リンク
関連記事
Pega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読むPega プロジェクトが失敗する7つの典型パターンと回避策
Pega プロジェクトの典型的な失敗パターン7つ(現行踏襲・作り込み過多・体制空洞化など)と、それぞれの回避策を実例の教訓から率直に解説します。
記事を読むPega エンジニアのキャリア論｜希少スキルの市場価値と成長戦略
Pega エンジニアのキャリアパスを現役 LSA が解説。市場での希少性・キャリアの入り方・資格ラダー・LSA までの成長戦略を整理します。
記事を読む