スクラムとは｜アジャイル開発での役割と進め方

スクラムとは、アジャイル開発の進め方の中で最も広く使われている枠組みの1つで、短い期間で作って確かめることを繰り返しながら、チームで製品を育てていく方法です。「アジャイル」と「スクラム」は一緒に語られることが多いものの、指しているものは同じではありません。アジャイルは考え方の名前で、スクラムはその考え方を実際の仕事の進め方に落とし込んだ型です。

この記事では、スクラムの考案者が書いた公式のスクラムガイド（2020年11月版の日本語訳）に沿って、スクラムの定義、3つの役割、5つのイベント、3つの作成物を順に説明し、導入の手順と、在宅やリモートのチームで回すときの注意点まで整理します。チームの作業を見える形にする道具の1つとして、国産のプロジェクト管理ツールPinateca（ピナテカ）にも触れます。

アジャイルとスクラムの関係

最初に、アジャイルとスクラムの違いを整理しておきます。

アジャイルは、ソフトウェア開発のための考え方の総称です。2001年に、ソフトウェア開発の実践者たちが「アジャイルソフトウェア開発宣言」をまとめました。その中心にあるのは、次の4つの価値です。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 出典: agilemanifesto.org

宣言はこの4つについて、左側のことがらにも価値があると認めながら、右側のことがらにより価値をおく、と続けています。計画や文書を軽んじるのではなく、変化が大きい仕事では、動くものを早く見せて対話しながら直していくほうが価値を生みやすい、という考え方です。

一方のスクラムは、この考え方を実践するための具体的な枠組みです。誰がどんな責任を持つか、どんな会議をどのくらいの時間で開くか、何を作成物として残すか、を決めています。アジャイルの進め方にはスクラムのほかにも、エクストリーム・プログラミング（XP）やカンバンなどがあります。つまり、アジャイルは「何を大切にするか」、スクラムは「どう進めるか」の答えの1つ、という関係です。

アジャイルソフトウェア開発宣言には、スクラムの考案者であるケン・シュエイバー氏とジェフ・サザーランド氏も名を連ねており、両者は深く結び付いています。ただし、スクラムを使っていなくてもアジャイルな進め方はできますし、スクラムの形だけをまねてもアジャイルにはなりません。

スクラムの定義と考え方の土台

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

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。 出典: scrumguides.org

フレームワークとは、仕事の進め方の骨組みのことです。スクラムガイドは、スクラムを意図的に不完全なものとしており、必要な部分だけを決めて、細かいやり方はチームが状況に合わせて選ぶ作りになっています。

スクラムの考え方の土台は、「経験主義」と「リーン思考」の2つです。スクラムガイドによると、経験主義では、知識は経験から生まれ、意思決定は観察に基づきます。リーン思考では、ムダを省き、本質に集中します。先の見通しが立ちにくい仕事では、最初に完璧な計画を立てるより、小さく作って結果を見て判断するほうが確実だ、という立場です。

この経験主義を支えるのが、「透明性」「検査」「適応」の三本柱です。

• 透明性：作業の状況や成果が、作業する人にも受け取る人にも見えていること
• 検査：成果やゴールへの進み具合を、頻繁に確かめること
• 適応：確かめた結果、ずれや問題が見つかったら、できるだけ早く進め方や作るものを調整すること

スクラムガイドは、透明性が検査を可能にし、検査が適応を可能にすると説明しています。見えていなければ確かめられず、確かめても直さなければ意味がない、という順番です。

さらに、チームの振る舞いの方向を示すものとして、5つの価値基準があります。確約（コミットメント）、集中、公開、尊敬、勇気です。ゴールの達成に責任を持ち、スプリントの作業に集中し、作業や課題を隠さずに見せ、お互いを能力のある個人として尊重し、正しいことをする勇気を持つ、という意味が込められています。

スクラムチームと3つの責任

スクラムの基本の単位は、スクラムチームという小さなチームです。スクラムガイドによると、スクラムチームはスクラムマスター1人、プロダクトオーナー1人、複数の開発者で構成され、通常は10人以下です。チームの中に、上下関係やさらに小さなチームは作りません。

スクラムチームは、機能横断型で自己管理型であるとされています。機能横断型とは、価値を生み出すために必要なスキルを、チーム全体として備えていることです。自己管理型とは、誰が何をいつどのように行うかを、チームの中で決めることです。

