SAPコンサルタントを業務委託で確保する方法｜単価相場と契約設計

経営会議で「基幹システムの移行方針」が承認され、期日と概算予算だけが先に決まりました。既存の SIer に提案を依頼したところ、返ってきた回答は「要員のアサインは半年先」「単価は想定の 1.5 倍」で、稟議に載せられる金額にはとても収まりません。社内の SAP 有識者は 1〜2 名しかおらず、そのうち 1 名は定年が見えています。SAP コンサルタントの業務委託を調べ始める発注担当者の多くが、こうした行き止まりから検索を始めます。

ところが「SAPコンサルタント 業務委託」「SAPコンサルタント 単価相場」で検索して出てくる記事のほとんどは、SAP 経験者が独立して単価を上げるための情報です。「月 150 万円の案件がある」と書かれていても、それは受け取る側から見た金額であって、発注側が「その金額を払う妥当性」を社内で説明するための材料にはなりません。役割ごとの内訳も、契約上のリスクも、外部人材が抜けた後にどうなるかも書かれていないからです。

発注側が本当に困っているのは、単価の数字そのものではありません。「その金額が妥当だと社内に説明できないこと」「準委任で日々の相談をしたら偽装請負にならないかが分からないこと」「契約が終わった後に社内へ何も残らないのではないかという不安」の 3 つが同時に押し寄せ、結果として調達計画そのものが書けなくなっている状態です。しかも SAP の保守期限は交渉で動かせません。判断を先送りするほど、市場の需給は締まっていきます。

この 3 つは、順番を決めれば解けます。先に「業務委託で埋めるロール」と「社内に残すロール」を切り分け、次にロールごとの単価レンジを積み上げ、最後に契約と引き継ぎの条項でリスクを閉じていきます。この順序で決めていけば、SAP の技術実装に詳しくない発注担当者でも、稟議に載せられる調達計画を自力で組み立てられます。

本記事では、保守期限が生む需給構造の説明から始め、役割・モジュール・フェーズ・商流の 4 軸で見た単価相場、SIer 一括発注と直接調達の比較、外部化してよいロールの切り分け、確保までの 5 ステップ、準委任契約での法務チェックポイント、そして撤収後も知見を社内に残す運用設計までを、発注企業の判断材料として順に解説します。

SAPコンサルタントの業務委託需要が高まっている背景と、発注側が置かれている状況

SAP コンサルタントの業務委託市場がこれほど逼迫している理由は、個々の企業の採用力や交渉力の問題ではありません。「同じ期限に向かって、全ユーザー企業が同時に動く」という構造そのものが原因です。まずはこの構造を押さえておくと、社内での説明が格段にしやすくなります。

SAPの保守期限が生む「同時期に移行が集中する」構造

SAP ERP 6.0（いわゆる ECC）のメインストリームメンテナンス（標準保守）は、2027 年末に期限を迎えます。当初は 2025 年末が期限とされていましたが、2020 年に 2 年間延長されて現在の期限になりました。さらに、拡張パッケージ EhP6 以上を適用しているユーザーは、2028 年以降に保守基準料金へ 2% を上乗せする延長保守を選択でき、その期限が2030 年末です（SAPの2027年問題とは？移行の注意点を解説｜NECソリューションイノベータ）。

ここで重要なのは、この 2 つの期限が交渉で動かせない外部要因だという点です。自社の予算編成や人員計画の都合とは無関係に、期日が先に確定しています。そして同じ期限を抱えたユーザー企業が国内に数百社単位で存在します。

移行の進捗も、余裕のある水準とは言えません。電通国際情報サービス（ISID）が 2023 年 9 月から 11 月にかけて実施した SAP ユーザー調査（有効回答 262 社、うち ECC6.0 ユーザー 190 社・S/4HANA ユーザー 72 社）では、S/4HANA ユーザーの比率は 2022 年調査の 16.3% から 27.5% へ増加したものの、依然として ECC6.0 ユーザーが多数派でした。移行方式は現行アドオンを引き継ぐ「コンバージョン」が最多で 32.3%、次いで「第三者保守サービスに移管して ECC6.0 を継続利用」が 17.5% という結果です（S/4HANAへの移行はコンバージョンが最多｜IT Leaders）。

つまり、期限が固定されているにもかかわらず、着手していない企業がまだ相当数残っているという状態です。この残存分が期限に向かって一斉に動き出せば、要員の需要は短期間に跳ね上がります。

なお、SAP の移行判断そのものを検討している段階であれば、基幹システムの刷新をどう進めるかという上位の論点から整理したほうが早いケースもあります。判断の枠組みはレガシーシステム刷新の記事でも整理しています。

SAP人材不足はなぜ解消しないのか

SAP 人材不足が慢性化する理由は、需要側と供給側の時間軸が噛み合っていないことにあります。

