Zenn
🐼

「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみました

2024/08/17に公開
スクラムマスター
scrum
idea

はじめに

先日、@Ryuzee さんの「スクラムマスターを雇う時に聞いてみるとよい38個の質問」という少し前の記事を見つけまして、面白そうだなと思ってので遅ればせながら私もやってみました。

お願い

回答は現時点での私の思う正しい回答になり、それと違う意見を否定するものではありません。
私自身も回答通りに出来ていない事もあり反省点も多いのです。
その点も踏まえてご覧いただけますと幸いです。

また、質問の意味を勘違いして答えている事もあるかと思いますが、そこは暖かい目で見て頂けますと幸いです。

「スクラムマスターを雇う時に聞いてみるとよい38個の質問」

スクラムマスターの役割について

  1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
    アジャイルマニフェストでは左記のことがらよりも右記のことがらに価値をおくとあるが左記をないがしろにして良いとは掛かれていない。スクラムのプロセスをまもることはスクラムを成功させるために必要なことなので大変重要であると考える
  2. 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
    何らかの成果物を出せるまでのリードタイムが徐々に短くなっていったとき、後者はメンバーの発言が「私」から「私たち」や「チーム」となっていったとき
  3. 追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
    チームが1スプリントで消化できるストーリーポイントのベロシティ、もしくはPBIの数は追跡すべきメトリックスだと考える。目的はチームが適切な力で価値貢献が出来ているかを把握するため。具体的にはベロシティが安定しているかなどになる。決して結果を評価するためのものではない。
  4. あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
  • プランニング時にその時点においてのチームのパフォーマンス以上のPBIがスプリントバックログに積まれている、PBIの見積りが適切に行われていないまま計画しスプリントが開始している、などが理由では無いかと考えられる。
  • まず、計画に無理が無かったかをメンバーに問いかける。次に見積りについて適切であったか、リファイメントなどで事前に見積もったものをプランニング時に見直したかなどを確認し見直しが出来ていなければプランイング時に再度見直し必要であれば見積りを再度行うことを提案する。
  1. 製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
    ディスカバリープロセスをプロジェクトの要件と目標の調査と分析　と仮定して回答すると参加して良いと考える。特に要件はステークホルダーや出来ればエンドユーザーへヒアリングなどはスクラムチームからも主体的に行いユーザーの求めているものを知るようにするのが望ましいと考える。
  2. 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
    プロダクトオーナーが仕事を抱えすぎていないかを確認する。持ち過ぎであればチーム内で分割出来ないかを検討する。この中でプロダクトオーナーがするべき判断以外であればチーム内に譲渡し、チーム内だけでは難しい場合はチーム外からの支援が出来ないか他のチームや組織に働きかけ相談し解決するようにサポートする。
  3. どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
    スプリントレビューや可能であればディリースクラムにステークホルダーを招くことが出来ないかを検討する。難しければせめてチャットツールなどで非同期にでもスクラムチームとステークホルダーが必要な時に直接対話が出来る環境を作ることを提案する。
  4. どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
    一堂に会する場を定期的に用意する。なるべく専門的な用語はさけチームと協力することで早く価値を生み出す事の価値を認識してもらえるように説明をする。
  5. 上級管理職にどのようにスクラムを紹介するか
  • アジャイルやスクラムを取り組んだ成果の他社事例や世界的な事例の数値的なエビデンスを紹介する
  • 上記の上でレゴスクラムなど体験してもらうトレーニングを行い体系的に理解をして貰るようにする
  1. あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
    抵抗する同僚の意見を個別に聞くようにする。おそらくスクラムを続ける事への不安・懸念があるはずなのでそれを出来るだけ具体的に（オンライン・またはオフラインの）ホワイトボードなどに付箋をはり可視化する。そのうえでどのようにその不安・懸念を解消すれば良いかをスクラムを廃止する選択肢も残した上でチームで議論し結論をチームで出していくように支援する。

