Scrum MasterとProduct Ownerの違い：役割を比較

Product Ownerは、プロダクトの価値を最大化し、バックログに何を入れるかを管理することに責任を負います。つまり「何を」「なぜ」です。Scrum Masterは、Scrumチームの有効性とチームの働き方に責任を負います。つまり「どのように」であり、「何を」ではありません。この2つを混同すると、両者の職務をめぐるほかの混乱のほとんどが、そこから生じます。

この混乱はよく見られるため、最初から正確に押さえておく価値があります。実務では2つの職務が絶えず曖昧になるからです。たとえば、Product Ownerの対応が遅いからとScrum Masterがこっそりバックログを並べ替えたり、誰にも止められないままProduct OwnerがDaily Scrumを進捗報告会のように運営したりします。

Key Facts

• 2020年版Scrumガイドは、Scrumが「Scrumチーム内に3つの明確なアカウンタビリティ（開発者、Product Owner、Scrum Master）を定める」と述べています。この表現は、以前の版の「ロール」に代わるものです。
• ガイドによれば、Product Ownerは「Scrumチームの作業から生まれるプロダクトの価値を最大化することにアカウンタビリティを負い」、Scrum Masterは「Scrumチームの有効性にアカウンタビリティを負います」。
• 2020年版Scrumガイドによれば、Scrumチームは「通常10人以下」です。両方のアカウンタビリティが、その上位の管理層ではなく1つのチームの内側に収まる小ささです。
• Large-Scale Scrum（LeSS）は、1つのプロダクトを開発するすべてのチームを通じて、Product Ownerをちょうど1人に保ちます。複数のProduct Ownerにバックログを分けると優先順位が分断される、という考えに基づいています。

2つのロールではなく、2つのアカウンタビリティ

この2つのポジションを比較する記事の多くは、出発点を誤っています。「Scrum MasterはXをし、Product OwnerはYをする」という左右対称のリストを並べ、あたかも両者が対等で並行する道を歩んでいるかのように扱うのです。実際にはそうではなく、2020年版Scrumガイドは、それを明確にするために表現そのものを変更しました。以前の版では、Product Owner、Scrum Master、開発者を「ロール」と呼んでいました。現行版は、そのどれにもこの言葉を使いません。Scrumは「Scrumチーム内に3つの明確なアカウンタビリティを定める」と述べています。これは意図的な変更ですが、競合する解説の多くは、習慣で「ロール」に戻ってしまい、いまだに誤っています。

言葉の選択は重要です。「ロール」は職務記述書を連想させ、人に割り当てられたタスクの集合を意味します。「アカウンタビリティ」はより限定的で重い概念です。誰かが、自分で作業をしたかどうかにかかわらず、ある成果について説明責任を負うということです。そう読むと、この2つの職務の違いはタスクリストではなく、何かがうまくいかなかったときに各自が何の責任を問われるのか、という問いになります。

Scrumがフレームワークとしてどう組み合わさっているかをまだ把握していない場合は、この比較の前にそちらを読む価値があります。以下の内容はすべて、Sprint、3つのアーティファクト、そしてScrumが定める小規模で自己管理型のScrumチームを前提としているからです。どちらのアカウンタビリティも、その構造の内側にしか存在しません。Scrumを取り除けば、どちらの肩書きにも具体的な意味はなくなります。

Scrum MasterとProduct Ownerの比較一覧

Product Ownerが実際に負っているアカウンタビリティ

ガイドによれば、「Product Ownerは、効果的なProduct Backlogの管理にもアカウンタビリティを負います」。これは4つの具体的な責務に分解されます。プロダクトゴールの策定と伝達、バックログアイテムの作成と伝達、バックログの順序付け、そしてバックログを透明で理解されたものに保つことです。実際の1週間に置き換えると、このリストは書類作業というより、判断の連続のように見えます。

ガイドの中の2つの文は、一見した以上に大きな役割を果たしています。1つ目は、「Product Ownerは上記の作業を自ら行うことも、他者に委任することもできます。いずれの場合も、Product Ownerがアカウンタビリティを負い続けます」というものです。Product Ownerは、実際のユーザーストーリーの作成や要望の受付プロセスの運営を他の人に任せることができます。しかし、アカウンタビリティそのものを手放すことはできません。つまり、ペンを握っていなくても、最終責任はProduct Ownerにあるのです。

2つ目は、「Product Ownerが成功するためには、組織全体がその決定を尊重しなければなりません」というものです。これは礼儀ではなく、構造上の要件です。VPに苦情を言えば誰でもバックログの順序を覆せるようなProduct Ownerは、肩書きが何であれ、実際には何に対してもアカウンタビリティを負っていません。自分のチームでそうなっているなら、その肩書きは飾りです。

Scrum Masterが実際に負っているアカウンタビリティ

Scrum Masterのアカウンタビリティは、3つの異なる対象への奉仕に分かれます。Scrumチーム、Product Owner、そして組織です。Scrum Masterを「スタンドアップを進行する人」としか考えていないと、この三方向の区分を見落としがちです。