供給側の育成リードタイムが長いことが第一の要因です。SAP コンサルタントは、SAP という製品知識だけでは務まりません。会計・生産管理・購買・販売といった業務そのものの知識と、SAP 標準機能への当てはめ方の両方を持って初めて設計判断ができます。この掛け合わせは短期研修では身につかず、実プロジェクトでの経験蓄積が必要です。単価が高止まりしている背景として、習熟までに長い年数を要する専門性、業務知識との掛け合わせの難易度、英語ドキュメントの読解、グローバルプロジェクトでの経験といった複数のハードルが重なる点が指摘されています（SAP単価相場2026｜待極）。

第二の要因は、需要が平準化せず特定期間に集中することです。通常の IT 人材不足であれば、需要は年間を通じてある程度ばらけます。しかし保守期限を起点とする移行案件は、期限の 2〜3 年前に立ち上げが集中します。育成が需要のピークに間に合わない構造になっているわけです。

第三に、既存ユーザー企業の社内有識者が高齢化しています。ECC を 10 年以上運用してきた企業では、導入当時を知る担当者が定年前後に差し掛かっていることが珍しくありません。社内から知見が失われるタイミングと、移行の要員需要が立ち上がるタイミングが重なります。

「SIerに任せれば要員は付いてくる」が成立しなくなった発注側の現実

従来の基幹システム案件では、「SIer に一括で発注すれば、必要な要員はベンダー側が確保してくれる」という前提が成り立っていました。この前提が崩れつつあります。

要員の需給が締まると、ベンダー側は自社のリソースを単価と規模の大きい案件に優先配分します。結果として、発注側から見ると次の 3 つの形で現れます。

いずれも、発注企業側の準備不足が原因ではありません。市場全体の需給が反映された結果です。ここを「自社の交渉が下手だったから」と捉えてしまうと、社内での説明が「担当者の力不足」という話にすり替わり、必要な予算も確保できなくなります。

この状況で発注側に残される選択肢が、必要なロールを業務委託で直接確保するという方法です。ただしこれは「SIer より安く済ませる手段」ではありません。ベンダーが担っていた要員確保・品質管理・与信管理といった機能の一部を、自社が引き受けるということです。何をいくらで買うのか、どこまで自社が引き受けるのかを決めるのが、次からの内容になります。

SAPコンサルタントを業務委託で確保する単価相場｜役割・モジュール・商流別

ここからは、稟議に載せられる形で単価を整理します。以下に示す金額は、いずれも発注企業が支払う税別の月額（人月単価）であり、週 5 日・月 140〜180 時間程度の稼働を前提とした水準です。稼働率が半分であれば金額もおおむね比例して下がります。

なお、公開されている単価情報の多くは受注側（フリーランス）向けメディアが発信しているため、「その人が受け取れる額」と「発注側が支払う額」が混在しています。本記事では一貫して支払う側の金額として扱い、両者の差については後述します。

役割別の月額単価レンジ

まず経験年数と役割による差を押さえます。エージェント各社が公開している水準を整理すると、次のようになります。

経験 1 年以上で月 70 万円程度、5 年以上の上級コンサルタントで月 100〜200 万円、プロジェクトマネージャーポジションでは月数百万円という水準が示されています（SAPコンサルタントは高単価？単価相場と案件動向｜ランサーズ プロフェッショナルエージェント）。別のエージェントでは人月単価の幅を 70 万〜250 万円、平均を約 150 万円としています（【SAPフリーランス】単価相場や案件例｜プロコネクト）。

上記の公開レンジから発注側の予算を組む場合、「設計判断を任せられる人」を確保する前提なら、シニアクラスのレンジ中央（月 130〜150 万円程度）を基準に置くのが安全です。レンジ下限で予算を組むと、確保できる候補者が経験年数の浅い層に偏ります。逆に想定より大幅に安い提示があった場合は、経験年数が短い、モジュールが自社の要件と一致していない、あるいは商流が深く実質的な稼働が別人になっている、といった可能性を確認してください。

モジュール別に単価が変わる理由

SAP は複数のモジュールで構成されており、モジュールによって単価水準が異なります。2025 年時点の目安として、次のような水準が示されています（SAP単価相場2026｜待極）。

単価差が生まれる理由は、需要の大きさだけではありません。「業務知識の希少性」と「誤った設計をしたときのダメージの大きさ」が効いています。

FI・CO が高くなりやすいのは、決算・原価計算という会計制度に直結する領域だからです。設計を誤ると決算数値そのものが狂い、監査対応や税務に波及します。会計の実務知識と SAP の設定知識を両方持つ人材は母集団が薄く、代替が効きません。

PP・QM は製造業固有の業務知識が要求される領域で、自社の生産方式（見込生産・受注生産・繰返生産など）を理解したうえで設定できる人が限られます。一方 SD・MM は案件数自体が多く、経験者の母集団も相対的に厚いため、単価は中位に落ち着きます。

技術寄りの領域では、Basis（システム基盤・アップグレード）と ABAP（アドオン開発）が別軸で存在します。Basis はシステム全体の安定運用を担うため高単価が出やすい領域とされ、ABAP は開発工数として比較的積みやすい代わりに、業務設計の判断は担いません。募集の際は、「業務設計を任せたいのか、開発工数がほしいのか」を先に切り分けることが単価の妥当性を判断する前提になります。

