SAP品質ゲート：設定方法と、失敗する理由

品質ゲートとは、プロジェクトのフェーズ間に置く正式なチェックポイントです。次へ進む前に、合意した基準を満たしていることを示さなければなりません。合格すれば前へ進み、不合格なら、まず問題を直します。SAPプログラムでは、ゲートをSAP Activateのフェーズの切り替わりに置き、それぞれに「まだ準備ができていない」と言える権限を持つ責任者を指名します。

シンガポールの大手消費財メーカーが、SAPをグローバルに展開していました。チームは期限に間に合わせるため、テストを急ぎました。私は、この失敗が進んでいくのを見ていました。ユーザーテストはほとんど行われなかったのに、経営陣はそれでも稼働を押し切りました。数日のうちに問題が表に出ます。設定の抜け、壊れたワークフロー、まったく合っていないデータです。稼働後の数週間に及んだ混乱は、本稼働の前から見えていた問題が原因でした。誰も立ち止まって確認しなかったのです。

私は、品質ゲートのレビューを省略しません。近道もしませんし、形だけの承認もしません。最初に時間はかかりますが、何か月分もの後始末を省けます。

ゲートは、文書化された基準、記録に残る承認、そしてプロジェクトを遅らせる実際の権限を備えた、意思決定の場です。進捗レビューでも、ステアリングコミッティの状況報告でもありません。

その権限がなければ、レビューは形だけの承認になります。そして形だけのゲートは、ないよりも悪いものです。偽りの安心感を生むからです。ある小売のクライアントは、実質的に承認印を押すだけの「レビュー」を行っていました。6か月後、そのレビューで拾うべきだった問題に誰も対処していなかったため、スケジュールは取り返しがつかないほど遅れていました。

SAP Activateには、Discover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズがあります。フェーズの切り替わりは、どれも自然なゲートになります。各ゲートで私が確認する内容は、次のとおりです。

フェーズゲート	品質の焦点	確認すべき証跡	合格の条件
Discover	ビジネスケース、経営陣の合意	ビジネスケース、大まかなロードマップ	ビジネスケースに署名済み、スポンサーがコミット
Prepare	ガバナンス、チーム、リスク	チャーター、ガバナンスモデル、リスク登録簿	チャーターが承認済み、リスクの責任者を指名済み、チームが参画済み
Explore	Fit-to-Standard、設計、連携の方針	ギャップの判断記録、プロセス設計、連携アーキテクチャ	プロセスオーナーが承認済み。すべてのギャップに判断がある
Realize	設定、結合テスト	テスト実施レポート、不具合ログ	テストのしきい値を達成、重大な不具合をクローズ
Deploy	データ、トレーニング、カットオーバーの準備状況	移行データの突合結果、トレーニング記録、カットオーバー計画	ドレスリハーサルを完了、ロールバック計画に合意
Run	安定化と引き渡し	インシデントログ、パフォーマンスレポート	インシデントが合意した範囲内、サポートへの引き渡しに署名済み

実際には、Explore、Realize、Deployの3つがもっともリスクの高いゲートです。この3つのどれかをすり抜けた問題は、本稼働後に表に出たときのコストがもっとも大きくなります。

1. 01Discoverビジネスケースに署名済み、スポンサーがコミット
2. 02Prepareチャーターが承認済み、リスクの責任者を指名済み
3. 03Exploreすべてのギャップに判断がある
4. 04Realizeテストのしきい値を達成、重大な不具合をクローズ
5. 05Deployリハーサルを完了、ロールバックに合意
6. 06Runインシデントが範囲内、引き渡しに署名済み

各ゲートに、「まだ準備ができていない」と言える権限を持つ責任者が一人署名する

設定を始める前に、すべてのゲートの入口基準と出口基準をプロジェクトチャーターに書き込んでください。納期のプレッシャーの下で書いた基準は、プロジェクトに必要なものではなく、チームが今見せられるものを書いてしまいます。あるクライアントは、「時間を節約する」ためにフェーズをまとめようとしました。結果は、数週間分の作業のやり直しでした。

