SAPプロジェクトのリソース配分計画

SAPプロジェクトのリソース配分計画とは、どの役割が、SAP Activateのどのフェーズで、週に何時間必要かを決め、そのうえで現実が計画に合っているかを毎週確認することです。一律の人数ではなく、役割単位で配置します。計画はフェーズごとの負荷曲線に合わせます。探索（Explore）では機能コンサルタント、実現（Realize）では技術系、展開（Deploy）ではデータ、Basis、チェンジマネジメントです。稼働できる時間は、ラインマネージャーから書面で確認します。このガイドは、S/4HANAのリソース計画を作る、あるいは立て直すプログラムディレクター、PMO、CIOに向けたものです。以下のFTEの表と日額単価のレンジは、出発点の目安として使ってください。

私は数十件の導入が、同じリソースの問題で苦労するのを見てきました。計画は、実行が始まった途端に消えてしまう安定を前提にしているのです。

以前、セキュリティリードが続けて休暇と研修に入ることに誰も気づかず、チームが丸1週間を失ったのを見たことがあります。共有もされず、追跡もされておらず、重要なシステムアクセスのレビューが9日遅れました。

SAPの計画の多くは、きれいな見積、フルタイムでの稼働、予測どおりのワークフローを前提にしています。そんな世界は、実現（Realize）の最初の1か月を持ちこたえることはまずありません。

私は3つのことを軸に計画します。作業が実際に必要とするもの、確保できる人が実際に出せる成果、そして現実が計画と違ったときに何が変わるか、です。持ちこたえる計画は、6つの観点を押さえています。

1. Activateのフェーズごと、役割ごとの人数。一律の配分ではありません。探索と実現はまったく別物です。
2. ラインマネージャーが確認した週あたりの時間。想定ではなく、書面で。
3. 1人あたりの同時担当。100%と記載されていても、本番サポートも兼務している人が出せる成果は、はるかに小さくなります。
4. クリティカルパス上のすべての役割のバックアップ。18か月のプログラムで、クロストレーニングは任意ではありません。
5. ストリーム間の依存関係。それぞれに担当者名、期日、エスカレーション経路を設け、遅れた日に見えるようにします。
6. 更新の頻度。実行フェーズでは毎週。キックオフ時点の計画は、バージョン1にすぎません。

計画がうまくいかなくなるのは、計画者が汎用的なITの役割を使うときです。SAPには、機能面でも技術面でも、固有の専門性が必要です。S/4HANAプログラムの標準的な構成はこうです。

プログラムのリーダーシップ：プログラムマネージャー、PMOリード、ソリューションアーキテクト。アーキテクトは、モジュール間の設計の一貫性に責任を持ちます。

機能コンサルタント：スコープ内のモジュールごとに1人のリード。財務会計（FI）、管理会計（CO）、資材管理（MM）、販売管理（SD）、生産計画（PP）、拡張倉庫管理（EWM）、さらにスコープに含まれる場合は人事管理（HCM）、プラントメンテナンス（PM）、プロジェクトシステム（PS）。従来型の倉庫管理（WM）をまだ使っている場合は、移行を計画してください。S/4HANAオンプレミスでのコンパチビリティパックの使用権は、2025年末で終了しました。

技術コンサルタント：レポート、インターフェース、変換、拡張、フォーム、ワークフロー（RICEFW）を担当するABAP開発者と、公開API上またはSAP BTP上のクリーンコア拡張を担当するABAP開発者。SAP Integration Suite（Cloud Integration、旧CPI）、まだ稼働している場合はSAP Process Orchestration、そしてサードパーティのミドルウェアを担当する連携スペシャリスト。

プラットフォーム：HANA、カーネルパッチ、トランスポート、システムコピー、パフォーマンスチューニングを担当するBasisコンサルタント。ロール設計、職務分掌の分析、スコープに含まれる場合はSAP GRC Access Controlを担当するセキュリティコンサルタント。

