【優れたスクラムマスターになりたい！】 Tips 1: スクラムマスターに求められていること
みなさんこんにちは。
LeanとAgileを体現する開発組織、Integritis Inc.代表のけい©︎です。
自身やチームの学びの共有と蓄積のため、Noteをはじめることにしました。
【優れたスクラムマスターになりたい！】というのは連載予定のタイトルになります。今後は「スクラムマスター」というロールを軸に、「Effectiveなスクラムの回し方」、「スクラムマスターとしての立ち回り方」あたりを、あまりこだわらない程度の丁寧さで書いていきたいと思います。
基本的な方針としては、スクラムガイドや認定スクラムマスター研修資料、各種アジャイル関連書籍の内容について整理しつつ、実務的な観点から具体的なHow toについて共有できたらと思います。
今回の記事はふわっとしたテーマでふわっとしたことを書きます。
この記事で書かないこと
■ スクラムとは何か？
■ 具体的なスクラムの進め方
■ スクラムでの開発者としての動き方について
■ スクラムでのプロダクトオーナーの役割と責任
こんな人が読んだらいいかも？というこの記事のペルソナ
■ スクラムはじめたての人
■ はじめてスクラムマスターをやってみるという人
■ やってって言われたからノリでやってるけど、ちゃんと理解してない人
我々について
受託開発を行う会社として、ツテなしコネなし実績なしで去年創業したばかりの当社ですが、徐々に手伝ってくれる人も増え、色々ありながらもまぁ悪くはないかな、という程度にはうまくいってると思います。（半年はだらだらしてたので、実質会社動かしてからは半年ちょいくらいたったかな、という感じです。）
会社の実績としてはまだまだですが、「LeanとAgileを体現する」という価値観、 "MVV" の "Value" でしょうか。このために事業や組織をそっち方面にTransformさせようとがんばってます。
また、代表のけい©︎は過去スクラムのプロダクトオーナーやったり開発者をやったりスクラムマスターをやったり、いちおうは全てのロールを（なめる程度に）経験しましたが、最近は専ら「スクラムマスター兼アジャイルコーチ」というところで価値を出そうとよいしょよいしょしてます。
そんなところで、自身がアジャイルやスクラムについて学習をしながらスクラムマスターとして実践を行ったり、組織 / チーム運営をしたりする中で得た知見や気付きを書いていきます。
スクラムマスターとは
まず、この記事はアジャイル開発の実践パターンの一つ、「スクラム」についての具体的解説は行いません。* が、スクラムマスターと呼ばれる人について体系的に整理をするため、一応軽くスクラムのロールについておさらいします。
* もし「そもそもスクラムについて知りたい」という人がいれば、まず「スクラムガイド」（2020年11月にアップデートがあり、より汎用化しました）を読んでみてください。その後に「スクラムとは？」みたいな初心者向けの記事に目を通すといいとおもいます。もっと興味が出てきたら、アジャイル関連の書籍を読み漁ったり、コミュニティに参加したり、実践してみたり、資格をとってみたりするのがよいでしょう。自分はそうしました。
# TODO: スクラム・アジャイル文脈で自分が読んだおすすめの書籍をまとめるスクラムには、それぞれ、プロダクトオーナー、開発者、スクラムマスターという３つのロールがあります。
極端にざっくりいうと、
プロダクトオーナーとは、「プロダクトに必要な、粒度粗めのTodo（プロダクトバックログアイテム）をどの順番でやるか」ということに責任を持つキャラです。
開発者とは、スプリントを通して、各スプリントで提供する価値にコミットメントを行い、必要なあらゆる作業を行うキャラです。
スクラムマスターとは、スクラムをうまく運用するために、様々な奉仕をするキャラです。
スクラムガイドの冒頭には次のような言葉があります。
簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4. 繰り返す
これはスクラムの説明なのですが、「スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである」と冒頭で言い切ってあります。
また、以下のように：
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
これ、自分が好きな言葉なんですが、スクラムマスターはスクラムプロセスにおける「真のリーダー」である、との記述があります。
このことから、スクラムマスター、すなわち「スクラムをうまく運用するために、様々な奉仕をするキャラ」という、ぱっと見チームが優秀であればいらなそうと思ってしまうキャラですが、スクラム上ではかなり重要かつ必要という位置づけがされていることが示唆されていることがわかります。
本来は開発者やプロダクトオーナーがスクラムについて完全理解していて、効果的に運用できる自信があるのであればスクラムマスターはいらないのでは？という当然の疑問もこの段階では湧いてくるのですが、ロールが３つに分かれていて、「スクラムマスター」という職が独立してスクラムに組み込まれているのには理由があります。この辺は後ほど解説していきたいと思います。
スクラム上のスクラムマスターの職責
スクラムガイドでは、スクラムマスターは以下のことをやるんだよ、と言っています。
スクラムマスターは、さまざまな形でスクラムチームを支援する。
■ 自己管理型で機能横断型のチームメンバーをコーチする。
■ スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
■ スクラムチームの進捗を妨げる障害物を排除するように働きかける。
■ すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
■ 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
■ 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
■ 複雑な環境での経験的なプロダクト計画の策定を支援する。
■ 必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を支援する。
■ 組織へのスクラムの導入を指導・トレーニング・コーチする。
■ 組織においてスクラムの実施方法を計画・助言する。
■ 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
■ ステークホルダーとスクラムチームの間の障壁を取り除く。
以上のように定義づけられていて、大別すると３つの対象への支援があります。
まず１つめはチームへの支援です。
スクラムマスターはスクラムチームに対して、コーチングをはじめとした様々な支援を行います。
具体例としては以下のようなことが挙げられるでしょう。
■ スクラムに慣れていないチームに各種スクラムイベントの導入、ファシリテーションを行う
■ イベント中のタイムキーピングや、円滑な進行をサポートする
■ スクラムチームの進捗を妨げる障害物（例えばスクラム外から割り込みタスクを依頼されるなど）から交渉などを通してチームを守ったり、内部的な問題（メンバー同士の不和など）を解決する
また、２つめはプロダクトオーナーへの支援です。
スクラムマスターはプロダクトオーナーに対して、主にプロダクトバックログアイテム（以下PBI）の効果的な扱い方を探求することをはじめとした様々な支援を行います。
具体例としては以下のようなことが挙げられるでしょう。
■ よいプロダクトバックログアイテムの起票の仕方について一緒に考える
■ プロダクトのロードマップを引く方法についてプロダクトオーナーと議論する
■ ステークホルダーとプロダクトオーナーのコミュニケーションを支援する（一緒に話す）
最後に、３つめは組織への支援です。
ここでいう「組織」とは、スクラムチーム外の、スクラムチームを内包する経済主体をいいます。（まぁ、だいたい会社のことだとおもいます。）
実はスクラムマスターが奉仕する先というのは、スクラムチームの中に留まりません。自分は寧ろここが「なんちゃってスクラムマスター」ではなく、真のスクラムマスターになるためのポイントだと思ってます。
■ 組織へのスクラムの導入を指導・トレーニング・コーチする。
■ 組織においてスクラムの実施方法を計画・助言する。
■ 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
■ ステークホルダーとスクラムチームの間の障壁を取り除く。
こうある通り、組織へのトレーニング・コーチングやスクラムの導入や運営に係る計画活動、社員やステークホルダーへの説明などもスコープに入っています。
そもそもスクラムを実施する前に、スクラムに対してReadyになっていない状態でスクラムを始めようとしている・初めている組織は死ぬほどたくさんあるというのが自分の認識です。
スクラムマスターは組織にスクラムをFitさせるための努力を惜しまず、組織全体の認識を変える・計画を主導するくらいのパワーが本来必要なのです。
「ステークホルダーを含め、組織全体としてスクラムやってこうぜという気概と合意があって、みんな十分に勉強している」という幸せな現場なら必要ないかもしれないです。
しかしながら、悲しいことですが、組織というものはそんなに余裕がないのが常であって、自分が観測している範囲でそれができているのは「優秀なメンバーだけで構成された、できたての組織」だけ、というのが経験則になります。
スクラムを効果的に運用するために組織を導くのも、スクラムマスターの重要な職責と言ってもよいでしょう。
よいスクラムマスターの条件
前述の通り、スクラムマスターはチーム・プロダクトオーナー・組織の３つに対して様々な支援（奉仕）を行うというのがありました。ではよいスクラムマスターの条件とはなんでしょうか？
■ よいObserverであること
Observeとは観察する、という意味です。スクラムマスターはチームのよい観察者である必要があります。
スクラムマスターがプロダクトオーナー・開発チームから切り離され、スクラム上の独立したロールとして成立している理由の一つでもありますが、スクラムマスターはチームを俯瞰して、当事者間では得られにくい良い点や課題を発見したり、発見した課題の解決に導く必要があります。
「当事者でないが故に得られるインサイト」というのがけっこう重要で、第三者視点で観察するキャラが必要ということです。
また、ここで肝要なのは、解決に「導く」必要があるということで、課題を指摘したり解決策を提示することではありません。
スクラムマスターの動き方は、よく「サーヴァント・リーダーシップ」と表現されたりしますが、静かにチームを見守り、チーム内の課題を発見し、「課題に気付かせ、解決策を導くための問いかけ」をします。
行動経済学の言葉で「ナッジ」 (nudge:そっと後押しする) というものがありますが、よいスクラムマスターはまさにこの「ナッジ」をチームをよりよくするために使っていきます。
ナッジについてはこのEYの記事が参考になるでしょう。
よくマーケティング・UX理論や人間工学的な文脈で使われる理論ですが、要は「小便器の小バエ」のような問いと場を用意するということです。
この辺のお話はまた後で書きたいとおもいます。
■ スクラムについて完全理解していること
「完全理解」と書きましたが、具体的になにがどこまでわかっていればよいのかというと、ステークホルダーや組織、チームに対して、実施するスクラムプロセスや各種スクラムイベントについての「How to」と「Why」が説明できる必要があるということです。
組織やチームで新しい試みをするためには、やり方を知っているのはもちろん、全員が「それをなぜやるのか」というところに納得して腹落ちしている必要があります。
スクラムマスターはチームに対してはもちろん、組織やステークホルダーに対してもトレーニングやコーチングができる必要があり、スクラムプロセスについて、「どうやるのか」と「なぜやるのか」を知っているべきです。
また、各種手続きだけでなく、スクラムの精神性について理解・実践していることも重要です。
例えば、スクラムの思想には「経験主義」というのがありますが、これは教科書や世の中のベストプラクティスを脳死で採用するのではなく、「現場で発生した問題」について、「教科書を踏まえた上で自分らの頭で考えたソリューション」を第一に優先しろ、ということです。
例えば、世の中ではDDDが流行っていて、開発者の１人がうちにも導入しようと言っているとします。まずは「Why」を聞いてみましょう。そして、それはこのプロジェクトにおけるどんなProblemを解決するものなのかを定義してあげます。そして、どんなコストとベネフィットが発生するのかをみんなでフラットに議論することを促しましょう。
世のベストプラクティス（と思われているもの）が、現場に適用できるとは限りません。一例ではありますが、経験主義に従い、メンバーにIssue Drivenの態度を習慣化してもらうための問いかけをするのもスクラムマスターとして重要な仕事でしょう。
■ 熱意と、マネジメントとも対話・交渉できるくらいのパワーがあること
前述で、スクラムマスターは組織への支援も行うと言いました。組織に対してスクラムへの理解を促し、効果的に運営するための対話と交渉をしていきます。
当然ですが、「組織」をスコープとした時、一気にスクラムマスターのハードルは高まります。マネジメント層に対してもトレーニングやコーチング、対話と交渉をする必要があるからです。
そして、スクラムを効果的に運営する障害が組織構造や文化・慣習にあることは珍しくありません。（というかうまくいかないケースの多くがそうだと思ってます）
ここはスクラム、ないしスクラムマスターにとってはタフで大きな障壁ですが、乗り越える必要があります。そのためには、当然スクラムマスターには熱意があって、かつマネジメントと対話・交渉できるパワーがなければいけません。最低限、マネジメントに聞く耳をもたせられるキャラである必要があるでしょう。
上記の理由から、自分はスクラムを効果的に運用する上で、スクラムマスターはスクラムに精通した外部のコンサルタントがやったほうがよいケースが多いと考えています。自分がフリーのスクラムマスター・アジャイルコーチを志向しているのも同じ理由です。自社でもスクラムについてのコンサルティングをさせて頂いたり、スクラムマスターとしてお手伝いさせて頂いている企業様もあります。
しかし、実際には信頼できる自社の人間をアサインするケースも多いでしょう。
難しい、ハードル高い、と思われる方も多いと思いますし、最初は難しいことがほとんどだと思います。その場合は、スクラムに熱意を持って取り組み、チームが変わっていく姿を見せながら、徐々に信頼してもらう必要があります。それができるのであれば間違いなくよいスクラムマスターだとおもいます。
スクラムマスターがやるべきではないこと
前項では、よいスクラムマスターの条件を雑に挙げてみました。もちろんこれはあくまで自分の思うよいスクラムマスター像のあくまで一例であって、他にも色々条件はあるかもしれません。ファシリテーションがうまいとか、チームの雰囲気を和ませることができる柔和さなども重要な素養だとおもいます。
それでは、スクラムマスターとしてやるべきではないこと、やらないほうがよいことはなんでしょうか。
自分の理解では、以下のようなことはスクラムマスターがやるべきでないと認識しています。
■ マネージャーやリーダーのように振る舞う
スクラム上においては、チーム内にリーダーやマネージャーという概念・存在はありません。
スクラムチームは「自己組織化」された、「自己管理型」のチームであると表現されています。（最新のスクラムガイド2020では「自己組織化」、という文言はなくなり、「自己管理型」のチームである、との記述に変更されていますが、重要な概念なので自分は敢えてこの言葉を今も使っています。）
自己組織化とは、「特定の集権機構を持たず、系全体を俯瞰せずとも全体最適に向けた動きを自律的に行う」ようになることです。（自律分散型、とどこかで表現されていたりもします）
スクラムにおいて、自己組織化されたチームでは、スプリントゴールに向けて「誰が」「どのように」作業を行うか自由に選択できるとされています。また、2020年のスクラムガイドアップデートからは、更に「自己管理型のチーム」として、「誰が」「どのように」「なんの」作業をするかを選択できることというのが前提です。
このことからもわかるように、「自律分散的なチーム」には、中枢機能はなく、リーダーやマネージャーの存在は必要ありません。寧ろそのように振る舞うキャラがいた場合、自律的な発言や行動を阻害するおそれがあります。
Scrum Community Wikiでは ”Gorilla in the Room” という言葉が定義されていますが、これはリーダー格の人が発した意見が全てで、周りのメンバーはそれに従うだけの状態のことを言います。
こうなってしまってはスクラムとしてチームのコラボレーションを期待することはできなくなってしまいます。
ただでさえ影響が強くなりがちなスクラムマスターは、立場上リーダー的なポジションになってしまいがちです。こうなることは少しでも避けるため、チームに対してはより控えめに振る舞うのがよいでしょう。
■ 自分の意見を言う
スクラムマスターは、スクラム上基本的には「第三者のObserver」として振る舞うことが求められていることがわかりました。
この立場を徹底するためには、「自分の意見」を極力言わないことが重要です。
これは誤解を招く言い方かもしれませんが、要は「スクラムマスターの決定」によりチームが動くことはあまり好ましくない状態であると言えるでしょう。
スクラムマスターは立場上影響力が強くなりやすいというのは前項でもお話しました。その上求められている役割としては「チーム外からスクラムプロセスを俯瞰」するということで、当事者になってしまってはそれが難しくなってしまいます。
自分はスクラムマスターとして働く上で自分の意見を言う時は、「これは自分の意見なんですが、、」とか、「あえて自分の意見を言うのであれば、、」という風なクッションを必ず使っています。
スクラムマスターが「意見を言う」ということに関しては、それくらい慎重になる必要がある、というのは覚えておくとよいかもしれないです。
■ 開発者との兼務
これはかなりあるあるかもしれませんが、リソースの都合上、開発者がスクラムマスターを兼務することがあります。
一応兼務をすることは禁止されていないし（スクラムガイド上想定もされてませんが）、どうしても予算の都合上こうなることは少なくないかと思います。ただ、これをやるにしても、どんな弊害があるかは理解しておく必要があります。
兼務する時の弊害は、前項でも話してある通り、当事者になってしまうために「第三者視点」が持ちづらくなってしまうことです。
また、スクラムマスターと開発者というアイデンティティの切り替えが非常に難しいです。
よくある話では、スクラムイベント中、「それはスクラムマスターとしての発言なのか開発者としての発言なのかわからない」というような混乱などが挙げられます。
また、スクラムマスターはPOとの対話、ステークホルダーとの対話、メンバーとの対話、様々なプロセス改善や透明性担保のための取り組みなど、シンプルに真面目にやろうとすると普通に忙しいです。
開発者としてのタスクを抱えている状態では、色々と疎かになるのは予想に難くないとおもいます。
「やってはいけない」わけではないですが、これらの弊害を踏まえて、十分に「やるべきでないこと」に入るかな、というところでしょうか。
スクラムマスターに向いている人
こんなかんじでスクラムマスターに求められていることをつらつらと書いてきましたが、適性のようなものはあるか？というのが気になる人もいるかと思います。
自分なりに「こんなひとが向いてるんじゃないかなー」というのをまとめました。
■ 人間性が穏やかで傾聴力・観察力がある人
当然のことながら、スクラムマスターはチームやステークホルダー、組織の様々な人間と対話する機会が多くあります。その中で信頼されるためには、シンプルに「人に好かれる」必要があります。
そして、対話を繰り返してより多くの情報を生むために、観察力や傾聴力が必要になってきます。特に、職責上「自分の意見をぐっと堪え、人の話に真に耳を傾ける」という態度が必要になるスクラムマスターにおいては、この辺がかなり重要なスキルになってくると思われます。
また、些末に思われがちですが、ユーモアがあることは非常に大事で、状況をよくするために重要なスキルでもあります。
スクラムマスターがアイスブレイクでうまく場の雰囲気を和ませ、心理的安全性を高めてチームから創造的な意見や改善活動を引き出すことができる状況を作れれば、よいスクラムマスターだね、となりそうです。
■ 脇役として徹することができる人
スクラムマスターというのは意外と大変な役回りです。当事者として自分でガンガンプロジェクトを前に推進するのではなく、主人公となる開発者チームの推進力を高め、サポートし続ける「サーヴァント・リーダー」であるが故の「脇役としての役回り」に徹する必要があります。
自分の意思が強かったり、自分でなんでも決めたい、という人にはけっこうつらいことなのかもしれませんね。
自分はわりと自分の意思が強く、自分でなんでも決めたいタイプなので、スクラムマスターとして振る舞うときはこの辺を非常に強く意識することで抑制しています。。
■ スクラムに対して情熱をもっている人
スクラムマスターは、スクラムについて深く理解している必要があります。
トレーニングやコーチングができるくらいスクラムについて勉強し、その強い意思をもってマネジメント層との対話や、チームの改善に継続的に粘り強く取り組んでいく必要があります。
特に組織に対しての支援、トップマネジメントと交渉して体制を整えるとか、ステークホルダーに説明するとかは、スクラムをうまく運用したいという強い気持ちがなければなかなかタフな仕事だと思います。
この辺情熱を持っていて、その情熱をもって人を動かせる人は、一つ上の、真のスクラムマスターに近いね、という気持ちになります。
自分もここに関しては原体験もあり強い想いを持っているので、人よりも短期間でより多くのことを勉強できている自負があるし、短期間で多くの実践ができたと思っています。
その熱意は自信に繋がり、自信はより大きな人や組織を動かします。
スクラムマスターをやる上ではこういうモチベーション的なところも大事になってくるかもしれません。（真面目にやろうとすると大変なので）
自分がスクラムマスターに向いてるぽいなー、とおもうひとはこんなかんじでしょうか。
おわり
スクラムマスターについて、ふわっとどんなことが求められていて、どんな人が向いてるのかな？みたいなことを書いてきました。
今回は導入的なところで、「スクラムマスターとは？」みたいなトークが多かったですが、次回以降はより実務的なところ、How toに寄った内容を書いていきたいとおもいます。
連載していく予定なので、読者になって頂けたらめちゃ嬉しいです！
気付いたらそれなりに長文になってしまってましたが、最後まで読んで頂きありがとうございました！
それではまたー。