「はい」か「いいえ」で答えが出る基準

「テスト完了」は基準ではありません。議論の火種になります。ある小売のクライアントのゲートには、ただ「UAT完了」と書かれていました。チームの半分は、すべてのテストを実施済みという意味に読み、残りの半分は、すべての不具合を修正済みという意味に読みました。

「テストケースの95%を実施済み、優先度1の不具合はすべて解決済み、5日より古い優先度2の未解決の不具合はなし」は基準です。答えが出ます。

ある製造業のクライアントのゲートは、基準があいまいすぎて機能しませんでした。合格したのかどうか、誰にも分かりませんでした。基準を測定できるしきい値に変えると、フェーズの移行をめぐる議論は止みました。

遅らせる権限を持つ責任者を一人置く

ゲートごとに、プロジェクトを遅らせられる責任者を名指しで決めてください。委員会ではなく、一人です。チームの準備ができていないのに、次のフェーズを止める権限を誰も持たず、頓挫した案件を見たことがあります。

逆の例はうまくいきます。ある小売のクライアントは、上級ディレクターをゲートの責任者に任命しました。彼が「まだ準備ができていない」と言えば、全員が耳を傾けました。その権限を、チャーターに書いてください。

プレッシャーがかかる前に取り付ける、経営陣の後ろ盾

経営陣は、ゲートが納期を脅かすまでは、品質ゲートが大好きです。あるCIOは、四半期目標を達成するために、不合格になったゲートを覆しました。その結果生じた問題のコストは、遅延で済んだ場合の2倍でした。このパターンは何度も繰り返されるのを見てきたので、今ではプロジェクトの開始前に、ゲートの枠組みについて経営陣の承認を求めています。

システム上の記録から取る証跡

ゲートの判断には、証跡が必要です。テスト実施レポート、不具合ログ、プロセスの承認、データ移行の突合結果などです。ツールから取ってください。「終わった」という人の話からではありません。私のクライアントの一社は、Solution Managerのレポートで、「完了」とされたテストケースの40%が、一度も実行されていなかったことを発見しました。ゲートの後ではなく、前に気づけました。

1. ゲートをフェーズの切り替わりに対応づける。 SAP Activateでは、最低でもPrepare、Explore、Realize、Deployの後に置きます。あるエネルギー会社は、その間に無作為なチェックポイントを作り、混乱に陥りました。
2. 設定を始める前に、入口基準と出口基準を定める。 テストのカバレッジ、不具合のしきい値、署名すべきプロセスオーナーを合意します。チャーターに書き込み、スポンサーの署名をもらってください。
3. 余裕を持ってゲートを予定に入れる。 各ゲートは、マイルストーンだけでなく、作業としてカレンダーに入れます。私のある小売のクライアントは、各ゲートの前に、後片付けのためだけに丸1週間を確保していました。
4. 決められる人をレビュアーに選ぶ。 業務リードはプロセスを承認します。技術リードは設定と連携を承認します。コンサルタントが業務側に代わって署名することは、決してありません。
5. 証跡は一か所にまとめる。 6か月後、監査人は、データ移行を誰が承認したのかを尋ねてきます。答えは、数分で見つかるようにしておくべきです。
6. 結果を見えるようにする。 あるクライアントは、ゲートのダッシュボードをプロジェクトルームの壁に掲げました。無視できません。

もっとも重要な二つのゲートの、出口基準の例

Realizeゲート：

1. テストの実施率が、合意したしきい値以上で、結果がテストツールに保存されている。
2. 優先度1の不具合が未解決のまま残っていない。優先度2の不具合は、合意した経過日数の上限内にある。
3. すべての重要なプロセスが、名前の決まったプロセスオーナーに承認されている。
4. 結合テストが、プロセスの流れ全体にわたって実施され、結果が文書化されている。
5. すべてのカスタム開発が、プログラムのクリーンコアのルールセットに照らして承認されている。

