「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみた
Scrum Master
みなさま、こんにちは。@stayfoolish.com です。
ryuzee さんの「スクラムマスターを雇う時に聞いてみるとよい38個の質問」を読んで、これは面白そうだなぁーと思ったので回答を考えてみました。
実はこの質問が公開された直後ぐらいに回答はしていたのですが、回答してみた目的が 「今の自分の理解を確認するため、考えを整理するため」 だったので、まったくもって公開するということすら思いつかなかったのです。
ですが、様々な方が回答を公開されている昨今のムーブメントに気づき、そのムーブメントに乗っかっちゃえーと思った次第です。
じゃー、まー、そんな感じでいってみますね。
スポンサーリンク
スクラムマスターの役割について
質問1:アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
どちらかだけを選択するかというゼロイチの話ではないですよね。
どちらに “より重きをおくか” という話なので反対のことはしていないと思います。
だけど、個人的には「（強引に）守らせる」ようなことはしないですね。
守れないことには理由があるはずで、過去の経験的にはそこに改善の余地があることが多いです。
質問2:自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
自分の組織でアジャイルがうまくいっていることを示す兆候は、ビジネスがうまくいってること、ビジネスの顧客が満足してること、組織のメンバーみんなが活き活きと働いてることだと思います。
自分の働きが成功してるか兆候は難しいですねー。
成功はチームの成果だし。
チームが成功してることを自分の働きが成功してることと言い切るのは違うと思うし。
多様なポジションの多くの人が、好ましいと感じる変化をもたらすことができたら、自分の働きが成功したかもと感じてひっそりと喜んでいることが多いです。
質問3:追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
あるでしょうー。チームとして成果にフォーカスできるようなメトリクスを追跡できると素敵だと思います。
ビジネス観点での成果。
顧客満足度の観点での成果。
自分の組織のメンバーの満足度としての成果。
この三つの観点での成果をメトリクスとして追跡し、メトリクス自体ももっといいものを探していく活動を継続的にできるのが素敵だなーと思います。
また、これらを追跡する目的は、チームとして成果にフォーカスし続けるという意識を高いレベルで維持することをメトリクスに助けて貰うためです。
質問4:あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
考えられる理由は、スプリントに投入するプロダクトバックログに改善が必要な状態だったり、プロダクトオーナーと開発チームの関係性だったり、雲の上からの圧力が大き過ぎたり、開発チームの技術力不足だったり、開発チームの仕事の仕方だったり、スプリント中の妨害事項をスクラムマスターが阻止できてなかったりすることが想像できます。
次に問題をどのように指摘するか？についてですが、指摘しません。
いま対応すべき問題かどうか？対応するならどう対応していくか？はチームで決めるのがいいと思うし、そもそもスクラムマスターが問題について分かった気になって単独で対応してくのは好ましくないことだと思うからです。
指摘する代わりに、チームが考えるために必要そうな情報の見える化や、考えられる場作りや、チームに聞いてみる（こういう事象があるように見えるんだけどどう思う？風に）ということは全力でやります。
質問5:製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
もちろん！参加してよい。
参加していないと…
開発チームとプロダクトオーナーの関係性が受発注のそれっぽくなったり、開発チームの意識が言われたものを作ればいいのね的な思考になってしまったり、その結果として、ステキなプロダクトを作るためのアイデアやチームとしてのパワーみたいなものが低くなったり…
つまり、チームとして成果にフォーカスするということよりも、アウトプットにフォーカスしたり「これは自分の仕事じゃない」と極端に線引し過ぎちゃったりというフォースが働きやすくなっちゃうと思います。
次にどのようにするか？ですが、スプリント内のチームのキャパシティから、ディスカバリーを実施する分の時間枠をスプリントプランニングの時に確保しておくのをよく薦めます。
質問6:設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
サポートの大方針としては、プロダクトオーナーでなくても出来ることは、開発チームやスクラムマスターが対応するように働きかけますね。
ただし、スクラムマスターがボリューミーなタスクを長期間持っちゃうと、その時のチームの状況にもよりますが、スクラムチーム全体に好ましくない影響が出ちゃうことが多いので、出来るだけ開発チームが対応できるといいなという考えです。
質問7:どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
インセプションデッキのご近所さんを洗い出すことをおやって、そのご近所さんに挨拶回りをして関心事をヒアリングしたり、飲み会をしたりとか、そんな感じです。
質問8:どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
マインドセットを広げるのに一番効くのは、経験上は、やはり実績です。
1つか２つのチームでやってみて、やってる最中の過程や結果をシェアしたりします。
特に、開発チームやプロダクトオーナーに事例を発表してもらうのも効果が高いです。
ITじゃないステークホルダーをコーチするときの戦略ですが、ITなステークホルダーと変わらないかなぁ。
ソリューション（ex.アジャイルやスクラム）の話を押しつけず、その人たちに寄り添いながら会話していくことを意識します。
具体的には、先ず会話してその人が目指している世界だったり、改善したいと思っていることなどをヒアリングするところがスタート地点ですね。
次に、ヒアリングした内容についてもっと良くするための方法を一緒に考える時間を取ってもらいます。
もっと良くするためにアジャイルなアプローチが合いそうなものがあれば積極的に紹介します。
必要に応じて、アジャイルなアプローチを体験してもらうためのワークショップや簡単なゲームを実施する場合もあります。
質問9:上級管理職にどのようにスクラムを紹介するか
んー… 先ず、聞かれてもいないのにこちらから積極的に紹介するということはしないです。
教えてよと言われたら、知っていることは喜んで教えますが、その人がなぜ教えて欲しいと思っているのか？を意識しながら何が知りたいか？を聞いてから紹介します。
今までで紹介したことが多いのは、スクラムの中身のことより、スクラムを導入することで期待できる効果（どうやるか？より、何故やるのか？）や、事例についてです。
質問10:あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
どんな戦略をとるか？・・・んー、何はともあれ話をしますかね。
何に対して、どう感じているのか？それを取り除くにはどうすればいいのか？を聞いて一緒に考えるかな。
一度だけ、スクラムはめんどくさいから嫌だ。
朝決まった時間に集まるのも、定期的に計画立てるのもめんどくさい。
以前やったことはあるがスクラムマスターから押し付けられてる感を強く感じてもうやりたくないと言われたことはあります。
その時も、何が嫌で、どうやったらいいと思うか？を話し合って、１つづつ具体的な対応方法を一緒に考えました。
結果、スクラムのイベントをやることになりましたが、イベントの名前はスクラムのものは使わなかったです。スクラムに対する嫌悪感を強く感じたので。
プロダクトバックログのグルーミングと見積りについて
質問11:プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
はい、グルーミングと見積の流れについてはよいと思います。
ですが、上記の流れ「だけ」だとすると、プロダクトオーナーの役割という観点でみると不十分ですね。
その要求の価値について考えたり探求したり、その上で、その要求の必要性やリリース時期を考えたりしながら優先順位を決めることでプロダクトや開発チームの活動の価値を最大化するための活動をすることが要求されます。
質問12:チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
プロダクトオーナーがステークホルダーに共有している資料から始めるのが手間もかからなくてよいかなと思います。
追加で知りたい情報があればチームからそのような要求がくるでしょうし。
質問13:誰がユーザーストーリーを書くとよいか？
誰が書いても構わないですが、プロダクトバックログを管理したり優先順位を決めたりするのはプロダクトオーナーなので、プロダクトオーナーが書くのが良いと思います。
質問14:よいユーザーストーリーとはどんなものか？どんな構造か？
下記のフォーマットのように「who、what、why」が明確になっているものがよいユーザーストーリーだと思います。
<役割>として<やりたいこと>ができる。それは<ビジネス的な価値>のためだ。
また、INVEST（独立していて、交渉可能で、価値があって、見積可能で、適切なサイズで、テスト可能）なものが良いですね。
質問15:「Readyの定義」には何が含まれているべきか？
「べき」って強い言葉だなぁという感覚で「絶対に含まれているもので、かつ、最小限のもの」というニュアンスに感じるのですが、そうだとすると、チームによって異なるので、それをあえて言葉にするととても抽象的になりますが…
「そのチームが、開発に着手するために必要なことが含まれているべき」って感じですかね。
自分の経験上は、下記が入ってないと、ちょっと危険かもなーと感じます。
- プロダクトバックログアイテムの内容について大きな疑問がないこと
- 見積もりが完了していること
- どのような状態になったらそのプロダクトバックログアイテムが終わったとみなしていいか？が分かっていること
質問16:ユーザーストーリーを時間で見積もらないのはなぜか？
スクラムでは、ユーザーストーリー（プロダクトバックログアイテム）を見積もることは要求しているが、時間で見積もってはならないとはいってません。
ですがが、ユーザーストーリーを時間ではなく「ポイント」で相対的に見積もることが多い理由には下記のようなものがあると思います。
- 時間で見積もりをした方が、見積作業により多くの時間が掛かりがち
- 時間で見積もりをすると、人によって見積もりの値が異なりやすい
- 時間で見積もると、その数値が独り歩きしたり、何時までに完成すると約束しているんだねと誤解されやすい
質問17:プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
「どのように取り組むか？」については、スプリントプランニングを実施して、過去の実績（ベロシティ）やそのスプリントのキャパシティを参考にしながら優先順位が上のチケットから順番にスプリントに投入していきます。
このときそのスプリントに入れるチケットを決められるのは開発チームだけです。
また、必要なタイミングでベロシティとリリースに含めたいけど未だ完了していないチケットの見積の合計値からリリース日を予測したり、必要に応じてリリースするプロダクトのスコープを調整したりすると思います。
「200個のチケットに取り組めるか？」については、本当に全てが必要なチケットならば取り組むし、そうでなければ取り組まないことになるとおもいます。
もし200個を作った時点で「絶対に200個を作る必要がある」ことが分かっているのならば、そもそも、スクラムで開発しない（別の開発方法で開発する）ことも選択肢として考えてみてもいいかもしれませんね。
スプリントプランニングについて
質問18:チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
もし開発チームが、プロダクトバックログの優先順位が下のものからスプリントに投入しようとしていた場合には、その理由を確認し、必要に応じてプロダクトオーナーと相談して優先順位を変えることもあるかもしれませんが、基本的には優先順位が上のものから投入するように働きかけます。
また、開発チームが、より柔軟に動いて創造性を発揮できるようになることを期待して、そのスプリントで達成したい成果をスプリントゴールとして設定するように働きかけます。
他には、事前にプロダクトバックログアイテムの内容や、やる意義をスクラムチーム全体で理解したり、適切なサイズにしたりして開発に着手できる状態にしておくために、プロダクトバックログリファインメントを活用します。
質問19:ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
そのユーザーストーリーの「利用者が得られると期待している成果、提供する企業が得られると期待している成果、開発者が得られると期待している成果」に基づいて判断します。
それらに紐付かないメトリクスは、多分やる意義を感じられないので受け入れがたいかなーと思います。
質問２０：チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
「質問18」で書いたことと同じです。
質問２１：どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
どのくらいの時間が適切かは、状況によって違いすぎるので僕には答えられないです。。
ただし、たとえばリファクタリングだけをするスプリントを設けるよりも、スプリントの中でプロダクトの開発も行うしリファクタリングもするしという感じで進めていくことをオススメします。
質問２２：チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
個人に割り当てようとする背景に改善したほうがよい事項が隠れているかもしれないので、その理由を教えて貰います。
場合によっては、ストーリーやタスクを個人に割り当てた時に想定される影響（スプリントが終わった時に仕掛中だけど完了しなかったPBIが複数発生しやすい、開発チームの自己組織化が阻害されやすい、開発チームがPBIを動作するソフトウェアに変えることへの責任感の熟成を阻害しがちなど）を説明した上で、今後どうしよっか？を一緒に考えてみる感じです。
行為には何かしら理由があるはずなので、それを聞く前に「それは、絶対にやっちゃダメです（怒）」と一方的に言うようなことは、とても勿体無いことだと思うので、そういうことはしないように意識しています。
質問２３：チームメンバーによるタスクのつまみ食いをどのように扱うか？
先ずはつまみ食いをする理由を聞きます。
そして場合によっては、つまみ食いをすることの影響（スプリントが終わった時に仕掛中だけど完了しなかったプロダクトバックログアイテムが発生しやすいなど）を説明した上で、今後どうしよっか？を一緒に考えてみる感じです。
質問２４：ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
Readyで無いものをスプリントに入れることで発生しそうな影響を共有した上で、それでも入れたいのであれば「確定していない内容、次のスプリントに回すのは無理な理由は何か？」などについてプロダクトオーナーと開発チームで会話する場を設けます。
それらの理由について開発チームが納得できて、2日目に確定した後に再度プランニングし直すコストが掛かること、それによってそのスプリントに入らないユーザーストリーが出てしまう可能性があることについて合意できるならスプリントバックログに入れてみてもいいかなと思います。
質問２５：スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
先ず会話をしますね。
今のスプリントプランニングをどう思っているのか？
スプリントプランニングの何が時間の無駄だと思うのか？
あたりについて教えてもらって、今ある好ましくない状況がどのように変われば、スプリントプランニングが有用な場になるか？を一緒に考えていきたいですね。
スタンドアップやデイリースクラムについて
質問２６：チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
はい、薦めます。
全員が毎日顔を合わせて会話することはチームにいい影響を与えると考えているので。
質問２７：なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
いえ、まったくもって期待しません。
質問２８：スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
まずは、1対1になってデイリースクラムの目的だったり、開催することで期待できる効果を説明します。
説明しても協力的な態度を示してくれない場合には、その人の態度（報告セッションにしてしまう）に対するフィードバック（報告セッションにしてしまっているように見えますよ、そしてそれは開発チームにこんな良くない影響を与えがちですよ）をし、協力をお願いしてみます。
質問２９：スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
まずは、1対1になって「今のスタンドアップをどう思っているか？どの辺りがムダだと思っているか？」というあたりをヒアリングしてみます。
次に、どうやったら有意義な場になるか？を一緒に考えてみたいです。
質問30：スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
んー、スクラムのデイリースクラムのことだと思うのでそれ前提で回答しますが、この状況を変えたいとは思いません。
デイリースクラムは開発チームのための場で、ステークホルダーが参加することは好ましくない状況を生みやすくなるので。
質問31：分散チーム間のスタンドアップをどのように進めるか？
オンライン会議システム（zoomなど）を活用したり、携帯電話をスピーカーモードにして使用します。
質問３２：スクラムチーム用の物理カンバンボードをいま書いてください
タスクボード
ふりかえりについて
質問３３：だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
スクラムチーム全員が参加してよい。なので、もちろんプロダクトオーナーも参加してよい。
その方が、改善できる範囲が広がるし、プロダクトオーナーと開発チームの関係性にも良い影響があると感じているので。
質問３４：チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
チームが健全な状態かは、終始気にしますが、ふりかえりの中でも確認します。
ふりかえりの中での確認方法ですが「ランチの席や飲みの席で個別に聞いた ”みんなには言いづらいかなと思えるような好ましくない事象” をふりかえりの場などを活用してみんなに共有しているか？」とか「スクラムチーム全員が参加しているか？」とか「参加者全員が発言しているか？」とか「特定個人について責任を追求し過ぎていないか？」とか「前回のふりかえりで決まったこと（ActionItemや決定事項）が実行されているか？／守られているか？」とか「愚痴大会になってしまっていないか？」とか…
そのあたりを確認しています。
質問３５：過去に使ったふりかえりのフォーマットはどんなものか？
タイムライン、KPT、KPTA、Start,Stop,Continue、ポジティブふりかえりマッピング、Fun/Done/Learn、YWT、リーンコーヒー、プラス／デルタ など。
質問３６：どうやってマンネリを防いでいるか？
あまりマンネリ感を感じたことはないですが、スクラムチーム全員にアンケートを取って、やってみたいふりかえり手法を募ったりします。
たまに違う場所で開催してみるとかもやります。
質問３７：チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
最新のスクラムガイドではアクションアイテムを最低1つはスプリントバックログに入れましょうと言っています。
もし入ってないのであれば入れるように働きかけます。
入っていても行動できていないのであれば、まず、行動できない原因をチームに聞いてみます。
そしてその原因を取り除くためには何をすればいいかについてみんなで考えていきます。
質問３８：どうやってアクションアイテムのフォローアップを薦めるか？
上記で書いたとおりです。