Timee Advent Calendar 2024 6日目の記事です。

タイミーでスクラムマスター（以下、SM）/アジャイルコーチを担当している正義です！

この記事では

SMに求められるリーダーの性質は何か
SMもプロジェクトマネジメントに関する知識を得ておくと良い

というお話をします。

スクラムマスターに求められるリーダーの性質は色々ある

SMはどのようなリーダーであるべきか、色々な観点で話されているのを見かけます。スクラムガイドから読み取ろうとしたり、実践ベースで考えたり、学術的な観点などがあります。

(過去に弊社SMが登壇した際の資料もご紹介します！) https://speakerdeck.com/shinop/practical-scrum-master-vs-theoretical-scrum-researcher-d29104ff-15ed-4fcc-a0e9-9e0bef2a0d3a

私も数年間SMを担当してきたので、自分なりに考えていることをお話ししてみたいと思います。

スクラムマスターはどんなリーダーなのか？

「スクラムマスター」というロールはスクラムガイド（2013、2017、2020年版）で定義されているので、そこから見ていきましょう。

まずは2013年版から。

スクラムマスター

スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
このように、明確にリーダーのスタイルがサーバントリーダーとして説明されています。

そして責任についても、「スクラムの理解と成立に責任を持つ」とあります。そのために、理論・プラクティス・ルールをチームに落とし込み、チーム外の人々に対してスクラムチームを理解してもらう活動が中心に記載されています。
つまり、大切にすべき事柄をチームが会得し、実践していくための環境・システム作りに重きを置いていると捉えました。

続いて2017年版から。

スクラムマスター

スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。

「スクラム」が「スクラムチーム」に変更されていますが、記載されている内容については大きな変更はありません。
責任については「SMは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ」とあります。「成立」ではなく「促進と支援」に変わったのは、スクラム成立はSMだけが責任を負うわけではなく、スクラムチームで進めていくことを意識付けているように感じました。
活動自体は、チームに落とし込む項目に「価値基準」が足されてはいますが、大枠では2013年からの変化はありません。引き続き2013年と同様の事柄に重きを置いていると解釈しました。

そして2020年版。

スクラムマスタースクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。

これまでとは異なる点が増えています。
「責任」に触れている部分（ほぼ全体）。

スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。
スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。

責任の内容とその果たし方がセットで書かれています。

注目したい点の一つは「スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ」です。今までの「促進と支援」よりその先の変化、つまり結果にフォーカスしています。
また、「スクラムチームの有効性に責任を持つ」という点が一番大きい変化だと捉えています。スクラムチームの有効性、つまり結果に対し責任を持つことが明確に記載されました。

以前はスクラムの定着がSMの役割でしたが、スクラムが効果的に働き、有効である、結果を出すことがSMに求められるように変化しました。スクラムはあくまで方法であり、大前提となる目的を達成することとSMがそこに意識を向けるために責任が明文化されたと考えています。

そしてリーダーについて言及している部分は「スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである」です。
これまでに色々な議論のきっかけになっている「真のリーダー」、これはとても抽象的なので様々な解釈があると思います。
継続して「奉仕する」が使用されているので、これまでのサーバントリーダーは引き継いでいるように見えます。しかし、サーバントリーダーが明示的に記載されなくなったのは、それ以外にも求められるリーダーとしての役割、リーダーシップが必要であることを示唆しているようです。
パス・ゴール理論の4つのリーダータイプではありませんが、

サーバントというスタイルで、チームの自律性を促し、支援するリーダー
自身が先導し、チームがゴールへ到達することを導くリーダー

という形で、自分でチームを引っ張り、目的にコミットする形も必要だと考えられます。（結果に対し責任を持つということは、こちらに繋がってきます）

スクラムマスターが向き合う”結果”とは？

「結果」についての分解方法としては「直接的な結果」と「間接的な結果」があります。

直接的な結果：ある役割や行動が、最終的な成果やアウトプットに対して直接的に影響を与える場合を指す
間接的な結果：ある役割や行動が、最終的な成果やアウトプットに直接関与せず、それを実現するためのプロセスや環境を整備する役割を果たす場合を指す

開発においては、下記のようになります。

項目	直接的な結果	間接的な結果
対象	成果物などアウトプット	プロセスや環境
影響の範囲	短期的で即時的	長期的で持続的
測定のしやすさ	測定可能（例：完成した機能の数）	測定が難しい（例：チームの生産性）
成果との距離	成果に直接結びつく	成果を間接的に支える