Deployゲート：

1. データ移行のドレスリハーサルを完了し、突合の結果にデータリードが署名している。
2. ロール別のトレーニング完了率が、合意したしきい値以上である。
3. カットオーバー計画をリハーサル済みで、所要時間と、本稼働の可否を決める判断ポイントがある。
4. ロールバック計画が文書化され、テスト済みである。
5. ハイパーケアのチームが指名され、エスカレーション経路と重大度の定義が合意されている。

Deployゲートで、突合の未解決の例外や、トレーニングを受けていないユーザーが見つかっても、業務側がなお進めたいのであれば、署名者を明記した、記録に残る判断にしてください。誰も「ノー」と言いたくなかったから、というなりゆきの結果にしてはいけません。

現行のプログラムでは、二つの点が、私のゲートの設計を変えました。

クリーンコアは、ゲートの基準になりました。 SAPは拡張を、レベルA（リリース済みインターフェースのみ）からレベルD（修正と、テーブルへの直接書き込み）まで分類しています。Exploreゲートでは、すべてのギャップに判断があるべきです。設定で対応する、リリース済みAPIによる拡張として作る、あるいは却下する、のいずれかです。Realizeゲートでは、新しいレベルDのオブジェクトが紛れ込んでいないかを確認します。Public Editionは、これを技術的に強制します。Private Editionとオンプレミスは強制しないので、強制するのはゲートです。

SAP Cloud ALMが、標準のツールです。 Enterprise Support付きのSAPクラウドのサブスクリプション（クラウドエディション）と、オンプレミスのお客様向けのSAP Enterprise Supportに含まれています（SAP Support）。Fit-to-Standard、タスクの割り当て、テストのオーケストレーション、トレーサビリティを扱えます。SAP Solution Manager 7.2のメインストリームメンテナンスは2027年末に終了し、SAPはそれまでにCloud ALMへ移行することを推奨しています（SAP Support）。Solution Managerでプログラムの途中にいるなら、そこで完了させてください。新しいプログラムは、Cloud ALMを前提に計画します。

ゲートを管理するツール

ツールよりも、規律のほうが重要です。ある小売のクライアントは、SharePointで無駄のないゲートのプロセスを作り、中規模の導入で見事に機能しました。逆に、Solution Managerを完全に構築していても、チームが並行してスプレッドシートを持ち続けたせいで、ゲートが機能しなかった例も見ています。

ツール	ゲート管理での役割	向いているケース
SAP Cloud ALM	Fit-to-Standard、タスク、テスト、トレーサビリティ	新規のS/4HANAプログラム（クラウド、オンプレミスとも）
SAP Solution Manager 7.2	プロジェクトの追跡、テストと不具合の管理	すでにこれで運用しているプログラム
JiraとConfluence	タスク、不具合、ゲートの基準と証跡	すでにAtlassianのツールを使っているチーム
Tricentis Tosca	テスト自動化とカバレッジのレポート	テスト自動化の比重が大きいプログラム
ServiceNow	承認ワークフローと監査証跡	すでにServiceNowを運用している企業

どれを選ぶにしても、唯一の信頼できる情報源でなければなりません。並行して持つスプレッドシートは、いつも、チームが見せたい版を映します。テストの面については、SAPのテストおよび検証ツールの比較で、さらに掘り下げています。

スケジュールのプレッシャーで飛ばされる。 プロジェクトが遅れると、真っ先に削られるのがゲートです。ある案件では、レビューが形だけの承認になり、本稼働は悪夢でした。システムは落ち、受注は滞り、完全にロールバックしました。「節約した」3週間のせいで、復旧に3か月かかりました。

あいまいな基準。 前述のとおりです。解釈が必要な基準は、会話のきっかけにすぎません。