フェーズ別の単価差

同じモジュールでも、担当するフェーズによって単価は変わります。上流工程ほど高く、下流ほど相対的に低くなるのが一般的な傾向です（プロコネクト）。

発注側が陥りやすいのは、構想策定・要件定義の単価が高いことを理由に、この工程を短く見積もることです。上流の判断を曖昧なまま設計に進むと、設計・開発フェーズで手戻りが発生し、結果として単価の安いフェーズで大量の追加工数を買うことになります。上流に厚く投資したほうが総額は下がるという構造を、稟議の説明に含めておくと後の追加予算申請が通りやすくなります。

商流で「本人に届く額」が変わる｜発注額と人材品質の関係

発注側が見落としやすいのが、同じ支払額でも商流の深さによって実際に稼働する人の水準が変わるという点です。

IT 業界の要員提供では、発注元と実際に稼働する人材の間に複数の企業が介在することがあります。各社が中間マージンを取るため、支払額と本人到達額の差が積み上がります。マージン率は企業によって異なりますが、おおむね 10〜25% の範囲とされ、これが各レイヤーで累積します（SES商流とは｜Heyday）。

発注額 160 万円で商流の深さが異なる場合、本人到達額は次のようなイメージになります（マージン率を各社 15% と仮定した試算です）。

ここで押さえるべきは、「中間マージンが悪だ」という話ではありません。エージェントやベンダーは、候補者の探索・与信確認・契約事務・稼働管理といった機能を提供しており、その対価としてのマージンには合理性があります。

発注側にとって重要なのは、支払額から逆算して「その金額で稼働する人材の水準」を推定できるという点です。月 160 万円を払っているのに本人到達額が 100 万円程度であれば、確保できるのは「月 100 万円で受ける人」であり、期待していたシニアクラスとは水準が異なります。見積書に商流の記載がない場合は、「実際に稼働する方はどの会社に所属していますか」「再委託は発生しますか」を提案時点で確認してください。これは値引き交渉のためではなく、期待する人材水準と支払額を整合させるための確認です。

稟議に載せる予算レンジの組み立て方

以上を踏まえ、稟議書に書く金額は次の手順で積み上げます。

1. 必要なロールを列挙する（例: FI 設計リード 1 名、MM 設計 1 名、ABAP 開発 2 名、PMO 1 名）
2. ロールごとに単価レンジの中央値を置く（レンジの下限で組むと確保できないリスクが高い）
3. 稼働率と参画期間を掛ける（フル稼働なら 1.0、週 3 日なら 0.6 程度）
4. 契約更新に伴う単価改定を織り込む（需給が締まる局面では、更新時に 5〜10% の上振れを見込んでおく）
5. 要員が抜けた場合の再調達コストをバッファとして持つ（探索期間中の空白と、後任の立ち上がり期間）

見積の例として、FI 設計リード（月 170 万円）1 名を 12 ヶ月、MM 設計（月 150 万円）1 名を 9 ヶ月、ABAP 開発（月 110 万円）2 名を 6 ヶ月、PMO（月 200 万円）1 名を 12 ヶ月という体制であれば、単純合計は約 6,270 万円です。これに更新時上振れとバッファを 15% 程度乗せて 7,200 万円前後、というのが稟議に載せる形になります。

なお、ISID の調査では S/4HANA 移行に妥当と考える費用として「1〜3 億円」が最多の 26.5% でした（IT Leaders）。人材費用は移行費用全体の一部であり、ライセンス・インフラ・データ移行ツール等が別途必要になります。人材調達の予算だけを切り出して稟議にかけると、後から全体像との整合を問われるため、「全体予算のうち人材確保分」という位置づけを明示しておくと説明が通りやすくなります。

SIer一括発注と業務委託による直接調達｜基幹システム人材の確保方式を比較する

基幹システム人材の確保方式には、大きく 4 つの選択肢があります。どれが正解かは自社の状況で決まります。

4つの調達方式と、それぞれが向く状況

1. SIer への一括発注（請負中心）

要件定義から本番稼働までを一括してベンダーに委託する方式です。成果物と納期が契約で確定するため、発注側の管理負荷は最も軽くなります。一方で、要員の確保はベンダー側の都合に左右され、単価も需給を反映して上振れします。社内に SAP 有識者がほとんどいない企業では、この方式以外の選択が難しいケースもあります。

2. SIer・ベンダーへの準委任発注（要員提供型）

ベンダーから要員の提供を受け、プロジェクトの進行は自社が主導する方式です。要員のバックアップ体制や代替要員の手配をベンダーが担うため、直接契約より継続性のリスクが低くなります。ただしベンダーのマージンが乗るため、直接契約より単価は高くなります。

3. エージェント経由の業務委託

フリーランス・個人事業主の紹介を専門とするエージェントを介して要員を確保する方式です。候補者の探索・与信確認・契約事務・支払事務をエージェントが担うため、社内の調達工数を抑えつつ、SIer 一括より単価を抑えられます。要員が抜けた場合の代替手配はエージェントの体制次第で差が出ます。