SMはどちらの結果に向き合うべきでしょうか。その答えはどちらか一方ではなく、アジャイルソフトウェア開発宣言のように「左記の結果を求めながら右記の結果に重きを置く」と考えています。

スクラムガイドでは、「スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす」とあります。これはスクラムチームに対して、間接的な結果および責任を果たすことに向き合うことを意味します。

しかし、SMは直接的な結果について完全に無関心でいることはできません。直接的な結果（品質、納期、成果物など）は、間接的な責任を果たす上での重要な指標であり、SMが仕事を効果的に遂行するためには、直接的な結果にどのように影響を与えるかを理解し、それを考慮する必要があります。

スクラムマスターがプロジェクトマネジメントを学ぶ必要性について

SMはチームが自律的に活動していけるように、「皆さんはどうしたいですか？」を問う姿が多く見られます。しかし、チームに問いかけ続けていれば全て問題なく進められるかというと、そうではありません。

チーム内で補える観点や知見に基づいてチーム内で考えることもできますが、それ以上の観点や知識はティーチングを主要なメタスキルとするSMが補う必要があります。

（ラーメンを構成する各材料の作り方をチームが知っていても、合わせて「美味しいラーメン」という成果物にする方法を知らなければ、想定よりもぬるかったり美味しくないラーメンができてしまうイメージ）

SMがプロダクト開発に紐づく全てのことをティーチングできれば良いのですが、スクラムガイドやスクラム・アジャイルに関する知見のみでは難しいです。スクラムガイドはスクラムを定義しており、スクラムは軽量級のフレームワークです。スクラムガイド自体も目次や用語集などを含めて全17ページ程度の少ないボリュームです。スクラムにおける重要な情報が厳選され、抽象化して記載されていて、プロダクト開発をチームで進める上で必要な考え方や観点を全て網羅しているわけではありません。そこで、比較的SMにとって親和性が高く、知っておくと活用しやすい知識は「プロジェクトマネジメント」だと考えています。理由はシンプルに、「そのプロダクト開発は、いつ・どうなったら終わりなのか？」という説明責任をSMにも果たしてほしいからです。

チームが自己管理できるよう、チームの自律性を高めることを主軸にして意識していくSMだからこそ、上記の質問には答えられる必要があると考えています。チームが自分たちで考えられる環境を求めていく一方で、チームに対してティーチングとコーチングを適切に行っていくためには、SM自身がプロダクト開発の完遂に対して必要な知見と考え方を自分で説明できるようになっていてほしいです。そうでないと、プロダクト開発およびプロジェクトを前に進めるための適切なWhyの説明ができず、チームにとってひたすら自身の思い浮かぶプラクティスを推進しようとする人になってしまうのでしょう…（経験談）

プロジェクトマネジメントから得られる観点を取り入れて知的創造を果たす

「そのプロダクト開発は、いつ・どうなったら終わりなのか？」という説明責任を果たすことは、一つのリーダーシップの体現です。

これはモノづくりをする上で行う2つの創造：知的創造と物的創造のうちの知的創造に該当します。書籍：スティーブン・R.コヴィー『完訳 7つの習慣人格主義の回復』（キングベアー出版）p.155 第二部「私的成功」第2の習慣「終わりを思い描くことから始める」より

簡単に説明すると、物的創造は定められた方向に向かって限られたリソースを活用し効率よく業務を遂行するための活動、つまりマネジメントと実行責任の完遂を意味します。一方、知的創造は組織が向かう方向を定め、「終わりを思い描く」「ゴールを決める」活動となります。つまり、リーダーシップとそれに伴う説明責任の完遂です。（ここでいう「終わり／ゴール」には抽象的なビジョンやミッションではなく、プロダクト開発のゴール、プロジェクトの終わりを当てはめています）プロダクト開発のSMが示す一つのリーダーシップであり、「自身が先導し、チームがゴールへ到達することを導くリーダー」に求められます。

では、どうやったらプロダクト開発における「終わりを思い描く」「ゴールを決める」という知的創造を果たすことができるのか？そのための一つとして、「プロジェクトマネジメントを学ぶ」を私はおすすめしているのです。

プロジェクトマネジメントのすべてをここで紹介するのは非常に大変なので、知っておくと良い点として一つ挙げるとPMBOK第6版に記載されている「10の知識エリア」があります。注：PMBOKは2021年に第7版が出版されています。第6版では日本語版で約780ページあったものが、第7版では約370ページになっています。また、内容としてもプロジェクトマネジメントの手順をまとめたものから、プロジェクトの方針や考え方といった原理・原則をメインにした構成になっています。今回は、観点として具体的に分かりやすくリストアップされている第6版の内容を記載します。

