ブログ

ryuzeeによるブログ記事。不定期更新

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック