チーム開発の視点が変わる アジャイル開発の新常識 第9回 意外とわかってない？スクラムマスターの役割
2022.02.14
＊本コラムは、技術評論社「Software Design」2021年8月号に寄稿したコラムを掲載しています。
アジャイル開発のデファクトであるスクラムに日々取り組んでいるスクラムマスター（以下SMと略記）や、これからスクラムを始めようとしているみなさんは、スクラムガイド注1の冒頭に書かれている次の文章をどう読み取りますか？
スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
「スクラムの理論を実現するために必要な部分のみが定義されている」と記載されている一方で、「スクラムのルールは詳細な指示を提供するものではなく」とあります。どうやら、最低限のことは書いてあるものの、細かいやり方は載っていないのかな、と想像できそうです。
最後まで読み進めてみましょう。多くの方は、読み切ってもSMの役割がいまいちピンとこなかったのではないでしょうか？ また、「SMとしてそれらしく振る舞っているけれど、合っているかどうか不安」と感じているSMもいるかもしれません。もう少し具体的なSMの姿を知っておきたいのではないでしょうか。
今回は、スクラムのフレームワークで定義されている要素の中の1つ、スクラムロール（スクラムチーム内の各メンバーの役割）を取り上げます。SMの目線でスクラムロールの責務について深く、実践的に読み解き、開発現場でのよくある誤った事例を紹介し、あるべき姿を解説します。
スクラムロールのおさらい
まずは、スクラムロールについて、スクラムガイドから抜粋しておさらいしましょう。
スクラムチームのメンバーには開発者・プロダクトオーナー（以下POと略記）・SMの3つのロールがあります。スクラムガイドに記載されている表現のまま、ロールごとに「役割」と「責務」に分けて紹介します（表1）。
表1 各スクラムロールが担う役割と責務
「ピザの宅配」でスクラムロールの関係性をたとえてみる
スクラムガイドに記載されているスクラムロールの定義をおさらいしたところで、スクラムロールを「ロール間の関係性」に注目して整理したいと思います。現実世界の何かにあてはめるとイメージしやすいので、「子どもに楽しい誕生日パーティーを過ごしてもらう」というシーンを、保護者の立場から考えてみます。
「誕生日を迎えた主役の子ども」と「その家族」は、「楽しい時を過ごす」という価値を受け取るので、この誕生日パーティーにおけるエンドユーザーです（図1）。子どもの保護者は、楽しい誕生日パーティーというサービスに対してのオーナーシップを持っていますので、POの役割です。誕生日パーティーを盛り上げるために「子どもが食べるピザを届けてもらう」というPBL（表2）を作成できそうですね。このPBLを実現するための各ロールを図2のイラストと表3にまとめました。
図1 誕生日パーティーのエンドユーザーが子どもだとすると、
プロダクトオーナーはその保護者
表2 ピザ宅配の例におけるプロダクトバックログ
図2 開発者をスタッフ、スクラムマスターを店長とする
図3 エンドユーザーにプロダクトが行き届いた状態
表3 ピザ宅配の例におけるスクラムロール
おや、「スクラムロールをピザ屋さんの宅配にあてはめる」話をしている間に、誕生日パーティーにアツアツでおいしいピザが届きました（図3）。子どもも家族も好物を目の前にしてうれしそうです。良かったですね！
さて、このピザはどのように運ばれてきたのでしょうか。「ピザを作るため、配送するための的確な注文、調理に必要な材料と厨房、整理されたプロセス、訓練されたスタッフ、的確な配送手段をもとに、おいしいピザを作るレシピをもって製造され、ご自宅に運ばれてきた」はずです。各ロールがそれぞれの責務を適切に果たしていたからこその連携プレーと言えるのではないでしょうか。
スクラムロールの誤解から起きる問題とあるべき姿
ではもし、ピザ屋さんの例で下記のようなことが起こっていたら、どうなっていたでしょうか？
- 注文者が子どもの好みやアレルギーの有無を取り違えた
- 店舗スタッフが注文を取り違えた。食材の在庫がなかった。配送スタッフが別注文で出払っていた
- 店長がスタッフの代わりに注文を受け、経験上子どもが喜びそうなメニューを勝手に考えて発注してしまった
- スタッフが足りないため、スタッフ経験のある店長が調理や宅配も行っているが時間がなく、仕事の品質や店舗設備のメンテナンス、労働時間や安全への配慮といった店舗全体のケアを怠ってしまった
結果として、楽しいどころか、残念では済まされない何かが起きるのではないでしょうか。
ここからはスクラムの開発現場で実際によくある誤った事例を挙げてみます。誤った事例には、スクラムにおける役割の定義と一致していない行動やマインドが含まれていそうです。
スクラムマスターがプロダクトバックログを作成してしまう
来週から開発チームのスプリントが始まりますが、POからSMに相談があるようです。
PO「実は、忙しくて、まだPBLが作成できていません。私の代わりにPBLを作成してもらえませんか？」
SM「わかりました！（POが困っている。助けなきゃ！あとでPBLをPOに確認してもらおう）」
その後、POがPBLを確認する時間すら取れないままスプリントが開始し、開発中もSMに任せっきりで、ついにスプリント最終日のスプリントレビューを迎えました。
PO「あれれ？このケースではこの機能はこのように動いてほしいのですが。困ったな。関係者に怒られちゃうよ」
開発者「PBLに記載されている完了の定義はすべて満たしていますよ？」
結局、次のスプリントで、成果物の半分を作り直す羽目になってしまい、開発チームのモチベーションも下がってしまいました。
- ●何が問題だったか？
SMは、「効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する」というスクラムガイドの記載を拡大解釈し、POの役割をすべて代行してしまいました。POは、SMの言葉に甘え、ついにスプリントレビューを迎えるまで、開発者が何を作っているかを理解していませんでした。 - ●どうすればよかったのか？
SMは、POから忙しくて時間が取れないと相談を受けたとき、まず、POがPBLを作成できない原因を正しく分析すべきでした。POがPBLの作成に時間が取れないことはよくあり、その原因はさまざまです。
- POの頭の中で作りたいものは明確になっているが、PBLを書く時間がない
- POの頭の中で作りたいものは明確になっていて、時間もあるが、PBLの書き方がわからない
- POの頭の中でも作りたいものが明確になっていない
POとして、作りたいものが明確であれば、SMはPOから少し時間をもらってやりたいことを引き出し、PBLを作り上げ、POに最終確認してもらう、という手段が取れそうです。作りたいものが明確になっていないのであれば、まずどこまで明確になっているかを把握する必要があるでしょう。詳しくは、連載の第3回、第4回注2の「初めての新規サービス開発」で進め方を説明していますが、ユーザーストーリーマッピングなどの手法をPOに教えてあげて、一緒に作りたいものを明確にしていくと良いのではないでしょうか。
このように、SMがPOに対して正しい振る舞いをしていれば、価値のあるPBLを開発チームへと提供できたでしょうし、開発チームのモチベーションが下がることもなかったはずです。
SMは、POがPBLを作成することを支援しますが、PBLに最終的な責任を持つのはPOです。そのためにも、SMはPOに自身の責務を強く認識してもらうような意識付けをしながら、POを陰から支援し、POの成長を促していくべきです。
スクラムマスターが開発チームの問題を解決しようとしてしまう
次のスプリントで実装する予定のPBLをSMと開発チームが確認しています。
開発者「このPBLをどうやって実現するかわからないです」
SM「（チームが困っている！ 助けなければ！）ここは僕が検討しておきます！」
なんとかSMが実現手段を確立し、開発チームにやり方を伝えることができました。
開発者「この技術は初めて使うので、自信がありません」
SM「（またチームが困っている！ 助けなければ！）ここは僕が作っておきます！」
そしてスプリントレビューを迎えました。
開発者「この機能はSMが作ったのでSMから説明をお願いします」
SM「……」
- ●何が問題だったか？
このSMは、PBLからインクリメントを作成するための実現手段を検討することや、インクリメントを作成することをSMの役割であると思い込んでしまっています。
このSMは、「スクラムマスターは、さまざまな形でスクラムチームを支援する」というスクラムガイドの記載を見て、開発チームが困っていたら、何が何でも助けてあげなければ、と誤解してしまったのでしょう。ところが、開発チームの役割についての記載を見てみると、「各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する」とあります。つまり、SMはインクリメントの作成は開発者の役割であることを念頭に、注意深く開発チームを支援しなければならないことがわかります。 - ●どうすればよかったか？
スクラムを始めて間もない開発チームは、スクラムロールを正しく理解しておらず、安易にSMへ助けを求めてしまうことがよくあります。さらに、このケースでは、SMも理解が乏しく、その助けに応じてしまっています。SMはスクラム経験が豊富な人が担当することが多く、おのずとSMは開発経験も豊富で、技術スキルも比較的高いことが多いです。仮に開発チームが正しいスクラムロールを理解していても、開発チームが未熟であるほど、SMに助けを求めたくなる気持ちもわかります。一方、POからすれば、誰がインクリメントを作成していようが、スプリントゴールを達成できていれば、それで良し、と思うでしょう。今回の例でも、このスプリントはインクリメントが作成できたようです。短期的にはそれでいいかもしれません。
しかし、中長期的に見て、このスクラムチームは現在の生産性を維持できるでしょうか。もし、SMでも実現できないPBLだったら？SMが開発チームの手助けばかりをして、本来のSMの仕事を放置してしまったら？ SMに負荷がかかり過ぎて、体調を崩してしまったら？開発チームがインクリメントの作成の方法に困っていたら、それは、開発チームにとっての障害ではなく、開発チームの成長に向けた絶好の機会です。SM自身が開発者として高いスキルを持っていることは心強いですが、チームの成長のために、SMはぐっと我慢しましょう。中長期的に見て高い生産性を出せる開発チームになってもらうために、SMは、チームが自律的に考え、手を動かし、失敗し、改善するのを促していくべきです。
スクラムマスターがプロダクトの品質を作りこもうとしてしまう
スプリントが開始し、デイリースクラムの場で開発者から問題が挙がりました。
開発者「これからテストを始めるのですが、テスト観点の整理がまだできていないので、テストケースが作れません」
SM「私ができるのでやっときます！（チームにはテストの作業に集中してもらいたいからな。テストが始められないのは困るだろうし）」
その後、チームはSMが作ったテスト観点表でテストを行いましたが、モンキーテスト注3でバグが多く見つかり、そのスプリントのレトロスペクティブ（振り返り）で品質の低さが話題に上がっています。
開発者「品質チェックの観点に漏れがあると思います。SMの対応漏れなんじゃないですか？」
SM「……」
- ●何が問題だったか？
SMは、「スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する」というスクラムガイドの記載を見て、開発チームがコーディングやテストの作業に集中できるよう、良かれと思ってテスト観点表を作成し、チームに提供しました。ところが、開発チームの役割の記載を見ると、「完成の定義を忠実に守ることにより品質を作り込む」とあり、品質の作り込みは開発チームの役割であることがわかります。テスト観点の作成は品質の作り込みと同義であり、SMがやるべきことではありません。
さらに、レトロスペクティブでは開発チームがSMに責任転嫁をしようとしており、開発チームの意識付けにも課題があることがわかりました。 - ●どうすればよかったか？
SMは、品質の作りこみは開発チームが責任を持つことを説明し、その実施を開発チームに促していくべきです。まず、今回のケースのように、品質の作り込みのプロセスに不足があることに開発チームが気づいたのであれば、SMは手助けをせず、開発チーム自身が問題を解決するのを促すべきでした。ほかにも、SM は、品質を透明化する手段を提供したり、スクラムチーム外から助言を得られる場を作ったりするなど、開発チームが自律的に品質の作りこみができるようにするための仕事をするべきです。
開発チームがSMに品質不足の責任転嫁をしてしまった問題は、根が深そうです。今回のケースでは、最終的にSMが品質の責任を負いそうになっていますが、一部の優秀な開発者のみが品質の全責任を負い、テストやバグの修正をその開発者に任せっきりにしているチームもよく見受けられます。テストやバグの修正に責任を負わない開発者が、良い設計や良いソースコードを書けるでしょうか？そのような開発者がいるチームで良好な信頼関係を築けるでしょうか？SMや一部の開発者のみで品質の責任を持つことは、プロダクトの品質低下を招くだけではなく、スクラムの根幹にある信頼関係も損ねかねません。
スクラムマスターがスクラムチームを守り過ぎてしまう
開発チームはスプリントプランニングが終わり、開発作業にとりかかっています。そこでSMはPOから相談を受けました。
PO「今のスプリントで開発している機能が、もしかすると不要になりそうです。ただ、正式決定まで時間がかかるんです」
SM「（すでに開発に着手しちゃってるし、スプリントのゴールが変わっちゃうな……。それに、まだ決まっていないしな。モチベーションが下がりかねないし、開発チームには言わないでおこう）わかりました！」
結局SMは、スプリントが終わるまで、このことを開発チームに伝えませんでした。そしてスプリントレビューを迎えました。
PO「SMには相談していましたが、結局、今回作成してもらった機能は不要となりました」
開発者「ええ、せっかくがんばったのに！作ったものが無駄だなんて……。それなら早く教えてほしかったな」
SM「（これはまずいな……）」
- ●何が問題だったか？
SMは、「スプリントゴールの達成を危険にさらすような変更はしない」というスプリントのルールの記載どおりに考え、POからのスプリント中のPBLの変更を受け付けませんでした。しかし、POの役割として、「スクラムチームから生み出されるプロダクトの価値を最大化すること」が求められており、この機能がスプリントの途中で無価値になったのにもかかわらず、それでも開発を続行させることをSMだけで判断したことが問題です。SMは、スプリントゴールまでひた向きに頑張っている開発チームのために、外部からの干渉から守ろうとしたのですが、その結果、開発チームのモチベーションが下がってしまいました。 - ●どうすればよかったか？
スプリント中の追加要求はスクラムとして当然あり得る事態です。SMは「スクラムチームの進捗を妨げる障害物を排除するように働きかける」という役割を持ちますが、SM自身が「障害物かどうか」を判断するのではなく、開発チームに情報を共有し、PO やSMも含めてスクラムチーム全体として、不要になった機能の開発を続行するのか、中断するのかを判断すべきだったのではないでしょうか。
では、今回のPOからの相談はスクラムチームにとって障害物だったのでしょうか。スクラムチームは、顧客に価値を提供するために行動しています。スプリントの成果が価値のないものになるのであれば、スプリント中であっても、機能の開発を中断するかどうか検討する余地はありそうです。今回のケースは極端ですが、SMがスクラムチーム外からの干渉から守り過ぎてしまう、というようなことはよくあるのではないでしょうか？ 実際は、スクラムチームにとって障害物ばかりではなく、プラスになるものもあるでしょう。それは、スクラムチームにしかわからないことです。そのために、SMはスクラムチームが自律的に判断できるように支援すべきでしょう。
まとめ
これらの事例から、スクラムガイドだけではあいまいでピンとこなかったSMとしてのあるべき姿が見えてきたのではないでしょうか。おそらく、ウォーターフォールのような従来型の開発プロセスのマネジメントをした経験がある人や、技術的に優秀な人であるほど、SMのあるべき姿を理解すると、実際の現場とのギャップに苦しむかもしれません。
また、このようなSMとしての行動は、2週間程度のスプリントで完結するものではなく、スクラムチームがある限り継続していかなければなりませんし、ほかの現場やチームでも同じような振る舞いが求められることでしょう。SMには、スクラムの正しい理解が求められるだけではなく、困難な状況であってもスクラムを正しく推進するためのノウハウやスキルセット、そして強いマインドセットが求められることが理解できたと思います。
◆ ◆ ◆
SMは、SM自身についての知識だけでなく、スクラムロールや各種のイベント、成果物など、スクラムのすべての要素において正しい理解が求められます。この記事を第一歩として、より理想的なSMを目指していってください。
用語解説
- スクラム：アジャイル開発手法の1つ。複雑なプロダクトを開発・提供・保守するためのフレームワーク
- スプリント：スクラムチームがプロダクトの価値を向上させるための固定的な期間。1ヵ月以内の決まった長さとする
- プロダクトバックログアイテム（PBI）：プロダクトの改善に必要な情報を定義したもの
- プロダクトバックログ（PBL）：PBIを優先度順に一覧化したもの
- スプリントバックログ（SBL）：PBLから、あるスプリント向けに選択したPBIと、それらのPBIを実現するための計画
- インクリメント：スプリントの成果物のこと （動作するソフトウェアである必要がある）
※図は技術評論社の許諾を得て掲載しています。
- 注1）https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese-2.0.pdf
- 注2）それぞれ本誌2021年2月号、本誌2021年3月号にて掲載。
- 注3）テスト手法の1つ。テスト対象や操作手順などを事前に定めず思いつきで試験を行い、意図しない問題がないかを確認することを指します。