スクラムマスターも一緒に作業をしたらいいんだよ
このメモは?
支援先のスクラムマスターから「スクラムマスターはコードを書いてもいいのか?」という質問があり、それに対するいくつかの考え方の1つを書いています。
要約
この文章で伝えたいことは次の3つです。
1. スクラムマスターは多くの時間を「観察」に使うことが多い。観察することでいろいろなことを獲得し、どのように関わっていくかのヒントを得る 2. 観察や情報の獲得の1つとして、自分も実際にやってみることがある
3. 実際にやってみる(=一緒に作業をする)際には、スクラムマスターのタスクの完了がチームのボトルネックにならないよう注意すること
観察には外からと中からがある
スクラムマスターの役割の基本には「観察」があります。少し外からチームがどんなふうに仕事をしているのか、どんな会話をしているのかを捉えることはチームの状況を知ったり、今後どのような支援をすることが必要かを知るために大切な活動です。
しかし外側からの観察だけでなく、実際にスクラムマスターも一緒にチームの活動に参加することで少し外から観察するだけではわからなかったことも「中から観察する」ことで獲得できます。
一緒にやってみるからわかること
「中からの観察」を実現するために一緒にやってみることとして例えば次のようなことがあります。
一緒にコードを書く
コードの全体観を把握したり、どんなコードの傾向にあるのかを知ったりすることができます
またテストコードにも触れることでどのような観点でテストコードが書かれているのかを知ることもできます
一緒にデプロイ作業、リリース作業を実際にやってみる
自働化の割合やどういうところにプレッシャーや手間があるのかを感じることができます
コードレビューをしたり、自分のコードをレビューしてもらう
レビュープロセスでのコメントのやりとりを通じてメンバーの関係性やスキルを知ったり、Pull Requestの粒度などを知ることができます
チームが普段どのように仕事をしているのか、どんな会話をしているのかといったことを詳しく体感レベルで知ることができます
ユーザーと会ったりする活動(ユーザーインタビューなど)を一緒に行う
チームがユーザーのこと、課題などといったプロダクトに価値を付与するために必要な情報をどういう風にとらえているかがわかります(自分も含む)
こうしてチームと同じ目線で作業を経験すると、情報や手触り感が得られ、プロダクトやチームの状況をより具体的に把握できます。 それが結果として「スクラムマスターとしてどのようにチームに働きかければよいか」を考える助けになるのです。
注意点:自分のタスクの完了がチームのゴールのボトルネックにならないこと
スクラムマスターがあるコードを書くというタスクを完了させないと、スプリントゴールが実現できない状況は避けるようにしましょう。あくまで「チームがうまくなるための観察」が一緒にやってみる理由です。スクラムマスター自身が生成物を生み出すために忙殺されてしまい結果としてその観察が不十分になるのは本末転倒です。
そのためにも、ペア/モブワークを活用したり、チームと話し合ってスクラムマスターの行動の目的などについて共通認識を作っておくのも必要です。