チームの中の3つの責任を表に整理します。

責任	人数	主に責任を持つこと
プロダクトオーナー	1人	プロダクトの価値を最大にすること。プロダクトバックログの管理
スクラムマスター	1人	スクラムを確立させること。チームの有効性
開発者	複数	スプリントごとに使える成果物（インクリメント）を作ること

プロダクトオーナー

プロダクトオーナーは、作る製品の価値を最大にすることに責任を持ちます。具体的には、製品の目指す姿（プロダクトゴール）を決めて伝え、やるべきことの一覧（プロダクトバックログ）の項目を作り、並べ替え、誰にでも分かる状態に保ちます。スクラムガイドは、プロダクトオーナーは1人の人間であり、委員会ではないと明記しています。関係者が一覧の内容を変えたいときは、プロダクトオーナーを説得する、という決まりです。

スクラムマスター

スクラムマスターは、スクラムがスクラムガイドの定義どおりに行われるようにすることに責任を持ちます。チームの進捗を妨げる障害物を取り除くよう働きかける、イベントが開かれて時間の上限が守られるようにする、プロダクトオーナーの一覧づくりを支援する、組織にスクラムを広めて指導する、といった役割です。スクラムガイドは、スクラムマスターをチームと組織に奉仕する真のリーダーと表現しています。指示を出す管理職ではない、という点が誤解されやすいところです。

開発者

開発者は、スプリントごとに使える成果物を作ることに責任を持つ人たちです。名前は「開発者」ですが、スクラムガイドは、プログラマーに限らず、スクラムから価値を得ている人は誰でも含まれると説明しています。デザイナーやライター、分析を担う人も、チームで成果物を作るなら開発者です。

なお、スクラムガイドには、プロダクトオーナーやスクラムマスターがスプリントバックログの作業に実際に取り組んでいる場合は、デイリースクラムに開発者として参加する、という記述もあります。小さな組織では1人が複数の責任を持つこともありますが、何を優先するかを決める責任と、進め方を支える責任は性質が違うため、どの立場で発言しているかを本人もチームも意識しておくと混乱を防げます。開発者は、スプリントの計画を作り、品質の基準を守り、毎日計画を見直し、専門家としてお互いに責任を持ちます。

5つのイベントと時間の上限

スクラムでは、決まった会議や期間を「イベント」と呼びます。イベントには時間の上限（タイムボックス）があり、会議が長引くことを防ぎます。スクラムガイドに書かれた上限を、スプリントが1か月の場合で整理します。

イベント	目的	時間の上限
スプリント	ほかのすべてのイベントを含む期間	1か月以内の決まった長さ
スプリントプランニング	スプリントで何をどう進めるかを決める	最大8時間
デイリースクラム	毎日の進み具合を確かめ、計画を見直す	15分
スプリントレビュー	成果を関係者に見せ、次の方向を話し合う	最大4時間
スプリントレトロスペクティブ	進め方を振り返り、改善を決める	最大3時間

スプリントの期間が短ければ、各イベントの時間も短くすることが多いとされています。2週間のスプリントなら、プランニングは半日程度、という具合です。

スプリント

スプリントは、スクラムの心臓の鼓動にたとえられる、1か月以内の決まった長さの期間です。前のスプリントが終わると、すぐに次のスプリントが始まります。プランニング、デイリースクラム、レビュー、レトロスペクティブはすべてスプリントの中で行われます。スプリントの途中では、スプリントゴールの達成を危うくする変更はしない、品質を下げない、という決まりがあります。スプリントを中止する権限を持つのは、プロダクトオーナーだけです。

スプリントプランニング

スプリントの最初に、チーム全体で計画を立てます。スクラムガイドは、話し合う内容を3つのトピックに分けています。このスプリントはなぜ価値があるのか、このスプリントで何ができるのか、選んだ作業をどのように成し遂げるのか、の3つです。1つ目の答えとして、スプリントの目標（スプリントゴール）を決めます。

デイリースクラム

