スクラムの会議を一通り開いていても、確認待ちが減らず、同じ問題が毎回持ち越されることがあります。
そのときは会議の進行だけでなく、チームが判断し、仕事の進め方を改善できる状態かを確かめる必要があります。
スクラムマスター(Scrum Master)は、スクラムを確立し、スクラムチームの有効性に責任を持つ人です。

チームが自分で判断できるようにする

スクラムマスターは、チームと組織がスクラムの理論と実践を理解するよう支援します。
チームには、仕事の進め方を自分たちで決めるための助言や、価値のある成果を完成させるための支援を行います。
イベントを目的に沿って進め、決められた時間に収めることも、その一部です。

たとえば、デイリースクラムが一人ずつの進捗報告で終わっていたら、スクラムマスターは、開発者がスプリントゴールへの進み具合を話せているか確かめます。
作業が止まっている箇所を一緒に確認する方法を提案し、開発者自身が今日の計画を変えられるようにします。
毎朝スクラムマスターが担当を割り振り続けると、開発者が互いの仕事を調整する機会を奪ってしまいます。

承認待ちが繰り返される例

たとえば、テスト環境の利用承認に毎回数日かかり、スプリントの後半まで検証を始められないチームを考えます。
スクラムマスターは、まず待ち時間と、どの判断で止まっているかをチームと確認します。
開発者が調整できる範囲を確かめ、権限を持つ部門の協力が必要なら、その対話を進めます。

一度だけ承認を急いでもらえば、その回の仕事は進むかもしれません。
同じ問題を減らすには、利用ルールの変更や、事前に使える環境の用意といった選択肢も関係者と検討します。
スクラムマスターがすべての障害を一人で解決する必要はありませんが、障害が取り除かれるよう働きかける責任はあります。

支援する相手で仕事が変わる

チームへの支援では、作業の停滞、技能の偏り、品質の認識のずれなどを扱います。
たとえば「実装済み」と「利用可能」が混同されていたら、完成の定義をチームで確かめる場を作ります。
個人の遅れだけを問題にすると、テストやレビューを後回しにする仕事の進め方が見えなくなります。

プロダクトオーナーには、プロダクトゴールの明確化や、バックログを理解しやすくする方法を支援します。
組織には、チームが関係者と直接話せるようにすることや、観察した結果から計画を変える考え方を理解してもらうことを働きかけます。
職位による指揮権がなくても、こうした対話を通じて変更を進めます。

活動の結果をどう確かめるか

スクラムマスターの仕事は、開催した会議や処理した依頼の件数だけでは判断できません。
たとえば、繰り返していた待ち時間が減ったか、チームが問題を早く共有できるようになったか、ふりかえりで決めた変更を試せたかを確かめます。
これらは、改善を検討するための観察項目です。

チームの有効性には、プロダクトの方針や組織の制約も関わります。
数値が改善しないときは、スクラムマスターだけを評価する材料にせず、どの制約が残っているかをチームや関係者と調べます。

参考資料