データ：SAP S/4HANA Migration Cockpitの「Migrate Your Data」アプリ（旧来のLTMCトランザクションは非推奨）、カスタムオブジェクト向けのMigration Object Modeler、複雑な変換向けのSAP Data Servicesを使う移行スペシャリスト。SAPのデータ移行が失敗する理由を解説した私のガイドで、このチームが多くの計画が見込むよりも早く始動すべき理由を説明しています。

チェンジ：チェンジリード、トレーニングリード、ビジネスレディネスのオーナー。必要性が見えてくるのが展開（Deploy）になってからのため、たいてい人員が不足します。

クライアント側：主要モジュールごとに1人のビジネスアナリスト、プロセスドメインごとに1人のプロセスオーナー、UATのために業務部門から選ばれたテスター。

これらを入れ替え可能な枠として扱うのが、最もよくある計画上のミスです。シニアのFIコンサルタントにSDの設計セッションは回せません。ジュニアのABAP開発者に連携のアーキテクチャは設計できません。役割ごとの責任については、SAP導入チームに欠かせない役割の一覧をご覧ください。

リソースの需要は一定ではありません。Activateのフェーズごとに予測可能な曲線が生まれ、一律の配分ではそれを捉えられません。

準備（Prepare）：通常は1〜4週目。負荷は軽めです。プログラムマネージャー、アーキテクト、スコープ確認のための各モジュールのリード。ビジネスユーザーがスコープを確認します。Basisとセキュリティが環境の構築を始めます。

探索（Explore）：通常は2〜5か月目。機能コンサルタントとビジネスユーザーの負荷が高く、設計ワークショップがスケジュールを決めます。設計上の決定が固まるまで、ABAPと連携は軽めです。Basisはサンドボックスと品質保証システムを用意します。

実現（Realize）：通常は5〜12か月目。技術系の負荷が高く、コンフィグレーション、構築、単体テストと結合テストを行います。ABAPの負荷がピークを迎えます。ビジネスユーザーがテストサイクルに加わります。データチームは移行オブジェクトを構築し、ドライランを実施します。

展開（Deploy）：通常は12〜14か月目。データ移行、Basis、セキュリティ、チェンジ、トレーニングの負荷が高くなります。UATがビジネス側の稼働を消費します。カットオーバーのリハーサルには、同じ場所に集まったチームが必要です。ハイパーケアの計画が始まります。

運用（Run）：14か月目以降。ハイパーケアは通常30〜90日。中核チームは少人数で、サポートの体制は手厚くします。Basisとアプリケーション運用保守の体制が立ち上がり、コンサルタントは縮小していきます。

これらを均等な需要の時期として扱うと、準備に人を割きすぎ、実現で人が足りなくなり、展開でデータ移行が手薄になります。フェーズごとの曲線は、計画のなかで最も重要な形です。

1. 準備約11 FTE1〜4週目。リードが範囲を固め、Basisが環境を用意
2. 探索約36 FTE2〜5か月目。機能コンサルタントとビジネスユーザー
3. 実現約56 FTE、ピーク5〜12か月目。構築が進み、ABAPの負荷がピーク
4. 展開約42 FTE12〜14か月目。データ、Basis、セキュリティ、チェンジ
5. 運用約12 FTE14か月目以降。ハイパーケアは通常30〜90日

常に緊急対応に追われる。チームがいつも火消しをしているなら、計画は現実を予測する力を失っています。1人の欠勤でワークストリームが止まるようではいけません。

必要なときにビジネスユーザーがいなくなる。ビジネスユーザーの都合がつかず、設計セッションやUATが止まります。遅延の最も多い原因の1つです。原因はほぼいつも同じです。時間を、正式に確保したのではなく、当て込んでいたのです。コミットメントを正式なものにしていなければ、現場の業務の都合が必ず勝ちます。

