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

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

以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。

なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。

それでは、行ってみましょう。

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

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？

スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかったりする場合は、ある程度カタにはめることで機能するようになっていきます。一方で、チームが機能するようになれば、チームが自分たちで良いと考えたことをやるようにしていけばよく、ただカタを守らせるのは無意味になります。つまり、チームを継続的に観察して、チームの状況によって、打つ手を変えていく必要があります。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？

アジャイルを適用する理由は、プロダクトのデリバリーの円滑化のためなので、アイデアが生まれてから実際にデプロイするまでのリードタイム、デプロイの回数はわかりやすい指標です。また、変化に対応して最大の成果を上げるという観点では、売上やコンバージョンレートなどのビジネス面での指標も参考になります。スクラムマスター自体の評価は、チームが成果を出せているかどうかでよく、スクラムマスター専用の指標は別のインセンティブを作るだけです。

追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？

これは上の質問と同じ回答になります。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？

ベロシティが安定しない理由は、選択したプロダクトバックログアイテムが完成したり完成しなかったりすることに起因します。これは、プロダクトバックログが大きすぎる、プロダクトバックログが具体的でない（Readyでない）状態で、無理にスプリントに投入することによって起こります。開発チームが扱えるサイズにプロダクトバックログアイテムを分割すること、プロダクトオーナーが生煮えのプロダクトバックログアイテムをスプリントに投入しようとした場合は全力で止めること、プロダクトバックログリファインメントを継続的に実施してちょっと先まで準備をしておくことなどが必要になります。スクラムチーム自体がスプリントレトロスペクティブで、この事象を問題だと考えて改善することが望ましいので、もしレトロスペクティブの議題としてこれがでないようであれば、毎回終わらないことについて聞いてみるとよいでしょう。

製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？

参加した方がよいです。プロダクトオーナーはプロダクトの責任者なのでディスカバリーの内容を踏まえてプロダクトバックログをどうするか考える必要があります。また開発チームは、単なるプロダクトバックログアイテムを開発するマシーンではなく、プロダクトの価値を実現する一員なので、ディスカバリーに参加したほうが、自分たちに何が求められているか理解できるはずです。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？

プロダクトオーナーしかできないこと、プロダクトオーナーでなくてもできることを分類して、プロダクトオーナーでなくてもできるものは開発チームや、その他の人がやるようにします。プロダクトバックログについても、並び順の最終決定権限はプロダクトオーナーにありますが、プロダクトバックログアイテムを用意する責任がプロダクトオーナーにあるわけではないので、ほかの人が準備をしても構いません。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？

これは最初が肝心かもしれません。プロダクト立ち上げの時点で、ステークホルダーにもアジャイルなやり方の考え方、スクラムの概要などを説明して理解してもらい、継続的に関与してもらえるようにします。ステークホルダーの教育が不足していると、関与の度合いが下がったり、途中でちゃぶ台返しが発生したり、プロダクトオーナーが自分でプロダクトバックログの並び順を決められなくなったり、といった問題が起こります。

どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？

関係者をあつめてトレーニングするのが王道ですが、一方で身近に成功事例がないと関心をもってくれないので、最初に1プロダクトを意地でも成功させて周りの注目をあつめるように仕向けるとよいかもしれません。

上級管理職にどのようにスクラムを紹介するか

スクラム自体はIT以外の仕事にも適用可能なので、不確実性が高い状況において成果を出すための考え方、という立て付けで説明します。

あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？

激しい抵抗を受けたことはないですが、もし抵抗されるようであれば、何か懸念点があることの証なので、理由を聞いてみるのがよいでしょう。それから、変化に対して恐怖を持つ人、失敗するリスクを極端に恐れる人がいることは事実なので、まずは安全な環境で実験してみて、安全であることを理解してもらうのもありです。それでもだめなら、相容れないので、その人を無理に巻き込むのは止めます。合う合わないは少なからずあります。

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

プロダクトオーナーはステークホルダーの要求をプロダクトバックログアイテムに落とし込んでその見積りをチームに求めることになる。その流れでよいか？

その流れもある、というのが正しいです。プロダクトオーナーはプロダクトの結果責任を取るので、なんでもかんでもステークホルダーの言うことを聞いて、それをプロダクトバックログアイテムに落とさなければいけないわけではなく、自分で思いついたアイデア、開発チームから出たアイデア、スプリントレビューのフィードバックの内容などをプロダクトバックログアイテムとして追加します。ステークホルダーの言うことを全部聞かなきゃいけないのであれば、プロダクトオーナー役はステークホルダー自身にやってもらった方がよいのではないでしょうか？

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？

プロダクトオーナーがステークホルダーと握っているKGIやKPIの項目と、その数値がどうなっているか。開発チームはプロダクトオーナーと運命共同体なので、プロダクトオーナーがどんな成果を達成しなければいけないのかを知っている必要があります。それを知っていれば、役に立たないプロダクトバックログアイテムを提案することもないですし、同じ成果を達成するもっと簡単な方法を提案できることもあります。

誰がユーザーストーリーを書くとよいか？