開発者が毎日、同じ時間と場所で15分だけ集まり、スプリントゴールに向けた進み具合を確かめて、その日の計画を見直します。進め方の形は自由で、「昨日やったこと、今日やること、困っていること」を順に話す形に縛られる必要はありません。スクラムガイドは、計画の調整はデイリースクラムのときだけではなく、1日を通じて頻繁に話し合うとしています。細かい相談は、必要な人だけで随時行います。

スプリントレビュー

スプリントの終わりに、成果を関係者に見せて、次に何をするかを一緒に考えます。スクラムガイドは、レビューを単なるプレゼンテーションにしないよう求めています。ワーキングセッション、つまり関係者と一緒に成果を確かめながら次の作業を考える場であり、必要に応じてプロダクトバックログを調整します。

スプリントレトロスペクティブ

スプリントの最後に、チームが自分たちの進め方を振り返ります。人、関わり方、手順、道具、完成の基準について、何がうまくいき、どんな問題があったかを話し合い、改善につながる変更を決めます。改善策は、次のスプリントの作業に組み込むこともできます。

3つの作成物と確約

スクラムでは、作業や価値を表すものを「作成物」と呼びます。作成物は3つあり、それぞれに「確約」と呼ばれる目標や基準が対になっています。

作成物	中身	対になる確約
プロダクトバックログ	製品の改善に必要なものを並べた一覧	プロダクトゴール
スプリントバックログ	スプリントゴールと、選んだ項目と、その進め方の計画	スプリントゴール
インクリメント	プロダクトゴールに向けた具体的な成果物	完成の定義

プロダクトバックログとプロダクトゴール

プロダクトバックログは、製品をよくするために必要なことを、優先する順に並べた一覧です。上にある項目ほど具体的に書かれ、すぐに取りかかれる状態にしておきます。項目を細かく分けて内容を詰める作業を、リファインメントと呼びます。プロダクトゴールは、製品の将来の姿を示す目標で、チームが目指す先になります。

スプリントバックログとスプリントゴール

スプリントバックログは、このスプリントで何をなぜどう進めるかの計画です。開発者が作り、開発者が使うものとされ、スプリントの途中でも学びに応じて更新されます。スプリントゴールは、このスプリントで達成する1つの目標です。

インクリメントと完成の定義

インクリメントは、プロダクトゴールに向けた具体的な踏み石となる成果物です。スクラムガイドでは、完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできないとされています。完成の定義とは、「テストが通っている」「レビューを受けている」「説明書が更新されている」のように、成果物が品質の基準を満たした状態を言葉にしたものです。何をもって完成とするかをチーム全員で共有することで、「できたと思ったのに直しが必要だった」という食い違いを防ぎます。

スクラムの進め方を1サイクルで追う

ここまでの要素を、2週間のスプリントを例に、時間の流れで追ってみます。

1. スプリントの初日に、スプリントプランニングを行う。プロダクトオーナーが優先する項目と、その価値を説明し、チームでスプリントゴールを決める。開発者は、こなせる量を見積もって項目を選び、作業を1日以内で終わる程度に分けてスプリントバックログを作る
2. 2日目から、毎朝15分のデイリースクラムを行う。スプリントゴールに向けて遅れが無いか、障害が無いかを確かめ、その日の計画を見直す
3. 作業の間も、プロダクトオーナーは次のスプリントに向けてプロダクトバックログのリファインメントを進める
4. 最終日の前半に、スプリントレビューを行う。完成の定義を満たした成果物を関係者に見せ、意見をプロダクトバックログに反映させる
5. 最終日の後半に、スプリントレトロスペクティブを行う。進め方を振り返り、次のスプリントで試す改善を1つか2つ決める
6. 翌日から次のスプリントが始まる

この流れを繰り返すことで、2週間ごとに成果を見せて確かめる機会ができ、方向のずれを早く直せるようになります。

スクラムのメリットとデメリット

スクラムの長所と短所を、使う側の視点で整理します。

メリットは主に3つです。1つ目は、方向のずれに早く気づけることです。スプリントごとに動くものを見せるので、「出来上がってみたら思っていたものと違った」という事態を避けやすくなります。2つ目は、優先順位がはっきりすることです。プロダクトバックログを1人のプロダクトオーナーが並べるため、「全部が最優先」という状態になりにくくなります。3つ目は、チームの進め方が継続的に良くなることです。レトロスペクティブで毎回小さな改善を決めるので、同じ問題を繰り返しにくくなります。

