「スクラムで開発を進めたいのに、スクラムマスターを担える人が社内にいない」。スクラム導入を決めた多くの中小企業・スタートアップが、この一点で手を止めてしまいます。プロダクトオーナーや開発者は社内で確保できても、チームの自律を支援するスクラムマスターは経験がものを言うロールで、正社員採用は難易度もコストも高いのが実情です。
そこで浮かぶのが「スクラムマスターを外部委託する」という選択肢です。ただ、いざ検討を始めると新たな迷いが生まれます。チームの自律を支援する立場の人を外注して、本当に機能するのか。外部の人に開発の現場で指示を出してよいのか、指揮命令の線引きを誤って偽装請負と疑われないか。判断材料がないまま、踏み切れずにいる方も多いのではないでしょうか。
この記事では、発注企業の担当者が「自社の状況ならスクラムマスターを外部委託すべきか」を自分で判断できるよう、判断軸・チーム体制・契約と指揮命令の線引き・費用感までを順に整理します。特に外部スクラムマスター特有の論点である偽装請負のリスクについては、厚生労働省やIPA(独立行政法人 情報処理推進機構)の公的な見解を根拠に、実務で押さえるべきポイントを解説します。読み終えるころには、社内で外注の可否を判断し、契約・体制の方針まで描ける状態を目指します。
スクラムマスターの外部委託とは|なぜ「外注」が選択肢になるのか
まず、判断の前提として「スクラムマスターとは何をする人か」を一度おさらいしておきます。ここを誤解したまま外注すると、体制設計も契約も的を外すためです。
スクラムマスターは「チームの自律を支援する人」であって指揮者ではない
スクラムマスターは、スクラムが正しく機能するように支援する役割です。具体的には、開発を妨げる障害(インピディメント)を取り除き、デイリースクラムやスプリントレビューといったスクラムイベントが機能するように整え、チームが自律的に動けるよう手助けします。
ここで重要なのは、スクラムマスターは「開発の指揮者」ではないという点です。何を作るかを決めるのはプロダクトオーナーであり、どう作るかを決めるのは開発者です。スクラムマスターは、そのチームが自分たちで判断し前に進める状態を支援する立場にあります。この「指揮者ではなく支援者」という性質は、後半でお話しする指揮命令や偽装請負の論点に直結する伏線なので、頭の片隅に置いておいてください。スクラムの役割やイベントの基本を改めて押さえたい場合は、アジャイル・スクラムの基礎ガイドもあわせてご覧ください。
外部委託が選択肢になる3つの背景
社内にスクラムマスター経験者がいない場合、正社員採用ではなく外部委託を選ぶ企業が増えています。背景は主に3つです。
- 採用難易度の高さ: 実務経験のあるスクラムマスターは市場で希少で、自社にフィットする人材を正社員で採用するには時間がかかります。
- コスト: 専任のスクラムマスターを正社員で雇うと固定の人件費が発生します。立ち上げ期や単一プロジェクトのために常時1名を抱えるのは、規模によっては過剰投資になります。
- 導入スピード: スクラムを「今すぐ正しく回し始めたい」という状況では、採用を待つより経験者を外部から迎えるほうが圧倒的に速く着手できます。
外部委託は、これらの制約を抱える企業にとって正当な選択肢です。問題は「外注すべきかどうか」と「外注するならどう体制を組むか」であり、ここから順に見ていきます。
スクラムマスターを外部委託する判断軸