技術系の人員が分散しすぎている。ジェラルド・ワインバーグのソフトウェアマネジメントに関する研究では、3つのプロジェクトに分散した人が出せる成果は総能力の約60%で、残りは切り替えで失われると推定されています。米国心理学会によるタスク切り替え研究の要約も、同じ規模の損失を報告しています。タスクを切り替えるときの短い思考の中断が、生産的な時間の最大40%を奪うことがあるというものです。計画上は効率的に見えます。成果物はそうなりません。

クリティカルパスが毎週変わる。絶え間ない組み替え、遅れて始まるワークストリーム、毎週の優先順位の変更は、多くの場合、不明確なスコープか、順序の悪い依存関係に行き着きます。リソース計画を直す前に、スコープを固めてください。

1. 見せかけの稼働可能時間。100%と記載された人が、月次決算と本番サポートも担当している。週に何時間か、ほかに何を担当しているか、ラインマネージャーが書面で確認しているかを尋ねてください。
2. 境界のない共有ロール。1人が、ソリューション設計、テスト、チェンジマネジメントを同時に担う。担当は肩書ではなくタスクで分け、1人が同時に2か所でクリティカルな存在にならないようにします。
3. ビジネスユーザーの時間の欠落。ワークショップが遅れ、UATの承認が数週間余計にかかる。部門長の署名入りで時間を書面で確保し、出席状況を追跡し、パターンが見えたら早めにエスカレーションします。
4. バッファがない。1人の欠勤でワークストリームが止まる。バッファはフェーズ単位だけでなくタスク単位で組み込み、各中核ロールについて少なくとも1人をクロストレーニングします。
5. 更新されない計画。キックオフ時に作って、そのまま見直されない。実行中は毎週レビューし、フェーズゲートに紐づけ、現実が変わったら更新します。

確認済みの稼働可能時間から始める。プロジェクトが始まる前に、ラインマネージャーのところへ行きます。週あたりの時間とほかの担当を確認し、文書にします。プロジェクトの途中で稼働状況が変わったとき、そのベースラインがエスカレーションの根拠になります。

フェーズに合わせて形を作る。ABAP開発者の負荷は、探索と実現で違います。ビジネスユーザーは、設計の探索と、UATの展開でピークになります。一律の配分は、紙の上ではバランスがとれて見えて、現場では破綻します。

依存関係を明示的にマッピングする。データ移行が結合テストに流れ、結合テストがUATに流れ、UATがカットオーバーを左右します。すべての依存関係に担当者、期日、フラグを付け、遅れたらその日のうちに見えるようにします。

ビジネスユーザーの時間は、ステアリングのレベルで守る。彼らの本業は続きます。マネジメントから週あたりの時間について明示的な承認がなければ、業務上のプレッシャーがかかった時点で、プロジェクトから離れていきます。部門長にその時間を求めるのは、プロジェクトマネージャーではなく、スポンサーであるべきです。

計画は毎週更新する。2週間手を付けていない計画は、おそらく間違っています。計画した稼働率と実績を追跡してください。2週続けて120%の人がいるなら、その人が過負荷か、計画が間違っているかのどちらかというサインです。

以下は、出発点の目安として使える、おおよその人数と単価のレンジです。業種、スコープ、地域、パートナーによって変わります。表は見積ではなく、妥当性の確認に使ってください。

ミッドマーケット向けブラウンフィールド（500万〜1,500万ドル、約12か月）

典型的なスコープ：単一の法人または小規模なグループ、3〜4モジュール（通常はFI、CO、MM、SD）、標準プロセス、限定的なカスタム開発。

ワークストリーム	準備	探索	実現	展開	運用
プログラムマネージャー	1	1	1	1	0.5
ソリューションアーキテクト	1	1	1	0.5	0
機能コンサルタント（FI/CO、MM、SDにもう1人）	1	4	4	2	1
ABAPと技術	0	1	3	1	0.5
連携	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
セキュリティと権限	0	0.5	1	1.5	0.5
データ移行	0	1	2	3	0
テストリード	0	0.5	1	1	0
チェンジとトレーニング	0.5	1	1	2	0.5
クライアント側のビジネスアナリスト	1	4	3	2	1
ピーク合計FTE	5	14	20	17	5