デメリットもあります。1つ目は、決まりを守るための手間です。イベントを毎回開くには時間がかかり、少人数のチームでは負担に感じることがあります。2つ目は、全体の期日や費用を最初に約束しにくいことです。変化を前提に進めるため、「いつまでに、いくらで、何が全部できるか」を最初に固めたい契約とは相性が良くありません。3つ目は、役割を理解した人がいないと形だけになりやすいことです。デイリースクラムが上司への報告会になる、レトロスペクティブで改善が決まらない、といった状態では効果が出ません。

スクラムが向いているのは、作るものの答えが最初から決まっておらず、利用者の反応を見ながら直していく仕事です。反対に、仕様が固まっていて変わる見込みが少ない仕事では、最初に計画を立てて順に進める方法のほうが合うこともあります。

従来の進め方との違い

スクラムと比べられることが多いのが、ウォーターフォールと呼ばれる従来の進め方です。ウォーターフォールは、要件を決める、設計する、作る、テストする、という工程を順番に進め、前の工程が終わってから次に移る方法です。水が上から下へ流れるように後戻りしない、という意味で名付けられています。

両者の違いを表に整理します。

観点	ウォーターフォール	スクラム
計画の立て方	最初に全体を細かく決める	全体の方向を決め、細部はスプリントごとに決める
成果を見せる時期	工程の終わり、最後にまとめて	スプリントごとに
変更への向き合い方	変更は手続きを経て例外として扱う	変化を前提に、優先順位を並べ直す
進み具合の測り方	計画に対してどこまで進んだか	動く成果物がどこまでできたか
向いている仕事	仕様が固まっていて変わりにくい仕事	答えが最初から決まっていない仕事

どちらが優れているという話ではありません。法令で決まった手続きをそのままシステムにする、建物のように後から作り直せないものを作る、といった仕事では、最初に計画を固める進め方に理があります。反対に、利用者がどう使うか分からない新しいサービスでは、最初の計画が当たる保証が無いため、短い期間で確かめながら進めるスクラムのほうが無駄が少なくなります。

実際の現場では、全体の予算と大まかな期日は最初に決め、その範囲の中でスクラムを回す、という組み合わせもよく見られます。自分たちの仕事がどちらに近いかを見極めたうえで選ぶことが大切です。

スクラムでよくある誤解

スクラムは用語が多いため、言葉だけが広まって中身が誤解されることがあります。代表的な誤解を5つ整理します。

1つ目は、「スクラムにすれば開発が速くなる」という誤解です。スクラムが目指すのは、価値のあるものを早く確かめることであって、作業の速度そのものを上げることではありません。むしろ、イベントや振り返りに時間を使う分、最初は遅く感じることもあります。

2つ目は、「アジャイルだから文書は要らない」という誤解です。アジャイルソフトウェア開発宣言は、包括的なドキュメントよりも動くソフトウェアにより価値をおく、と言っているのであって、文書を否定してはいません。完成の定義に「説明書を更新する」を入れるなど、必要な文書は作ります。

3つ目は、「スクラムマスターはプロジェクトの管理者だ」という誤解です。前に説明したとおり、スクラムマスターは指示を出す役割ではなく、チームが自分たちで進められるように支える役割です。

4つ目は、「スプリントの最後に必ず製品を公開しなければならない」という誤解です。スクラムガイドが求めているのは、完成の定義を満たした使える成果物を作ることで、それを利用者に公開するかどうかは別の判断です。

5つ目は、「デイリースクラムは進み具合の報告会だ」という誤解です。デイリースクラムは開発者のためのイベントで、目的はスプリントゴールに向けて計画を調整することです。上司への報告の場になると、問題を隠す方向に働き、透明性が損なわれます。

個人や小さなチームでスクラムの考え方を使う

スクラムはチームのための枠組みですが、その考え方は、1人で仕事をするフリーランスや、2人から3人の小さなチームでも役立ちます。正式なスクラムとは呼べなくても、要素を取り入れることはできます。

たとえば、抱えている仕事を1つの一覧にまとめて優先する順に並べるのは、プロダクトバックログの考え方です。1週間を1つの区切りにして、週の初めに「今週はこれを終わらせる」という目標を1つ決めるのは、スプリントゴールの考え方です。毎朝5分、その日の作業を見直すのはデイリースクラムに、週の終わりに「うまくいったこと」と「次に変えること」を書き出すのはレトロスペクティブに当たります。

