こんにちは。 スクラムマスターの濱田（ @hamakou108 ）です。
弊社の開発チームでは特定の役割を遂行するための指針を「型」として文書化し、チーム内で共有しています。
今回はその一つである「スクラムマスターの型」を紹介します。
昨年末より弊社の開発チームではスクラムを使って開発を進めています。 自分は入社以来エンジニアとして開発に携わってきましたが、チーム内でもスクラムに関する知見がある方だったので、今は専任スクラムマスターとして役割をこなしています。 幾つかの困難はありましたが、スクラムが始まってからメンバー視点でも良い変化を感じているようです。
スクラムが何とか軌道に乗ってきたところで、次にスクラムマスターの引き継ぎという課題に取り組んでいます。 スクラム開始当初から、エンジニア内でスクラムマスターを数ヶ月スパンでローリングする計画を立てており、今月はスクラムマスターの引き継ぎを粛々と進めています。
ただ、スクラムマスターに期待される役割はエンジニアとは大きく異なります。 自分は前職でのスクラムマスターの経験から業務内容をある程度イメージできたものの、いざ進めてみるとチームの問題解決に悩む場面が多くありました。 そのような経験を顧みたとき、スクラムマスターの指針となるようなドキュメントがあると嬉しかったという思いから、「スクラムマスターの型」を作成しました。 スクラムマスターのこれまでの業務の引き継ぎに加えて、このドキュメントなどを通してスクラムマスターの責務を明確にすることで、意欲があれば誰でもスクラムマスターの役割を果たせるような体制を作りたいと考えています。
弊社に限らず、他社のチームのスクラムマスターにも参考になればと思い、このドキュメントの内容を紹介します。
はじめに
これは何？
弊社におけるスクラムマスターの役割についてまとめた資料です。 M&Aクラウドで新しくスクラムマスターを担当される方にとっての指針となることを狙いとしています。
このドキュメントで書かないこと
スクラムマスターの役割
スクラムガイドによると、スクラムマスターが責任を持つのは次の2つ。
1 の責任を果たすために、まずスクラムマスター自身がスクラムの理論、プラクティスを理解しよう。 スクラムは「経験主義」と「リーン思考」に基づいており、これらを理解しないままスクラムを実践することは難しい。 「経験主義」や「リーン思考」について理解を深めたい場合、例えば以下のような書籍を読んで理解を深めよう。
2 の責任を果たすために、スクラムマスターはスクラムチームをゴールに向けてコーチングしよう。 チームの置かれた環境は市場、組織、プロセス、プロダクト、メンバーなど様々な要素で構成され、各チームによって固有のものとなる。 したがって、同じような問題であっても有効な解決策はチームによって異なる。 スクラムマスターはチームの状況と発生した問題を観察し、スクラムが確立された状態を維持しながら、チームが自分たちに合った適応を実践できるように手引きしよう。
本やネット上のリソースをそのままチームに適用しても機能するとは限らないが、似たような問題への対処例として参考にできる側面もある。 例えば以下のような書籍を読んで参考にしよう。
判断に迷ったときは「経験主義」と「リーン思考」に立ち返ることをおすすめしたい。 その方策が「経験主義」や「リーン思考」を強めるかどうか考え、チームが正しい方向に向かっているのか判断しよう。 チームが方策を決めるまでのプロセスに関しても、上記の基準に照らして振り返ると良い。
標準的な業務およびプラクティス
M&Aクラウドのスクラムマスターの標準的な業務およびプラクティスについて記す。 なおこれらの役割分担やプラクティスが有効かどうかはチーム固有のコンテキストに依存するため、スクラムマスターは臨機応変に業務の委任や排除について判断しよう。
スクラムを始める前に
チームを設計する
チームを構成するメンバーがどのような専門性、価値観、性格を備えているか理解しよう。 例えばどんなに技術的な専門性が高くても、アジャイルやスクラムの価値観に共感してもらえないメンバーをスクラムチームに加えることのリスクについて考えよう。
チームのサイズについても考慮しよう。 チームメンバーの数が少なすぎるとチーミングによる相乗効果を生み出せず、多すぎるとコミュニケーションパス増大の問題が顕著となる。
また弊社にはエンジニアメンターの型として規定されるようなメンターの役割が存在する。 メンター役のメンバーと業務がコンフリクトしないように、メンターとスクラムマスターの間でどのように役割分担するのかあらかじめ調整しておこう。
スクラムを設計する
スクラムを構成する要素についてあらかじめ設計しておこう。
- スプリントのタイムボックスを何週間にするか
- 各スクラムイベントはいつ、何時間行うか、誰を招待するか、どのようなアジェンダで進行するか
- プロダクトバックログやスプリントバックログをどのように管理するか
- ユーザーストーリーをどのようなフォーマットで記述するか
- DoD や READY をどのように定義するか
- 開発やコミュニケーションにどのようなツールを利用するか
- etc.
これらの最適解もチーム固有のコンテキストに依存する。 しかし一般的に言って、チームがアジャイルやスクラムに慣れていないほど丁寧に導入した方が良い（タイムボックスを長くする、スクラムイベントの進行ルールを細かく規定しておくなど）。
スクラムについてチームに理解してもらう
チームがスクラムについてあまり理解していない場合、スクラムマスターはチームにスクラムを伝授しよう。 最初のスプリントを開始する前に、スクラムとは何か、スクラムはどのようにして問題を解決するのかをチームに説明して理解してもらおう。
チームがプロダクトの置かれている状況について理解していないようなら、 PO からプロダクトゴールについても説明してもらおう。 またインセプションデッキを作るなど、そのチームが置かれている状況について双方向的に理解を深めるのも有用だ。
スクラムを回す
スクラムのルールを守らせる
スクラムを実践する中で、スクラムから逸脱するようなチームメンバーの意見や行動があれば指摘しよう。 どうすべきか伝えるだけでなく、なぜそうすべきなのかも併せて伝えよう。
スクラムイベントのファシリテート
スクラムイベントのファシリテートはスクラムマスターが担当しよう。 各イベントをどのように進行するのか、どのような問題が生じる可能性があるのか、あらかじめシミュレーションしておこう。 必要があればチーム内外のメンバーに協力を依頼して、スクラムイベントが円滑に進行され、きちんと目的が果たされるように取り計らおう。
- e.g. スプリントプランニングの前に PO にプロダクトバックログをリファインメントしてもらう
- e.g. スプリントレビューの前にデモを担当する開発者を決め、リハーサルをしてもらう
ファシリテートそのものに関してはファシリテーター & 議事録係の型も参照。
障害物を排除するように促す
スクラムチームの進捗を妨げる障害物があれば、チームがそれを排除するように働きかけよう。 特にデイリースクラム、スプリントレビュー、スプリントレトロスペクティブについては、「検査」と「適応」が促されるようにイベントを設計し、ファシリテートしよう。 イベントの外でもチーム内外の状況やコミュニケーションを目ざとく観察して、障害物の予兆があればいつでも出向くことができるように備えておこう。
このときスクラムマスターは自分自身で障害を排除してしまわないように注意しよう。 スクラムマスター自身で対処してしまうと、チームメンバーの学習の機会を奪ってしまうことに繋がる。 ただしプロジェクトの存続に関わるほどの緊急事態であれば、この限りではない。
チームを成長させる
チームの成長には時間が掛かることを理解しよう。 タックマンモデルによると、チームは「形成期」、「混乱期」、「統一期」、「機能期」の順に成熟する。 チームがいかに「形成期」と「混乱期」をスピーディーに通り抜けられるかは、スクラムマスターの腕の見せ所だ。 チームメンバーが互いの価値観を理解し合えるようなレトロスペクティブの方法や協力して問題に取り組むためのプラクティスを導入するなどして、チームの結束や信頼感を醸成しよう。
またチームの成長に合わせて、チームがより中長期のゴールにフォーカスできるようにしよう。 例えば Sailboat Retrospective などを活用してチームがゴールについて振り返られる機会を設けよう。
またチームのメンバーが変更された場合、チームは「形成期」から成長のはしごを登り直さなければならない。 チームメンバーの変更を打診された場合、スクラムマスターはそれがチームにどのような影響を与えるのか説明できるようにしておこう。
スクラムを広める
ある程度スクラムマスターとしての経験を積んだ人向けの話。
スクラムマスターの育成
自チームのスクラムマスターを引き継ぐ、あるいは新しくスクラムチームが発足するとき、スクラムマスター経験者として新人スクラムマスターを育成しよう。 実際にその人がスクラムマスターとして働き出す前に、自分がスクラムマスターを経験して得た知見や資産をその人に伝授しよう。
また実際にスクラムマスターを担当すると様々な状況に直面することは実感しているはずだ。 そんなときにいつでも相談できる先駆者の存在は支えになるので、新人スクラムマスターを積極的にメンタリングしよう。 特にスクラムを初めて1ヶ月経たないうちは、少なくとも毎週 1on1 する時間を確保しよう。
おわりに
いかがでしたか？ 生まれたばかりでまだまだ揉まれ足りていないドキュメントではありますが、自分と同じように悩める駆け出しスクラムマスターの助けになれば幸いです。
また弊社ではエンジニアやプロダクトマネージャーを積極募集中です。 もし興味があれば気軽に話を聞きにきてください！
