回答: スクラムマスターを雇う時に聞いてみるとよい38個の質問
ryuzeeの記事が目に入ったので、自分なりの回答を考えてみる。多分、他のスクラムマスターとは異なる回答になってそう。各位の回答も見たいので、是非書いてみてほしい。
では、始めよう。
スクラムマスターの役割について
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
私もそう思うので、プロセスを守らせる方針は取らないし、プロセスを守らせるスクラムマスターは信用していない。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
事業としてうまく行っていること、そしてみんなが自由に働けていること。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
経営上のメトリクス。営利組織であれば売上や利益、C向けスタートアップであればユーザ数とかになるんですかね。
書籍によると、
- デプロイの頻度
- リードタイム
- 平均復旧時間
が事業に関係があるという研究結果があるらしいので、その3点に着目してみるってのはやってみたい。ちなみに、今のチームでは「悪くない」という印象をもっている。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
コミットメントがチャレンジングすぎるんだと思うし、コミットメントがチャレンジングすぎると思うって言う。
逆に、コミットメントを毎回達成していたり、ベロシティが安定していたりするなら、チャレンジから逃げている予兆と言える。不安定なのは悪いことではない。
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
参加しようぜ！って思うし、参加しようぜ！って言う。
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
DevOpsを推進する。デリバリーに対するコストを下げることで優先度の判断リスクが管理しやすくなり、心配事が軽減され、仕事が減る。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
一番のステークホルダー（たとえば社長とか、大企業なら事業部長的な人）に、ステークホルダーにアクセスできないと仕事できないからね！そんときはよろしく！って言っておく。そこで協力的じゃない人はあんまり見たことないよ！みんな頑張ってるしね！
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
自分たちが成果を出していく。ステークホルダーに対しては、リスクある判断に対するアプローチとして示していく。
上級管理職にどのようにスクラムを紹介するか
うーん、紹介必要？知りたいって言われたら、ryuzeeのブログから適当なの引っ張るかなぁ。
あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
どういう心配があるのかを聞いてみる。そこにうまくやるヒントがあるはず。後半の質問には回答が難しい。激しく抵抗された経験（もしくは記憶）がない。
プロダクトバックログのグルーミングと見積りについて
プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
まあ、いいんじゃない？でも、優先度はつけておきたいね。ふんわりと。見積もりするのもタダじゃない。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
「チームに最新情報やマーケット状況を伝えてほしい」って言う。あ、でも、伝えられる情報によってチームはどう変化するのか？ってのは確認しておきたいところ。つまり、チームが知りたがってる理由がほしい。それがないと一般論の講義になってしまう。
誰がユーザーストーリーを書くとよいか？
誰でもいいんじゃない？結果、できたものがチームとして自然だって思えたら。チーム全員の合意である必要はない。
よいユーザーストーリーとはどんなものか？どんな構造か？
具体的。
「Readyの定義」には何が含まれているべきか？
ゴール。それ以外は些細な問題。
ユーザーストーリーを時間で見積もらないのはなぜか？
実装する人によって時間は違うから、ってのが教科書的な回答だっけ。
でも最近は、時間でもぜんぜん良いと思ってる。見積もりはポイント（相対ポイントや時間でもいい）を出すことよりも、実現に対するアイデアを集めるのが大事なので。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
優先度を整理しようぜ！ってする。でも、全体を眺める時間も取りたいかなぁ。もしかして、100個くらいを一気に解決する素晴らしいアイデアがでるかもしれない。
スプリントプランニングについて
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
優先度の感覚が共有されていることを確認したい。まあつまり、それぞれのアイテムの目的の確認かなぁ。
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
事業としてのKPIにつながるかってのがあると強い。あとは勘。受け入れがたいものってのは想像難しいけど、たとえば「価値=工数」とか。あとは、メンバーの教育上の観点は主の判断材料にはしないようにしてる。経験値はあくまでも副作用。
チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
Disagree and Commit かなぁ。
議論はするし、意見は出すよ！スクラムマスターもチームメンバーだしね！まあでも、チームメンバー同士の議論が活発になるところからですかね。活発すぎて先に進まない（自転車置き場とか）なら、リスク判断の議論を促すし。チームの状態によるかもしれない。
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
必要なだけ。っていうと面白くないか。
不具合対応は「チームが不具合対応に追われている」って感覚になる手前で抑えておきたい。あふれると、不具合が雪崩る。不具合が起こりにくくするリファクタリングもできなくなる。そうなる前に手は打ちたい。
新技術やアイデアの調査は、時間とれるならやろう！素晴らしいね！
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
あとで考えようぜ！って言う。何を実現しようとしているかが大事なので、そこの確認をしていこう。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
必要ならいいんじゃない？優先度の感覚にギャップがあるのかもしれないので、合わせていこう。
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
「ユーザーストーリーの確定」ってなんだろ。ユーザーストーリーを検討するところを一緒にやればいいんじゃないかな。だって、優先すべき重要なストーリーに見えるから、やりたいんでしょ？
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
どういう心配があるのかを聞いてみる。そこにうまくやるヒントがあるはず。（2回目の回答）
スタンドアップやデイリースクラムについて
チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
わりとおすすめするかも。どのようにやるかを工夫しよう。
なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
随時解決しようぜ！っていう雰囲気を作りたい。が、まあ、お互いにタイミングはあるので、スタンドアップで話題がでると比較的健全だと思う。1週間スタックしまうってのは健全なチームでも油断すると起こりえるし、それは避けたい。
スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
いいんじゃない？あ、でも、一人30秒ね。
スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
どういう心配があるのかを聞いてみる。そこにうまくやるヒントがあるはず。（3回目の回答）
スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
ギャップが出なければ許容。ギャップが出てるならなんか考えたいね。
分散チーム間のスタンドアップをどのように進めるか？
Slackで「やること」チャンネルはわりとおすすめ。特別なツールを入れる必要はない。
スクラムチーム用の物理カンバンボードをいま書いてください
ふつうのカンバンの話？
ふりかえりについて
だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
必要だと思うなら誰でも。もちろんプロダクトオーナーも参加していい。
実務的にはふりかえりのタームによるかな。毎週のものはチームだけでいい。数ヶ月単位ならステークホルダーも参加してほしい。長ければ長いほど、広く参加するイメージ。
チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
確認するでしょ。それぞれの認識のギャップを確認するかなぁ。
過去に使ったふりかえりのフォーマットはどんなものか？
短期ならKP。Tはあんまり出さない。長期ならタイムラインを作りがち。
どうやってマンネリを防いでいるか？
マンネリになってるくらいならやめようぜ。まあでも、メンバー変える、とかかなぁ。チーム外の関係者を呼んでみたりとか。わからんけど。
チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
T，難しいよね。普通にバックログアイテムにしそう。仕事だしな。
どうやってアクションアイテムのフォローアップを薦めるか？
バックログアイテムにして優先度を設定しよう！
まとめ
はうー、長かった。ここまでたどり着いた勇者は素晴らしい。一般的回答とは違うところはいろいろあるかもしれないので、皆さんの回答を見てみたい。
ということで、今から読む:
こんなスタイルに興味がある人は、コンタクトください。初回相談無料！
