こんにちは、佐藤と申します。
普段は MiROHA という治験業務を支援するプロダクトの開発兼スクラムマスターとして活動しています。
スクラムをソフトウェア開発手法として採用した際、必ず読むであろうスクラムガイド。
その中で、
スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスター という 3 つの明確な責任を定義する。
スクラムガイド P.6「スクラムチーム」
と、開発者・プロダクトオーナー・スクラムマスターの 3 つのロールがあることが定義されています。
しかし、実際スクラムマスターとしてスクラムを回してみると、
- 「スクラムマスターの目的は何だろう？」
- 「組織にとっては何を期待されているのだろう？」
- 「具体的に何をすれば良いのだろう？」
とスクラムマスターに関しての疑問が色々浮かんできました。
そこで今回は、スクラムマスターの目的を改めて整理しつつ、その結果スクラムマスターが組織に何をもたらすのかについて自分なりに考えてみました。
スクラムマスターの理解を深める上で参考になれば幸いです。
スクラムマスターの目的
まずは定義を見ていきましょう。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
スクラムガイド 2020 P.7「スクラムマスター」
と記載があります。
これを整理してみると、以下のようになります。
目的
- スクラムガイドで定義されたスクラムを確⽴し、スクラムチームがスクラムの有効性をもつ状態にすること
達成条件
- スクラムチームと組織が、スクラムの理論とプラクティスを理解していること(スクラムの理解)
- スクラムチームがスクラムフレームワーク内でプラクティスを改善できること(自己管理型の組織)
ここでもしかしたら「スクラムの確立とは？」「プラクティスって何？」と思った方もいらっしゃるかも知れませんが、こちらについては後ほど「具体的なプラクティスは何か」のセクションでお話します。
スクラムマスターはスクラムチームだけでなく、組織を見ていくことを前提に明記されているのは個人的に興味深いです。
スクラムチームと組織のつながりについては、「SCRUMMASTER THE BOOK」の著者である Zuzi さんの 3 つのレベルの概念 が参考になります。ここでは詳しく触れませんが、気になる方はぜひ読んでみてください。
3 つのレベルは以下の記事でも端的にまとめられていて理解しやすいです。
少し脱線しましたが、スクラムマスターの目的がスクラム(の理論)を確立させ、チームの有効性をもたせるということが分かりました。
スクラムが確立されると組織にとって何が嬉しいのか
この問いに答えるためには、なぜスクラムをやるのかを理解する必要があります。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
スクラムガイド 2020 P.4「スクラムの定義」
言い換えると、組織は複雑な問題に対して価値を生み出したいからスクラムを採用するということです。
複雑な問題とは、ドメインの難易度・市場の不確実性・要望の不透明さなど様々な要素が含まれています。現代において、技術革新の早さや社会情勢の変化などの速度を考えると、今後ますます問題の複雑性が増していくことは確実だと言えるでしょう。
また価値を生み出すとは、資本主義においては、誰かの課題解決や要望を叶えることで対価としてお金を儲ける行為だと言えます。
つまり、現代という複雑な問題を多く抱える社会の中で、ソフトウェアによって誰かの課題解決や要望を叶えることで多くの利益を生み出したい。その動機によって多くの組織にスクラムが歓迎されるわけです。
そして、そのスクラムの完成系がスクラムの確立です。
ロジックとしては以下の通りです。
スクラムの確立によって、チームがスクラムの理論を理解し、実践し、自律的に改善できるようになる。スクラムは不確実性の高い問題を解決するために最適化されたフレームワークなので、解決策の不確実性が高いスタートアップや新規事業、前例の少ないドメイン領域のプロダクトの仮説検証を最速で回すことができるようになり、解決策の質が高まる。その結果、解決策に満足した顧客やユーザーから多くの利益を生み出すことができる。
簡潔にまとめると、
スクラムの確立 → 仮説検証が最速で回る → 解決策の量と質が上がる → 顧客やユーザーの課題解決や要望を満たす機会が増える → 利益が増える
という流れです。
つまり結果として、組織は最速で利益拡大を最大化できるわけです。
もちろん現実的には、プロダクトが優れているから利益になるという簡単な構造ではないですし、ビジネスモデルや外的要因など様々な要素が絡み合ってできています。とはいえ、プロダクトチームとして最大限のパフォーマンスを出すことが組織として求められていることに変わりはありません。詳しくは期待付加価値と実現付加価値の話になるので興味がある方は以下の記事をご覧ください。
スクラムを確立するための具体的なプラクティスは何か
スクラムの確立をする理由が分かったところで具体的なプラクティスとはなんでしょうか？
その達成条件であった、スクラムの理解と自己管理化された組織にするためには何をする必要があるのでしょうか？
結論から言うと、具体的なプラクティスはチームの文脈に大きく左右されるので明確な TODO は存在しないと思っています。
チームの文脈とはチームの人数やスキルセット、ドメイン領域や制約、スクラムの成熟度などのチームを構成する様々な要素であり、それはチーム毎にバラバラです。
例えば、デイリースクラムのアジェンダはスクラムガイドに明記されていません。ざっくり言うと、タイムボックスが 15 分であり、スプリントゴールの進捗に関する検査と適応をするという目的のみが定義されています。
この場合、全員が毎日出社するのであればオフィスのホワイトボードを使って進捗を話すでもよいし、リモートメンバーが多い場合は jira や notion などプロジェクト管理ツールを使い画面共有をしながら進捗を話すことが多いでしょう。また人数が 5 人未満で少数のチームであれば 3 つの質問(昨日やったこと、今日やること、困っていること)を使って各自の進捗についても詳細に話しても良いですが、10 人のチームではタイムボックスを守るために 3 つの質問をやめたり、簡潔に話すなど工夫が必要になります。
how は自分たちで試行錯誤しながら考えていく
もっと明確に how も定義してくれれば具体な施策に迷わずに済むのに、、と思いますよね。
ですが、これは不備ではなく、スクラムガイド及びスクラムを意図的に抽象化していることが以下の記事を読むと分かります。
日本語訳はこちらの記事を引用させていただきました。
The scrum guide was never intended to be prescriptive or a checklist for a software development team. Many important practices are not covered in the scrum guide! Gasp! We actually have to go and figure some of this out for ourselves…
It is interesting to note here, however, that this omission is entirely by design.
スクラムガイドはソフトウェア開発の細かいことを規定したりチェックリストであることを意図しているわけではありません。 重要なプラクティスの多くはスクラムガイドには載ってはいません！ 実際に進めてみて、自分たちに足りないものを見つけないといけないのです。
この不足自体が完全に設計された意図的なものである点は興味深いと言えるでしょう。
あえて明記をしないのは、先の通りチームによって文脈が異なるので共通化したプラクティスをつくるのがそもそも難しいのと、チームがプラクティスを自分たちで考えていくことで自然と責任感が醸成され、自分たちで自発的に改善できるチーム = 自己管理化されたチームになるのを促すためだと考えています。
この抽象から具体への変換は正解はなく、チームの状態によっても変わっていきます。そこが難しさでもあり、スクラムマスターの腕の見せ所でもあるのですが例え失敗しても全く問題ないのがスクラムの良い所です。また次のスプリントがありますし、失敗はチームの学びとしてより良いプラクティスを見つけるための糧になるからです。
「私は失敗したことがない。ただ、１万通りのうまくいかない方法を見つけただけだ。」
トーマス・エジソン
これが経験主義というスクラムの根底にある考え方なのかなと思いました。
まとめ
- スクラムマスターの目的は、スクラムを確立し、チームにスクラムの有効性をもたせること
- スクラムを確立することで、組織は最速で利益を最大化できるようになる
- スクラムガイド及びスクラムは意図的に抽象化されていて、スクラムを確立するための具体的なプラクティスは日々試行錯誤しながら自分たちで考えていく
- 具体的なプラクティスは失敗しても問題ない。チームの学びとしてより良いプラクティスを見つけるための糧になるのだから
最後に
日々試行錯誤しながら、最高の組織を作っていきましょう！
Discussion