Pega プロジェクト開始前に発注側が準備すべき10項目チェックリスト

結論から：準備は「体制・意思決定」「業務・データ」「審査・環境」の3領域を、開発着手前から並行で整える

Pega プロジェクトの遅延要因を振り返ると、その多くは Pega の技術的な難しさではなく、開始前の準備不足に行き着きます。開発ベンダーがどれだけ優秀でも、業務を語れる人が捕まらない、決めるべきことが決まらない、環境が出てこない——この状態ではプロジェクトは前に進みません。

結論を先に言うと、発注側が着手前に整えるべきことは 10項目 に集約でき、それらは「体制・意思決定」「業務・データ」「審査・環境」の3領域に分類できます。そして重要なのは、これらを逐次ではなく並行で進めることです。

とくにセキュリティ・法務審査（数週間かかる）と業務有識者の稼働確保は、開発着手のクリティカルパスになりやすい。この2つは契約検討の段階から前倒しで動かすのが鉄則。

本記事では、10項目をそのまま社内展開できるチェックリストとして提示し、つまずきやすい項目を実案件での経験に基づいて深掘りします。

なぜ「開始前の準備」が成否を分けるのか

Pega プロジェクトは、一般的なウォーターフォール開発とは進め方が異なります。Pega がすべての導入案件で推奨する標準の進め方（Pega Express デリバリーアプローチ）は、アジャイル（スクラム）をベースに、短いサイクルで動くアプリケーションを見せながら、業務部門と直接すり合わせて作り込んでいくスタイルです。要件のすり合わせには DCO（Directly Capture Objectives）と呼ばれる、業務と IT が同席して仕様を直接固めるセッションが用いられ、その中核チームには業務側の意思決定者であるプロダクトオーナーが参加することが公式に想定されています。「要件定義書を書いて渡したら、あとは納品を待つ」という関わり方は想定されていません。

この進め方は、要件の誤解を早期に潰せる強力な方法ですが、裏を返せば発注側の関与が最初の週から必要だということです。業務を語れる人がその場にいなければセッションは空転し、決められる人がいなければ論点は持ち帰りの山になります。ウォーターフォールなら「要件定義の遅れ」として後半に表面化する準備不足が、Pega では着手初週から直撃します。

そして、開発チームの体制費用は準備が整うのを待ってくれません。準備不足の1か月は、そのまま1か月分のコストと機会損失になります。だからこそ、開始前に整えるべきことをリスト化し、着手判断の材料にすることに価値があります。

発注側が準備すべき10項目チェックリスト

以下がチェックリストの全体です。社内のキックオフ準備会でこのまま使える形にしてあります。「準備しないと何が起きるか」まで含めて関係者に共有すると、協力を取り付けやすくなります。

#	領域	準備項目	具体的に用意するもの	準備しないと何が起きるか
1	体制	プロダクトオーナーの任命	優先順位と仕様を即断できる担当者1名	都度持ち帰りになり意思決定が遅延する
2	体制	業務有識者の稼働確保	誰が・週何日関与するかを計画に明記	仕様確認が滞留しスプリントが空転する（最頻出）
3	体制	意思決定ルートと期限の取り決め	誰が・何を・何営業日以内に決めるかのルール	論点が塩漬けになり手戻りが増える
4	体制	ステークホルダー合意	関係部門へのスコープ・体制の事前共有	後から要求が噴出しスコープが膨張する
5	業務	対象業務の現状フロー資料	業務フロー図・手順書・帳票サンプル	ヒアリングがゼロベースになり要件整理が長期化する
6	業務	成功指標の定義	処理時間・件数など測定可能な KPI と現状値	完成しても効果を説明できない
7	データ	テストデータとマスタの準備	本番相当の件数・バリエーション（マスキング済み）	結合テスト直前にデータ整備で停滞する
8	データ	接続先システムの仕様と窓口	IF 仕様書・テスト接続の可否・担当窓口	連携設計が「想定」で進み後で作り直しになる
9	環境	環境・アカウントの調達	環境の申請、開発者アカウント・接続経路の手配	着手初週に「入れない・触れない」で空費する
10	環境	セキュリティ・法務審査の前倒し	クラウド利用・データ持ち出しの社内審査を並行開始	審査待ちの数週間がそのまま遅延になる

10項目すべてが均等に重要なわけではありません。経験上、プロジェクトを実際に止めるのは特定の数項目に偏っています。次節でそこを深掘りします。

つまずきやすい3項目を深掘りする

業務有識者の稼働確保 — 最頻出のボトルネック

実案件で最も頻繁にプロジェクトを止めるのは、技術課題ではなく「業務有識者が忙しくて捕まらない」ことです。

これは「あれば助かる協力」の話ではありません。Pega の公式な役割定義でも、業務有識者（SME：Subject Matter Expert）は業務プロセスに深い知見を持つ発注側の代表として、要件の提示や現行業務のウォークスルーを担うことが想定されており、SME の関与は進め方の前提に組み込まれています。

業務有識者は現場のエース級であることが多く、当然ながら本来業務でも多忙です。「〇〇さんに聞いてください」と名前だけアサインされても、質問への回答が2週間返ってこなければ、その間の設計・実装はすべて仮置きになります。仮置きが積み重なった状態でようやくレビューが行われ、前提が違っていたことが判明してまとめて手戻りする——これが典型的な失敗パターンです。

