スクラムマスターに関するよくある質問とその回答

みなさんこんにちは。@ryuzeeです。

6/1にスクラム道.06を実施しました。今回のテーマはスクラムマスターということで幅広い議論になりました。その中でも一番最後に出た4つの質問が非常に良い質問だったので、現場でも僕の解を言いましたがここにも書いておきたいと思います。なお、いつも言っていますがソフトウェア開発はコンテキスト依存性が極めて高いので、唯一絶対解はありません。ある現場でうまくいったことが他の現場でうまくいくとは限りません。そこがまた面白いところということで理解してください。

質問：スクラムマスターは指示しないと言っているが、誘導尋問をしていないか？

もともとの話の流れは、チームに対してスクラムマスターが開発チームにアーキテクチャや実装上のお願いをしたい場合指示するの？それともしないの？という話から来ています。

まずスクラムマスターの役割は、スクラムのプロセスがうまく回ることを保証する役割および外部の妨害からチームを守るものであって、一義的にはアーキテクチャや実装に関して決定する権限はありません。権限がないことをチームが理解していれば、チームに対してスクラムマスターが何をいっても、「まーた鶏（この場合は）がなんか言ってるので聞いてみるけど、決めるのは俺たちチームだからなー」という行動がとれます。

スクラムマスターが指示をしてしまって、なおかつチームがそれを指示と受け止めてしまうのであれば、まだチームはコマンドコントロールから抜け出せていないことを意味します。

こうなる理由としては、従来型組織の中でスクラムを実施する場合、スクラムマスターの人間が会社のライン上のポジションではチームメンバーより上の立場に位置していること、さらにはチームメンバーの評価権限を持っていたりすることが多いことが挙げられるでしょう。従来型組織における管理職（コマンドコントロール）とスクラムマスター（自己組織化を誘発）の両立は器用な人であれば可能かもしれませんが、多くの人にとっては難しいことすし、そのような人と接するチームメンバーにとっても当然ながら行動が難しいものになります。組織の成熟度があがるまでは、管理職とスクラムマスターの担当者は明確にわけておくほうが無難でしょう。

以上を踏まえて僕の意見としては、チームにお願いしたい内容は、自分がスクラムマスターの場合は、プロダクトオーナーと相談してバックログに入れるというのが解になります（もちろんコンテキストに依存しますし、1つの解に過ぎません）。

プロダクトバックログに入れる内容は単純な実装の話ではなく（それは通常プロダクトバックログアイテムとしては入らないことが多い）、なぜそれが必要かの理由を含めたストーリーであることが一般的です。例えばチームにログ出力の精緻化を依頼したい場合、その背景にはビジネス価値があるはずです。ストーリーは「アプリケーションの操作ログからエラー内容と対応策を知ることができる。それによって障害時の検知と対応を短縮化する」みたいな感じになるでしょう。

質問：スクラムマスターが決めてしまったほうが早く価値を生める場合もチームに決めさせるのか？

強いチームを作って長くそのチームで仕事していくのであれば、チームに決めさせたほうが良いでしょう。それは魚を与えるのか魚の取り方を教えるのか、という話だからです。機能横断のチームを作ってチームで成果を出していくことが価値観なので、必要な職能はチームメンバーに付けさせたほうが良いわけです。でないとスクラムマスターはいつまでも忙しいままです。

質問：スプリントの期間はどうプロダクトオーナーに納得してもらうのか？

スクラムではスプリントの期間は1か月までと決められていますが、その中で1スプリントをどのくらいの長さにするのかは以下の要因によって決定します。

プロダクトオーナーがチームが作っているモノに対しての口出しを我慢できる期間
プロダクトオーナーとチームの物理距離やプロダクトオーナーがかかわれる時間と頻度
構築しているソフトウェアの大きさ
チームの成熟度
品質基準、完成の定義の粒度
チーム体制（1チームなのか複数チームなのか、分散開発なのか…）

なお、スプリントで実施すると宣言したものができないことも当然あり得ます。ソフトウェアが不確実である以上、当然の話です。スプリントプランニングで選択したプロダクトバックログアイテムの実現に対して、チームは「全力でそのプロダクトバックログアイテムに取り組む」ことに対してコミットするのであって、必ず終わらせることをコミットするわけではありません。（この点については今年の1月にジェフ・サザーランドさんのCSPO研修の際にご本人に直接質問して確認しました。参考：https://www.ryuzee.com/contents/blog/3567）

これをはき違えて、必ず完了にすることに対して圧力がかかると、チームはテストの量を減らしたり、見積りを大きく出したり、本来は確保すべきでないバッファを予め積み上げたりして自分たちを守るようになります。それでは透明性が失われてしまいます（ビジネス価値の実現に向かってチームが活動するのではなく、自分たちが被害をこうむらないようにする、とういうのが行動基準になってしまう）。

質問：優先順位は低いがあとから実施すると開発工数が大きくなるようなプロダクトバックログアイテムにどう対処するのか？

優先順位（ビジネス価値）の高いものからリリースする、必要になってはじめて作業をする（YAGNIの原則）あたりが大事な価値観なので、当初の段階では上記のようなことはあまり想定しません。 Standishの調査によれば、そもそも構築したソフトウェアの64%はほとんど、もしくはまったく使われていないという統計データもあり、将来を予測して現在に多くの労力を使うことはムダです。

とここまでで断定してしまっていますが、アーキテクチャジャンプの話はもちろん気にしなければならず、特に大規模アジャイルの場合などは、アーキテクチャは自生せず、継続的なアーキテクチャの変更には耐えられないことが多いので、意図的にアーキテクチャをプロジェクト初期段階につくることが多くなります。詳しくはアジャイル開発の本質とスケールアップを参照すると良いでしょう。

ただし、あくまで多くのチームによって構成される大規模なものの場合の話であって、1チームでの開発であれば、将来を予測しすぎることはムダです。本日の話の中でプロダクトバックログアイテムの抽出と見積りに時間がかかっている、という悩みをもった方がいましたが、次のスプリントを実施するのに十分な量のプロダクトバックログアイテムが準備できれいればよいのであって、全てのプロダクトバックログアイテムを最初から精緻化してしまうのも作り過ぎのムダであるといえます。

それでは。