開発会社から「アジャイルで進めます。スクラムマスターが必要です」と言われ、提案書や見積に書かれた「アジャイルコーチ」「スクラムマスター」という言葉に戸惑っていませんか。役割の違いも、本当に必要なのかも、費用を誰が負担するのかも判然としないまま、発注の判断を迫られているという方は少なくありません。
ウォーターフォール型の発注に慣れていると、「進行役にわざわざ専任の人を立てて費用を払う」という構造そのものが腑に落ちにくいものです。さらに厄介なのは、その役割を開発会社に任せるべきなのか、自社が担うべきなのかという論点が、費用負担とプロジェクトの主導権の両方に直結している点です。ここを曖昧にしたまま発注すると、想定外のコストが発生したり、開発がブラックボックス化して中身が見えなくなったりするリスクがあります。
本記事では、発注者（クライアント）の立場から、アジャイルコーチとスクラムマスターの違い・役割を整理したうえで、もっとも重要な「スクラムマスターを誰が担うのか」の判断基準を、3つのパターンとチェックリストで具体的に解説します。最後まで読めば、自社プロジェクトに合った体制を社内で説明でき、開発会社との費用交渉・体制協議に自信を持って臨めるようになります。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
アジャイルコーチとは？発注者がまず押さえるべき基本
アジャイルコーチとは、ひとことで言えば「組織やチームがアジャイル開発をうまく進められるよう、外から支援する専門家」です。個々のプロジェクトの進行役というより、複数のチームや組織全体に対して、アジャイルの考え方・進め方を定着させる役割を担います。
発注者の立場でこの言葉に出会うのは、たいてい開発会社の提案や、社内の「アジャイルでやろう」という方針転換の場面でしょう。まず押さえておきたいのは、「アジャイルコーチ」と「スクラムマスター」は別の役割であり、必要になる場面も異なるということです。多くの発注プロジェクトで実際に論点になるのは、後ほど詳しく説明するスクラムマスターのほうです。
アジャイルコーチの役割をひとことで言うと
アジャイルコーチの主な仕事は、組織やチームが自律的にアジャイル開発を回せる状態に育てることです。具体的には、複数チームをまたいだ進め方の標準化、開発文化の醸成、マネジメント層への助言など、「1つのプロジェクトを動かす」より広い範囲を対象にします。
つまりアジャイルコーチが本領を発揮するのは、「全社的にアジャイルへ移行したい」「複数のプロダクトチームを抱えていて足並みを揃えたい」といった、組織変革フェーズの場面です。1チームで1つのシステムを開発する、という規模の発注では、アジャイルコーチが前面に出てくることはそれほど多くありません。
「社外コーチ」と「社内コーチ」がいる
アジャイルコーチには、外部から招く「社外コーチ」と、社内人材が務める「社内コーチ」の2種類があります。発注者がコストとして意識することになるのは、主に開発会社やコンサルティング会社から派遣される社外コーチです。
ただし繰り返しになりますが、1つのシステム開発を委託するという通常の発注では、見積で目にする項目はアジャイルコーチではなくスクラムマスターであることがほとんどです。「コーチとマスターの両方に費用を払う必要があるのか」と不安に感じた方は、まず両者の違いを理解しておけば、提案内容の妥当性を判断しやすくなります。
アジャイルコーチとスクラムマスターの違い
アジャイルコーチとスクラムマスターは、対象とする範囲（スコープ）と関与の深さが大きく異なります。発注者として混同しやすいポイントなので、ここで整理しておきましょう。
役割・スコープの違い
両者の違いを表にまとめると、次のようになります。
比較項目 | アジャイルコーチ | スクラムマスター |
|---|---|---|
対象範囲 | 組織全体・複数チーム横断 | 単一のスクラムチーム内 |
主な目的 | アジャイル文化の定着・組織変革 | チームが円滑に開発を回せるよう支援 |
関与の深さ | 助言・育成が中心（伴走型） | チームの一員として日常的に関与 |
関わる期間 | 変革フェーズの一定期間 | プロジェクト期間を通して継続 |
発注で登場する頻度 | 組織変革時に限られる | アジャイル開発の発注で一般的 |
ざっくり言えば、スクラムマスターは「1つのチームの中に入って毎日の開発を支える人」、アジャイルコーチは「複数のチームや組織を外から育てる人」です。スクラムマスターが経験を積み、より広い視野で組織を支援する立場に発展したのがアジャイルコーチ、と捉えるとイメージしやすいでしょう。
発注者にとっての違い「どちらの費用を見積で見ることになるか」
発注者にとって実務上重要なのは、「自社のプロジェクトでは、どちらの費用が見積に乗ってくるのか」という点です。
1つのシステムやサービスを1チームで開発するという一般的な委託では、見積に含まれるのはスクラムマスターの費用です。一方、「全社的にアジャイル開発を導入したい」「複数の開発チームの進め方を統一したい」という組織変革を伴う場合に限り、アジャイルコーチの費用が登場します。
したがって、もし1チーム規模のプロジェクトなのに提案書へアジャイルコーチの費用が計上されていたら、その必要性を開発会社に確認するのが妥当です。逆に組織横断の改革を狙っているのにスクラムマスターしか想定されていなければ、コーチの要否を議論する余地があります。以降は、多くの発注で論点になるスクラムマスターに焦点を当てて解説します。
スクラムマスターの役割（発注者視点で読み解く）
スクラムマスターは、アジャイル開発の代表的な手法である「スクラム」において、チームが円滑に開発を進められるよう支援する役割です。役割の定義はスクラムの公式ガイド（スクラムガイド）に示されていますが、ここでは発注者にとって「自社のプロジェクトに何をもたらすか」という観点に翻訳して読み解きます。
スクラムマスターの主な3つの仕事
スクラムマスターの仕事は、大きく次の3つに整理できます。
- チームの自己組織化を支援する: 開発チームが自分たちで考えて動けるよう、進め方をサポートします。指示命令で管理するのではなく、チームが自律的に成果を出せる状態を作るのが目的です。
- 障害を取り除く: 開発が滞る原因（仕様の不明点、関係部署との調整、ツールの問題など）をいち早く検知し、解消に動きます。発注者から見ると「開発が止まらないよう先回りで手を打ってくれる人」です。
- プロセス改善を回す: スプリント（短い開発サイクル）ごとに振り返りを行い、チームの進め方を継続的に改善します。
発注者にとって重要なのは、スクラムマスターが単なる「進行役・調整役」ではなく、開発のスピードと品質を左右する存在だという点です。優秀なスクラムマスターがいるチームは、問題が小さいうちに解消され、手戻りが減り、結果として発注者が支払う総コストの抑制につながります。
スクラムマスターが進行を担うスプリントの具体的な進め方や、発注者としての関わり方については、スプリントとは？発注者が知るべきスプリントレビューの関わり方と費用評価で詳しく解説しています。
プロダクトオーナーとの違い（発注者はどちらに近いか）
スクラムには、スクラムマスターのほかに「プロダクトオーナー」という重要な役割があります。両者の違いを理解しておくと、発注者である自社がどの立場を担うべきかが見えてきます。
- プロダクトオーナー: 「何を作るか」を決め、開発の優先順位を判断する責任者。プロダクトの価値を最大化する立場です。
- スクラムマスター: 「どうチームを支えるか」に責任を持つ役割。プロセスを円滑に回す立場です。
発注者である自社は、多くの場合プロダクトオーナーに近い立場になります。なぜなら、何を作りたいか・どの機能を優先するかを決めるのは、発注した自社だからです。この役割分担を理解しておくと、「自社はプロダクトオーナーとして要件と優先順位に集中し、スクラムマスターをどうするかは別途決める」という整理ができます。
発注者から見た「良いスクラムマスター」の見分け方
発注者が体制を判断するうえで、良いスクラムマスターの特徴を知っておくと役立ちます。次のような点に注目してください。
- 専門用語を並べず、開発の状況を発注者にわかる言葉で説明できる
- 問題が起きてから動くのではなく、リスクを先回りして共有してくれる
- チームを管理・支配するのではなく、チームの力を引き出そうとする姿勢がある
- スクラム認定資格（CSMやPSMなど）の有無は参考になるが、資格よりも実プロジェクトでの経験を重視する
開発会社に体制を提案された際は、「想定しているスクラムマスターはどのような経験を持つ方か」を確認すると、その提案の質を測る材料になります。
誰がスクラムマスターを担うのか——3パターンと判断基準
ここが本記事のもっとも重要なテーマです。「スクラムマスターが必要」と言われたとき、発注者が直面するのは「では、誰がその役割を担うのか」という問いです。これは費用負担とプロジェクトの主導権の両方に直結する、避けて通れない意思決定です。
担い手のパターンは、大きく次の3つに分けられます。それぞれのメリット・リスク・向くケースを整理します。
パターンA：開発会社が専任スクラムマスターを立てる
開発会社が、スクラムマスター専任の人材をプロジェクトに配置するパターンです。
- メリット: 経験豊富な専任者が常時チームを支えるため、開発の安定性がもっとも高い。発注者は要件の検討に集中できる。
- 費用: 専任分の人件費が見積に上乗せされる（具体的な相場は後述します）。3つのパターンの中でもっとも費用がかかる。
- リスク: 開発会社にプロセス全体を委ねるため、発注者が意識的に関与しないと開発の中身が見えにくくなる（ブラックボックス化）。これを防ぐには、後述するプロダクトオーナーとしての関与が欠かせません。
- 向くケース: プロジェクト規模が大きい／開発が複雑／納期が厳しく失敗が許されない／社内にアジャイル経験者がいない場合。
パターンB：開発会社のエンジニアが兼任する
開発会社のリードエンジニアなどが、開発業務と並行してスクラムマスターを兼任するパターンです。
- メリット: 専任者を立てないぶん費用を抑えられる。小規模なチームでは、技術に精通した人が進行も担うことで意思疎通がスムーズになる場合がある。
- リスク: 兼任者の負荷が高く、開発が忙しくなるとスクラムマスター業務が後回しになりがち。本来取り除くべき障害が放置され、プロセス改善が止まるおそれがある。
- 向くケース: チーム人数が少なく（おおむね5〜6名以下）、開発内容がシンプルで、関係者間の調整も限定的な小規模プロジェクト。
兼任を提案された場合は、「兼任者が開発とスクラムマスター業務のどちらを優先するのか」「負荷が高まったときの体制はどうするか」を事前に確認しておくと安心です。
パターンC：発注者側がスクラムマスターを担う
発注者である自社の人材が、スクラムマスターを担うパターンです。
- メリット: プロジェクトの主導権を自社が握れる。開発の進捗・課題がリアルタイムで把握でき、ブラックボックス化を根本から防げる。アジャイルのノウハウが社内に蓄積される。
- 前提条件: スクラムマスターの役割を理解し、チームに日常的に関与できる人材を社内に確保できること。専任に近い時間を割けることが望ましい。
- 難易度: 社内にアジャイル経験者がいない場合、立ち上げ時の負荷とつまずきのリスクが大きい。最初は開発会社のスクラムマスターやアジャイルコーチの支援を受けながら、徐々に自社へ移管する進め方が現実的です。
- 向くケース: 継続的にアジャイル開発を続ける見込みがあり、社内にノウハウを残したい／主導権を確保したい場合。
避けるべき組み合わせ（プロダクトオーナーとスクラムマスターの兼任など）
担い手を決めるうえで、避けたほうがよい組み合わせがあります。代表的なのが、プロダクトオーナーとスクラムマスターの兼任です。
先ほど説明したとおり、プロダクトオーナーは「何を作るか」を決め、スクラムマスターは「チームをどう支えるか」に責任を持ちます。この2つは時に利害が対立します。たとえば「もっと早く機能を盛り込みたい」というプロダクトオーナーの意向と、「チームに無理をさせず持続可能なペースを守りたい」というスクラムマスターの立場は、ぶつかることがあります。1人が両方を兼ねると、どちらかの視点が抑え込まれ、健全なブレーキが効かなくなってしまいます。
発注者がプロダクトオーナーを担う場合、自社の同じ担当者がスクラムマスターも兼ねるのは避け、別の人材か開発会社側に任せるのが基本です。
判断チェックリスト（プロジェクト規模・社内人材・主導権の優先度で選ぶ）
3つのパターンのどれを選ぶか、次のチェックリストで整理してみてください。
判断軸 | パターンA（開発会社が専任） | パターンB（開発会社が兼任） | パターンC（発注者が担う） |
|---|---|---|---|
プロジェクト規模 | 中〜大規模 | 小規模（5〜6名以下） | 規模を問わない |
社内のアジャイル経験 | 不要 | 不要 | 望ましい（なければ支援前提） |
失敗の許容度 | 低い（失敗が許されない） | ある程度許容できる | 立ち上げ期は許容が必要 |
主導権・ノウハウ蓄積 | 開発会社主導 | 開発会社主導 | 自社主導 |
費用 | 高い | 抑えられる | 人件費＋立ち上げ負担 |
判断に迷ったときの優先順位の付け方として、次の3つの問いが役立ちます。
- 失敗が許されないプロジェクトか？ → そうであればパターンA（専任）が無難です。
- 社内にアジャイルを理解し、関与できる人材がいるか？ → いなければパターンC（自社が担う）は支援なしでは困難です。
- アジャイル開発を今後も続け、ノウハウを社内に残したいか？ → そうであればパターンCを、支援を受けながら段階的に目指す価値があります。
いずれのパターンを選んでも、発注者がプロダクトオーナーとして要件と優先順位に責任を持つ姿勢は変わりません。スクラムマスターを開発会社に任せる場合でも、定例の振り返りや進捗確認に発注者が参加することで、ブラックボックス化は十分に防げます。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
スクラムマスター・アジャイルコーチの費用感（発注者が負担構造を理解する）
担い手のパターンが見えてきたら、次は費用です。費用は「誰が担うか」と切り離せません。ここでは相場と負担構造を整理します。
スクラムマスターの月額費用相場
外部のスクラムマスターを起用する場合の月額費用は、おおむね次の水準が目安です。
- スクラム開発全体での相場として、スクラムマスターの単価は月100万〜150万円程度が目安とされ、シニアクラスやより広い役割を担う場合は月150万〜250万円に達することもあります（株式会社ripla「スクラム開発の見積相場や費用」）。
- フリーランス案件として見た場合、スクラムマスターの月額平均単価は約88万円、最高単価は90万円という公開データもあります（2025年5月時点、テックタレントフリーランス スクラムマスター案件）。
このように幅があるのは、経験レベル・実績・プロジェクトの規模や複雑さによって単価が大きく変動するためです。発注者としては、「提示された費用がこの相場のどのあたりに位置するか」「その金額に見合う経験を持つ人材か」を確認の起点にするとよいでしょう。
専任・兼任で費用はどう変わるか
費用は担い手のパターンによって変わります。
- パターンA（開発会社が専任）: 専任スクラムマスター1名分の人件費がまるごと見積に計上されます。上記相場が、ほぼそのまま発注者の負担になります。
- パターンB（開発会社が兼任）: 専任分の費用は発生しませんが、兼任者の工数の一部がスクラムマスター業務に充てられるぶん、エンジニアとしての開発アウトプットは専念時より下がります。「安く見える」分の一部は、開発速度の低下という形で表れることに注意が必要です。
- パターンC（発注者が担う）: 開発会社への支払いは抑えられますが、後述する自社側のコストが発生します。
見積を受け取ったら、スクラムマスターの費用が「どの項目に・専任か兼任か・何名分として」含まれているかを開発会社に確認しましょう。費用が明細に現れず工数にまとめられている場合もあるため、内訳の説明を求めることが大切です。
発注者が担う場合の「見えにくいコスト」
パターンCを選ぶと開発会社への支払いは減りますが、その分は「自社のコスト」に置き換わります。見落とされがちなコストを挙げておきます。
- 担当者の人件費・工数: スクラムマスターは片手間でこなせる役割ではありません。担当者の時間が、本来の業務から相応に割かれます。
- 立ち上げの学習コスト: 社内にアジャイル経験者がいない場合、進め方の習得に時間がかかり、初期はつまずきも避けられません。
- 支援を受ける費用: 立ち上げ期に開発会社のスクラムマスターやアジャイルコーチの支援を受ける場合、その費用が発生します。
つまりパターンCは「無料で主導権が手に入る」わけではなく、「外部への支払いを、自社内の人件費とノウハウ獲得への投資に振り替える」選択だと理解しておくことが重要です。
費用対効果をどう判断するか
費用の絶対額だけでなく、「その費用が何を生むか」で判断するのが本質です。スクラムマスターへの支出は、次のような効果を通じて回収されると考えられます。
- 開発の停滞・手戻りが減り、結果として総開発コストが抑えられる
- 問題の早期発見により、プロジェクト全体の失敗リスクが下がる
- 発注者側の進捗把握が容易になり、意思決定が速くなる
一方で、小規模・短期で開発内容もシンプルなプロジェクトに高額な専任スクラムマスターを付けると、費用が効果を上回ることもあります。プロジェクトの規模・複雑さ・期間に見合った担い手とコストを選ぶ——これが費用対効果を判断する基本姿勢です。
まとめ——自社プロジェクトに合った担い手を選ぶために
ここまで、発注者の視点でアジャイルコーチとスクラムマスターの違い・役割、そして「誰がスクラムマスターを担うか」の判断基準と費用感を整理してきました。要点を振り返ります。
- アジャイルコーチとスクラムマスターは別物。組織変革を伴わない通常の1チーム開発で論点になるのは、ほとんどの場合スクラムマスターです。
- スクラムマスターは進行役以上の存在で、開発のスピードと品質、ひいては総コストを左右します。
- 担い手は3パターン（開発会社が専任／開発会社が兼任／発注者が担う）あり、プロジェクト規模・社内人材・主導権の優先度で選びます。
- 費用は担い手と不可分。外部起用なら月100万〜250万円程度（フリーランスで平均約88万円）が目安で、自社が担う場合は人件費と立ち上げ負担に置き換わります。
- プロダクトオーナーとスクラムマスターの兼任は避ける。発注者は基本的にプロダクトオーナーの立場に集中します。
次のアクションとしては、まず自社プロジェクトをチェックリストの判断軸（規模・社内人材・失敗の許容度・主導権・費用）に当てはめて、どのパターンが妥当かの仮説を立ててみてください。そのうえで開発会社に対して、「スクラムマスターは専任か兼任か」「費用は見積のどこに含まれるか」「どのような経験を持つ人材か」を確認すれば、体制と費用の交渉を主体的に進められます。
スクラムマスターが日々運営するスプリントの具体的な進め方や、発注者としてスプリントレビューにどう関わるべきかは、スプリントとは？発注者が知るべきスプリントレビューの関わり方と費用評価で詳しく解説しています。あわせて読むことで、アジャイル開発を委託する際の判断材料がより具体的になります。
よくある質問（FAQ）
アジャイルコーチとは何ですか？
アジャイルコーチとは、組織やチームがアジャイル開発をうまく進められるよう、外から支援する専門家です。1つのプロジェクトの進行役というより、複数チームや組織全体に対してアジャイルの考え方・進め方を定着させる役割を担います。全社的なアジャイル導入や組織変革の場面で起用されることが多く、1チームでのシステム開発の発注では、後述のスクラムマスターのほうが論点になるのが一般的です。
スクラムマスターの役割は何ですか？
スクラムマスターの主な役割は、(1) 開発チームの自己組織化を支援する、(2) 開発の障害を取り除く、(3) プロセス改善を継続的に回す、の3つです。発注者から見ると、単なる進行役ではなく、開発のスピードと品質を支え、手戻りや停滞を減らして総コストの抑制につなげる存在です。
スクラムマスターは必ず専任で立てる必要がありますか？
必ずしも専任である必要はありません。チーム人数が少なく（おおむね5〜6名以下）、開発内容がシンプルな小規模プロジェクトでは、開発会社のエンジニアが兼任するケースもあります。ただし兼任の場合、開発が忙しくなるとスクラムマスター業務が後回しになるリスクがあります。中〜大規模で失敗が許されないプロジェクトでは、専任を立てるほうが安定します。
スクラムマスターとプロダクトオーナーは兼任できますか？
兼任は推奨されません。プロダクトオーナーは「何を作るか」を決める立場、スクラムマスターは「チームをどう支えるか」に責任を持つ立場で、両者は時に利害が対立します。1人が兼ねると健全なブレーキが効かなくなるため、別々の人材が担うのが基本です。発注者がプロダクトオーナーを担う場合、スクラムマスターは別の人材か開発会社側に任せましょう。
発注者側がスクラムマスターを担うことはできますか？
可能です。自社が担うとプロジェクトの主導権を握れ、開発のブラックボックス化を防ぎ、アジャイルのノウハウを社内に蓄積できます。ただし、役割を理解しチームに日常的に関与できる人材の確保が前提です。社内にアジャイル経験者がいない場合は、立ち上げ期に開発会社のスクラムマスターやアジャイルコーチの支援を受けながら、段階的に自社へ移管する進め方が現実的です。
スクラムマスターを外注する場合の費用はいくらですか？
外部のスクラムマスターを起用する場合、月額の目安はおおむね100万〜250万円程度です。スクラム開発全体での相場ではスクラムマスターの単価は月100万〜150万円程度、シニアクラスでは月150万〜250万円に達することもあります（出典: 株式会社ripla）。フリーランス案件では月額平均単価が約88万円という公開データもあります（2025年5月時点、出典: テックタレントフリーランス）。経験レベル・実績・プロジェクト規模により大きく変動するため、提示された費用が相場のどこに位置するかを確認するとよいでしょう。
画像指示
- アイキャッチ推奨クエリ: "agile software development team planning meeting"
挿入位置（H2見出し） | クエリ |
|---|---|
誰がスクラムマスターを担うのか——3パターンと判断基準 | "agile team collaboration meeting whiteboard" |
スクラムマスター・アジャイルコーチの費用感（発注者が負担構造を理解する） | "business budget planning office" |
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