対策はシンプルで、稼働率をプロジェクト計画に数字で明記することです。

• 「週2日（稼働率40%）はプロジェクトに充てる」のように、割合か日数で合意する
• 質問への回答期限（例：2営業日以内）をルール化する
• レビュー会を定例化し、有識者のカレンダーを先に押さえる
• 本人だけでなく上長と合意する（本来業務との優先順位の裁定は上長にしかできません）

「アサインした」と「稼働を確保した」は別物です。ここを曖昧にしたまま着手しないことが、10項目の中で最も費用対効果の高い準備です。

意思決定ルートと期限 — 「誰がいつまでに決めるか」

Pega の役割定義では、プロダクトオーナーは発注側の業務部門を代表し、プロジェクトのスコープ管理と要件の優先順位付けを担うとされています。ただし、プロダクトオーナーを任命しても、すべてをその人が決められるわけではありません。実案件では、論点を2種類に分けておくことが効きます。

• プロダクトオーナーが即断できる論点 — 画面項目の要否、業務ルールの詳細など日々の仕様判断
• エスカレーションが必要な論点 — スコープの増減、部門間の役割分担、予算に関わる判断

前者は「その場で決める」、後者は「何営業日以内に・誰が決めるか」をあらかじめ取り決めておきます。この期限がないと、「持ち帰って検討します」が数週間単位で滞留し、反復型の進め方の利点が失われます。逆にこのルートが機能しているプロジェクトは、多少の課題が出ても推進力が落ちません。

セキュリティ・法務審査 — 並行前倒しが鉄則

見落とされがちで、かつリードタイムが最も長いのがこの項目です。

Pega をクラウドで利用する場合、多くの企業ではクラウドサービス利用の社内審査が必要です。さらに、本番データをテストに使う場合のデータ持ち出し・マスキング方針の審査が加わることもあります。これらは社内規程によっては数週間から1か月以上かかります。

開発着手後に審査を始めると、審査待ちの期間がそのまま遅延になります。環境が使えない、データが投入できない状態で開発チームだけが待機する——コスト面で最も痛いパターンです。

鉄則は「契約検討の段階から、審査部門への情報提供を並行で始める」ことです。利用するクラウドのリージョン・データの所在・セキュリティ認証の取得状況など、審査に必要な情報はベンダー側が提供できます。着手前に「審査は通る見込みか、何週間かかるか」まで見えている状態を作ってください。

よくある失敗

失敗1：「アサインはあるが稼働がない」

前述のとおり最頻出です。体制図に名前は載っているのに、実際には本来業務で手一杯で週1時間も取れない。稼働率が計画に書かれていないプロジェクトは、ほぼ確実にこの状態に陥ります。体制図の名前ではなく、計画書の稼働率の数字を確認してください。

失敗2：審査と環境調達を「始まってから」動かす

キックオフ後にクラウド利用審査を申請し、最初の1か月を審査待ちと環境待ちで消費するパターンです。開発チームは着任しているのでコストは発生し続けます。審査・環境はプロジェクトの中ではなくプロジェクトの前に置くタスクです。

失敗3：接続先システムに話が通っていない

連携する基幹システムやマスタの管理チームに事前の合意がなく、IF 仕様の質問先すらない状態です。連携部分は「たぶんこうだろう」という想定で設計が進み、後で仕様が判明して作り直しになります。接続先ごとに仕様書の所在と担当窓口を開始前に確定させてください。

失敗4：成功指標がなく、完成しても評価できない

「処理時間を何分から何分にしたいのか」「月何件を捌けるようにしたいのか」が定義されないまま完成を迎えると、効果を経営層に説明できず、次フェーズの投資判断も通りません。着手前に測定可能な KPI と現状値を押さえておくことは、プロジェクト自体の継続性を守る準備でもあります。

まとめ

• Pega プロジェクトの遅延要因の多くは技術ではなく開始前の準備不足。Pega Express の反復型の進め方は発注側の関与を最初の週から必要とするため、準備不足が着手直後に直撃する
• 準備すべきは10項目。「体制・意思決定」「業務・データ」「審査・環境」の3領域を逐次ではなく並行で整える
• 最頻出のボトルネックは業務有識者の稼働確保。名前のアサインではなく、稼働率を計画に数字で明記し上長と合意する
• セキュリティ・法務審査は数週間かかる。契約検討の段階から並行前倒しで動かすのが鉄則
• チェックリストは「準備しないと何が起きるか」とセットで社内展開すると、関係部門の協力を取り付けやすい

開始前のわずか数週間の準備が、その後の数か月の進み方を決めます。本記事のチェックリストを、着手判断の材料としてそのままお使いください。

---

これから Pega の導入を検討される場合や、準備段階の進め方にご不安がある場合は、Pega Platform 開発支援 や 無料相談 をご利用ください。実案件の設計・推進を支援してきたコンサルタントが、プロジェクト計画の段階からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Customer Service 導入支援
• Pega 最初の1案件の選び方：灯台プロジェクトの選定基準と失敗回避
• Pega 開発の工数見積もり手法：ケース積み上げとベロシティ換算の使い分け
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• Pega Constellation UI と Cosmos の違いを徹底比較
• 無料相談に申し込む