誰でも書いて構いません。プロダクトバックログアイテム自体は、そもそも必ずユーザーストーリー形式で書かなければいけないわけでもありません。プロダクトバックログの並び順を決められるのはプロダクトオーナーだけなので、誰かが書いたアイデアやストーリーは、プロダクトバックログのいちばん下とか別のインボックスなどに入れておいて、定期的にプロダクトオーナーが選別するとよいでしょう。

よいユーザーストーリーとはどんなものか？どんな構造か？

INVESTの性質を満たすとよい、とよく言われます。それぞれIndependent（独立している）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積り可能）、Sized Right（適切なサイズ）、Testable（テスト可能）の頭文字を取ったものです。また、そもそもという点では、「誰にとってどういう価値があって、なにができるようになってほしいか」が明確であることが重要です。個人的にはストーリー形式でなければいけないとは思いません。あくまで会話の道具なので、プロダクトバックログを見たり話したりした結果、全員で共通認識を持てるならそれで構いません。

「Readyの定義」には何が含まれているべきか？

「べき」という質問に対する答えはほとんどの場合、そんなの現場次第でしょ、となります。「必ず」も同じ。とはいえ、最低限、開発チームとして、そのプロダクトバックログアイテムは何ができれば完成なのか分かっていて、大きな質問はなく、サイズの見積りができている、というくらいは必要でしょう。そうしないと、スプリントに入ってから、実はやらなきゃいけないことがたくさんあることが後から分かって完成しなかった、みたいなことが頻繁に発生して、成果の量が不安定になり、予測精度が下がるためです。

ユーザーストーリーを時間で見積もらないのはなぜか？

スクラムでは、プロダクトバックログを見積もれとは言っていますが、時間で見積もってはいけないとか、ポイントで見積もらないといけないとは言っていません。一般論で言うと、具体的な単位がついた見積りは、独り歩きしやすく危険であること、ムダに詳細化してしまう傾向にあること、サイズの見積りに工数を使った場合、それは今も将来も同じサイズのものには同じ時間がかかる前提となっているが、チームの能力は変化するため必ずしもそうはならないことなどが挙げられます。とはいえ、見積りは頻繁に実施しますし、どんどん精度はあがっていくので、数字が悪用されないなら別に具体的な単位がついた数字でも構いません。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？

本当に重要で必要であれば実施するでしょうし、とりあえず入れておいたアイデアはいつまでたっても実施しないかもしれません。プロダクトバックログアイテムを、必ずすべて終わらせる保証などどこにもありません。通常プロダクトバックログの下位になればなるほど、投資対効果が下がっていき、実施する意味は減っていく傾向にあります。なお、一度にたくさん着手するのは仕掛中が増えて、成果がでるまでの時間が伸びるので、仕掛中のプロダクトバックログアイテムの数は減らすことがおすすめです。

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

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？

スプリントプランニングで、どのプロダクトバックログアイテムに着手するかを延々と検討するのでは遅いので、あらかじめプロダクトバックログリファインメントの場で、プロダクトバックログが最新の状態になるように手入れをするように促します。手入れができているかどうかは、スプリントプランニングでの議論の内容や所要時間を観察することで判断できるはずです。リファインメントのタイミングで、プロダクトオーナーに対して、なぜその順番にプロダクトバックログが並んでいるのかを説明してもらうようにすると、開発チームのメンバーが順番に対してフィードバックできるようになります。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？

ビジネス価値とか、KGIとかKPIへの影響度合いでしょうね。目的を達成するために何かを作るので。受け入れがたいメトリクスはあまり経験がないのですが、社内の政治的な話に起因するメトリクスに基づいて何かを作ってもプロダクトとしての成果には関係ないのでムダです。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？

プロダクトバックログを上位から選ぶ際に、まず過去のベロシティと相当する程度のプロダクトバックログアイテムを選択し、その実行計画をたててみます。その実行計画が妥当なものであれば問題ないですし、もし量が少なそうであれば、プロダクトバックログアイテムをさらに追加します。もし量が多いようであれば、対象とするプロダクトバックログアイテムを減らすことを提案します。あんまりぎちぎちにプロダクトバックログアイテムをスプリントに投入する必要もないので、もしプロダクトオーナーが毎回溢れんばかりのプロダクトバックログアイテムを投入したがるなら、それをやめるように提案します。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？

チームによって違うので一概には言えませんが、2-3割くらいではないでしょうか。機能開発だけにフォーカスしつづけると無理が溜まっていき、どこかでいきなり速度が落ちることもあるので、継続的に機能開発とリファクタリングのバランスをとってやっていくのがよいと考えます。もちろん時期によって割合の変動はあるはずです。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？

チームの誰がどのタスクをやるかはチームが決める話ですし、プロダクトバックログアイテムに担当者を割り当てると、あちこち完成しない状況になるって説明するところから始めます。それでも聞かないようであれば、一旦個人で受けておいて、それをチームでやるようにすれば、いずれ気付くのではないかという気がします。

チームメンバーによるタスクのつまみ食いをどのように扱うか？

