スクラムマスターとPMOの共通点と違い：プロジェクト支援の視点から理解する
はじめに
プロジェクトを成功に導くうえで、「スクラムマスター」と「PMO（プロジェクト・マネジメント・オフィス）」は重要な役割を果たします。
どちらもプロジェクトを支援する立場ですが、その役割や貢献の仕方には違いがあります。スクラムマスターと PMO の共通点と違いを明確にし、どのような場面でどちらが適しているのかを解説します。
目次
- スクラムマスターとは？
- PMO とは？
- スクラムマスターと PMO の共通点
- スクラムマスターと PMO の違い
- それぞれの役割が必要になる場面
- スクラムマスターと PMO が解決できないこと
- スクラムマスター・PMO が存在しない時、どうすべきか
- スクラムマスターと PMO の役割を理解し、適切に活用する
スクラムマスターとは？
スクラムマスターの役割
スクラムマスターは、スクラムチームが最大限のパフォーマンスを発揮できるよう支援する役割です。管理者ではなく、 サーバントリーダー として、スクラムのフレームワークを適切に運用できるよう導きます。
主な役割
-
チームの支援
- デイリースクラムやスプリントレビューなどのイベントを円滑に進行
- チームが自己組織化し、主体的に動けるよう促す
-
プロセスの改善
- スクラムの原則に則り、継続的な改善を進める
- ベロシティ（生産性指標）を計測し、ボトルネックを特定
-
障害の除去
- 開発を妨げる問題（組織的な課題や技術的な障害）を取り除く
- ステークホルダーと調整し、チームの環境を整備
スクラムマスターの実践経験
新規チームの立ち上げ支援
私自身、認定スクラムマスター（CSM）として、複数のスクラムチームを立ち上げてきました。
あるプロジェクトでは、スクラム未経験のメンバーが多く、以下のような課題が発生しました。
- タスクの可視化が不十分で、進捗が見えづらい
- スプリントごとの成果が安定せず、見積もりの精度が低い
- レトロスペクティブ（振り返り）が形骸化し、改善につながらない
実践的なアプローチ
この課題を解決するため、以下のアプローチを実施しました。
1. タスクの可視化
- Jira を活用し、タスクの状況をボードに明確に表示
- WIP（Work In Progress）制限を設け、並行作業の増加を防止
2. ベロシティの計測と改善
- 過去のスプリントで完了したストーリーポイントを分析し、チームのペースを把握
- 過去データをもとに適切なスプリント目標を設定
3. ボトルネックの特定と解消
- デイリースクラムで進捗確認を徹底
- 問題が発生したらチーム全員で議論し、解決策を考える文化を醸成
これらの取り組みにより、チームの業務効率は向上し、安定したペースでの開発が可能になりました。
スクラムマスターの本質：スクラムゾンビを防ぐ
スクラムを形だけ導入してしまうと、「スクラムゾンビ」と呼ばれる状態に陥ります。
これは、プロセスを形式的に実施するだけで、本質的な改善につながらない状態を指します。
スクラムの三本柱（透明性・検査・適応）
- 透明性：情報をチーム内外で共有し、全員が状況を把握できるようにする
- 検査：定期的に進捗やプロセスを振り返り、問題点を明らかにする
- 適応：発見した課題に対し、迅速に対策を講じ、チームの成長につなげる
実際の研修でも**「スクラムの三本柱が達成できてあれば、たとえカンバンだけでもスクラムである」**と教わりました。スクラムマスターとして支援する中でも「形ではなく、本質を理解することの重要性」を何度も実感しました。
プロセスに固執せず、チームが自ら考え、改善を進められるよう支援することが、スクラムマスターの本当の役割だと考えています。
PMO とは？
PMO の役割
PMO（プロジェクト・マネジメント・オフィス）は、
プロジェクト全体を統括し、標準化や管理を支援する組織的な役割です。
スクラムマスターがチーム単位で支援するのに対し、
PMO はより広い視野で複数のプロジェクトや組織全体の最適化を目指します。
PMO の主な役割
1. プロジェクトの標準化
- プロジェクト管理の手法やフレームワークを整備
- スクラム、ウォーターフォールなど、複数の手法を適用できるガイドラインの策定
2. リソース管理と調整
- プロジェクト間のリソース配分の最適化
- ステークホルダー間の調整
3. リスクと品質の管理
- プロジェクトの進捗をモニタリングし、リスクを事前に特定
- KPI を設定し、プロジェクトの成功基準を明確化
PMO の種類
PMO の定義はスクラムマスターより抽象的で幅広く、組織ごとに異なる役割や機能がありますが、主に以下の 3 つのタイプに分類されます。
支援型 PMO
プロジェクト管理のベストプラクティスを提供し、サポートを行う（アドバイザー的な立場）
コントロール型 PMO
プロジェクトの標準化やテンプレートの適用を強制し、一定の統制を行う
指揮型 PMO
プロジェクトの意思決定を行い、実質的なリーダーシップを発揮する
自分が経験した PMO は支援型＆コントロール型 PMO であり、機能はスクラムマスターと似ていました。
スクラムマスターと PMO の共通点
共通する役割：プロジェクトの成功を支援する
スクラムマスターと PMO は、直接プロダクトを作る立場ではありませんが、
プロジェクトの成功を支援する重要な役割を担っています。
- スクラムマスター → チームレベルでの支援（アジャイル開発の促進、自己組織化の支援）
- PMO → 組織・プロジェクト全体の支援（標準化、リソース管理、リスク管理）
どちらも、開発チームや組織がより良い状態で成果を出せるよう支援することが使命です。
共通点：プロセスの改善を推進する
継続的な改善（インスペクション＆アダプテーション）
-
スクラムマスター
- チームの振り返り（レトロスペクティブ）を促し、改善を継続
- スプリントごとの課題を見つけ、実行可能なアクションを設定
-
PMO
- プロジェクトの進捗データを分析し、プロジェクト管理手法の改善を推進
- 組織全体のプロセスを標準化し、各プロジェクトに適用
スクラムの透明性を活かして、PMO と情報を共有できれば、組織全体の改善につながることがわかります。
共通点：課題解決をリードする
ボトルネックを特定し、解決を促す
-
スクラムマスター
- チーム内のコミュニケーションを活性化し、障害を早期に発見
- 技術的・組織的な問題を明確にし、解決に向けたアクションを推進
-
PMO
- プロジェクト全体のリスクを分析し、事前に対策を講じる
- リソースの適切な配分を行い、ボトルネックを軽減
例えば、チーム間の依存関係が原因でスプリントの進行が遅れる問題が発生した場合、PMO と連携して組織全体のプロジェクト・リソース調整を行えれば、依存関係の調整に繋げることができます。
スクラムマスターと PMO の違い
フォーカスする対象の違い
スクラムマスターと PMO は、支援する対象の範囲が異なります。
- スクラムマスター → 1 つのスクラムチームにフォーカスし、チームの成長を促進
- PMO → 複数のプロジェクトや組織全体に関わり、プロジェクトの標準化や最適化を推進
例えば、スクラムマスターはチームの日々のスクラムイベントやスプリント改善に関与しますが、
PMO はプロジェクト全体の進捗を監視し、全体最適を図る役割を担います。
主な目的の違い
スクラムマスターと PMO では、活動の目的が異なります。
| スクラムマスター | PMO | |
|---|---|---|
| 主な目的 | チームのアジャイル実践を支援し、自己組織化を促進 | 組織レベルでプロジェクト管理の標準化や最適化を行う |
| 支援の視点 | チームが最大限の力を発揮できるよう支援 | プロジェクト全体のリスク管理、リソース調整 |
| 時間軸 | 短期的（スプリント単位での改善） | 中長期的（複数プロジェクトの成功を支援） |
関与の仕方の違い
スクラムマスターはチームに深く関与し、日々の支援を行うのに対し、
PMO はより広い視点でプロジェクトの進捗やリスクを管理します。
スクラムマスターの関与
- チームと密接に関わり、日々の課題解決をサポート
- スプリント計画、デイリースクラム、レトロスペクティブのファシリテーション
- チームのアジャイル理解を深め、スクラムの価値を実践できるよう支援
PMO の関与
- 組織全体のプロジェクト管理プロセスを策定し、標準化
- 複数のプロジェクトマネージャーやスクラムマスターと連携し、組織横断的な課題を解決
- KPI を設定し、プロジェクト全体のパフォーマンスを監視
スクラムマスターと PMO の違いを活かした協力
スクラムマスターと PMO は、役割や目的が異なりますが、対立するものではなく、それぞれの強みを活かして協力できる存在です。
下記のように、スクラムマスターと PMO が協力することで、チームのアジャイル性を保ちつつ、組織の管理ニーズにも応えられる形を作ることが可能になります。
- チームはスクラムを採用し、アジャイルな進め方を実践
- しかし、PMO が求めるプロジェクト進捗報告はウォーターフォール的な形式だった
- そこで、スクラムの透明性を活かし、スプリントごとの成果を可視化する方法を提案
- PMO 向けのレポートをシンプルにし、スクラムの進め方と整合性を取ることで、双方の要件を満たす形に改善
スクラムマスターと PMO は対立しない
| スクラムマスター | PMO | |
|---|---|---|
| フォーカス領域 | 1 つのスクラムチーム | 組織・複数プロジェクト |
| 目的 | チームのアジャイル実践を支援 | プロジェクト管理の標準化 |
| 関与の深さ | チームに密接に関わる | 広い視点で全体最適を考える |
| 改善のアプローチ | スプリントごとの振り返りと最適化 | 組織レベルでのベストプラクティス策定 |
スクラムマスターと PMO は、役割や目的が異なりますが、
対立するものではなく、それぞれの強みを活かして協力できる存在です。
- スクラムマスターがチームの成長を支援し、現場での課題を解決
- PMO がプロジェクト全体の最適化を図り、組織レベルの改善を推進
それぞれの違いを理解し、適切な協力関係を築くことで、プロジェクトや組織全体の成功につながります。
それぞれの役割が必要になる場面
スクラムマスターが活躍するケース
スクラムマスターは、アジャイル開発の現場でチームを支援する役割を担うため、
以下のような場面で特に効果を発揮します。
1. アジャイル開発を実践するチーム
- チームがスクラムやカンバンを採用し、アジャイルな働き方を実践している
- デイリースクラムやスプリントレビューなどのイベントを円滑に進めたい
- チームが自己組織化し、主体的に改善を進める文化を育てたい
2. チーム単位の課題解決が求められる場合
- 開発スピードが安定せず、チームの生産性が低い
- タスクの属人化が進み、可視化ができていない
- コミュニケーション不足で、チーム内の連携がうまく取れていない
PMO が必要とされるケース
PMO は、組織全体や複数プロジェクトの管理・最適化を担う役割のため、
以下のような場面で特に重要な役割を果たします。
1. 大規模プロジェクトや複数チームを統括する必要がある場合
- 複数のスクラムチームやウォーターフォール型プロジェクトが並行して進行している
- プロジェクト間のリソースやスケジュールの調整が必要
- 企業全体で統一されたプロジェクト管理手法を確立したい
2. プロジェクトの標準化やガバナンスが求められる場合
- 組織全体のプロジェクト管理を標準化し、ベストプラクティスを策定したい
- 各プロジェクトの進捗状況を可視化し、一貫した管理を行いたい
- ガバナンスを強化し、リスクを最小限に抑えながらプロジェクトを進めたい
スクラムマスターと PMO の役割の使い分け
スクラムマスターと PMO は、それぞれ異なる強みを持っており、状況に応じて適切な役割を選択することが重要です。
| ケース | スクラムマスターが適任 | PMO が適任 |
|---|---|---|
| アジャイル開発の支援が必要 | ✅ | ❌ |
| チームの成長と自己組織化の促進 | ✅ | ❌ |
| 複数プロジェクトの統括が必要 | ❌ | ✅ |
| プロジェクト管理手法の標準化 | ❌ | ✅ |
| チーム単位の課題解決 | ✅ | ❌ |
| 組織全体のリソース調整 | ❌ | ✅ |
スクラムマスターと PMO が解決できないこと
スクラムマスターと PMO は「開発」そのものはしない
スクラムマスターも PMO も、プロジェクトを支援する役割ではありますが、
直接 Web サービスの開発や実装を行う立場ではありません。
チームの生産性に大きく影響するの技術力の向上を直接的に行うこともできません。
不明確なビジネス戦略を解決することはできない
ビジネス戦略が不明確な場合の問題点
スクラムマスターと PMO が支援できるのは、開発チームやプロジェクトの運営の部分です。
下記の様にプロダクトの方向性が不明確な場合、いくらプロジェクト管理を改善しても成果は出ません。
- ターゲットユーザーや市場ニーズが不明確
- ビジネスモデルや収益構造が固まっていない
- 経営陣やプロダクトオーナーの意思決定が遅い、または曖昧
この様な場合はまずこれらの対策が必要です。
- プロダクトオーナーやビジネス側が、市場リサーチやユーザーインタビューを行い、ビジョンを明確にする
- 経営陣と開発チームの連携を強化し、意思決定プロセスを整理する
チームやプロジェクトの文化を一瞬で変えることはできない
スクラムマスターや PMO は、チームの改善を支援する役割ですが、**組織やチームの文化を即座に変えることはできません。**例えば、こんな状況では即時の解決が難しいです。
- トップダウンの文化が根強く、自己組織化が進まない
- 失敗を許容しない雰囲気があり、イノベーションが生まれにくい
- チームメンバーが受け身で、主体的に動こうとしない
スクラムマスターができること
- 継続的な対話を通じて、チームのマインドセットを変えていく
- 透明性を高め、心理的安全性を確保する取り組みを進める
PMO ができること
- 組織全体のマネジメント層に働きかけ、ボトムアップの変革を促す
- ガバナンスと柔軟性のバランスを取り、アジャイルな組織運営を支援する
スクラムマスターや PMO だけの力ではなく、組織全体の意識改革が必要になります。
ステークホルダーの意識改革を強制できない
スクラムマスターや PMO がサポートできるのは、チームやプロジェクトの範囲内です。
しかし、ステークホルダーがアジャイルの考え方を理解していなければ、どれだけスクラムを適切に実践しても、開発がうまく進まないことがあります。例えば、こんな状況では苦戦します。
- スクラムの「スプリントごとの価値提供」を理解せず、細かい仕様変更を求める
- ウォーターフォール型の固定スケジュールに固執し、アジャイルの柔軟性を受け入れない
- 短期的な成果ばかりを求め、長期的な開発の健全性を軽視する
スクラムマスターや PMO ができること
- ステークホルダー向けのアジャイル研修を提案する
- 小さな成功事例を積み重ね、アジャイルの価値を理解してもらう
スクラムマスターや PMO ができないこと
- ステークホルダーの意思決定を強制的に変えること
- ステークホルダーの期待値をコントロールすること（PO と協力が必要）
スクラムマスターと PMO ができること・できないこと
スクラムマスターと PMO の役割を正しく理解し、他の役割と協力することが重要です
| 課題 | スクラムマスター | PMO | 解決策 |
|---|---|---|---|
| ビジネス戦略の不明確さ | ❌ | ❌ | PO・経営層と連携 |
| 技術スキル不足 | △ | ❌ | Tech Lead の配置 |
| 組織文化の変革 | △ | △ | 継続的な改善 |
| 経営層の意識改革 | ❌ | △ | 経営層との対話 |
スクラムマスター・PMO が存在しない時、どうすべきか？
どちらの役割も支援的であるため、組織の意向によっては専門の役割としては設置されず、開発リーダーや役職者が部分的に役割をこなすことがあります。
1. スクラムマスターや PMO がいないとどうなるか？
スクラムマスターや PMO の役割が存在しない場合、
プロジェクトやチーム運営に以下のような課題が発生しやすくなります。
チームレベルの問題（スクラムマスター不在）
- スクラムの形骸化：イベントが形式的になり、チームの改善が進まない
- 課題の放置：チーム内の障害やボトルネックが解消されず、生産性が低下
- ファシリテーション不足：会議がスムーズに進行せず、意思決定が遅れる
プロジェクト全体の問題（PMO 不在）
- 進捗の不透明さ：プロジェクト全体の管理ができず、リスクが見えない
- リソースの非効率な配分：複数のプロジェクト間での調整が機能しない
- 標準化の欠如：組織としてのベストプラクティスが共有されず、プロジェクトごとにバラバラな進め方になる
スクラムマスター・PMO がいない場合の対策
スクラムマスターや PMO の役割が正式に存在しない場合、チームや組織全体での対応が求められます。
スクラムマスター不在の対策
チーム内で「スクラムマスター的な役割」を分担する
- チームメンバーの中から、スクラムイベントの進行役を決める
- 課題解決のための振り返り（レトロスペクティブ）を定期的に実施
- 「スクラムゾンビ」を防ぐため、透明性・検査・適応の原則を意識する
ただし、スクラムについての深い理解のあるメンバーは必要だと考えられます。
PMO 不在の対策
プロジェクト管理の仕組みをチーム間で統一する
- 各チームのリーダーやプロジェクトマネージャーが集まり、プロジェクトの進め方を標準化
- 定期的な進捗確認ミーティングを設定し、リスクを早期に共有
必要に応じて、代替的な役割を設定する
- 組織の規模が大きい場合、リードエンジニアやアジャイルコーチが PMO の一部の役割を担う
- スクラムチームが増えたら、「アジャイルオフィス」や「アジャイル PMO」のような組織を設置する
こちらもプロジェクトマネジメントを体系的に理解しているメンバーが必要です。
スクラムマスター・PMO が不要な場合はある？
スクラムマスターや PMO が必ずしも必要とは限らないケースもあります。
例えば、以下のような状況では、これらの役割なしでもプロジェクトを円滑に進めることができます。
スクラムマスターが不要なケース
チームが高い自己組織化を実現している
→ メンバーが自発的にスクラムイベントを運営し、改善を進めている
アジャイルに精通したプロダクトオーナーが存在する
→ PO がチームの支援も担い、スクラムマスターの役割を補完できる
小規模なチームで、メンバー同士の調整が容易
→ 3〜4 人の小さなチームなら、自然にコミュニケーションが取れる
PMO が不要なケース
組織がフラットで、プロジェクト管理がシンプル
→ 小規模な組織では、PMO のような統括的な管理が不要な場合もある
アジャイルな文化が根付いており、各チームが自律的に動ける
→ 各チームが独立してプロジェクトを運営し、情報共有の仕組みが整っている
システムツールを活用し、管理の手間を最小限にできる
→ Jira や Trello などのツールで進捗管理ができ、PMO の介在なしで運営可能
スクラムマスター・PMO がいない場合の対応策
| 状況 | 課題 | 対策 |
|---|---|---|
| スクラムマスター不在 | スクラムの形骸化、課題の放置 | チームで役割を分担し、イベントのファシリテーションを強化 |
| PMO 不在 | 進捗の不透明さ、管理の不統一 | チームリーダー間で最低限の管理ルールを統一 |
| 組織が成熟している | 特に問題なし | 自律的に運営できるなら、無理に設置する必要はない |
まとめ：スクラムマスターと PMO の役割を理解し、適切に活用する
スクラムマスターと PMO は、それぞれ異なる役割を持ちながらも、
共にプロジェクトの成功を支援する重要な存在です。
- スクラムマスターは、チームレベルでのアジャイル実践をサポートし、スクラムのフレームワークを適切に運用する
- PMOは、プロジェクト全体の標準化やリソース調整を行い、組織全体のプロジェクト管理を支援する
しかし、スクラムマスターや PMO がいても、「開発そのもの」や「ビジネス戦略の決定」はできません。
アジャイル開発を成功させるためには、組織全体の理解と協力が不可欠です。
Discussion