スクラムマスターを雇うときに聞いてみると良い 38 個の質問をやってみた

「スクラムマスターを雇う時に聞いてみるとよい38個の質問」というものがあり、昔から知っていたのだが、改めて自分で考える機会ということで書いてみた。

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

※ あくまで自分の経験に基づく考えなので、使えるかどうか（≒採用に値するかどうか？）はわかりかねます。

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

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

ツールやプロセスが大事ではないとは言っていない。あくまで比較の話。
ツールやプロセスは、チームが価値を生むまでの一連の作業に、より集中できる為に必要とされる場合がある。
「いつまでにスプリントが終わるんだっけ？」とか、「どうやってスプリントの進捗を見えるようにすればいいんだっけ？」といったトコロにいちいちクリエイティビティを発揮しなくていい。
(逆に、ツール・プロセス標準化、みたいな、ツール・プロセスありきは NG だと思う。誰も使わなくなる。)

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

どうやるか、どこまでやるか/出来たか、といった議論ではなく、デリバリーしたものが期待通り使われているか、デリバリーしたことからの気付きは何か、を考えるようになっている
そのために、組織・チームとして、どうすれば(改善すれば)いいのかを考え続けられている

の、２点は、上手く回っている状況だと思う。

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

チームが直面している問題や、リスクに応じて取るメトリクスは変えるので、必ずこれ！というのはない。
メトリクスをとると、観察者効果でよくない影響を与える可能性があるので注意が必要と感じている。
ストーリーのサイクルタイムは、チームの効率的な仕事ができているか、どこを改善すれば一番チームの作業効率に効くのか、を考える上で重要な指標になる。
ベロシティは、サイクルタイムが改善した結果、わかりやすく表れる指標なので、チームのモチベーションや気づきの意味でも取ることが多い。
あとはビジネス的な KPI とかも見ることで、チームが注力すべきことに集中しやすくなる。（売上、VOC、ストアレート etc）

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

コミットしたタイムボックスの長さが、既に計画駆動できないドメインに置かれているため、割り込みが多い
- 割り込みが多いのに計画でコミットしてしまうのは問題ではないですか？と聞く。
- (ある程度の)割り込みを前提とするか、タイムボックスを短くする。
- そもそも PO が直近必要なものを予測/計画できていない場合もあり、PO のお仕事の仕方を一緒に考えることもある。
技術的に、”やってみないと分からない” ものが多いアイテムを扱っている
- 技術的 Spike と分割することは可能か？を考えてみる。
- 可能であれば、Sprint を半分の長さにする。（Spike → Ready になった Story としても CT を悪化させないため)
チームがコミットメントしないといけないという意識がそもそもない
- ふりかえりなどで、計画でコミットしたことが終わらなかったことは、私たち/ステークホルダーから見て問題だと思いますか？という問いを投げる。
コミット下はいいものの、内容を詳細に見積っておらず、楽観的に開始したまま達成できず、振り返りもできていない
終わるかどうかをトラッキングしていない
- デイリースクラムで、終わるかどうかをどう考えているかを観察する。
- どうすれば今日この時点で Sprint が終わりそうだと判断できそうですか？と聞いてみる。
メンバーが別の作業と兼務していて、コミットしても状況に振り回されてしまう
- 本人ではなく、アサインしている？上司？などに、意図を聞き、ムダやコミットできない問題の温床であることを伝える。

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

当然参加してよい。プロダクトの要求が、何を狙って決定されたものであるのかを理解することは、ストーリーのカードに詳細な Acceptance criteria を書き込むよりはるかに効率が良い。
また、実現方法においては、チームは Professional であるので、より良い解決法が提案できる場合は、アドバイスできるとよい。
ただし、チームや PO らは考え方や価値観が異なる場合が多いので、主観で話してしまって対立を生むようであれば、事実ベースで話すように心がけさせる必要がある。（スクラムの話に拠らないですね、これは）

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

PO が注力すべきでないことに労力を割いているようであれば、それらを分離し、PO 以外の人間でできるように整理する。
学習やディスカバリーに注力できるように、実現手法においてはチームがある程度の粒度の粗さで検討開始できるように、チームのドメインに対する理解や技術レベルを向上させることも長期的には必要になる。

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

難しい質問。いま接しているステークホルダーが”しかるべき”ステークホルダーであるかどうかを検証する必要がある。
この人に聞いても裏の決定者がいるな、とか、デリバリーしたプロダクトに対する要求や不満を発見するのに効率が悪いな、と感じれば、しかるべき人探しをするのが良いと思う。
- エンドユーザー向けサービスなら、エンドユーザーの振る舞いやインタビューから学ぶこと！
- 社内にエンドユーザーはいないし、PO もその代わりにはなれない。
- 幸せの青い鳥探しにならないように。

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

