SAPプロジェクトスコープテンプレート：定義すべきこと、除外すべきこと

SAPプロジェクトスコープテンプレートは、プログラムが何を提供し、あえて何を提供しないのか、各部分を誰が担うのか、そしてスコープをどう変更できるのかを定めるものです。下の9つのセクションでそのすべてを押さえます。最も重要な2つは、チームが飛ばしがちな部分、つまり除外事項の明記とデータ移行のスコープです。コンフィギュレーションが始まる前にテンプレートを埋め、スポンサーとプロセスオーナーの署名をもらってください。

スコープテンプレートを埋めて、それで終わりにしてしまうチームがあります。この段階は簡単に感じられます。数週間後、設計や構築の最中に、誰かが「対象範囲に含まれると思い込んでいた」プロセスを指摘します。話し合いは気まずくなります。誰も書き残していません。誰も意図的に外したわけではありません。こうした場面を、私は何度も見てきました。最初に確認されなかった前提がいくつかあるだけで、プロジェクトは静かに数週間ずれていきます。

スコープ文書の役割は、会議室で語られたことを記録することではありません。コンフィギュレーションが、あとで覆すと高くつく前提を固めてしまう前に、はっきりさせることです。

9つのセクションと、それぞれが答えるべきことを示します。

1. 目的

なぜこの取り組みを行うのか、完了したときに事業部門には何が見えるのか。各目的を測定可能な成果に結び付けます。月次決算を3日短縮する、3つの法人にまたがる手作業の照合をなくす、全プラントの在庫を一つの画面で把握する、といったものです。目的があいまいだと成功基準もあいまいになり、その食い違いはユーザー受入テスト（UAT）で表面化します。

2. スコープ定義

モジュール、法人、プラント、国、言語、連携、そして導入形態。具体的に書きます。「財務」はスコープではありません。「S/4HANA Cloud Private EditionにおけるUAEの法人向けに、買掛金管理、売掛金管理、総勘定元帳、原価センタ会計を対象とする財務会計・管理会計（FI/CO）」ならスコープです。

3. 除外事項

ほとんどのスコープテンプレートが失敗するのは、ここです。除外と書かれていないものは、誰かが含まれていると思い込みます。名前を挙げて書き残すべき除外事項は次のとおりです。

1. 後のフェーズに先送りする国または法人。
2. 当面は現状のまま残すレガシーの連携。
3. 定められたカットオフ日より前の履歴データ。
4. 本稼働後の機能強化リストに回すレポート。
5. 法的確認が出るまで先送りする規制要件。

各除外事項には、移行先のフェーズがあればそれも書き添えます。署名された除外事項があれば、2週間続くはずの議論が短い会話で済みます。

4. データ移行のスコープ

いつも死角になる部分です。次の3つの問いに、書面で答えます。

1. 何を移すのか。 未決済項目だけか、履歴も含めるのか。顧客と仕入先は全件か、稼働中のものだけか。品目は全プラント分か、本稼働する法人の分だけか。
2. カットオフのルールは何か。 未処理の購買発注、受注、作業指図の基準日と、カットオーバー時点で処理中の項目をどう扱うか。
3. 代わりにアーカイブするものは何か。 履歴に対する法定保存のルールと、レガシーシステムをどれだけの期間、参照できる状態に保つか。

ここで文書化されないまま残った前提は、構築中に争いの種になります。計画については、私の記事SAPのデータ移行が失敗する理由と対処法で詳しく解説しています。

5. 非機能のスコープ

計画段階で抜け落ち、テストの終盤になって障害として表面化します。次をスコープに入れてください。

1. 可用性とメンテナンス時間帯。RISEの場合は、契約の可用性条件を参照します。
2. ピーク時の負荷での性能。月次決算などです。
3. 監査ログ。対象とするトランザクションと、ログの保存期間です。
4. ロール別のセキュリティとアクセス制御。
5. レポーティングの遅延。リアルタイム、ニアリアルタイム、日次のいずれかです。