外部委託すべきか、それとも内製・採用で進めるべきか。この判断を感覚で行うと後悔しやすいため、いくつかの軸に分解して考えます。自社の状況を各軸に当てはめてみてください。
外部委託が向くケース
次のような状況では、外部委託のメリットが大きくなります。
- 社内にアジャイル/スクラムの実務経験者が誰もいない: 手探りで始めるより、経験者に伴走してもらうほうが立ち上がりの失敗を避けられます。
- 立ち上げ期・短期のプロジェクトである: 「まずスクラムを回せる状態を作りたい」「数か月の集中開発を回したい」といった、期間が限定された状況に向いています。
- 採用に時間をかけられない: 事業のスピードが優先で、採用プロセスを待つ余裕がない場合です。
- まずは小さく試して自社に合うか見極めたい: いきなり正社員を雇うリスクを避け、外部委託で検証してから内製化を判断したい場合です。
内製・採用が向くケース
逆に、次のような状況では内製や採用を優先したほうが合理的です。
- 長期的にスクラムの知見を組織に残したい: 自社プロダクトを継続的に開発し続けるなら、知見が社内に蓄積される内製のほうが中長期では強くなります。
- 複数チーム・複数プロダクトに展開する見込みがある: スクラムマスターを社内に育てておくと、横展開のときに内部人材で対応できます。
- 専任を置ける規模・予算がある: 固定費として専任スクラムマスターを抱えられるなら、コミットメントの高さという面で内製が有利です。
なお、外部委託と内製は二者択一ではありません。よくある現実解は「立ち上げ期は外部委託で回しつつ、並行して社内メンバーを育て、軌道に乗ったら内製に切り替える」というハイブリッドです。外部スクラムマスターに「自社メンバーへの知見移転」も役割として依頼しておくと、この移行がスムーズになります。
判断軸チェック観点
ここまでの内容を、自社で確認するためのチェック観点として整理します。
判断軸 | 外部委託が向く | 内製・採用が向く |
|---|---|---|
社内のアジャイル経験 | 経験者がいない | 経験者がいる/育成中 |
内製化したい度合い | まず回したい | 知見を組織に残したい |
プロジェクトの期間・継続性 | 短期・立ち上げ期 | 長期・継続開発 |
採用にかけられる時間 | 待てない | 確保できる |
予算・専任を置けるか | 専任は過剰 | 専任を置ける規模 |
多くの軸が左列(外部委託)に寄るなら外注、右列(内製)に寄るなら採用が基本方針となります。判断が割れる場合は、後述するスモールスタートで小さく試しながら見極めるのが現実的です。
外部スクラムマスターを迎えるときのチーム体制

外部委託を選ぶと決めたら、次は「どこまでを外に出すか」を設計します。スクラムマスターだけを外注するのか、開発者も含めて委託するのかで、体制も契約も変わります。代表的なパターンを3つに整理します。
体制パターン|外注範囲別
パターンA:スクラムマスターのみ外部委託(PO・開発者は自社)
プロダクトオーナーと開発者は自社で確保し、スクラムマスターだけを外部から迎える形です。社内に開発メンバーがいて、スクラムの進め方だけを補いたい企業に向いています。知見が社内チームに残りやすく、内製化への移行もしやすいのが利点です。
パターンB:スクラムマスター+一部開発者を委託
スクラムマスターに加え、不足している開発リソースの一部も外部から補う形です。社内の開発人員が足りない、特定の技術領域に強いメンバーが欲しい、といった場合に選ばれます。自社メンバーと外部メンバーが混在するため、後述する指揮命令の線引きがより重要になります。
パターンC:スクラムチームごと委託(PO以外)
スクラムマスターと開発チームをまとめて外部に委託し、自社はプロダクトオーナーに専念する形です。社内に開発体制がほとんどない場合の選択肢ですが、知見が社内に残りにくいため、内製化を見据えるなら知見移転の取り決めが欠かせません。
プロダクトオーナーは原則自社で持つ
どのパターンでも共通して言えるのは、プロダクトオーナーは原則として自社で持つべきだということです。プロダクトオーナーは「何を作るか」「優先順位はどうするか」を決める、プロダクトの意思決定責任を担うロールです。これを外部に委ねると、自社のビジネス判断が外部に依存し、プロダクトの主導権を失いかねません。
外部に出してよいのは「スクラムを機能させる支援(スクラムマスター)」や「作る作業(開発者)」であって、「何を作るかを決める権限(プロダクトオーナー)」ではない、と整理しておくと判断を誤りません。
外部スクラムマスターと社内メンバーの連携を機能させるポイント
外部スクラムマスターを「機能させる」かどうかは、迎え入れ方で大きく変わります。次の点を押さえてください。
- プロダクトオーナーと密に連携する場を設ける: 何を作るかは自社のプロダクトオーナーが持つため、外部スクラムマスターがプロダクトオーナーと頻繁に対話できる関係を作ります。
- チームの自律を待つ姿勢を持つ: スクラムマスターはチームが自律するのを支援する役割です。社内側が結果を急いで逐一指示を出すと、その機能が損なわれます(この点は失敗パターンでも改めて触れます)。
- 知見移転をゴールに含める: 内製化を見据えるなら、外部スクラムマスターに「社内メンバーがスクラムを回せるようになる」ことまで支援範囲として依頼しておきます。
契約形態と指揮命令の線引き|偽装請負を避ける

