スクラムマスターは、開発者が開発しているときは何をしているのか

という質問をたまにいただきます。今回はこの疑問に答えてみましょう。

スクラムガイドには何と書いてあるか

まずスクラムガイドを紐解いてみましょう。スクラムマスターの役割として、スクラムガイドには下記の３つが挙げられています。

• 開発チームの支援

• プロダクトオーナーの支援

• 組織の支援

ではこれら３つについて見ていきましょう

開発チームの支援

開発チームがコードを書いている間も、プロダクトオーナー（ＰＯ）は顧客の問題を解決するための新しいアイデアを求めて日々活動しています。さまざまな情報を集め、それらを整理してユーザーストーリーを書き、それらに優先順位を付けてプロダクトバックログを更新しています。これらのＰＯの仕事を支援するのもスクラムマスターのお仕事です。

プロダクトオーナーの支援

スプリントの間も、POは次回以降のスプリントに向けたプロダクトバックログづくりに向けて顧客からの情報収集や要求の分析などの活動を続けています。そんな中、ＰＯは集めた情報の整理に苦労していないでしょうか？ユーザーストーリーを上手く書けなくて困っていないでしょうか？何を基準に優先順位を付ければ良いのか考えあぐねていないでしょうか？ステークホルダーと開発チームの板挟みにされて悩み苦しんでいないでしょうか？

これらを解決・改善するために、例えばＤｔｏＤやユーザーストーリーマッピングのセッションを開いてそれをファシリテートしてあげてはどうでしょう？データの分析方法をＰＯといっしょに考えてみてはどうでしょう？ステークホルダーに頻繁な仮説検証の意味を説いてあげてはどうでしょう？

開発者の支援

一方開発チームでは日々コンフリクトが起きているかも知れません。何もGitのマージ時のコンフリクトだけではありません。実装やテスト方法を巡る開発者同士の小さな言い争いも起きるでしょう。そんなときスクラムマスターは颯爽と立ち上がってホワイトボードに向かい、「今議論しているのはこういう問題だよね？選択肢はこれとこれ？じゃあどちらがいいかの選択基準をいくつか挙げてみてくれる？」とファシリテーションを買って出ます。

あなたにエンジニアリングの素養があるなら、ビルドスクリプトが遅く、頻繁なビルドをためらっている開発チームに、実験的にスクリプトの改善版を作成して提案することも出来るでしょう。

組織の支援

スクラムチームが、より大きな組織の一部である場合、特に一定以上の規模の企業である場合、従来型の官僚的なガバナンスとアジャイルな仕事のやり方の整合が取れていない可能性が高いです。ＱＡチームからはリリースごとの判定会議開催を求められているかも知れませんし、ＰＭＯからは、要件変更のたびに無意味な変更要求仕様書と要件合意のプロセスを強要されていることでしょう。管理職たちはプレッシャー以外の方法で部下を動かす方法を知らず、プロダクトのリリースよりも局所最適のために日々奔走し、従業員たちは、自らの仕事の目的や意味を考えることを放棄し、全ての意思決定を上司に委ねているかも知れません。

こういう人たちを官僚主義の呪縛から解放し、自立した大人によるSelf Organizedな組織に変貌させて行くこともスクラムマスターの仕事なのです。たとえばVSMをやってムダな承認会議を廃止したり、DevとOps、あるいはQA間の対立解消や緩和をファシリテートしたり、組織間のハンドオーバーをなくしたストリームアラインド（Stream Aligned）なチームづくりを支援したりしてはどうでしょうか。

というようなことをやっていると、開発者が開発している間何をしよう？と悩んでいるひまはなさそうですね！