エンタープライズ向けブラウンフィールド（3,000万〜8,000万ドル、15〜18か月）

典型的なスコープ：複数のエンティティ、6〜9モジュール、複雑な連携、かなりの規模のカスタム開発、複数の国への展開。

ワークストリーム	準備	探索	実現	展開	運用
プログラムマネージャーとPMO	2	2	3	3	1
ソリューションアーキテクト（リードとモジュール担当）	2	3	3	1.5	0.5
機能コンサルタント（スコープ内の全モジュール）	2	10	12	5	2
ABAPと技術	0	3	8	3	1
連携とミドルウェア	0.5	2	5	2	1
FioriとUI5	0	1	3	1	0.5
Basis	1	1	2	4	2
セキュリティとGRC	0.5	1.5	2	3	1
データ移行	0	2	5	6	0.5
テスト	0.5	1	3	4	0
チェンジとトレーニング	1	2	3	5	1
クライアント側のビジネスアナリスト	2	8	7	5	2
ピーク合計FTE	11	36	56	42	12

役割別・地域別の日額単価（2024〜2025年）

これらはパートナーが請求する、スペシャリスト1人あたりの単価であり、給与ではありません。プログラム全体の加重平均単価は、通常、オンショアのシニア単価より30〜50%低くなります。ほとんどのプログラムが、オンショアのアーキテクトとオフショアのデリバリーを組み合わせるためです。

役割	オンショア（米国/英国/ドイツ）	GCC（UAE/KSA）	ニアショア（中南米/東欧）	オフショア（インド）
ソリューションアーキテクト（シニア）	$2,000〜$3,500	$1,500〜$2,500	$900〜$1,500	$500〜$1,000
機能コンサルタント（シニア）	$1,500〜$2,800	$1,200〜$2,000	$700〜$1,400	$300〜$700
機能コンサルタント（ミドル）	$1,000〜$1,800	$800〜$1,400	$500〜$900	$200〜$500
ABAPと技術（シニア）	$1,400〜$2,500	$1,000〜$1,800	$600〜$1,200	$300〜$700
連携スペシャリスト	$1,500〜$2,800	$1,100〜$1,900	$700〜$1,300	$350〜$800
Basis	$1,400〜$2,200	$1,000〜$1,800	$600〜$1,100	$300〜$700
セキュリティとGRC	$1,500〜$2,500	$1,100〜$1,900	$700〜$1,300	$350〜$800
データ移行	$1,300〜$2,200	$1,000〜$1,700	$600〜$1,100	$300〜$700
チェンジ・トレーニングリード	$1,200〜$2,000	$900〜$1,500	$500〜$1,000	$250〜$600
ジュニアコンサルタント（全職種）	$800〜$1,400	$500〜$900	$400〜$700	$150〜$350

オンショア、ニアショア、オフショアの配分

ほとんどのSAPプログラムは、複数の地域を組み合わせます。これはコストとスピードのトレードオフであり、二者択一ではありません。

米国の民間企業のプログラムは、FTEベースで通常30〜60%がオンショアです。オンショアは、アーキテクチャ、チェンジ、ビジネス分析、シニアの機能系の役割に集中します。ビジネスとの距離が重要な領域だからです。オフショアは、ABAP、連携の構築、データ移行の実行に集中します。仕様を定めやすい仕事だからです。米国連邦政府のプログラムは、作業内容によっては、米国人に限るという制約のもと、全面的にオンショアになることがよくあります。

GCCのプログラムは、通常60〜70%がオンショアです。現地の雇用規則とアラビア語の要件が、その比率を押し上げるためです。オフショアの作業は、時差の重なりから、南アジアの拠点に寄る傾向があります。欧州のプログラムはさまざまです。製造業ではおよそ50%がオンショアのことが多く、公共部門や規制の厳しい業界では、データレジデンシーの理由からさらに高くなります。