特に役立つのが、完成の定義を自分で決めておくことです。「納品前に誤字の確認を2回する」「取引先の指定の形式で書き出す」のように、仕事が終わったと言える条件を言葉にしておくと、品質のばらつきが減り、手戻りが少なくなります。

ただし、1人ではプロダクトオーナーと開発者の視点を同時に持つことになり、優先順位の判断が甘くなりがちです。取引先に週に1回、進み具合を見せて意見をもらう機会を作ると、スプリントレビューに近い効果が得られます。

導入するときの進め方

スクラムを初めて取り入れるときは、小さく始めるのが基本です。スクラムガイドも、まずはそのままの状態で試してほしいと書いています。

1. 1つのチームと1つの製品で始める。全社で一斉に始めるより、成果を確かめやすい
2. プロダクトオーナーとスクラムマスターを決める。兼務はできるだけ避ける
3. プロダクトバックログを作り、上位の項目を具体的にしておく
4. スプリントの長さを決める。最初は1週間か2週間が試しやすい
5. 完成の定義を決める。最初は簡単なものでよく、スプリントごとに見直す
6. 3回から5回のスプリントを回してから、レトロスペクティブの結果をもとに進め方を調整する

学ぶ順番としては、まず公式のスクラムガイドを通して読むことをすすめます。日本語版のPDFは表紙や用語集を含めて18ページで、1〜2時間あれば読み通せます。解説書や研修はその後で構いません。先に解説を読むと、書き手ごとの流儀とスクラムの定義の区別が付きにくくなるためです。チームで導入する場合は、全員が同じ版のスクラムガイドを読んでから始めると、用語の意味のずれによる行き違いを防げます。

導入の初期によくある失敗は、スクラムの用語だけを取り入れて、中身が以前と変わらないことです。会議の名前をデイリースクラムに変えても、上司が一人ずつ進み具合を問いただす形のままなら、自己管理型のチームにはなりません。

チームの作業を見える形にする道具

スクラムの三本柱の最初が透明性であるように、作業の状況が誰にでも見えることは、スクラムを回す前提です。同じ部屋で働くチームなら、ホワイトボードに付箋を貼るだけでも、プロダクトバックログとスプリントバックログを見える形にできます。

在宅やリモートで働くチームでは、これを画面の上で再現する道具が必要になります。スクラムの専用の機能が無くても、カンバン（作業をカードにして、列の間を動かして進み具合を表す方式）のボードで、列を「プロダクトバックログ」「今回のスプリント」「作業中」「完成」のように分ければ、スプリントの状況を全員で共有できます。

その道具の候補の1つがPinatecaです。公式の料金ページによると、Pinatecaのフリープランは5人まで、ボード10個まで期限なしで無料で、クレジットカードの登録は要りません。カンバン、ガント、カレンダー、リストなど8種類のボードと、チャット、コメント、受信箱、カスタムフィールド、権限ロールがフリープランから使えます。6人目、または11個目のボードからはスタンダードプランになり、料金は1人あたり月額500円（年払いなら1人あたり月額400円、税抜）です。Trelloからのインポートにも対応しています。スクラムチームは通常10人以下とされているので、5人以下の小さなチームでスクラムを試すなら、無料の範囲で始められます。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

道具を選ぶときの注意として、道具がスクラムを回してくれるわけではない、という点があります。ボードを用意しても、デイリースクラムで実際に見て計画を見直さなければ、カードは古いまま放置されます。道具は透明性を支えるもので、検査と適応はチームの習慣が担います。

在宅やリモートでスクラムを回すときの注意

在宅やリモートの働き方では、同じ部屋にいれば自然に起きる会話が減ります。スクラムを回すうえで気を付けたい点を整理します。