4. フリーランスとの直接契約

要員と直接契約する方式です。中間マージンが発生しないため、同じ支払額でより高い水準の人材に届きます。一方で、候補者の探索・スキル判定・与信確認・反社チェック・契約書作成・支払事務のすべてを自社が引き受けます。社内規程上、個人事業主との直接契約に制約がある企業も少なくありません。

4方式の比較表

「撤収後の知見残存」がいずれの方式でも自動的には担保されない点に注意してください。これは調達方式ではなく、後述する運用設計で決まります。

SAPエンジニアを外注する場合に社内で必ず必要になる役割

どの方式を選んでも、社内に置かなければ機能しない役割が 2 つあります。ここを空席にしたまま外注すると、方式の優劣に関係なくプロジェクトが停滞します。

発注責任者（何を頼むかを決める人）

依頼範囲・優先順位・予算配分を決定し、外部人材からの相談に一次回答を返す役割です。SAP の技術詳細を理解している必要はありませんが、自社の業務としてどちらを選ぶかを決められる立場であることが必須です。この役割が不在だと、外部人材は判断待ちで手が止まり、稼働時間だけが消化されます。

受入判定者（成果を受け取ってよいか判断する人）

提出された設計書・テスト結果・移行データを検証し、受け入れの可否を判断する役割です。SAP の実装知識がない場合でも、「自社の業務要件を満たしているか」の観点であれば業務部門の担当者が判定できます。技術面の妥当性まで見たい場合は、レビュー専任の外部人材を別途配置するか、既存 SIer にセカンドオピニオンを依頼する形が現実的です。

この 2 役割は兼務でも構いませんが、外部人材に兼ねさせてはいけません。発注責任と受入判定を委託先が実質的に担う状態は、成果物の品質を検証する主体が存在しないことを意味します。

自社の状況から調達方式を選ぶ判断フロー

次の順に判断していくと、自社に合う方式が絞り込めます。

1. 社内に発注責任者と受入判定者を置けるか — 置けない場合は SIer 一括を選ぶ以外にありません。まず社内体制を確保することが先です
2. 個人事業主との直接契約が社内規程上可能か — 与信基準・反社チェック・情報セキュリティ規程を満たせない場合、エージェント経由かベンダー準委任に絞られます
3. 要員が抜けた場合に自社で再探索する余力があるか — 余力がなければ、代替手配を担ってくれるエージェントまたはベンダーを選びます
4. 必要な期間が 6 ヶ月未満か — 短期であれば直接契約の事務コストが相対的に重くなるため、エージェント経由が効率的です
5. 必要なロールが 3 名以上か — 人数が多いほど直接契約の管理工数が増えるため、一部をエージェント経由に寄せる併用が現実的です

多くの中堅企業では、「設計リードは単価を積んでエージェント経由で確保し、開発工数はベンダー準委任でまとめる」という併用が落としどころになります。1 つの方式に統一する必要はありません。

業務委託で確保すべき役割と、社内に残すべき役割を切り分ける

調達方式を決める前に、そもそも「何を外に出すのか」を決める必要があります。ここが曖昧なまま募集をかけると、要件が「SAP ができる人」で止まり、単価だけで比較する状態に陥ります。

移行プロジェクトのロール分解

基幹システムの移行プロジェクトは、次のようなロールに分解できます。

外部化してよいロール／社内に残すべきロールの切り分け表

上記のロールを、外部化の可否で整理します。

切り分けの原則はシンプルです。「決めること」と「引き受け続けること」は社内に残し、「作ること」と「検討材料をそろえること」は外部化できると考えてください。

SAPフリーランスの活用が特に効くロールと、期待してはいけないロール

SAP フリーランスの活用が特に効果を発揮するのは、特定モジュールに深い経験を持つ人材を、必要な期間だけピンポイントで確保するケースです。

効きやすいロール:

• 特定モジュールの設計リード — FI/CO や PP のように業務知識の希少性が高い領域では、社内に育成する時間がありません。移行期間だけ外部から確保するのが合理的です
• アドオン開発 — 仕様が確定していれば工数として切り出せます
• データ移行の設計 — 現行データの汚れをどう扱うかは経験値がものを言う領域です
• テスト設計 — シナリオの網羅性は経験に依存します

一方で、次の期待は持たないほうが安全です。

• 自社の業務ルールを決めてくれること — 外部人材は「他社ではこうしている」という選択肢は出せますが、自社としてどれを選ぶかは決められません
• 社内政治の調整 — 部門間の利害調整は、社内の立場がある人でなければ動きません
• 稼働後の長期運用 — 契約が続く保証はありません。運用の責任を外部人材に集約すると、契約終了が即座にリスクになります
• 全モジュールを一人でカバーすること — 「SAP コンサルタント」という肩書きは広く、実際に設計判断まで担えるモジュールは通常 1〜2 領域です

社内有識者が1〜2名しかいない場合の現実的な体制案

