スクラムマスターの役割 完全解説｜チームのコーチ・障害除去・組織変革を担うサーバントリーダー

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

スクラムマスターが機能しない根本原因は、「プロジェクトマネージャーと同じように指示・管理しようとすること」にあります。 結論から言えば、スクラムマスターは「決める人」ではなく「チームが自己管理できるよう支援する人」であり、スクラムガイド2020はこれをサーバントリーダーシップという言葉で表現しています。たとえばデイリースクラムで「今日は○○さんがAタスクを、△△さんがBタスクを担当してください」と指示するスクラムマスターは、スクラムの本質から外れています。本記事では、スクラムガイド2020に基づき、スクラムマスターの3つのアカウンタビリティ・PMとの違い・4つのスタンス・よくある失敗を1本に整理します。

スクラムマスターとは｜公式定義と「アカウンタビリティ」という概念

スクラムガイド2020は、スクラムマスターを次のように定義しています。

スクラムマスターは、スクラムガイドで定義されたスクラムを確立することに責任を持つ。スクラムマスターは、スクラムチームとより大きな組織の両方でスクラムの理論とプラクティスを誰もが理解できるよう支援することで、スクラムを実現させる責任がある。

重要なのは、スクラムマスターが持つのは「プロジェクトの成功責任」ではなく、「スクラムが正しく機能するよう支援する責任」だという点です。スクラムガイド2020は「役割（Role）」という表現を廃止し、代わりにアカウンタビリティ（説明責任） という概念を採用しています。これはPO・SM・開発者が別々のグループではなく、同じ1つのスクラムチームの中に存在する3つの責任であることを示しています。

スクラムマスターの3つのアカウンタビリティ

スクラムガイド2020は、スクラムマスターの責任を3つの対象（スクラムチーム・プロダクトオーナー・組織）への奉仕として整理しています。

① スクラムチームへの奉仕

スクラムマスターがチームに対して担う主な責任は次の4点です。

責任	具体的な行動
コーチング	メンバーが自己管理型・機能横断型のチームとして機能できるようコーチする
集中の支援	完成の定義の範囲内で高い価値のインクリメントを生み出すことへの集中を支援する
障害の除去	チームの進捗を妨げる障害（インピディメント）を見つけ、除去または軽減する
イベントの有効化	すべてのスクラムイベントが開催され、ポジティブで生産的かつタイムボックス内に収まるよう確実にする

コーチングと指示の違いを押さえておくことが重要です。コーチングとは「答えを与える」のではなく、「チーム自身が答えを見つけられるよう問いかける」アプローチです。「どうすればいいと思いますか？」「この問題を解決するために、チームで何ができそうですか？」という問いかけがコーチングの典型です。

障害（インピディメント） とは、チームがスプリントゴール達成に向けて動く際の妨げになるものすべてを指します。技術的な環境問題（CIが壊れている、環境構築手順が不明確）だけでなく、組織的な障壁（隣部署との調整が進まない、意思決定者がつかまらない）も含まれます。

② プロダクトオーナーへの奉仕

スクラムマスターはPOに対しても奉仕する責任を持ちます。

責任	具体的な内容
バックログ管理の支援	効果的なプロダクトゴールの定義とプロダクトバックログ管理の技術を見つけるのを支援する
明確化の支援	バックログの項目を明確に簡潔に表現する必要性についてPOが理解するよう助ける
計画法の支援	複雑な環境における経験主義的なプロダクト計画法の確立を支援する
連携の促進	ステークホルダーとの連携が必要な場合に、それを促進する

POへの奉仕でスクラムマスターがよく担う実務は、バックログリファインメント（バックログの整備・見積もり）のファシリテーションです。「このユーザーストーリーはINVESTの”Small”を満たしているか？」「受け入れ条件が書けない状態のものは分割が必要では？」といった問いかけを通じて、POとチームが質の高いバックログを維持できるよう支援します。

③ 組織への奉仕

スクラムマスターはチームの外にも目を向け、組織全体のスクラム浸透を担います。

責任	具体的な内容
スクラム導入のリード	スクラムの採用に関して組織をリードし、トレーニング・コーチングを行う
実装の助言	組織内でのスクラムの実装を計画し、助言する
理解の支援	経験主義的アプローチを従業員やステークホルダーが理解し実施できるよう支援する
バリアの除去	スクラムチームとステークホルダーの間のバリアを取り除く

組織への奉仕は、スクラムマスターの役割の中で最も見えにくく、かつ長期的に重要な部分です。「隣部署がスクラムを理解していないため、スプリントレビューに参加してもらえない」「経営層が週次レポートを求めてきてスプリントのリズムが崩れる」といった組織的な摩擦を取り除くのも、スクラムマスターの仕事です。

スクラムマスターとプロジェクトマネージャー（PM）の違い

スクラムマスターとPMは、どちらもプロジェクトの成功を支援する存在ですが、根本的なアプローチが異なります。