• デイリースクラムの時間を固定する。スクラムガイドは、同じ時間と場所で開催することを求めています。リモートでは、決まった時間に同じ会議室のURLに集まる形が「同じ場所」に当たります
• 書き残す量を増やす。対面なら口頭で済むことも、リモートではボードやチャットに書いておかないと、別の時間に働く人に伝わりません
• 画面共有で成果物を見せる。スプリントレビューでは、資料の説明より、実際に動く画面を共有して触ってもらうほうが、意見が出やすくなります
• 振り返りは発言しやすい形にする。リモートの会議では発言する人が偏りがちです。最初に全員が付箋の代わりにボードへ書き込んでから話す、といった工夫が役立ちます
• 業務委託のメンバーの扱いを決めておく。チームに業務委託の人が加わる場合、イベントへの参加が契約上の業務に含まれるかを、最初に取り決めておきます

業務委託の人が参加する場合は、指示の出し方にも注意が要ります。業務委託は、仕事の完成や事務の処理を任せる契約で、働き方の細かい指揮命令を前提とした雇用とは違います。デイリースクラムへの参加時間や報酬の扱いは、契約の形によって考え方が変わるため、迷う場合は契約書の内容を確かめ、必要に応じて専門家に相談してください。

スクラムの知識を仕事に生かす

スクラムの知識は、ソフトウェアの開発に関わる人だけのものではありません。スクラムガイド自身が、ソフトウェアの領域を超えて、本質的に複雑な作業を必要とするさまざまな領域で採用されていると書いています。

在宅や業務委託の仕事では、スクラムで進める開発チームに加わる場面が増えています。プログラマーとして加わるなら、プロダクトバックログの項目の読み方や、完成の定義を意識した仕事の進め方が求められます。開発の仕事の種類と必要なスキルは、アプリケーション開発のお仕事で整理しています。デザインの担当として加わる場合も、スプリントごとに使える形の成果物を出す進め方に慣れておくと、チームに溶け込みやすくなります。職種ごとの単価の目安はデザイナーの年収・単価相場で確かめられます。

企業がスクラムやアジャイルの導入を外部に相談する例もあります。業務の進め方やAIの活用を支援する仕事は、AIコンサル・業務活用支援のお仕事で紹介しています。経営の視点から業務の改善を支援する国家資格として中小企業診断士もあり、進め方の改善を経営課題として扱う力を身に付けたい人には選択肢の1つです。

フリーランスと在宅ワークの仲介を20年あまり続けてきた運営者として見てきた限りでは、チームの開発に業務委託で加わって長く続く人ほど、作業の速さよりも、進み具合や困りごとを早めに共有する姿勢で信頼を得ていると感じます。これはスクラムの透明性そのものです。仲介の手数料が差し引かれない直接取引の形であれば、こうした継続的な関係のなかで、受け手は手取りを減らさずに長く関われ、発注する側も同じ予算でチームの体制を保ちやすくなります。スクラムの用語を覚えること以上に、見える形で働く習慣を持つことが、どのチームでも通じる強みになります。

よくある質問

Q. アジャイルとスクラムの違いは何ですか？

アジャイルは、変化への対応や動くものを重視するソフトウェア開発の考え方の総称です。スクラムは、その考え方を実践するための具体的な枠組みで、3つの責任、5つのイベント、3つの作成物を決めています。アジャイルな進め方にはスクラムのほかにもXPやカンバンなどがあり、スクラムはその中で広く使われている方法の1つです。

Q. スクラムチームは何人で組むのがよいですか？

スクラムガイドでは、スクラムチームはスクラムマスター1人、プロダクトオーナー1人、複数の開発者で構成され、通常は10人以下とされています。小さなチームのほうがコミュニケーションがうまくいき、生産性が高いとも書かれています。人数が多くなりすぎる場合は、同じ製品に取り組む複数のチームに分けることを検討します。

Q. スプリントの長さはどのくらいにすればよいですか？

スクラムガイドでは、スプリントは1か月以内の決まった長さとされています。期間が長すぎるとゴールが役に立たなくなりリスクが高まり、短くすれば学びの機会が増えます。初めて導入するチームは、1週間か2週間で始めると、短い間に何度も振り返りができ、進め方を早く調整できます。

Q. スクラムマスターは管理職のような役割ですか？

管理職とは違います。スクラムマスターは、スクラムが正しく行われるようにし、チームの有効性に責任を持つ役割です。作業を指示するのではなく、チームの障害物を取り除くよう働きかけ、イベントが時間の上限内で生産的に行われるよう支援し、組織にスクラムを広めます。スクラムガイドは、チームと組織に奉仕するリーダーと表現しています。