社内の SAP 有識者が 1〜2 名という状況は、中堅企業では標準的です。この前提で組める体制の例を示します。

この体制で最も重要なのが、社内 SAP 有識者を設計作業に投入しないという点です。有識者を実務に組み込むと、その人がボトルネックになり、かつ知見の移転が進みません。有識者の時間は「現行仕様を外部人材に説明すること」と「外部人材の成果を受け入れ判定すること」に配分してください。特に定年が近い有識者がいる場合、この配置が知見移転の最後の機会になります。

SAPコンサルタントを業務委託で確保する5ステップ

ここからは、実際に確保するまでの手順です。各ステップで発注側が陥りやすい失敗も併せて示します。

ステップ1｜依頼範囲・成果イメージ・稼働率を言語化する

最初にやるべきは、体制図のどの枠を埋めるのかを決めることです。先ほどのロール分解表を使い、「このロールを、この期間、この稼働率で埋める」という単位に落とします。

言語化すべき項目は次の 4 つです。

• 担当ロール（例: MM モジュールの設計リード）
• 期間（例: 2026 年 10 月〜2027 年 6 月）
• 稼働率（例: 週 4 日、月 128 時間程度）
• 期待する成果物（例: 業務フロー図、Fit&Gap 一覧、設定仕様書、テストシナリオ）

よくある失敗: 依頼が「SAP の移行を手伝ってほしい」で止まっているケースです。この状態で募集をかけると、候補者は自分の得意領域を前提に応募してくるため、面談してから要件不一致が判明します。ロール単位まで割ってから募集してください。

ステップ2｜募集要項に書くべき5項目

募集要項には、少なくとも次の 5 項目を明記します。SAP は領域が広いため、この 5 項目が揃っていないと候補者は自分が適合するか判断できません。

さらに、必須要件と歓迎要件を分けて書いてください。すべてを必須要件に書き込むと応募が来ず、逆にすべて歓迎要件にすると要件不一致の応募が増えます。

よくある失敗: 業種経験を安易に必須要件に入れることです。「製造業経験必須」と書くと候補者は大幅に減ります。自社の業務プロセスの特殊性が本当に業種依存なのかを確認し、歓迎要件に落とせるなら落としてください。

ステップ3｜探索チャネルを選ぶ

候補者の探索チャネルは主に 3 つです。

• フリーランスエージェント — 候補者データベースを持ち、要件に合う人材を提案してくれます。契約・支払事務も代行されます。単価にマージンが乗りますが、社内の調達工数を大きく削減できます
• マッチングサービス — 発注企業が直接候補者にアプローチできるプラットフォームです。マージンが低い分、スキル判定と契約事務は自社で行います
• 既存取引先・社内人脈からの紹介 — 前提となる信頼があるため、立ち上がりが速いのが利点です。ただし母集団が限られ、単価の妥当性を比較しにくくなります

SAP のように母集団が薄い領域では、複数チャネルを並行して走らせるのが現実的です。1 つのチャネルで待っていると、期限に間に合わなくなるリスクがあります。

よくある失敗: 最初の 1 名の提案で決めてしまうことです。母集団が薄いとはいえ、比較対象なしで単価と水準の妥当性は判断できません。最低 2〜3 名は面談してから決めてください。

ステップ4｜面談でSAPスキルを見極める質問設計

面談の目的は、「SAP ができるか」ではなく「自社の要件に対して設計判断ができるか」を確認することです。具体的な質問設計は後述の見極めの内容で詳しく扱いますが、ステップとしては次を確認します。

1. 担当したモジュールと、そのモジュール内でどこまでの設計判断を担ったか
2. S/4HANA での実務経験があるか（学習・研修経験と実プロジェクト経験を区別する）
3. 参画したフェーズ（上流のみか、実装まで通したか）
4. 自社と近い業務プロセスの経験があるか
5. 標準機能で足りない要件に直面したときの判断の仕方

よくある失敗: 発注側に SAP の技術知識がないため、質問が「経歴の確認」で終わってしまうことです。技術知識がなくても、「その判断をした理由」を掘り下げれば、設計判断の深さは推し量れます。

ステップ5｜条件交渉と契約締結

条件交渉で合意すべき項目は次の通りです。

契約書のレビュー観点は SAP 案件に限らず共通する部分が大きいため、汎用的な確認項目は業務委託契約のリスクチェックリストを参照してください。本記事では、次の内容で SAP 固有の論点に絞って扱います。

よくある失敗: 単価だけを交渉して、稼働率と期間を曖昧にすることです。「月 150 万円」で合意しても、稼働が週 3 日なのか週 5 日なのかで実質単価は倍近く変わります。稼働率・稼働時間の下限上限・超過時の扱いを必ず契約に明記してください。

準委任契約でSAPコンサルタントに業務委託する際の契約・法務チェックポイント

契約形態の選択と法務上の線引きは、発注側が最も不安を抱える領域です。ここでは SAP プロジェクト固有の論点を中心に整理します。

準委任契約と請負契約、SAP案件ではどちらを選ぶか

契約形態の選択基準は、成果物を契約時点で確定できるかどうかです。