自分の得意なタスクしかやらず、複数のプロダクトバックログアイテムからつまみぐいしてしまうと、これもあちこち完成しない原因になります。チームとしてプロダクトバックログアイテム自体の同時仕掛り数を制限して、上から確実に終わらせるようにするのがひとつ。ほかには、その人のスキルをつけてもらえばよいので、ペアプロ・モブプロなどを活用して、ほかのこともできるようにしていくのもよいでしょう。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？

Readyではないので、さらに次のスプリントに回すようにするのが安全です。とはいえ、最終的に確定していなくてもサイズが十分小さくて、現状の不確実性がチームで吸収可能だと判断でき、さらにそのプロダクトバックログアイテムは急ぎでやらなければいけないものなのであれば、着手してみてもよいのでは、という気がします。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？

実際にすごく時間がかかっているのかもしれません。まずは参加したくない理由、時間のムダだと思っている理由を個別に聞くところから始めるのが良さそうです。いきなりみんなの前で詰めるようなことをすると、色々こじれてしまうので避けておくのが無難です。

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

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？

チームがスクラムで進めているのであれば、やるように薦めるでしょう。とはいえ、この質問の背景には、チームがデイリースクラムに意味がない、と感じている状況だと思われるので、どんな話をしているのか観察した上で、進め方や話す内容を改善していくのが良さそうです。個人的な意見としては、チームのサイズが小さくて、みんなが同じ場所にいるような状況では、いつでも気軽に同期を取れるので、デイリースクラムという名前じゃなくても、それ相当のことができていることが多いと思いますが、一方でチームのサイズが大きくなると、見えていないことやコミュニケーションロスが増えていくので、デイリースクラムの重要性が増すと考えます。

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？

待たなくてよいです。むしろ早め早め、先手先手で解決していくほうがよいです。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？

立場が上の人、声が大きい人がいるとそうなりやすいです。その人がデイリースクラムの目的を理解していないことに起因することが多いので、イベントの役割を別の場で説明してみます。またデイリースクラムでの立ち位置をみんなの後ろにしてもらったり、試しに発言しないようにしてもらったり、場合によっては他のところに連れ出してみたりしてみます。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？

まずはイベントの意味を説明して理解してもらうところがスタートでしょう。あとはデイリースクラムは必ずしも朝やらなければいけないわけではないので、遅刻しない時間に設定する手もあります。また、デイリースクラム自体がそもそも形骸化していて、本当に意味がない可能性もあるので、デイリースクラム自体を観察して、機能しているのかどうかを確認する必要もあります。それでもだめであれば、その人はすくなくとも、そのチームで働くのは難しいという判断をするかもしれません。その意思決定自体はスクラムマスターではなくて、チームのメンバーが下します。

スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？

デイリースクラムは開発チームのためのイベントなので、別にそれでも構いません。むしろ多数のステークホルダーが参加して、好き勝手に発言するほうが害になります。

分散チーム間のスタンドアップをどのように進めるか？

最近はビデオ通話のツールもだいぶ良くなっているので、そういうのを活用しましょう。

スクラムチーム用の物理カンバンボードをいま書いてください

たとえば、こんなかんじです。

ふりかえりについて

だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？

スクラムチーム全体、つまりプロダクトオーナーと開発チームとスクラムマスターが参加します。あとは、必要だと思うステークホルダーも呼んで構いません。スプリント単位ではスクラムチームでやっておいて、4半期ごととかリリースごとにもうちょっと大きく全体ふりかえりする、というのをよくやっています。

チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？

逆に確認しなかったらまずいです。問題がないかどうか、問題にはどんなものがあるかを識別した上で、アクションプランを考えていく必要があります。現状の把握もなく、思いつきでいろいろやってもムダな労力になってしまいます。確認の方法は、チームの関係性にもよります。成熟したチームであればディスカッションでも大丈夫でしょうし、そうでないチームであれば、なんらかのフォーマットを使うことになるかもしれません。

過去に使ったふりかえりのフォーマットはどんなものか？

タイムライン、Story of Story、WWW、Happiness Radar、Good/Bad、Fun/Done/Learn、KPT、闇鍋などなど。

どうやってマンネリを防いでいるか？

マンネリはやり方が同じだから起きるのではなく、同じ問題が何回も顕在化するにも関わらず解決しないことに起因することが多いです。したがって、まずは少量でもよいので、チームで決めたアクションアイテムを確実に実行できるようにするところがスタートになります。やり方のマンネリという点では、同じやり方を続けると視点が偏るので、複数のやり方を使い分けるのがよさそうです。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？

最新のスクラムガイドだと、スプリントレトロスペクティブで選択したアクションアイテムを、最低1つは次のスプリントバックログに入れろと言っています。複数のリストを持っていると、それぞれの順番をどう捉えるかがわからなくなるので、アクションアイテム自体をスプリントバックログやプロダクトバックログに入れていき、全体の中で管理するのがわかりやすいでしょう。なお、いつも行動できない理由として、そもそもそのアクションが具体的でない、何ができたら終わりなのかはっきりしていない、自分たちで扱えるサイズより大きいといったことも考えられます。具体的で測定可能にしないと放置されるので、プロダクトバックログアイテムやスプリントバックログのタスクと同様に具体的にするようにアドバイスするのも良さそうです。