これらは機能ではありません。システムが満たすべき制約です。スコープに入っていなければ、誰もそれを前提に設計しません。

6. 役割と責任

すべてのワークストリームに、コンサルタント側のリードと、意思決定権限を持つ業務側のカウンターパートを置き、どちらも名前を明記します。私が最もよく目にする抜けは、UATの責任者です。プロセスのテストと受入が済んだと承認できるのは誰か。それを本稼働の2週間前ではなく、構築が始まる前に決めてください。

7. 変更管理

「変更には正式な承認が必要」と書くだけでは足りません。具体的なプロセスです。何が変更要求のきっかけになるのか、納期と予算への影響を誰が評価するのか、誰が承認するのか、何を記録するのか。これがないと、「これを追加できますか」が「含まれていると思っていました」に変わり、やがて誰も計画していなかった3週間の延長になります。

8. 拡張ルール

カスタム開発をどう承認するか。SAPは現在、拡張をレベルAからレベルDまで分類しています。レベルAはリリース済みAPIのみ、レベルDはコアの修正です（SAP News、2025年8月）。GROW with SAPで利用するPublic Editionでは、システムがリリース済みインターフェースしか許しません。RISE with SAPで利用するPrivate Editionやオンプレミスでは、コアを修正することが依然としてできるため、スコープには目標とするレベルと、例外を承認する人を明記してください。レベルについては、私のクリーンコアのガイドで解説しています。

9. 前提と制約

スコープの背後にある前提を列挙し、誰かが確認せざるを得ないようにします。次に制約を挙げます。本稼働日を決めてしまう規制上の期限、予算の上限、兼務でしか参加できない人員、レガシーシステムの廃止日です。

カスタマイズは、スコープクリープの中でも表に出るのが最も遅い形です。承認したカスタムレポート1本が5本になります。ワークフローの例外1件が、以後のすべての要望の前例になります。

何かを承認する前に、すべての要望を分類してください。

区分	判断基準	対応
必須	法的または業務上、これがなければプロセスが成り立たない	承認する。ただし、アップグレードに影響しない最も低コストの拡張方法で
重要だが致命的ではない	効率は上がるが、なくても業務が止まるわけではない	費用対効果が明確な場合に限って承認する
不要	好みであるか、レガシーシステムのやり方をそのまま写したもの	異議を唱え、却下するか先送りする

不要なカスタマイズの大半は、SAPがそのプロセスに対応できないからではなく、誰かが自分の仕事のやり方を変えたくなかったために存在します。しかも、構築コストは出発点にすぎません。カスタムオブジェクトは一つ増えるたびに、存続するかぎり、テスト、トレーニング、ドキュメント、アップグレードの作業を増やします。

チェンジフリーズを設定します。 日付を決めます。通常は本稼働の4〜6週間前で、それ以降はそのリリースに対する新規要望を受け付けません。後から出たものはすべて、本稼働後のバックログに回します。フリーズには、ステアリングコミッティの署名という裏付けが必要です。プロジェクトマネージャーが告知しただけの日付は、部門長が最初に押してきた時点で覆されます。

1. 01要望の提起何を変更とみなすかは最初に定義しておく
2. 02分類必須、重要、不要のいずれか
3. 03影響の評価納期と予算について、指名された評価者が評価する
4. 04判断指名された承認者が承認、却下、先送りのいずれかを決める
5. 05スコープの版管理新しい版番号と変更点の一覧

チェンジフリーズ後の新規要望は、本稼働後のバックログに回す

アナリティクスは、スコープの議論が白熱する領域です。誰もがレポートを求め、誰も本数を口にしません。