「アジャイルを目的にする」と、迷走するし、上手くいかない。目的も共有できないのでうまくいかない。
自分たちが置かれている環境と現状のやり方で、どういった課題があって、アジャイルのどんな考え方であれば、よりよくやれるのか、を説明する。始めに課題ありき。
コーチの初期段階は、上記のように進めて、具体的にやっていく中で、こういった事象は、アジャイルだと当たり前のように捌けてるけど、計画駆動だったら無駄に苦労してたね、っていう点を一緒に気付けてあげられれば、彼らの気付きになる。あとは勝手に広めてくれる。

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

必要がないなら、しない。
どういう状況に対して、どういう考え方で臨むのか程度は伝えておく。
いわゆるスクラムってやつだとイチイチ言わなくてもいいと思う。
上級管理職が「それスクラムってやつか」と ”自分で” 気付けたら、その時点で敵にならない場合が多い。
「なかまになりたそうに、こちらをみている！」な上級管理職であれば、積極的に説明して巻き込むこともある。

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

上手くやるためにやっていることを共有する
そのうえで、スクラムをやる上で、何に懸念や不安があるのかを一緒に明らかにする。
トム・デマルコもいう通り、「怒りとは恐怖」なので、彼らの恐怖している内容を共有することが大事。
分かりやすい拒絶に対して、不安を取り除くための活動をすること自体は、他のチームメンバーにとっても、不安を共有し、取り除くことの重要性が伝わるので、心理的安全性の向上に寄与できる場合が多い。
逆に、簡単にその「人」を除外すると、他から見ているメンバーは…後はお察し。

プロダクトバックログのグルーミングと見積りについて

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

流れとしてはよいが、以下の点が気になる。

ステークホルダーの要求を分析する段階が無いと、PO が ROI を最大化するための情報が曖昧になる恐れがある。
チームのドメインへの理解度か高ければ、要求をチームが理解して PBI にする、といった形も取れる。チームが受け取るのに Ready (Sprint Ready じゃなくて) であるかどうかは、チームの力量によるので一概には言えないが。
また、特にプロダクトの内部改善のための PBI はチームが作る場合もあるので、↑ の流れ以外にはない、というのは誤解を生みやすいので注意が必要。

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

プロダクトに関する VOC の KPI を知ることで、自分たちが優先順位付けする際の議論の情報ベースになる。
また、ビジネス目標や競合分析情報を知ることで、チームにいい効果が得られる場合もある。

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

誰が書いてもよいが、コツがいるので、内容の確認のムダが多いようであれば、教育を要する。

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

いわゆる INVEST と言われるものになる。
- Independent: 他のストーリーと独立している
  - これがないと、優先順位等を考える際にとても無駄が増えるので大事。
- Negotiable: 交渉可能である
  - どう実現するのか、どこまでやるのかに幅を持っておくことで、PO とチームがお互い効率よく進めるためのやり方を導く余地ができる。
- Valuable: そのストーリーが単体で価値があること
  - ”＊＊基本設計書を書く” みたいなストーリーの書き方をしても変化に対応できないし何も学習できないﾉﾃﾞ、やらないようにしましょう。
- Estimable: 見積もり可能である
  - 見積れないようなものはエピックと名前を付けて、細分化させた方が良い。
- Sized small: 十分小さい
  - スプリントの期間内で終わるサイズでないと、レビューできないし、変化にも追従できなくなってしまう。
- Testable: テスト可能である
  - テスト可能でない時点で、完了したかどうか判断できないので揉める。
  - テスト可能でない時点で、将来的にデグレードしているかを判断できないし、自動化もできない。

これらに加えて、よく、「状態で書くようにしましょう」と言うことが多い。

実現手段はチーム次第。「～～を実施する」といった書き方だと、期待値を見たいしていなくても良いような書き方になってしまうし、チームも意識できない。

どういった背景で、何を実現したいのか(どういう状態になっていてほしいのか)をチームに伝え、実現手法と効率よくやる方法はチームが考える、でよいし、そこまで PO が踏み込むのはチームに対してリスペクトが無いし、チームとしても自律して考えることを放棄してしまっていてよくないと思う。

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

チームによる。
スクラムを円滑に運営する上で増やすこともあるし、チームの Capability が上がって減らすこともある。

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