比較軸	スクラムマスター	プロジェクトマネージャー
リーダーシップスタイル	サーバントリーダー（奉仕型）	コマンド＆コントロール（指示型）
意思決定権	意思決定権を持たない（チームが自己決定）	意思決定権あり
計画の立案者	チームが計画を立てる（SMは支援）	PMが計画を立てる
作業の割り当て	チームが自分で決める（SMは割り当てない）	PMが割り当てる
進捗管理の手法	経験主義（透明性・検査・適応）	計画ベース（ガントチャート等）
責任の対象	スクラムが正しく機能すること	プロジェクト全体の成功
指向する開発スタイル	スクラム（アジャイル）	ウォーターフォール含む全般
チームとの関係	チームと対等（同じスクラムチームの一員）	チームの上位管理者

スクラムマスターの4つのスタンス

Scrum Inc. Japan は、スクラムマスターが使い分ける4つのスタンスを次のように整理しています。チームの状況に応じてスタンスを柔軟に切り替えることが、優れたスクラムマスターの特徴です。

Teaching（ティーチング）— 教える

スクラムの価値観・理論・プラクティスを、チームや組織が理解できるよう教えるスタンスです。スクラムを始めたばかりのチームや、スクラムの概念が浸透していない組織に対して有効です。「デイリースクラムの目的は進捗報告ではなく計画の調整です」のように、正しい理解を伝えます。

Facilitating（ファシリテーティング）— 促進する

スクラムイベントやチームの対話を促進するスタンスです。スプリントプランニング・スプリントレビュー・スプリントレトロスペクティブでは、議論が発散しないよう時間を管理し、全員が発言できる場を作り、合意形成を助けます。ファシリテーターは議論の「中身」ではなく「プロセス」を管理することに徹します。

Mentoring（メンタリング）— 助言する

チームメンバーが経験から学べるよう、スクラムマスター自身の経験をもとにアドバイスするスタンスです。「前のチームで同じ問題が起きた時は〇〇という方法が有効でした」のように、具体的な経験を共有します。コーチングが「答えを引き出す」のに対し、メンタリングは「答えを提示する」点が異なります。

Coaching（コーチング）— 気づかせる

チームや個人が自ら気づき、自分で答えを見つけられるよう問いかけるスタンスです。スクラムチームが自律性を持って成長するためには、最終的にコーチングが最も重要なスタンスです。「この問題を解決するために、チームとして何ができると思いますか？」「今週のレトロスペクティブで、何を試してみたいですか？」という問いかけが典型例です。

スクラムマスターの1日の活動例

スクラムマスターは会議を「こなす」のではなく、各活動に目的を持って臨みます。以下は標準的なスプリント中の活動例です。

活動	目的と注意点
デイリースクラム（15分）	ファシリテーション。インピディメントをその場で拾い上げる。「報告会」にならないよう場を設計
インピディメント対応	チームから上がった障害を追跡・除去。組織障壁はその日中に担当者にコンタクト
バックログリファインメント支援	POと開発者の対話を促進。ストーリーの明確化・分割・見積もりをファシリテート
ステークホルダーとの調整	チームを巻き込まずに済む組織調整をSMが代行。チームの時間を守る
自己研鑽	スクラムに関する書籍・コミュニティ・カンファレンスから学び続ける
1on1（必要に応じて）	個別のコーチングセッション。チームには見えにくい個人の困りごとを引き出す

---

スクラムマスターがやってはいけないこと

スクラムガイドとスクラムの経験主義から逸脱する行動は、チームの自己管理を損ないます。

やってはいけないこと	なぜ問題か
タスクを割り当てる	開発者が「誰がいつまでに何をやるか」を自分たちで決めることがスクラムの核心。SMが割り当てると自己管理が育たない
スプリントゴールを一人で決める	スプリントゴールはPOが提案し開発者が合意して初めて確定する。SMが単独で決める権限はない
デイリースクラムで進捗を管理する	デイリーはSMへの報告の場ではなく、開発者が自分たちのスプリントゴールへの進捗を検査し計画を調整する場
インピディメントを「上に伝えた」で終わる	伝えた後に障害が解消されるまで追い続けるのがSMの責任。報告して終わりでは障害は残る
スクラムイベントをスキップする	スクラムガイドはすべてのイベントを省略不可と定めている。「忙しいからデイリーは今週なし」はスクラムを壊す
メンバーの問題を代わりに解決する	チームが問題を解決できる力を育てることが目的。毎回SMが解決すると依存が生まれる

---

---

よくある失敗5選

失敗① デイリースクラムを「進捗報告会」にしてしまう

「昨日○○をやりました。今日は○○をやります。問題はありません」が毎日同じように続く、いわゆるゾンビデイリー。チームメンバーがSMやPMに報告するための場と誤解しているケースです。デイリースクラムは開発者がスプリントゴールへの自分たちの進捗を検査し、計画を調整するための場であり、SMへの報告の場ではありません。SMが「今日の予定は？」と質問することで報告構造を作ってしまっていないか確認しましょう。

失敗② インピディメントを「受け取るだけ」で解消しない