このリストに載っていないものに注目してください。経営陣への進捗報告書の作成、納期の所有、チームが何を作るかの決定です。これらは実務では絶えずこのロールに吸収されていきますが、まさにそれが、Scrum Masterが肩書きだけ違うプロジェクトコーディネーターになってしまう道筋です。ガイドによれば、アカウンタビリティはチームの有効性そのものであり、それに付随する報告機能ではありません。

両者が衝突する場面と、健全なチームの解決法

多くの比較記事が飛ばすのがこの部分ですが、日々の実務で本当に重要なのはここです。2つのアカウンタビリティは設計上対立するものではありませんが、異なる方向に引っ張り合うことが多く、摩擦が生じるのは普通のことであり、何かが壊れているサインではありません。

この5つの行に共通するパターンはこうです。Product Ownerの仕事は価値を擁護し、素早く動くことであり、Scrum Masterの仕事は、その価値を持続可能な形で実際に届けるチームの能力を守ることです。どちらの本能も、それ自体は間違っていません。この摩擦は、システムが失敗しているのではなく機能している証拠です。ただし、緊張を解消するために一方が他方のアカウンタビリティを押し切ってしまわない限りにおいてです。

Scrumイベント別：誰が何をするか

両方のアカウンタビリティはすべてのイベントに現れますが、立ち位置が異なります。一方は内容を持ち込み、もう一方はそれが行われる器を守ります。

1人で両方を担えるか

担える場合もありますが、たいていは長くは続きません。2つのアカウンタビリティは構造的に引っ張り合います。Product Ownerの仕事は、価値に対して「はい」と言い、素早く動くことが報われます。一方、Scrum Masterの仕事は、チームのペースを守り、スピードが品質を脅かすときに押し返すことが報われます。この2つのインセンティブを1人の頭の中に入れると、ほとんどの場合、より大きく差し迫ったプレッシャーを伴う側が自動的に勝ちます（ステークホルダーの期限は、たいてい地味なコーチングの会話に勝ちます）。

ガイドの委任に関する条項は、兼任の場合に状況をむしろ悪化させます。タスクを委任しても総アカウンタビリティは減らず、2種類の別々のアカウンタビリティが1人のカレンダーに集中するだけです。Product OwnerとScrum Masterを兼任する人は、2つの職務の半分ずつをこなしているのではなく、1人分の時間で両方に全面的な責任を負っているのです。

これは、別の種類のロール圧縮と区別しておく価値があります。Large-Scale Scrum（LeSS）は、1つのプロダクトを開発する多数のチームを通じて、意図的に単一のProduct Ownerを置きますが、その理由は正反対です。人員を節約するためではなく、競合するバックログに優先順位が分断されるのを防ぐためです。これは、1人のProduct Ownerがより多くのチームをカバーするということであって、1人が2つの異なるアカウンタビリティをカバーするということではありません。組織が単一チームを超えて拡大する場合は、必要に迫られて誰かが兼任ロールを即興で作る前に、LeSSなどのスケーリング手法を読んでおく価値があります。

兼任がうまくいくのは、ごく小規模で衝突の少ないチームで、一時的な取り決めであると明示し、チームやステークホルダーのリストが増えた時点ですぐ見直す場合です。失敗の原因は、試すこと自体ではありません。兼任を解消する計画をまったく立てないことです。

Scrum Master・Product Ownerとプロジェクトマネージャー・プロダクトマネージャーの違い

Scrum MasterもProduct Ownerも、肩書きを変えたプロジェクトマネージャーではありません。実務では、どちらもその職務の一部を静かに吸収しているとしてもです。また、Product OwnerとProduct Managerの比較については、すでに別の記事でじっくり解説しています。Product OwnerとProduct Managerの違いで、この混乱の大半を生むアカウンタビリティと職位の非対称性を確認してください（要点：Product Ownerは1つの文書で定義されていますが、Product Managerはどの文書にも定義されていません）。

Scrum Masterとプロジェクトマネージャーの比較は、より明確な切り分けになります。2つの職務は、所有するものがほとんど重ならないからです。

プロジェクトマネジメントやプログラムマネジメントが、どちらのScrumのアカウンタビリティとも異なる点について、より詳しくはプログラムマネジメントとプロジェクトマネジメントの違いの比較をご覧ください。

最初に採用すべきはどちらか、あるいはどちらを目指すべきか

よくあるアンチパターン

これらは、一度決めたら忘れてよい恒久的な組織図の決定には落ち着きません。チームの規模は変わり、プロダクトは成長段階を移り、新しいステークホルダーが現れる、バックログが膨らむ、あるいは必要に迫られて始めた兼任ロールをチームが超えて成長するなど、何かが変わるたびに、上の衝突の表にある摩擦点が再び現れます。そのとき明確さを取り戻す最速の方法は、肩書きをめぐる新たな議論ではありません。それぞれのアカウンタビリティが本来拠って立つ一文に立ち戻ることです。誰がプロダクトの価値に責任を負い、誰がそれを届けるチームの能力に責任を負うのか、という一文です。

この問題を整理する目的が、採用であれ、曖昧になったチームの立て直しであれ、キャリアの方向選びであれ、立ち返るべきなのはガイドが実際に書いた一文です。1人はプロダクトの価値に、もう1人はチームの有効性に、アカウンタビリティを負います。それ以外は細部です。