SAP の移行プロジェクトでは、上流工程の大半が準委任になります。請負が適するのは、仕様が確定したアドオン開発など限定的な範囲です。請負と準委任の使い分けをより詳しく検討する場合は、請負と準委任の判断基準を整理した記事もあわせてご覧ください。

偽装請負にしないための指示・進捗管理の線引き

「準委任で日々の相談をしたら偽装請負になるのではないか」という不安は、発注側から最も多く聞かれる懸念です。

法的な判断基準は、厚生労働省の告示（昭和 61 年労働省告示第 37 号、いわゆる 37 号告示）で示されています。要点は、受託者が自らの労働力を自らの判断で用いて業務を処理しているかであり、契約書の形式ではなく実態で判断されます。厚生労働省は疑義応答集を公開しており、具体的な場面ごとの考え方を示しています。

発注側の実務としては、次の線引きを守るのが基本です。

実務上のコツは、「作業」ではなく「成果」の単位で依頼することです。「今日は MM の設定作業をしてください」ではなく、「今週末までに購買プロセスの Fit&Gap 一覧を提出してください」という形にすれば、進め方の裁量は受託者側に残ります。定例会も「作業の割り振り」ではなく「成果の確認と次の依頼範囲の合意」の場として設計してください。

なお、個人のフリーランスと直接契約する場合、労働者派遣法の枠組みとは別に労働者性の判断という論点も生じます。実質的に自社の指揮命令下で時間を拘束して働かせている状態は、契約形態にかかわらず問題になり得ます。線引きの考え方は同じです。

本番データ・アクセス権限と秘密保持の設計

SAP プロジェクトで固有性が高いのが、本番データと権限の扱いです。基幹システムには、取引先との単価情報、原価データ、人事情報、決算数値といった機微情報が集約されています。

設計すべき論点は次の通りです。

• 本番データを開発機・検証機にコピーするか — データ移行のテストでは本番相当のデータが必要になりますが、コピーすると機微情報が検証環境に展開されます。マスキング（取引先名・単価・個人情報の置換）の要否を先に決めてください
• 外部人材に付与する SAP 権限の範囲 — 開発機・検証機・本番機のどこまでにアクセスを許すか。本番機の参照権限は「調査時に都度申請・都度付与」とし、常時付与は避けるのが基本です
• 移送（トランスポート）の承認者 — 開発機から本番機へ変更を反映する移送の承認は、社内の Basis 担当または受入判定者が行う体制にしてください。外部人材が自ら承認できる状態は避けます
• 秘密保持義務の範囲と存続期間 — 契約終了後も存続する条項として明記し、存続期間（3〜5 年が一般的）を定めます
• 端末・作業環境 — 貸与端末を使わせるのか、本人の端末での作業を認めるのか。認める場合の要件（ディスク暗号化、業務データの端末保存禁止等）を明記します

これらは契約書の別紙（情報セキュリティ要件）として整理しておくと、複数名を確保する際に使い回せます。

アドオン・設計書の権利帰属と、契約終了時の引き渡し条項

SAP プロジェクトで作られる成果物は、アドオンのソースコードだけではありません。設計書、Fit&Gap 一覧、テストシナリオ、設定パラメータの一覧、移行データのマッピング定義といったドキュメント群が、その後の保守運用を左右します。

契約で明記すべき点は次の 3 つです。

1. 著作権の帰属 — アドオンのソースコードと設計ドキュメントの著作権を発注者に帰属させます（または発注者に無償・無期限の利用許諾を与えます）
2. 著作者人格権の不行使 — 権利帰属を定めても、著作者人格権の不行使特約がないと改変時に問題が生じます
3. 契約終了時の引き渡し — 引き渡すべき成果物の一覧と、引き渡し先（社内の管理場所）を契約に明記します

3 番目は特に見落とされやすい項目です。「作業は完了したが、設計の意図を書いたメモは本人のローカル環境にしかない」という状態は、契約終了と同時に情報が失われます。後述する運用設計と合わせて、成果物の保存場所を最初から社内資産の中に固定してください。

フリーランス新法で発注者に生じる義務

個人事業主（特定受託事業者）に業務委託する場合、2024 年 11 月 1 日に施行された「特定受託事業者に係る取引の適正化等に関する法律」（フリーランス・事業者間取引適正化等法）に基づく義務が発注者側に生じます。

主な義務は次の通りです（公正取引委員会・中小企業庁 説明資料）。

発注側の実務対応としては、契約書の締結だけで済ませず、個別の発注ごとに条件を明示する運用にしておくのが安全です。SAP プロジェクトでは追加依頼が発生しやすく、口頭で範囲が広がりがちなためです。詳細な要件は公正取引委員会のフリーランス法特設サイトでも公開されています。

なお、この法律はエージェント経由・ベンダー経由の場合でも、契約の相手方が個人事業主であれば適用されます。商流に企業が介在する場合は、直接の契約相手が誰かを確認してください。

外部人材のスキルを見極め、撤収後も知見を社内に残す運用設計

