職種・体制

スクラムマスター

（すくらむますたー／Scrum Master）

登場（海外）: 2010年
国内で見られるように: 2013年ごろ
更新: 2026-08-24

一言でいうと

スクラムがチームで機能している状態に責任を持つ役割で、進捗を管理するのではなく、進行を妨げている要因を取り除きます。

この職種の出自と登場時期

Scrum Guide は冒頭で「私たちは1990年代初頭にスクラムを開発した」と述べています。手法そのものは1990年代初頭まで遡ります。ただし役割の責務が公式な文書として定義されたのは2010年です。この年に Ken Schwaber と Jeff Sutherland が Scrum Guide の初版を書き、以降、改訂を重ねながら唯一の定義文書として維持されています。

国内では2013年前後から、認定スクラムマスター研修の受講者が増え、求人票にも現れるようになりました。アジャイル開発を導入する事業会社が増えた時期と重なります。

呼称の理解には注意が要ります。「マスター」という語から管理者と受け取られやすいものの、Scrum Guide が定義する責務は支援と環境整備で、指示によってチームを動かす立場ではありません。この誤解が、国内で導入がうまくいかない典型的な原因のひとつです。

ミッション

問われるのは、チームがスクラムの枠組みを使って自律的に進めているかどうかです。イベントを開催したことではなく、そこでチームが必要な判断をできているかで評価されます。

そのため、成果は目に見えにくくなります。妨げになっている要因が減っているか、チームの見積もりと実績の差が縮んでいるか、ふりかえりで出た改善が実行されているかといった、チーム側の変化で測ることになります。

主な業務範囲

スクラムイベントの運営。スプリントプランニング、デイリー、レビュー、レトロスペクティブを機能させる
妨げの除去。チームの外にある障害を特定し、関係部署と交渉して取り除く
プロダクトオーナーの支援。バックログの整理と優先順位づけの進め方を助ける
組織への働きかけ。スクラムを妨げている社内の慣行や制度に対して改善を提案する
チームの育成。自己管理できる状態へ近づくよう、進め方の判断をチームへ移していく

求められる能力

開発チームの議論についていける程度の知識は要ります。実装できる必要はありませんが、技術的な難しさが分からないと、見積もりの妥当性を判断できません。

技術以外では、ファシリテーションと交渉が中心になります。答えを出すのではなく、チームが自分で答えを出せるように場を作る進め方が求められます。指示で解決したくなる場面で我慢できるかどうかが、この役割の分かれ目です。

この職種に就く人のキャリア経路

多いのは開発チームのメンバーからの兼務です。専任として置く組織は限られ、エンジニアやQAが兼ねる形が国内では一般的です。プロジェクトマネージャーから移る例もありますが、指示型の進め方から切り替える必要があります。

この先は、アジャイルコーチとして複数チームを支援する道、Engineering Manager、プロダクトオーナーへ進む道に分かれます。

隣接職種との違い

職種	責任の中心	スクラムマスターとの違い
プロジェクトマネージャー	期日・予算・進行の管理	計画どおり進めることが責任。スクラムマスターはチームが自律する状態づくりが責任
Engineering Manager	メンバーの成長・評価・組織の成果	評価権限を持つ。スクラムマスターは評価者ではない
プロダクトオーナー	プロダクトの価値と優先順位の決定	何を作るかを決める。スクラムマスターはどう進めるかを支える
アジャイルコーチ	組織全体へのアジャイルの導入と定着	対象が組織。スクラムマスターは担当チームが単位

採用担当の見極めポイント

求人票では、専任か兼務かを明記してください。専任のスクラムマスターを置ける組織は限られ、兼務なら主となる職務を書く必要があります
経歴書では、資格の有無ではなく、チームがどう変わったかを確認してください。研修の受講歴だけでは実務の力を判断できません
経営や他部署がスクラムの前提を理解しているかを、募集前に確認してください。組織側が変わらないままでは、この役割は形だけになります

求人・市場の傾向

専任の求人は限られ、開発職やQAの募集要件のなかに含まれる例が中心です。媒体では各領域の職種カテゴリで引き、経歴のなかにスクラムの運営やチーム改善の記述があるかで絞る進め方が現実的です。

既存のスクラムがどこで止まっているかを、正直に書いてください。うまくいっている前提の求人は、経験者ほど信じません。