よくある間違いは、コストだけで配分を最適化することです。80%がオフショアで、オンショアのアーキテクトが20%のチームは、表計算の上では安く見えます。隠れたコストは、日々の引き継ぎサイクルと、ビジネスの文脈を欠いた設計ワークショップの遅さです。最も安いチームが、最も安いプログラムになることはまれです。パートナーを比較するときは、ティア別のSAP導入パートナーのガイドで、単価とチームの形がパートナーごとにどう違うかを取り上げています。

一度作って見直さない計画は、計画とは呼べません。計画のあらゆる前提は、実行の初週と、その後の毎週に検証する仮説として扱ってください。

SAPプロジェクトのリソース配分計画とは何ですか。なぜ重要ですか？

プロジェクトにどの人が必要で、いつ、その人の時間をどれだけ使うのかを決め、それが現実と合っているかを追跡することです。

SAPプロジェクトは、特定の個人に依存します。勘定科目表を理解しているFI/COのリード、レガシーデータを知っている移行スペシャリスト、現場に人脈を持つチェンジリードなどです。必要なタイミングでその人たちの手が空いていなければ、作業は止まるか、誤った形で進みます。技術的に見える遅延の多くは、実はリソースの問題です。

リソース配分の不備は、どのようにしてSAPプロジェクトの遅延を招きますか？

依存関係を通じてです。コンフィグレーションのリードが、実現フェーズで別のプロジェクトに引き抜かれます。その人の作業が止まり、結合テスト、UAT、カットオーバーの準備が順に遅れます。8週目の2週間の不在が、本稼働までに6週間の遅れに膨らむことがあります。

序盤の小さな穴が、終盤の大きな遅延になります。影響が目に見えるころには、立て直しのコストは、早期に手を打った場合の数倍になっています。

日常業務を持つビジネスユーザーに、SAPプロジェクトへのコミットをどう得ればよいですか？

プロジェクトが始まる前に、ラインマネージャーから書面でのコミットメントを得ます。週あたりの時間、どのフェーズで最も必要か、稼働状況が変わる場合にどんな承認が必要かです。

出席状況を、ほかのリソースと同じように追跡します。低下したら、ステアリングのレベルでエスカレーションしてください。コミットメントを実行させられるのは部門長であり、プロジェクトチームではありません。

プロジェクトの途中でキーパーソンが抜けた場合は、どう対処すればよいですか？

そもそも単一障害点を作らないことです。各クリティカルなワークストリームを、止めずに回せる程度に理解している人が、少なくとももう1人いるようにします。

誰かが抜けるときは、その人の知識をすぐに記録します。文書化されていない決定や、コンフィグレーションの根拠などです。後任を見つけるよりも難しいことがよくあります。補充にあたっては、引き継ぎ資料、録画したセッション、1週間の重複期間が最低限です。

リソースの問題は、いつエスカレーションすべきですか？

居心地が悪いと感じるよりも早くです。名前の挙がった依存関係のオーナーが1週間を超えて不在のとき、ビジネスユーザーがセッションを欠席し続けるとき、技術系のリソースが2週間にわたり稼働率120%を超えているとき、あるいは、先送りされたリソースの決定でワークストリームが止まっているときにエスカレーションしてください。

早すぎるエスカレーションのコストは、気まずい会話です。遅すぎるエスカレーションのコストは、数週間の遅れです。

複数のプロジェクトにまたがって共有されるリソースは、どう扱えばよいですか？

共有されている人は、プレッシャーがかかれば、ほかのものを優先すると考えてください。主たる上長と、週あたりの具体的な時間を合意し、その人に依存する作業にはバッファを組み込み、代替策がない限り、その人をクリティカルパスに載せないでください。

共有されるビジネスユーザーについては、依頼はスポンサーから出さなければなりません。プロジェクトマネージャーが部門長に時間を頼んでも、毎回、業務上の優先事項に負けます。