ここが本記事で最も重要な内容です。単価と契約が整っても、撤収後に社内へ何も残らなければ、次の保守期限や制度改正のたびに同じ調達を繰り返すことになります。

面談で「モジュールの深さ」を見極める質問例

SAP の技術詳細を知らない発注担当者でも、次の質問で設計判断の深さは推し量れます。ポイントは、知識を問うのではなく「判断の理由」を問うことです。

特に有効なのが 2 つ目の「アドオンにしなかった例」です。アドオンを増やすほど移行時の負担は膨らみます。標準機能に業務を寄せる判断を経験している人材は、移行プロジェクトでの価値が高くなります。

また、S/4HANA の経験を確認する際は、「経験あり」という回答をそのまま受け取らず、実プロジェクトでの担当範囲まで踏み込んでください。研修受講やサンドボックス環境での検証を「経験」と表現するケースがあります。

SAP認定コンサルタント資格をどう評価するか

SAP は認定コンサルタント資格制度を運営しており、モジュールごと・バージョンごとに試験が用意されています。発注側としては、この資格を次のように位置づけるのが実務的です。

資格があることで分かること:

• そのモジュール・バージョンの標準機能について、体系的な知識を持っていること
• 学習にコストと時間を投じていること
• バージョンが明記されているため、どの世代の機能を学んだかが分かること

資格では分からないこと:

• 実プロジェクトで設計判断を担った経験があるか
• 業務知識（会計・生産管理等）の深さ
• 顧客折衝や合意形成の能力
• 標準機能で満たせない要件に直面したときの判断力

つまり、資格は候補者を絞り込むための一次フィルタとしては有効だが、選定の決め手にはならないというのが実務的な扱いです。資格を必須要件にすると母集団がさらに薄くなるため、歓迎要件に置き、面談での判断を主軸にすることをおすすめします。

契約期間中に知見を社内に吸い上げる3つの仕組み

撤収時に慌てて引き継ぎを依頼しても、間に合いません。契約開始時点から知見が社内に蓄積される仕組みを作っておく必要があります。

仕組み1: 記録先を社内資産に固定する

設計判断・検討経緯・却下した代替案を、社内が管理するドキュメント基盤（社内 Wiki、共有ストレージ、チケット管理システム等）に記録することを、契約開始時に合意します。外部人材の個人環境やエージェントのツール上にしか記録がない状態を作らないことが目的です。

記録すべきは成果物そのものだけではありません。「なぜその設定を選んだのか」「他にどんな選択肢があり、なぜ却下したのか」という判断の経緯が、保守運用のフェーズで最も効いてきます。

仕組み2: レビューに社内メンバーを同席させる

設計レビュー・仕様確認の場に、社内の運用オーナー候補（将来この領域を引き継ぐ人）を必ず同席させます。この時点では理解が追いつかなくても構いません。「どこで何を議論したか」を知っている人が社内にいるという状態が、後の調査コストを大きく下げます。

同席者を固定することも重要です。毎回違う人が出ると、文脈が誰にも蓄積されません。

仕組み3: ナレッジ移転を業務範囲に含める

月次で 1 日程度、「社内メンバーへの説明・質疑応答」の時間を業務範囲に含め、契約書の業務内容に明記します。契約外の善意に頼ると、繁忙期に真っ先に削られます。

移転のテーマは事前に決めておいてください。「今月は購買プロセスの設定思想」「来月はマスタ設計の考え方」のように、社内側がテーマを指定する形が効果的です。外部人材に任せると、目の前の作業の説明に終始しがちです。

撤収を前提とした引き継ぎ条項と、運用オーナーの設計

契約の終了は、更新しない選択をした場合だけでなく、本人の都合による離脱でも発生します。撤収は起こる前提で設計してください。

契約に含めるべき引き継ぎ関連の条項:

• 引き継ぎを履行範囲に含める — 契約終了時に、引き継ぎ資料の作成と後任者への説明を行うことを業務範囲に明記します
• 引き継ぎ資料の要件を定義する — 「設定一覧」「未解決課題一覧」「運用上の注意点」「関係者・問い合わせ先」を最低限含めます
• 引き継ぎ期間を確保する — 契約終了の 1 ヶ月前から引き継ぎに着手します。中途解約の予告期間（30 日前）と整合させます
• 成果物の返還・削除 — 貸与端末・アクセス権限の返却、本人環境に残る業務データの削除確認

そして最も重要なのが、運用オーナーを社内に置き、移行プロジェクトの期間中から任命しておくことです。稼働後に「誰がこのシステムを見るのか」を決めようとすると、詳しい人が誰も残っていない状態から始まります。プロジェクトの初期段階で運用オーナーを指名し、設計レビューへの同席とナレッジ移転の受け手を担わせてください。

社内 SAP 有識者の定年が近い企業では、この運用オーナーの育成が移行プロジェクト最大の副産物になります。移行そのものは外部人材の力で乗り切れますが、その後 10 年運用するのは社内の人間です。

保守期限から逆算するSAP人材の調達スケジュールとチェックリスト

