スクラムマスターとマネージャー？役割の違いとコツ
アジャイルチームにおけるスクラムマスターの役割は、組織図上の位置づけについて疑問を投げかけることがあります。また、スクラムマスターが同時に「機能マネージャー」として機能すべきかどうかという検討もなされることがあります。この記事では、これらの役割の違いを明らかにし、スクラムマスターが同時に「機能マネージャー」として機能することが推奨されない理由についても説明します。まずは小さいことから始めましょう…
スクラムマスター、管理職？| 機能開発マネージャー
スクラム・マスターは管理職なのか？
そもそも、スクラムマスターは従来型の管理職なのでしょうか？
簡単に言うと、スクラムマスターの役割は、伝統的な意味での管理職ではない。むしろ、スクラムマスターは、スクラムチームがスクラムの原則とプラクティスに従って効果的に動くようにする責任がある。その焦点は、チームが最適なパフォーマンスと生産性を達成できるようにサポートすることにある。
スクラムマスターの主な仕事には、チームのタスクの実行を妨げる障害を取り除くこと、チーム内にアジャイルマインドセットを促進すること、スクラムミーティングを組織し司会すること、チームの仕事の進め方の継続的な改善を支援することなどがある。
多くの場合、意思決定を行い、結果に責任を負う従来のマネージャーとは対照的に、スクラムマスターはファシリテーターやコーチとしての役割を果たす。意思決定権は通常、チーム自身にある。スクラムは、自分たちの仕事に共同責任を持つ自己組織化チームを促進する。
スクラムフレームワークの管理者としてのスクラムマスター
スクラムマスターは「スクラムの実装の管理者」の一種であると主張する人もいます。この名称は、スクラムマスターがチームおよび組織におけるスクラムフレームワークの円滑な実装と適用を確実にする責任を強調しています。スクラムマスターはチームメンバー間の仲介役として行動し、スクラムの原則を理解し、効果的に実装するのを支援します。スクラムマスターは伝統的な階層的な意味で「管理」しませんが、チームのメンターおよびサポーターとして機能することにより、スクラムの正常な実装に貢献します。
一部の実践者がそのように主張しているとしても、個人的にはこの論理はこじつけだと思います。マネージャーは通常、スクラムマスターとはまったく異なる意思決定権限を持ち、仕事への取り組み方も異なります。そのため、スクラムマスターをマネージャーのポジションとは見なしません。
スクラムマスター、管理職？| 機能開発マネージャー
スクラムマスターと他のマネージャー職との比較
インターネット上では、アジャイルやITの文脈におけるスクラムマスターと他の様々なマネージャーの役割の違いについて多くの質問がある。次に、その違いを簡単に説明し、またこの2つの役割をどのように調和させることができるかについて簡単に考えてみたい。
まず第一に：要するに、スクラムマスターの仕事は常にフルタイムで行うことを推奨する。また、スクラムマスターはマネジャーのように伝統的な意思決定権やライン責任も持つことが推奨される。とはいえ、両方の役割を雇用する余裕がない企業もある。この点に関して、それぞれのケースで何が必要かをより具体的に説明しよう：
-
スクラム・マスター、デリバリー・マネージャー：
- スクラムマスターとデリバリーマネージャーの違い： スクラムマスターは、スクラムの原則をチームに導入し、障害を取り除くことに集中する。デリバリーマネージャーは、多くの場合、プロジェクト成果の効率的なデリバリーに責任を持ち、複数のアジャイルチームやプロセスにまたがることがある。
- スクラムマスターとデリバリーマネージャーを推薦する： 小規模な組織では、必要なスキルがあれば、1 人の担当者が両方の役割を担うこともできる。しかし、大規模な環境では、アジリティとプロジェクトデリバリの特定の側面に集中するために、役割を分 担することが理にかなっているかもしれない。
-
スクラムマスター、Agileマネージャー：
- スクラムマスターとAgileマネージャーの違い： スクラムマスターは、スクラムチームを支援し、アジャイルプロセスを最適化することに集中する。Agileマネージャは、組織全体のアジャイル変革に焦点を当てる包括的な役割となる。
- スクラムマスターとAgileマネージャーを推薦する： おそらく、Agile マネージャーがアジリティの戦略的側面を管理し、スクラムマスターがスクラムチー ムの具体的なニーズに対応するのが効果的であろう。連携は重要であるが、両方の役割が独立した焦点を持つことも可能である。また、両方の役割を同時に果たすことも可能である。
-
スクラムマスター、プログラムマネージャー：
- スクラムマスターとプログラムマネージャーの違い： スクラムマスターはチームにおけるスクラムフレームワークの実装に注力し、プログラムマネージャーは多くの場合、プログラム（この言葉は主にSAFeの文脈で使われる）内の複数のチームやプロジェクトの調整を担当する。
- スクラムマスターとプログラムマネージャーの推薦： 異なるレベルのアジリティで活動するために、両方の役割を持つことは理にかなっている。スクラムマスターはチームの日常業務に集中し、プログラムマネージャーはより高いレベルでの調整役を担うべきである。
-
スクラム・マスター、リリース・マネージャー：
- スクラムマスターとリリースマネージャーの違い： スクラムマスターはアジャイルプロセスとチームのパフォーマンスに焦点を当て、リリースマネージャーはソフトウェアリリースの計画と実施に責任を持つ。
- スクラムマスターとリリースマネージャーの推薦： 小規模なチームであれば、一人の人間が両方の役割を担うことも可能だが、大規模な組織であれば、明確な集中を可能にするために、責任を分けた方が有利であることは言うまでもない。
-
生まれ変わってったな：
- イテレーション・マネージャーとスクラム・マスターの違い： 両者の役割には共通点があり、組織によっては異なる呼び方をされることもある。イテレーションマネージャーは特定のイテレーションやスプリントに焦点を当てるかもしれないが、スクラムマスターはアジャイルプロセスにおいてより広い役割を持っている。これが、スクラムマスターとイテレーションマネージャーの典型的な違いかもしれない。
- イテレーション・マネージャーとスクラム・マスターを推薦する： 多くの環境では、役割が統合されたり、焦点が異なったりすることがある。どのような名称が使われようとも、責任を明確に定義することが重要である。
-
スクラム・マスターとライン・マネージャー：
- スクラムマスターとラインマネージャーの違い： スクラムマスターはチーム内の自己組織化とコラボレーションを促進し、ラインマネージャーはチームメンバーのキャリア開発と業績評価に責任を持つ。
- スクラムマスターとラインマネージャーの推薦： 利害の対立を避け、チーム内の効果的な協力を確保するために、これらの役割は分離されるべきです。「機能マネージャー」の詳細については、以下をご覧ください。
-
スクラム・マスター、QAマネージャー：
- スクラムマスターとQAマネージャーの違い： スクラムマスターはアジャイルプロセスに注力し、QAマネージャーは品質保証とテスト戦略に責任を持つ。
- スクラムマスターとQAマネージャーの推薦： 両方の役割が協力し、品質面がアジャイルプロセスに統合されるようにすれば、効果的である。責任の明確な連携が重要である。私は、QAマネージャーがスクラムマスターの活動を引き受けるのを見たこともある。
-
スクラム・マスター、エンジニアリング・マネージャー：
- スクラム・マスターとエンジニアリング・マネージャーの違い： スクラム・マスターはアジャイル実装でチームをサポートし、エンジニアリング・マネージャーは技術的側面、リソース、技術戦略により責任を負う。
- スクラム・マスターとエンジニアリング・マネージャーの推薦： スクラムマスターはアジャイルプロセスに集中し、エンジニアリングマネージャーは技術的側面に集中する。私の意見では、エンジニアリングマネージャーのスクラムマスターがミーティングの司会などの仕事を引き受けることも珍しくない。
-
スクラムマスター、プロダクトマネージャー：
- スクラムマスターとプロダクトマネージャーまたはPMの違い： スクラムマスターはアジャイルプロセスを実施するチームをサポートし、プロダクトマネージャーまたはPMは製品要件を定義し、製品価値を最大化する責任を負う。
- スクラム・マスター、プロダクト・マネージャーまたはPMを推薦する： 両方の役割が緊密に連携するのが一般的ですが、重点が異なります。明確なコミュニケーションと協力が重要です。プロダクトマネージャー（PM）も、「継続的な改善」を担当する従業員がいない場合、ある意味でチームのスクラムマスターになることがあります。
これで、スクラムマスターの様々なマネージャーの役割をどのように区別すればよいかがわかった。しかし、スクラムマスターがファンクショナルマネージャーにもなれるのか、なるべきなのかという疑問についてはどうだろうか？
スクラムマスター、管理職？| 機能開発マネージャー
スクラム・マスターはファンクショナル・マネージャーになれるか？
通常、スクラムマスターは従来の意味での「機能マネージャー」ではありません。機能マネージャーは通常、特定の機能グループまたは部門に対する直接的な権限と責任を持つ組織内の人物です。このタイプのマネージャーは、多くの場合、意思決定を行い、グループのパフォーマンスに責任を持ち、明確なラインの権限を持ちます。
対照的に、スクラムマスターは、スクラムチームのコーチ、メンター、ファシリテーターとしての役割が強い。スクラムマスターは通常、チームメンバーに対する直接的な権限を持たず、伝統的な意味での監督者としては機能しない。その代わりに、スクラムマスターは自己組織化とチームワークを促進する。
アジャイル環境におけるスクラムマスターの役割は、自己組織化された自律的なチームを支援するために、伝統的なヒエラルキーと命令構造に挑戦するように意図的に設計されていることに注意することが重要である。この点で、二重の役割は対立を招きやすい。
そういえば：例えば、あなたの組織が経済的な理由でフルタイムのスクラムマスターを雇いたくなく、代わりにマネージャーを使う予定だとしたらどうだろう？
ふぅ、それは間違いなく理想的ではないだろう。とはいえ、実際にまったく同じ方法で処理している会社もあることは知っている。では、このような状況に直面した場合、どう反論すればいいのだろうか？いくつか考えてみた。
スクラムマスター、管理職？| 機能開発マネージャー
スクラム・マスターはファンクショナル・マネージャーである：どうすべきか？
原則として、スクラムマスターが同時に「機能マネージャー」として機能しないことが推奨されます。その理由は、スクラムを含むアジャイル手法の原則と価値観にあります。
具体的な考えをいくつか挙げてみよう：
-
利益相反： スクラムマスターは、チームをサポートし、チームがアジャイルの原則に従って効果的に機能するようにするために存在する。もし同じ人がチームに対する正式な権限も持っていたら、利害の対立が生じるかもしれない。スクラムマスターの焦点は、障害を取り除き、チームに力を与えることであり、直接命令することではない。
-
自己組織化を促進する： Agileメソッドは、チームの自己組織化を重視する。スクラムマスターがマネージャーを兼務すると、チームメンバーが主体的に意思決定するのではなく、上からの指示を待つことになり、チームの自己組織化が損なわれる可能性がある。
-
外からの独立した視点： スクラムマスターは、多くの場合、外部から独立した視点を持ち、チームと開発プロセスを客観的に評価できるべきである。スクラムマスターが部門のライン責任も持っている場合、客観的な判断を下す能力に影響を与える可能性がある。
したがって、アジャイル環境では、アジャイルの原則と価値を効果的に実施するために、スクラムマスターと管理職は別の役割であることがより一般的である。
スクラムマスター、管理職？| 機能開発マネージャー
兼任のコツ
あなたの会社では、スクラムマスターの役割をフルタイムで各チームに専属させることができないのだろうか？それなら、Echometerはあなたの興味を引くかもしれない。そのような状況では、従業員に焦点を当てた継続的な改善プロセスが可能になる。例えば、アジャイル・レトロスペクティブを匿名で実施し、オープンなフィードバックを得る可能性を高めることができる。
Echometerは、アジャイルレトロスペクティブとチームHealth Checkでアジャイルチームリーダーを支援するデジタルツールである。リモート、ハイブリッド、オンサイトに関わらず、チームコーチングを測定可能なものにし、あなたの仕事をプロフェッショナルなものにすると同時に、多くの労力を削減する。詳しくはウェブサイトをご覧いただきたい： www.echometerapp.com。
スクラムマスターは、従来型の管理職にあると考えるべきではありませんが、意思決定者の視点を理解するために、可能な限り緊密な意見交換をする必要があります。
クリスチャン・ハイデマイヤー、心理学者、スクラムマスター
スクラムマスター、管理職？| 機能開発マネージャー
結論 - 管理職としてのスクラムマスター
アジャイル環境では、スクラムマスターとファンクショナルマネージャーの役割を分離することが重要である。スクラムマスターが、チームに対して形式的な権威主義的権力を行使することなく、アジャイル手法の推進に注力することで、自己組織化やチームのエンパワーメントといったアジャイルの原則がよりよくサポートされる。これは、効果的で自己組織化されたアジャイルな仕事のやり方を促進するのに役立つ。
最後に、もう一度お知らせします。もしあなたが私たちのツールを使ってチームをさらに発展させるのがどんな感じか試してみたいなら、ログインせずにアジャイルレトロスペクティブを開始することができます。この場合、「Keep, Stop, Start」ワークショップを試してみてください。
あるいは、当ウェブサイトを担当の同僚に転送するだけでもいい： www.echometerapp.com。
Keep Stop Start Retro
