スクラムマスターの研修を受けてきたので、
スクラムマスター（SM）の立場に立ってみて、
改めてスクラムガイド2020を読んでみた気づきや学びを紹介したいと思います。
はじめに
普段はDeveloperを担当している私ですが、
SMから見たスクラムチームの視点が気になり、
スクラムマスター研修を受けてきました。
想像していたよりも遥かに異なる視点で、
スクラムチームを俯瞰して見なければならないのがSMなんだ
という気づきや学びが得られ、
非常に有意義な研修でした。
この有意義な研修の内容が頭の中に鮮明に残っている状態で、
改めてスクラムの教科書とも言えるスクラムガイド2020を読むことで、
今まで以上にスクラムに対する解像度が上がり、
良い発見があるのではないかと考えました。
ということで、改めてスクラムガイド2020を
読んでみた気づきや学びを紹介したいと思います。
※あくまで個人の解釈であり、この記事の内容にも
間違いが多々あるということを念頭にお読みください
この記事を読んで得られるもの
- スクラムマスター（SM）として、スクラムをどう捉えるのかの解釈
- SMがスクラムチームを動かすために必要な武器・能力
研修内容（超ざっくり）
本研修、スクラムマスターの研修ではありますが、
スクラムガイドを最初から最後まで説明する
というようなことはしていません。
研修参加者全員との議論やグループワークを通じて、
スクラムの考え方やSMとしての振る舞いを学べる研修内容でした。
（文章にすると簡単なのですが、実態としては物凄く頭を使い、
深く考えさせられる研修となっています。）
スクラムガイド2020を読み込む
それでは頭から読み進めていきます。
スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。
中略
スクラムによって現在の マネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
スクラムは現状を把握するために適したフレームワークであると学びました。
「透明性」、「検査」、「適応」が守られることで
現状を把握できるようになり、スクラムを実践出来ていると言えるのかな。
上記の3点については後述します。
スクラムの理論
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的） でインクリメンタル（漸進的）なアプローチを採⽤している。
イテレーティブであり、インクリメンタルであることは大切ですね。
SMとして、常にインクリメンタルな状態になっているかに
目を光らせる必要があり、
なっていなければそれを推進していく必要があるということかな。
以下の三本柱が守られていなければ
スクラムとは言えないというのがとても重要です。
透明性
創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。 スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
複数人での議論に例えると、
現在の話題は何なのか、
どのような議論の経過をたどってきたのか、
このような事柄をグループ全員で共有出来ている状態かなと思います。
ホワイトボートに可視化するでもいいし、
共通認識を持てる状態を保つことが透明性を確保する上で必要です。
この透明性が無ければ、次のステップである検査が不可能となります。
SMとして、スクラムチームの状況を俯瞰して捉えて、
透明性が保たれるように推進していくことが大切なのかな。
検査
スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5つのイベントでリズムを提供している。 検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
これも議論の例に例えると、
今決めたい事柄、話したい事柄に対して
どこまで完了していて、それは進捗としてはどうなのか
常に確かめなければならないということかなと思います。
大事なのか次の行動に繋がるかどうか。
次の行動に繋がらないのであれば、
それは意味の無い検査ということになる。
SMとして、常に検査が出来ているか、
検査は次の行動に繋がるものなのか、
常に目を光らせ、考え続けることが必要なのかな。
適応
プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。 関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。 スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
議論の例にすると、
進捗が悪いことが分かった場合、
議論が停滞したり脱線したりしている場合、
あるべき姿に近づけるために行動出来ているかどうか
なのかなと思います。
検査の結果から学びを得て、適応出来る状態になると言えます。
逆に言うと、学びが無い場合は適応しているとも言えないということも言えます。
SMとしては、検査によって学びを得られているかどうか
常に意識し続けなければならないということかな。
SMはこれら3本の柱が守られているかどうかに対して
常に厳密である必要があると理解しています。
ここで言う厳密とは、
スクラムチームの活動に対して
現状がどうなっているのか、
振り返った結果から学びを得られ、
適応するための行動に繋がるものであるかどうか、
考え続けなければなりません。
スクラムチームの活動全体を俯瞰して、
3本の柱が守られていて、正しい方向に進もうとしているのか
考え続けなければなりません。
スクラムの価値基準
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）
スクラム3本の柱が守りだとすると、
上記5つはスクラムにおける攻めの価値基準です。
これらの強化していくことで、スクラムの土台が構築できます。
SMとして、これら5つの価値を具現化し、
強化していく必要があります。
これら5つの価値に対しても、絶対的/相対的指標を計測し、
スクラムチームの傾向を分析出来る状態を保たなければなりません。
そして、問題があるのであれば、
根拠と共にスクラムチームに示し、行動を促す必要があります。
スクラムチーム
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチー ム内で決定する。
スクラムチームは中央集権型組織ではないということですね。
ちなみに、会社は中央集権型組織であることが多く、
中央集権型組織の中にスクラムチーム（チーム中心型組織）が
存在する構図となることが多いです。
SMは中央集権型組織の圧力から、
スクラムチームを守ることも求められます。
開発者（Developers）
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
スクラムチームの生産性を最大化することに責任を持つと学びました。
決して、POの奴隷、開発や作業だけをするのではないと
肝に命じましょう。
プロダクトオーナー（PO）
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること の結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
スクラムチームのROIを最大化することに責任を持つと学びました。
決して、プロダクトのみを最大化するのではないと
肝に命じましょう。
スクラムマスター（SM）
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティス を全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムチームの実現確率を最大化することに責任を持つと学びました。
スクラムイベント
スプリントは他のすべてのイベントの⼊れ物である。スクラムにおけるそれぞれのイベントは、 スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運⽤しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられる。
スクラムイベントは、スクラム3本の柱を守るために定められているものです。
スクラムイベントの背景や目的を知らずに
我々のチームではこういうやり方なのだ！
のようなものがあってはなりません。
規定通りにイベントを運用しなければ、
検査と適応の機会が失われ、スクラムと言えなくなります。
スプリント
進捗の⾒通しを⽴てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有⽤性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できる。
これらのツールを使えと言っているわけではないですね。
特に、最後の1文が印象的です。
過去のプロジェクトの経験則がだとー
みたいなものは何の根拠にもならないわけですね。
既に発生したことだけが、重要なのですね。
SMとして、過去案件踏襲とか、
個人の経験則を語る人の発言には注意すべきではないでしょうか。
スプリントプランニング
スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
これは、スクラムチーム以外の人に対する
透明性でもあるのではないでしょうか。
SMとして、3本の柱を守り、5つの価値に高める活動に繋がっているかどうか
注視する必要があるポイントとも言えます。
デイリースクラム
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
検査と適応のためのイベントなわけですね。
プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
これは上手く読み解けなかったです。
POやSMとしてではなく、Developersとして
デイリースクラムに参加する必要があるということでしょうかね。
スプリントレビュー
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。 スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
中略
スプリントレビューはワーキングセッションであり、スクラムチームは スプリントレビューをプレゼンテーションだけに限定しないようにする。
目的は検査ということですね。
ただの発表会ではなく、
相互のフィードバックが重要であるということでしょうか。
スプリントレトロスペクティブ
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。
ただの1週間の振り返りではなく、
完成の定義等にも目を向けるべきなのですね。
スクラムの成果物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最⼤化できるように設計されている。作成物を検査する⼈が、適応するときと同じ基準を持っている。 各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
スクラムにおける透明性を最大化できるようにするのが、
スクラムの成果物なわけですね。
スクラムイベントが検査と適応を促進するイベントだとすると、
スクラムイベントと成果物の関係性が見えてくる気がします。
プロダクトバックログ
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。
SMとして、プロダクトバックログにより
透明性が確保されているかどうか目の光らせどころですね。
スプリントバックログ
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。 スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
スプリントバックログはあくまで開発者による、
開発者のための計画であるというのが重要そうですね。
スプリントバックログの消化に伴い、
学びの最大化に繋げる活動が出来ているか、
SMとして気になるポイントなのかな。
インクリメント
完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。
この1文がとても重要な気がします。
完成の定義を満たし、次に受入条件を満たしてようやく
インクリメントとなるようなイメージかな。
完成の定義 → 受入条件 という順番に
SMは目を光らせておく必要がある気がします。
講義の中で、この辺が一番難しかった。
インクリメントの完成の定義が組織の標準の⼀部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。
プロダクトごとに完成の定義は存在するわけですね。
完成の定義には、組織の標準的なものもある。
そして、これらは常に満たされているかどうか
検査されている状態になければならない。
順番が大事ですね。
後で検査するという流れに陥った瞬間、
それはUndoneなタスクになる。
Undoneなタスクが積み上がると、リリーススプリントという
スクラムの体をなさないスプリントが発生してしまう。
そもそもUndoneが発生した時点で、スクラムとは言えない。
でも100％スクラムが出来ている組織もまた存在しない。
この難しさの狭間で、
いろんな組織がスクラムにチャレンジしているとのこと。
SMとして、「順番」には常に目を光らせておきましょう。
スクラムガイド読み込みパートは終了。
SMの武器とスクラムチームへの関わり方
これまでで、SMの関わり方を少しだけ挙げてきたものの、
SMの役割をもう一度確認してみます。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムガイドで定義されたスクラムを確立させることに
責任を持つわけです。
とは言え、SMがPOやDevelopersの方々のやり方に対して、
細かく口出ししていたらどうなるでしょうか？
それは無理やりスクラムチームを動かしているだけに過ぎず、
恣意的なやり方であり、自律的なチームを作り上げることには結びつかないです。
トップダウン型の組織になってしまいます。
では、SMはどのようにスクラムチームに関わっていくのか？
指示型ではなく、自律的に動いてもらえるように
スクラムの考えを伝える必要があります。
その時に役立つ能力がフィードバックの力です。
スクラムガイドには記載がありませんが、
研修の中で、このフィードバック力を考えさせられました。
では、フィードバック力とは何なのでしょうか。
これを考えるには、どのような状態になったら
「フィードバック出来た」と言えるのかを考えます。
それは、「相手が自ら必要だと考えて行動に移せた時」です。
「相手に課題や問題を伝えた時」ではないのがポイントです。
そう考えた時、フィードバック力は
「相手が必要性を理解し、自ら行動に移させるための伝える力」
と言えるのではないでしょうか？
SMの武器はフィードバック力です。
フィードバックを通じて、スクラムチームに行動を促し、
スクラムを確立させることを目指します。
決してトップダウンの力でスクラムチームを
支配してはいけません。
では、どうやってフィードバックすればいいのか、
具体的なHowが気になってきます。
具体的には以下を御覧ください。
フィードバックに必要なこと
- 駄目な理由を伝える
- 基準とルールに基づいた理由を明確に
- 抽象と具体の両方で伝える
- 具体的な事実を明確に
- 繰り返し伝える
- NGワード「何回言ったら分かるんだ」
- ポイントを明確にして伝える
- 改善点は明確に
- 1対1で伝える
- 人前で屈辱を与えない
そんなフィードバックにおいては、4つのAを意識します
- Aim to assist（相手のためになること）
- 何が良くなるのか明確であること
- Actionable（相手が行動できること）
- 相手が行動を変えやすいように伝えること
- Appreciate（FBを受けたことを感謝すること）
- 防御や言い訳は不要。教えていただけることに感謝すること
- Accept or Discard（受け入れるか否かは相手が決めること）
- 聞く・従うは自身で決めること
このフィードバック力を鍛え、武器にすることで
SMは文化や姿勢を創り、チーム力を向上させることに努めます。
って言っても中々に難しい内容だと思うので、
地道にトライを重ね、力を身に着けていく必要がありますね…
SMに必要な能力
SMにはスクラムの理解以外にも様々な能力が求められることが、
研修内容やスクラムガイド2020から分かります。
以下は、筆者が考えたその一例です。
- スクラムへの理解
- フィードバック能力
- 組織からスクラムチームを守る力（ex: 組織論）
- 人や組織を動かす力（ex: 心理学）
- 大局観
- スクラムチーム全体を俯瞰する能力
- 組織全体とスクラムチームとの関係性や方向性を俯瞰する能力
SMは想像しているよりも遥かに難しく、
探求が必要な役割なのかもしれません。
まとめ
思っていることを書き留めてしまったため、
いつも以上に構造的ではない、読みにくい記事となってしまいました。
この記事が誰かの参考になっていれば幸いです。
なお、考え方の解釈には誤りも多いと思います。
これが全てだという受け取り方をしないことを望みます。
ここまで読んでいただき、ありがとうございました。