最後に、期限から逆算した調達スケジュールを整理します。

期限から逆算した調達スケジュール

メインストリームメンテナンスの期限である 2027 年末を本番稼働の期限とする場合、逆算すると次のようなスケジュールになります（コンバージョン方式・中堅規模を想定した目安です）。

延長保守（2030 年末）を選択する場合はこの全体が 3 年後ろにずれますが、延長保守の適用には EhP6 以上への更新が前提となる点に注意してください。EhP5 以前を利用している場合は、まず EhP の更新プロジェクトが必要になります。

このスケジュールで注目してほしいのは、本番稼働の 18〜20 ヶ月前には募集を開始しているという点です。設計リードの探索・面談・契約・参画には、母集団が薄い領域では 2〜3 ヶ月かかることも珍しくありません。

着手が遅れるほど不利になる理由

着手の遅れが不利に働く理由は 3 つあります。

1. 需給が期限に向かって締まる

同じ期限を抱えた企業が同時に動くため、期限が近づくほど候補者は選択肢を持ちます。単価が上がるだけでなく、「条件の良い案件から埋まる」という順序で市場が動きます。

2. 稼働開始までのリードタイムが伸びる

需給が締まると、候補者は既存案件が終わるまで動けません。「良い候補者は見つかったが、参画は 4 ヶ月後」という状況が発生します。

3. 選択肢が「移行」から「延命」に狭まる

要員が確保できず期限に間に合わないと判断した場合、第三者保守サービスへの移管による延命という選択肢を検討することになります。前述の ISID 調査でも、ECC6.0 ユーザーの 17.5% が第三者保守への移管を想定していました（IT Leaders）。これは有効な選択肢ですが、移行そのものが不要になるわけではなく、判断を先送りしているだけです。延命コストを払いながら、いずれ同じ調達に向き合うことになります。

早期に着手する最大のメリットは、単価が安く済むことよりも、「どの選択肢も選べる状態」を保てることにあります。

発注側チェックリスト

最後に、本記事で扱った判断軸をチェックリストとしてまとめます。稟議書の作成前に確認してください。

体制・ロールの切り分け

• 社内に発注責任者（何を頼むかを決める人）を指名したか
• 社内に受入判定者（成果を受け取ってよいか判断する人）を指名したか
• 稼働後の運用オーナーを、プロジェクト開始時点で指名したか
• 業務要件の最終決定権を、外部人材に委ねていないか
• 社内 SAP 有識者を設計作業ではなく「説明と受入判定」に配置したか

単価・予算

• ロール単位（モジュール・フェーズ・稼働率）で単価を積み上げたか
• 単価レンジの下限ではなく中央値で予算を組んだか
• 契約更新時の単価上振れをバッファに織り込んだか
• 商流の深さ（再委託の有無）を提案時に確認したか
• 人材費用が移行費用全体のどの部分にあたるかを明示したか

調達方式

• 個人事業主との直接契約が社内規程上可能か確認したか
• 要員が離脱した場合の代替手配を誰が担うかを決めたか
• 複数の探索チャネルを並行して走らせているか
• 最低 2〜3 名を面談したうえで決定しているか

契約・法務

• 業務内容ごとに準委任・請負を使い分けたか
• 稼働率・稼働時間の下限上限・超過時の扱いを契約に明記したか
• 日々の作業指示ではなく成果単位での依頼になっているか
• 本番データの取り扱い・アクセス権限の範囲を定めたか
• 移送の承認者を社内に置いたか
• アドオン・設計書の著作権帰属と著作者人格権の不行使を定めたか
• 個人事業主が相手の場合、取引条件の明示と 60 日以内の支払期日を満たしているか

知見移転

• 設計判断の記録先を社内が管理する基盤に固定したか
• 設計レビューに社内の運用オーナー候補を同席させる運用にしたか
• ナレッジ移転の時間を業務範囲に含め、契約に明記したか
• 引き継ぎ資料の作成と後任者への説明を履行範囲に含めたか
• 引き継ぎ期間を中途解約の予告期間と整合させたか

このチェックリストのうち、「体制・ロールの切り分け」が空欄のまま単価の検討に進んでいる場合は、順番を戻してください。誰が何を決めるのかが決まっていない状態でいくら単価を積み上げても、その金額が妥当かどうかを社内に説明することはできません。

明日から着手する最初の一手として推奨したいのは、移行プロジェクトの体制図を 1 枚描き、各ロールに「社内」か「外部」かを書き込むことです。それが決まれば必要な単価が決まり、必要な予算が決まり、募集要項が書けます。判断の起点は、単価表ではなく体制図に置いてください。

関連情報

外部人材の活用方針を社内で整理する際は、外部エンジニア活用の戦略立案ガイドもご利用いただけます。内製チームとの役割分担の設計や、業務委託発注の要件定義書テンプレートを、そのまま社内共有できる形にまとめています。

基幹システムの移行体制や外部人材の活用について、要件の整理段階からご相談いただけます。ご検討中の方はお問い合わせフォームよりお気軽にお声がけください。