10の知識エリア

プロジェクト統合マネジメント	プロジェクトやフェーズをどのように進めるのかを定義する知識エリア
プロジェクト・スコープ・マネジメント	プロジェクトやフェーズにおける作業範囲や、成果物の設定に関して定義する知識エリア
プロジェクト・スケジュール・マネジメント	納期管理に関する知識エリア
プロジェクト・コスト・マネジメント	プロジェクトで承認された予算に関する知識エリア
プロジェクト・品質・マネジメント	生成される成果物やプロジェクトの品質に関する知識エリア
プロジェクト・資源・マネジメント	メンバーなどの人的資源や、物的資源などの管理に関する知識エリア
プロジェクト・コミュニケーション・マネジメント	会議予定を調整し、適切にコミュニケーション内容や方法を管理する知識エリア
プロジェクト・リスク・マネジメント	プロジェクトにおけるリスクの特定・分析・対応方法、対応策の実行、リスク監視に関する知識エリア
プロジェクト・調達・マネジメント	契約終結やベンダーの管理に関する知識エリア
プロジェクト・ステークホルダー・マネジメント	ステークホルダーの関与度の定義や管理に関する知識エリア

すべてを満遍なく検討してマネジメントしましょう、というわけではありません。ただ、これらの項目について考えてみることで、プロダクト開発をスクラムで行おうとしている現場において、スクラムガイドに記載されていない観点を補うことができると考えます。

例えば、プロジェクト・ステークホルダー・マネジメント。スクラムガイドでは、「ステークホルダー」が誰なのかをはっきりと定義していません。それはプロダクト開発におけるステークホルダーは多く存在しますし、それぞれのステークホルダーに対しての期待や重要度は常に一定ではないからでしょう。

そのため個々のプロジェクトにおいては、チームが関わるステークホルダーは誰なのかを明確にし、ステークホルダーとの関わり方を定義しないと、チームの動き方や目指すことは容易にぶれてしまいます。

ステークホルダーマネジメントでよく見るのは、影響度合いと関心度合いを2次元で表現した次の図です。

ここに、チームが関わるプロダクト開発において関連するステークホルダーを配置します。そうすることで、ステークホルダーの洗い出しと対応方針をチームで見える化し、透明性を高めることができます。

さらに、ステークホルダーに対しての具体的な関わり方を定義していくことで、プロジェクト・コミュニケーション・マネジメント（どのような場で何を議論すれば良いのかを定義し、チームにとって必要なコミュニケーションを適切に管理する知識エリア）の一部を満たすことができます。

また、チームの中からは意識しづらいが、じつは重要なステークホルダーも存在します（例えばCTOやCPOなど予算を握っている人やチーム）。そのようなステークホルダーに対しても意識を向ける視座をSMが獲得していて、チームに気づかせることができれば、必要な報告などを行うことができるようになり、急なプロジェクトの方向転換の回避などリスクマネジメントにつながる可能性もあります。それは、SMの支援に記載されている項目の一つ、「スクラムチームの進捗を妨げる障害物を排除するように働きかける」という項目に該当します。

このように、プロジェクトマネジメントの要素を知り、観点として身につけていくことで「スクラムガイドには記載されていないが、プロダクト開発を行う上で知っておくべきこと」を補えるようになります。そしてその知識を活用し、チームが向き合う開発が「いつ・どのように終わるのか？」をSMなりに考え、チームに適切なティーチングを行いつつ、プロダクト開発にとって必要なことをチームで考えていける環境を作ることがSMのリーダーシップの体現だと私は思います。

最後に

プロダクト開発において、知っておかないといけないこと、チームで話した方がよいことはとても多いです。チームがそのすべてを足並み揃えて一つずつ学び、ディスカッションを行い意思決定できると、チームにとって学びを多く得られて良いのかもしれませんが、プロダクト開発という点においては、その動きが最適とは限らない状況もあります。
そのため、プロダクト開発を進める上で必要な様々なことに優先順位をつけて考え、その上でスクラムの理論とプラクティスを無理なくチームに適用し、徐々にチームの自律性を高めつつ、時には自分がプロダクト開発をリードしていけるSMでありたいです。

以上、約2年間で考えていた自分のSM像を少し言語化してみました！ SMのあり方に正解はありませんが、一つのイメージとして誰かの参考になればいいなと思っています。

それでは、私のTimee Advent Calendar 2024 Day 6は終わりとなります。

明日は、SMのしほりんさんのターンですので、お楽しみに！