プロダクトバックログのリファインメントと見積りについて

  1. プロダクトオーナーはステークホルダーの要求をプロダクトバックログアイテムに落とし込んでその見積りをチームに求めることになる。その流れでよいか？
    PBIはスクラムチームの誰もがプロダクトに取って価値のあると感じるものを作成出来ることが望ましい。ただしそのPBIを実際に実現するかの判断はPOの責任になるため、POが必要だと判断したもののみをメンバーは見積りを行う事が望ましい形だと考えます。
  2. チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
    ステークホルダーとのやり取りや、マーケティング部門からの情報、ユーザーからのフィードバックなどはフィルターなく透明性を持ってチームに共有されるようにお願いをします
  3. 誰がユーザーストーリーを書くとよいか？
    スクラムチームやステークホルダーがプロダクトに必要だと思われるものを書くことが理想的だと考えます。
  4. よいユーザーストーリーとはどんなものか？どんな構造か？
    だれが何を実現したいのか、またそれはなぜなのか（Why）が一目で分かる見出しと、具体的な説明と受け入れ基準が明確になっているものが望ましい形だと考えます。
  5. 「Readyの定義」には何が含まれているべきか？
    PBIがそのスプリントで仕掛かれるかに必要な準備は全て含める必要があると考えます。
    そのため少なくとも下記の点については含まれているべきだと私は思います。
    1. PBIはPOが仕掛かることを同意しているものか
    2. PBIに受け入れ基準は設けられているか
    3. PBIは正しく見積もれる十分な情報が揃っているか
    4. PBIは1スプリント以内、出来れば１日、2日以内に収まるボリュームになっているか
  6. ユーザーストーリーを時間で見積もらないのはなぜか？
    時間の概念は個々によって違うためチームとしての見積りとして出すのは適切ではなくなるため。
  7. プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
    直近、一か月以内に必要となるもの以外はPBLに追加しない方が良いと考えます。理由は時間が経つにつれて状況は変わり、その時に必要だと思われたPBIも不要になるものが出てくるためです。
    ですのでここで行うべき対応はその200件が本当に必要かをリファイメントなどを定期的に行い精査し不要なものをその時点で破棄し必要なものを見積り、仕掛かるスプリントのプランニングで再度確認を行いその段階で必要と判断されたものだけを取り組むべきだと考えます。

スプリントプランニングについて

  1. チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
    スプリントで達成できそうなPBI = スプリントゴールではなく、達成したいゴールを満たすためのPBIになるように意識するようにファシリテーションをしていく。
    なぜならゴールを目指す中で全てのPBIを完成しなくてもスプリントゴールを達成する可能性があるため。逆にスプリントゴールの達成にはプランニング時の想定出来なかったPBIが必要になる場合に計画の変更を行う必要が出来てくる可能性もあるため。

  2. ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
    ユーザーストーリーの価値は完成後にユーザーが得ることが出来る価値を基準に判断するべきである。そのユーザーストーリーをリリースすることによるROIなどが判断の際に使用するメトリックスとしては適切であると考えます。受け入れがたい判断基準としては実装の難易度などユーザーには関係のない運用側の都合などになり、これは避けるべきだと考えます。

  3. チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
    プロダクトにおいてもっとも価値を上げる事の出来るユーザーストーリーは何かをPOを含めチームに問いかけ答えを出してもらえるようにします。

  4. どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
    感覚値になりますが1スプリントの10%以上、50％以下くらいが妥当ではないかと考えます。

  5. チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
    担当を決めるのはエンジニアであってPOが決める事ではないので特にどう扱わない。

  6. チームメンバーによるタスクのつまみ食いをどのように扱うか？
    基本的にないようにしたい。だがスプリントゴールを早めに達成した場合のおかわりや連休の中日などでチーム活動は停止しているが稼働しているメンバーが隙間時間に気になるＰＢＩの調査であったりリファクタリングをする事はチームのためになるので、事前にチームには仕掛かることを共有した上で行い、完了後はその内容を共有し属人化しないように意識してもらう。

  7. ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
    可能な限りこういった状態は避けるべきなので事前に先のユーザーストーリーを作成出来るようにＰＯの業務の巻き取りなどをＳＭとして積極的に行う。その前提で起きてしまった場合はそのユーザーストーリーをそのスプリントでどうしてもやらなければならないか（スプリントゴールの達成に必要など）をＰＯに確認しや無負えない場合はメンバーに同意を得たうえでスプリントバックログに入れ対応してもらうようにする。

  8. スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
    なぜそのように思うかを1on1を設けてヒアリングする。その理由がアジャイルやスクラムに対する理解不足であれば理解して貰えるように説明をし納得が行くまで話をする。それでも納得して貰えない場合はチーム全員でスクラムをすべきか否かを含めて議論をして納得の結論をチームで出し、その結果にＳＭ、ＰＯも含めたスクラムチームとして従うようにする。これにはスクラムを止める決断も含まれる。