時間のないレビュアー。 主要なレビュアーが複数のプロジェクトを掛け持ちしていると、レビューはチェックを入れるだけの作業になります。中規模のプログラムのRealizeゲートのレビューには、少なくとも半日を充て、証跡は事前に読んでおくべきです。

文化。 マイルストーンを急ぐことに慣れたチームは、ゲートを回避する方法を探します。キックオフで経営陣がゲートは必須だと宣言し、最初に遅延を招いたゲートを覆すことを拒んで、それを証明すれば、状況は変わります。

ゲートが機能しているかを示す三つの数字

ゲートがプロジェクトを守っているのか、守っているように見えるだけなのか、次の数字で確認してください。

1. 不具合の流出： ゲートを通過した後に見つかった不具合のうち、ゲートが捕捉すべきだったものの割合。
2. 初回合格率： すべてのゲートが初回で通るなら、おそらく基準に実効性がありません。
3. 本稼働後のインシデント： 最初の30日間の高優先度のインシデントは、Deployゲートに対する直接の評価です。

ゲートは、初日からチャーターに入れるものです。どこに入れるかはプロジェクトチャーターのガイドで、強制する権限を誰が持つべきかはステアリングコミッティのガイドで解説しています。

SAPプロジェクトにおける品質ゲートとは何ですか？

プロジェクトのフェーズ間にある、正式なチェックポイントです。次へ進む前に、具体的で測定できる基準を満たしていることを、チームが示さなければなりません。各ゲートには、プロジェクトを遅らせる権限を持つ責任者がいます。SAP Activateでは、ゲートはフェーズの切り替わり、とりわけExplore、Realize、Deployの後に置きます。

SAP Activateの品質ゲートには何がありますか？

SAP Activateには、Discover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズがあり、それぞれの切り替わりがゲートです。Discoverではビジネスケースを確認します。Prepareではガバナンスとチャーターを確認します。Exploreでは、設計の承認とギャップの判断を確認します。Realizeでは、テスト結果と不具合を確認します。Deployでは、データ、トレーニング、カットオーバーの準備状況を確認します。Runでは、安定化と引き渡しを確認します。

SAPの品質ゲートの基準には、何を含めるべきですか？

「はい」か「いいえ」で答えが出る基準です。Realizeでは、テストの実施率のしきい値、優先度別の未解決の不具合、プロセスオーナーの承認、結合テストの結果です。Deployでは、移行データの突合、ロール別のトレーニング完了率、リハーサル済みのカットオーバー計画、テスト済みのロールバック計画、人員の揃ったハイパーケアのチームです。それぞれの基準には、証跡を出す責任者が必要です。

SAP導入で品質ゲートが失敗するのはなぜですか？

スケジュールのプレッシャーで飛ばされる、基準があいまい、レビュアーが準備する時間を取れない、あるいは不合格になったゲートを経営陣が覆す、といった理由です。根本の原因は、ゲートを保護ではなく、手間として扱っていることにあります。

SAPの品質ゲートの管理には、どのツールを使うべきですか？

新しいプログラムなら、SAP Cloud ALMです。SAPクラウドのサブスクリプションとEnterprise Supportに含まれており、Fit-to-Standard、テスト、トレーサビリティに対応します。SAP Solution Manager 7.2は、2027年末にメインストリームメンテナンスが終了します。Jira、Tricentis Tosca、ServiceNowは、すでに会社で運用している場合にうまく機能します。ルールは、唯一の信頼できる情報源を持つことです。

最後の品質ゲートで、本稼働の準備状況をどう評価しますか？

証跡とともに、5つの点を確認します。データ移行をリハーサルし突合済みであること、ロールごとにトレーニングが完了していること、go/no-goの判断ポイントを含めてカットオーバー計画をリハーサル済みであること、ロールバック計画がテスト済みであること、そしてエスカレーション経路を含めてハイパーケアの人員が揃っていることです。どれか一つでも満たさず、それでも業務側が進めたいのであれば、署名の入った業務上の判断として記録します。