時間はとても分かりやすい概念で、容易に誤用されやすいため。
- 「なんで3日の仕事が3日で終わらないんだっけ？」→「それは理想日で、現状のチームの置かれている状況とタスク消化スタイルとしては・・・・・」みたいな不毛なやり取りをするくらいなら顧客を見てコードを書いて障害を取り除く時間に充てたい。
そもそも相対見積りするのに単位は必要ないため
日付としての定量評価に使わない単位なら、当たり前だけど付ける理由すらない。

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

バックログに突っ込んで、必要な時に必要なだけ考えましょう？とするだけ。
先々のことまで気を回したい人はいるしそれは性格だからいいけど、「今やるべきこと」に注力して、「今見えていないこと」に早めに気付ける方がリスクが少ない。
今時点で先々まで見通して他に抜け漏れがない！という自信があるなら、計画駆動のウォーターフォールでどうぞ。

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

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

PO と協力して、バックログアイテムを優先度の高い順に並べる
ストーリーに背景や解決したい課題を明記して、チームがそのストーリーの価値を理解できるように助ける
チームが気付けない・伝わらないことを察知し、改善に向けた下ごしらえを考える。または、その場で簡単な問いかけを行い、気付きを深める手助けをする(初期に2，3回やると、自分たちで気付きやすくなる）
価値の低いストーリーの話題になるようであれば、時間の無駄なので、その会話を今(スプリントのスコープを明確化するための会議で)やる理由があるのか、確認する。

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

ビジネス KPI や VOC のコメント、ユーザーの利用ログを用いて、期待した振る舞いに改善されているかを測定する。
かけた工数や、コードの行数はどうでもいい。

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

PO とストーリーを優先順位順に並べ、チームの計画に対して、価値を最大化できるように取り組めているか？を問いかける。

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

チームやプロダクトの状況によるとしか…
経験的に 10％は最低でも必要だと思うし、だいたい毎日1hくらいはみんなやってるんじゃないかなあ。

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

自己組織化の阻害や、PO 自身がボトルネックになっていることを理解させる。
あなたがいなくてもチームが自分で同じ選択をできるようになったら、あなた(PO)はもっとプロダクトの価値発見に時間を割けるようになるし、そうすべきだ、という話をする。
一方で、チームが良い判断をできるようには、どうしたら育つだろうか、という議論を一緒に考える、になる場合が多い。

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

ムダを生んでいること、チームの生産性を阻害し、残業を生むということを理解させる。
サイクルタイムでも測定しておくとわかりやすい。
一方で、なぜつまみ食いしたくなった？というのは尋ねておく。
手が空いたので、、とかであれば、大事な取り組みはつまみ食いではなく、仕掛中のタスクを終わらせるスキルを身に付けたり、調査を進めてあげることだったりする。できることをつまみ食いすることより大事。

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

終わらせることをコミットできないし、割り込むのであれば、チームのスプリントの達成に向けたコミットメントに対する挑戦行為であることは理解してもらう。
一方で、なぜ1日遅れてしまうのかを共に考える。
- ひょっとしたら、スプリント期間が長すぎるのかもしれない
- ひょっとしたら、スプリント開始タイミングが悪いのかもしれない
- 単純に PO のポカであれば、どうやればうまくできるかを考えた方が良いかもしれない

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

なぜ無駄だと考えるのかを質問する。
スプリントプランニングの目的が伝わっているか、確認する
無駄だと感じられてしまうような、チームのスクラム状況の問題を見つけ、ともに改善する

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

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

推奨する。経験度合いは関係ない。
スタンドアップ形式による集中と、長引かせないための仕組みはどのチームでも機能しやすい。
タイムボックスを守れないとしたら、そのこと自体についても振り返りで考えられるように仕向ける

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

期待しない。アンドンでも Slack でも StackOverflow でも Qiita の謎ポエムでもいいから最速で解決されることを望む。

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

デイリースクラムの目的を理解させる。
自己組織化し、お互いのやっていることを共有し、お互いが今日何をやることがベストなのかを考える場であることを理解させる。

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

チームへの悪影響が出ているか、事実として把握する
属人化したタスクの持ち主であったりする場合に見かけることがある気がする。
- その場合は、属人化しないようなタスクの取り方になっていないことがリスクでないか、考え、属人化せずチームとして機能するようにタスクの選び方を考える場を設ける。
- そもそもチームのメンバーである必要が無い場合、外すこともありうる。
チームになっていないようであれば、チーム構成として必要かを見直す。