スタンドアップやデイリースクラムについて

  1. チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
    薦めます。デイリースクラムは単なる進捗共有の場ではなく透明化されたチームの状況からスプリントゴールに対して検査を適用をおこなう、例えば必要であればスプリントゴールの見直しなどを行うなどの判断をするための場でもあるためチームのサイズや経験度合いに関係なく行う必要があると考えます。
  2. なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
    待つ必要はないと考えます。チームの支援が必要な場合はその時に助けを求めるべきです。チームはそれが可能な安全な環境である必要があると考えます。
  3. スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
    その場で報告セッションではなくスプリントゴールの達成に対しての場である事の説明を行いそのよう場にしていく提案を行います。そこで合意を得れないのであれば個別に1on1を行い解決策を一緒に議論します。
  4. スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
    個別に1on1を行い、なぜ無駄だと思うかを確認します。そのうえで必要性を説明しやむを得ない事情が無い限り出席してもらうように依頼をします。この時、事情があり開催時間が問題ある場合は時間帯の変更をチームに相談し適切な時間を調整します。
  5. スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
    可能な限り調整を行いだれかが出てもらうように調整をします。またスタンドアップに限らずモブプログラミングなどを行っている場にステークホルダーが自由に参加出来るようにします。
    それでも調整が無理な場合は非同期でのコミュニケーションをいつでも出来るようにするなどの環境を用意しスクラムチームとステークホルダーが直接やりとり出来る機会を増やすようにします。
  6. 分散チーム間のスタンドアップをどのように進めるか？
    分散チーム=同じ場所に揃っていないチームの前提で答えます。メンバーの環境をフラットにするために全員個別にオンラインツールにアクセスするのが望ましいと考えます。オンライン数人とオフライン数人で後者が一つの場所に集まっているとそこでコミュニケーションのズレが生じるのでなるべく避けた方が良いと考えます。もしくはオフラインの数人とオンラインのメンバーでチームを分けてしまうのも一つの方法ではないかと考えます。
  7. スクラムチーム用の物理カンバンボードをいま書いてください

ふりかえりについて

  1. だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
    ふりかえりは誰が参加しても問題ありません。プロダクトオーナーもスクラムチームのメンバーであるためもちろん参加可能です。

  2. チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
    確認する。ふりかえりはそのためにやっていると思っています。確認方法はふりかえりのフォーマットで明らかに出来るもの、たとえばFun！Done！Learn！であれば明確に可視化出来るので結果で確認できますがそうではないフォーマットの場合はふりかえりでのメンバーの発言であったり起票する課題などの内容から健全かを読み取るように心がけています。例えばあまり無難な事しか書いていなかったり、数が極端に少ないメンバーは個別に深堀をするようにインタビューをその場でするようにしています。

  3. 過去に使ったふりかえりのフォーマットはどんなものか？
    KPTA、Fun/Done/Learn、WWW、YWT、「象、死んだ魚、嘔吐」を状況に合わせて使っています。特にチームの状態を把握したい時は「Fun Done Run」が有効でおすすめです。「象、死んだ魚、嘔吐」は腹を割って話したいとき、何かチームが目を背けながら進んでいるなと感じた時に提案してます。

  4. どうやってマンネリを防いでいるか？
    定期的にフォーマットを変えてマンネリしないようにしています。

  5. チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
    行動できていなかったことでの影響を確認します。
    結果、問題があればなぜできなかったのか？どうしたら出来なかったをテーマにディスカッションを行い次に活かすようにします。逆に何も問題が無いのであればそもそもそのアクションが無意味だったという事になるのでそれを学びに次のアクションを選ぶ際は意味のあるものを選んでいくように支援していきます。

  6. どうやってアクションアイテムのフォローアップを薦めるか？
    最初はデイリースクラムでの日々の確認をしたり、ふりかえりの冒頭で確認をするようにします。徐々にチームが自らやってもらえるように支援して行きます。

おわりに

おもしろそうだという動機で始めたのですが、質問に答えていくとかなり真剣に考えてしまい書き終わるのに少し時間が掛かってしまいましたがスクラムマスターのお仕事を改めて考える良い機会になりました！

また他にも回答している人もいらっしゃって、拝見すると色々と発見があり面白かったし学びがありました。

今回の質問には当然ながら色々な答えがあると思っています。
私自身も現時点での回答になるので色々な経験をした後だと答えも変わると思うので定期的に見直しをしてみようかと思います！

それではー

Discussion