「Aさんから○○という障害を受け取りました、上に伝えます」と言ったまま障害が放置される。障害はインピディメントリストに記録し、誰が・いつまでに・何をするかをチームと合意し、解消されるまで追い続けることが責任です。

失敗③ レトロスペクティブで「Tryが10個以上」出てしまう

「改善したいことが山盛り出てきた」はよく聞く話ですが、Try（試してみること）が多すぎると次のスプリントで一つも実行されない結果に終わります。Tryは2〜3個に絞り、実行担当者と確認日を決めることで「決めて終わり」を防ぎます。次のレトロスペクティブの冒頭で前回のTryを必ず確認する文化が定着するまで、SMが意識的に促す必要があります。

失敗④ スクラムマスターとPMを同時に演じる

スプリントプランニングでは「どのタスクをやるかは自分たちで決めてください」と言いながら、翌日のデイリーで「○○さん、あのタスクはどうなっていますか？」と進捗を追い詰める。チームは「結局指示・管理している」と感じ、自己管理の動機が失われます。二つの役割を持つ場合は、どの場でどのスタンスで話しているかを明示することが重要です。

失敗⑤ スクラムのプラクティスだけを守り、価値観を浸透させない

スプリントのタイムボックスを守り、全イベントを開催しているが、チームに「透明性・検査・適応」という経験主義の3本柱が根づいていない。スクラムは「型を守れば成果が出るプロセス」ではなく、「価値観と原則に基づいて判断できるチームを作るフレームワーク」です。Atlassianが指摘するように、SMの最終的なゴールは「チームがSM不在でも機能すること」です。

---

FAQ

Q. スクラムマスターは開発も担当できますか？

スクラムガイドは禁止していませんが、実務上は推奨されません。SMはチーム全体に目を向け、障害除去・コーチング・ファシリテーションに集中する必要があります。開発タスクを持つとインピディメント対応や即時のコーチングが後回しになりやすく、タイムボックスのある開発コミットメントを持つとSM本来の活動の質が下がります。チームが小さく兼務せざるを得ない場合は、「今はSMとして話している」「今は開発者として話している」をチームに明示することが重要です。

Q. スクラムマスターに資格は必要ですか？

必須ではありませんが、認定スクラムマスター（CSM：Certified Scrum Master） や PSM（Professional Scrum Master） は学習の起点として有効です。CSMはScrum Alliance認定、PSMはScrum.org認定で、どちらもスクラムガイドの理解と実践力を問われます。ただし、資格はスクラムの知識を証明するものであり、チームへの影響力やコーチング力は現場での実践によって磨かれます。

Q. プロダクトオーナーとスクラムマスター、どちらが権力が上ですか？

どちらも上位・下位の関係にありません。スクラムの3つのアカウンタビリティ（PO・SM・開発者）は対等な責任分担です。POは「何を作るか」の最終決定権を持ち、SMはその決定プロセスが円滑に進むよう支援します。組織図上はSMとPOが同じ階層にあることが理想的です。

Q. スクラムマスターは何人のチームまで対応できますか？

スクラムガイドは、スクラムチームを「10人以下」の少人数と定めています。スクラムマスター1人が複数のスクラムチームを掛け持ちするケースもありますが、スクラムを始めたばかりのチームでは1:1の対応が推奨されます。チームが成熟するにつれ、1人のSMが2チームを見ることも可能になります。

Q. スクラムマスターがいなくてもスクラムはできますか？

スクラムガイドはスクラムマスターを3つのアカウンタビリティの一つとして必須と定めており、SMなしはスクラムではありません。ただし、チームが成熟し自己管理が機能している段階では、SMの介入は少なくなります。 スクラムマスターの最終的なゴールは「チームがSMなしでもスクラムを回せる自律性を持つこと」であり、SM自身が不要になることを目指すのがサーバントリーダーシップの本質です。

---

まとめ

スクラムマスターは「チームのコーチ・障害除去者・組織変革推進者」という3つの顔を持つサーバントリーダーです。

• スクラムチームへの奉仕：コーチング・集中の支援・障害除去・イベントの有効化
• プロダクトオーナーへの奉仕：バックログ管理支援・明確化支援・ステークホルダー連携促進
• 組織への奉仕：スクラム浸透・組織内バリア除去・経験主義の浸透支援

PMとの最大の違いは「指示・管理」ではなく「支援・促進」で動くという点であり、タスクを割り当てず、チームが自分たちで決定できる環境を作ることに価値があります。4つのスタンス（Teaching・Facilitating・Mentoring・Coaching）をチームの成熟度に応じて使い分け、「チームがSM不在でも機能する」状態を最終ゴールとして据えることが、スクラムマスターとしての成長の指針になります。

関連記事：スクラムガイド2020完全解説（3つの役割・5つのイベント・3つの作成物の全体像）・スクラムの5つのイベント完全解説・スクラムの3つの作成物 完全解説・ユーザーストーリーの書き方・アジャイルとウォーターフォールの使い分け