外部スクラムマスターの委託で、発注者が最も不安を感じやすいのがこの論点です。「支援する立場」の人を外注したとき、現場でどう関わってよいのか。線引きを誤ると偽装請負と疑われるのではないか。ここを公的な根拠に基づいて整理します。
準委任契約が基本になる理由
外部スクラムマスターの委託は、原則として準委任契約が適しています。準委任契約とは、特定の成果物の完成ではなく、専門家として業務を遂行すること自体に対価を支払う契約形態です。
スクラムマスターの仕事は「特定の成果物を完成させること」ではなく「スクラムが機能するよう支援し続けること」です。また、アジャイル開発では作るものを固定せず、スプリントごとに優先順位を見直しながら進めます。あらかじめ成果物を確定させて完成責任を負わせる請負契約とは、そもそも相性がよくありません。
この点はIPAも同様の考え方を示しています。IPAが2020年3月に公開した「情報システム・モデル取引・契約書(アジャイル開発版)」は、成果物の完成に対価を支払う請負契約ではなく、業務の遂行自体に対価を支払う準委任契約を前提として作られています(IPA:情報システム・モデル取引・契約書(アジャイル開発版))。請負と準委任の違いをより詳しく知りたい場合は、アジャイル・スクラムの基礎ガイドもあわせて参考にしてください。
偽装請負と判断されないための指揮命令の線引き
外部スクラムマスターを迎えるとき、発注者が踏みやすいのが「外部のメンバーに直接指示を出してしまう」ことです。準委任契約や請負契約では、発注者が委託先のメンバーに対して直接、業務の遂行方法を指揮命令することはできません。これをやってしまうと、契約の名目は委託でも実態は労働者派遣に近いとみなされ、いわゆる偽装請負と判断されるおそれがあります。
ここで多くの発注者が抱く不安が「アジャイル開発では発注者と開発チームが密にコミュニケーションを取るが、それ自体が偽装請負になるのではないか」というものです。この点について、厚生労働省は明確な見解を示しています。
厚生労働省は2021年9月に「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)に関する疑義応答集(第3集)」を公表しました。ここでは、発注者と受注者が対等な関係のもとで協議し、開発担当者が自律的に判断して開発を行うというアジャイルな働き方が前提として示されています。そして、発注者と受注者が密にコミュニケーションを取っていても、対等な関係で受注者が自律的に判断して開発を行っていれば偽装請負には当たらない、という考え方が明示されています(厚生労働省:労働者派遣・請負を適正に行うためのガイド(PDF)、NEC:アジャイル開発って偽装請負になるの? 厚生労働省回答編)。
つまり、線引きの本質は「密にコミュニケーションを取るかどうか」ではなく、「チームが自律的に判断して動いているか」「発注者が個々のメンバーに業務遂行方法を直接指示していないか」にあります。スクラムマスターは元々チームの自律を支援する役割なので、本来のスクラムを正しく運用していれば、この線引きは自然と守られる構造になっています。
チームの自律性を保つ運用設計
公的見解を踏まえると、偽装請負を避けるための運用は次のように整理できます。
- 「何を作るか」はプロダクトオーナーが要求として伝え、「どう作るか」はチームに委ねる: 発注者側は要望・優先順位を伝え、実現方法の判断はチームの自律に任せます。個々の作業手順を発注者が逐一指示しないことが要点です。
- 指示はチームに対して、個人にではなく: 特定の外部メンバーに直接「これをこうやって」と命じる形を避け、スプリントの目標やプロダクトバックログを通じてチーム全体に共有します。
- スクラムイベントを協議の場として機能させる: スプリントプランニングやレビューを、対等な立場で協議する場として運用します。これが「対等な関係での協議」という公的見解の要件にも合致します。
過剰に身構えてコミュニケーションを絞る必要はありません。むしろ、スクラムを正しく運用し、チームの自律を尊重することが、結果的に偽装請負リスクを避ける最も確実な道になります。
外部委託の費用感とスモールスタートの進め方
最後に、発注者が気にする費用と、リスクを抑えた始め方を整理します。
稼働形態による費用の考え方
外部スクラムマスターの費用は、稼働形態によって大きく変わります。具体的な金額は人材の経験や市場状況によって幅があるため、ここでは費用を左右する要素の考え方を押さえてください。
- 常駐かリモートか: 現場に常駐してもらう場合と、リモートで関わってもらう場合では稼働コストが変わります。
- フルタイムかパートタイムか: 1チームに専念してもらうのか、週数日・特定のイベントのみ関わってもらうのかで費用が変わります。スクラムマスターは複数チームを兼任できる場合もあり、必ずしもフルタイムを要しません。
- 実務遂行型かコーチング型か: スクラムマスターとして日々のチーム運営を担ってもらうのか、社内メンバーを育てるコーチング・伴走を主に依頼するのかでも費用感が変わります。
業務委託は短期・スポットでの契約も可能なため、「まずスクラムイベントの設計と数スプリントの伴走だけ」といった限定的な依頼から始めることもできます。
スモールスタートで自社に合うか見極める
外部委託で失敗を避ける最も実践的な方法は、いきなり長期契約を結ばず、小さく始めることです。
- 数スプリントのトライアルから始める: まず2〜3スプリント程度の短期契約で迎え、自社のチームや文化に合うか、期待した支援が得られるかを見極めます。
- コーチング型から入る: 常駐フルタイムではなく、まずはスクラムの立ち上げ支援やコーチングという軽い関わりから始め、必要に応じて関与度を上げる方法もあります。
スモールスタートには「自社に合わなければ早期に見直せる」「費用が予算内に収まるか検証しながら判断できる」というリスク低減の効果があります。立ち上げ期こそ、小さく試して手応えを確かめてから本格化させるのが堅実です。
外部委託でよくある失敗と回避策