設計の段階で、レポートの一覧を固定します。必要なものを尋ね、欲しいかもしれないものは尋ねません。各レポートを、SAP標準の出力かカスタム開発かに分類し、その一覧をスコープの他の部分と一緒に署名してもらいます。標準レポートのコストは、カスタムのほんの一部です。同時に、各レポートのデータソースを特定します。3つのシステムからデータを取得するレポートは、連携の要件です。ダッシュボードや計画がスコープに入っている場合は、最初に決めておくべきことを、私のSAP Analytics Cloudのガイドで解説しています。

ミス	引き起こすこと	避け方
目的が測定可能でない	「動いている」の意味をめぐるUATでの対立	最初に測定可能な成果を設定する
除外事項が書かれていない	承認なしに作業が吸収される	スコープ外のものを名前で列挙する
データ移行のスコープがあいまい	量の読み違い、カットオーバーの遅れ、手戻り	移行対象、カットオフ、アーカイブを定義する
非機能要件の欠落	本稼働時の監査と性能の問題	可用性、性能、ログ、セキュリティをスコープに入れる
UATの責任者が未指名	テストが長引き、誰も承認できない	権限を持つ個人を指名する
変更管理がない	非公式な追加、圧縮されるテスト	変更プロセスをスコープに書き込む
署名がない	後からスコープが争われても責任の所在がない	スポンサーとプロセスオーナーが署名する
アナリティクスを後回しにする	本稼働の2週間前にレポート要望が出る	設計中にレポート一覧に合意する
導入形態や拡張ルールが未確定	議論が構築フェーズまで持ち越される	スコープに署名する前に両方を決める

スコープは、SAP Activateのフェーズゲートごとと、承認された変更のたびに見直し、版番号と変更点の一覧を付けます。スコープは参照のかたちでプロジェクト憲章にも含め、2つの文書が同じ内容を語るようにします。

SAPプロジェクトスコープテンプレートには何を含めるべきですか？

9つのセクションです。測定可能な成果を伴う目的、スコープ定義（モジュール、法人、国、連携、導入形態）、明示的な除外事項、データ移行のスコープ、非機能要件、名前を挙げた役割、変更管理、拡張ルール、そして前提と制約です。最も欠けやすいのは除外事項のセクションです。

SAPプロジェクトでスコープクリープを防ぐには？

除外事項を明示的に書き、すべての変更を影響評価と指名された承認者を伴う正式な要求に通し、承認する前にカスタマイズを分類し、本稼働の4〜6週間前に署名付きのチェンジフリーズを設定します。目的は、すべての変更を拒むことではありません。変更を可視化し、評価し、承認を経たものにすることです。

SAPプロジェクトにおけるデータ移行のスコープとは？

どのデータをどのルールでSAPに移すかの定義です。対象のオブジェクト（顧客、仕入先、品目、未処理の発注、履歴）、カットオフ日、そして移行せずにアーカイブするものを含みます。工数とスケジュールを左右し、レガシーシステムをどれだけの期間アクセス可能にしておく必要があるかも決まります。

SAPプロジェクトにおける非機能スコープとは？

システムが支援するプロセスではなく、システムが満たすべき制約です。可用性、ピーク時の負荷での性能、監査ログ、セキュリティとアクセス制御、レポーティングの遅延が含まれます。スコープから外されがちで、テストになって初めて見つかります。規制のある業界では、監査ログは法的な義務です。

スコープの中でカスタマイズはどう扱うべきですか？

要望ごとに、必須、重要、不要のいずれかに分類します。承認したものについては、要件、標準SAPでは満たせない理由、工数、テストへの影響、保守コスト、拡張の方法を記録します。Private Editionとオンプレミスでは、目標とするクリーンコアのレベルと、例外を承認する人を明記します。

SAPプロジェクトのスコープはいつ見直すべきですか？

SAP Activateの各フェーズゲート、承認された変更要求のたび、そして予算、リソース、スケジュールが変わったときです。すべての版を、日付、版番号、変更点の要約とともに保管します。その履歴は、後からスコープが争われたときにチームを守ります。