外部スクラムマスターの委託でつまずく企業には、共通したパターンがあります。先回りで地雷を把握しておきましょう。
プロダクトオーナーを置かず、外部に丸投げする
最も多い失敗が、プロダクトオーナーを社内に置かないまま外部スクラムマスターに「うまくやっておいて」と丸投げするケースです。何を作るかの意思決定が宙に浮き、開発が止まります。
回避策: プロダクトオーナーは必ず自社で持ち、何を作るか・優先順位を決める責任を社内に残します。外部に出すのはスクラムの運営支援であって、プロダクトの意思決定ではありません。
指揮命令の線引きを誤り、偽装請負リスクを抱える
外部メンバーに直接、作業手順を逐一指示してしまい、実態が労働者派遣に近づいてしまうパターンです。
回避策: 準委任契約を基本とし、要望はプロダクトバックログやスプリント目標を通じてチームに伝え、実現方法はチームの自律に委ねます。前の章で触れた厚生労働省の見解のとおり、チームが自律的に判断して動いている状態を保つことが要点です。
チームの自律を待てず、社内が逐一指示してしまう
結果を急ぐあまり、社内側がチームの一つひとつの判断に口を出し、スクラムマスターが本来の「自律支援」を発揮できなくなるパターンです。指揮命令上のリスクであると同時に、スクラムそのものが機能しなくなる問題でもあります。
回避策: チームが自分たちで判断し改善するのを待つ姿勢を持ちます。スクラムマスターには、社内側が過干渉になりそうなときに調整役を担ってもらうことも依頼できます。
知見が社内に残らず、内製化の出口がない
外部スクラムマスターに頼り切った結果、契約が終わると社内に何も残らない、という失敗です。立ち上げは成功しても、その後が続きません。
回避策: 契約開始時に「知見移転」「社内メンバーの育成」を支援範囲として明確に依頼します。内製化を目指すなら、いつ・どのように外部から社内へ役割を引き継ぐかという出口も初めに描いておきます。
まとめ|自社の状況に合った判断をするために
スクラムマスターの外部委託は、社内にアジャイル経験者がいない企業にとって正当で有効な選択肢です。最後に、判断のための要点を振り返ります。
- 判断軸: アジャイル経験の有無・内製化したい度合い・プロジェクトの期間・採用にかけられる時間・予算という軸で、外部委託と内製・採用のどちらが向くかを見極める。
- チーム体制: スクラムマスターのみ/開発者も含める/チームごと、のどこまでを外に出すかを設計し、プロダクトオーナーは原則自社で持つ。
- 契約と指揮命令: 準委任契約を基本とし、チームの自律を保つことで偽装請負リスクを避ける。密なコミュニケーション自体は問題ではなく、対等な協議と自律的な判断がポイント。
- 進め方: いきなり長期契約せず、数スプリントのトライアルやコーチング型から小さく始めて、自社に合うか見極める。
これらを自社の状況(経験者の有無・内製化の意向・期間・予算)に当てはめれば、「外注すべきか」「契約はどうするか」「誰がプロダクトオーナーを持つか」を社内で判断できるはずです。スクラムやアジャイルの基礎を整理したい場合はアジャイル・スクラムの基礎ガイドを、スクラム開発そのものを外注する場合の進め方はスクラム開発の外注ガイドを、あわせて検討の材料にしてください。
よくある質問
- 外部スクラムマスターはフルタイムで常駐してもらう必要がありますか?
必須ではありません。スクラムマスターは複数チームの兼任やパートタイムでの関与も可能で、リモート・週数日・特定イベントのみといった関わり方も選べます。立ち上げ期は数スプリントの伴走から始め、必要に応じて関与度を調整するのが現実的です。
- スクラムマスターを外部委託する場合、契約は準委任と請負のどちらにすべきですか?
準委任契約が基本です。スクラムマスターの仕事は成果物の完成ではなく「スクラムが機能するよう支援し続けること」であり、作るものを固定しないアジャイル開発とは完成責任を負う請負契約が馴染まないためです。IPAのモデル契約書も準委任を前提としています。
- アジャイル開発で発注者がチームと密にやり取りすると偽装請負になりますか?
密なコミュニケーション自体は偽装請負には当たりません。厚生労働省の見解でも、対等な関係で協議し、チームが自律的に判断して開発していれば問題ないとされています。境界は「コミュニケーション量」ではなく「個々のメンバーに業務遂行方法を直接指示していないか」にあります。
- プロダクトオーナーも外部に委託してよいですか?
原則として自社で持つべきです。プロダクトオーナーは「何を作るか・優先順位をどうするか」を決めるビジネス上の意思決定責任を担うロールで、外部に委ねるとプロダクトの主導権を失います。外に出すのはスクラムの運営支援や開発作業に留めるのが安全です。
- 外部委託で始めても、いずれ社内で内製化することはできますか?
可能ですが、契約開始時に「知見移転」「社内メンバーの育成」を支援範囲として明確に依頼しておくことが前提です。外部に頼り切ると契約終了後に社内へ何も残らないため、いつ・どう役割を引き継ぐかという出口も初めに描いておきましょう。
- 自社に合うか分からない段階で、いきなり長期契約を結ぶのが不安です。
まずは2〜3スプリント程度の短期トライアルやコーチング型の軽い関与から始めるのがおすすめです。自社のチーム・文化に合うか、費用が予算内に収まるかを検証しながら判断でき、合わなければ早期に見直せるためリスクを抑えられます。



