以前、スクラムマスターを雇う時に聞いてみるとよい38個の質問 を読んで面白そうだなと思っていたら、実際にこれに回答をする記事をちら見したので、読みたい衝動を抑えてまず自分で答えてみることにしました。回答したら @Ryuzee さんが点数を付けてくれると聞いて（言ってない）。
回答するにあたって、
- 「コンテキストに依る」は全てにおいてそうなので禁止
- 問題に対するつっこみはなし
を前提に真摯な態度で回答しました。
また、自分はここしばらくキレイなスクラム／スクラムマスターをやっていないので、基本的には「自分だったらどうする？」をベースに回答しているのと、スクラム／スクラムマスター前提の質問に対しては「転生したらスクラムマスターだった件」という気持ちで答えております。
-
スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた | Ryuzee.com
スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみました
www.ryuzee.com
答えてみて
スクラムの復習にちょうどいいかもー！！
復習じゃなくても「自分（たち）だったらどうする？」を考えながら回答していくことで、頭の整理ができると思います。採用面接の場でも、こういうケースを問う質問は相手の仕事の仕方が垣間見えるので有効かもしれません。
答えながら感じたことは、自分はスクラムマスターとしては失格なのかもしれないなー。まあ、いいか。
スクラムマスターの役割について
1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
「よりも」って言ってるだけで、二元論じゃないよね。プロダクトづくりを円滑に進めるためにプロセスやツールをうまく活用していくことが必要なときもあるので、反対のことをしているとは思わないかなー。
（1問目から言ってしまうと）でも「プロセスを守らせる」とか言ってるスクラムマスターはあんまり好きじゃないかも。自分の場合は、「今の状況からして何をするのがよさそうだろう」を大事にするかな。チームの立ち上げてからしばらく（タックマンモデルで言う形成期〜混沌期くらい）はまずは型に合わせた方がうまくいくことが多いけど、チームが自走しはじめたなら自分たちでよりよいやり方を選んでいけばいいだけだし。
もし専任スクラムマスターをやっていたとすると、立ち上げ当初が一番忙しくてだんだん用無しになっていくのが理想だよねー！そしたらコード書けるし！！
2. 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
関わっているプロダクトやビジネスがうまくいっていること！
そこからブレイクダウンしていった時に、
- バリューストリームが端から端まで流れるまでのリードタイム
- SLAがどれくらい守れているか
- ハッピーメトリクス
などを計測していったりはするけれど、まずはビジネスメトリクスと同じものを見るのが自然だと思います。
基本的にチームの成果なので「自分の働きが成功している兆候」って難しいけれど、自分が専任スクラムマスターだとしたら…を無理やり考えると、
- やることいっぱい⇒やることを探しつつ見つけたらやる⇒やることがない、に近づいていること
- チームメンバーが評価されていること
- 各関係者からの自身の評価がそこそこよいこと
- 自分自身が楽しめていること
あたりかな。
3. 追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
2で回答した通りで、少なくともプロダクトやビジネスが追っているメトリクスは追跡しないといけないかな。それが一番外側のIN/OUTだし。
「キレイなスクラムがまわっている」「チームだけ仲がいい」「デプロイ回数だけ増えている」のような部分最適で終わってしまわないように、常に追跡しておくのがよさそう。
4. あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
- 差し込みが多くて集中できていない
- メンバー入れ替えが多い、兼務者が多いなどチームが固定化されていない
- バックログアイテムがReadyじゃない
- 必要な役割とのコミュニケーションコストが高い
- チームの技術力が低い
いずれにしても短期的な問題解決よりも自分たちで問題を見つけて自浄作用が働くようになることが最も重要なので、直接指摘はしないかな。代わりにチームで考えてチームとしての答えが出せるような場づくりを全力でサポートする。
5. 製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
え、ダメなの？よいでしょ。
むしろ参加しなきゃダメだと思ってます。「よいプロダクトつくってるよ！お客さんやユーザーの顔見たことないけど」ってただのオ○ニーだと思うので、最初から参加するのが当たり前って状況にしちゃうかな。
そうしないとただの受発注の関係になっていってしまいがちだし、なによりもつくる人は考えることもできるのだ！
6. 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
チームがうまくまわりだすと、ボトルネックが移動してプロダクトバックログがジリ貧になる問題は何度も体験してきたなー。
プロダクトオーナーが集中すべきこと／プロダクトオーナーに頑張ってほしいことに集中してもらえるように、それ以外のことはチームでサポートできるように持っていくことが多いかな。ほとんどのことはプロダクトオーナーじゃなくてもできることなので、走り回れる人が走り回ればいいのです。
7. どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
必要なステークホルダーには最初から話しておく。
経験上アジャイルやスクラムの話を面と向かってする必要があったことはなくて、「よいプロダクトをつくりたいんだ！だからこういう協力して下さい」って話したときに反対する人には会ったことがない（いたとしたら会社にいちゃダメ）。
あと彼らは仲間に入れなくて寂しがってることが多いので、定期的に「こういうところがうまくいかないんですよねー」「あ、前に教えて下さった通り○○をやってみたうまくいきましたよー」みたいな相談や雑談をムダにしてあげると強力な仲間になってくれることが多いです。
8. どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
何もできていない内から広げようとしてもなかなかうまくいかないので、パイロットチーム1〜2チームでうまくいかせることに集中する。うまくいき始めると、不思議なもので「砂山の法則」でまわりのチームによい影響が流れ出すのでそのあたりではじめてスケールすることを考えてもいいのかも。
近くのチームで結果が出始めるとステークホルダーからの信頼も得やすいし、まわりのチームも主体的に取り組んでくれやすいので、ステークホルダーごとチームごと研修を受けてもらうのがよさそう。
9. 上級管理職にどのようにスクラムを紹介するか
（必要なければ）しなーい！！
「どうしても教えてください」って言われたら考えるけど、そんなに興味があるなら研修に行ってもらうことをおすすめするかな。偉くなっても勉強したまえ。
10. あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
なぜ抵抗するのか話を聴いてみる。それしかない！
自分自身が「手法やフレームワークを導入しよう」という立ち位置でアプローチすることはなくて、「いまよりもっとうまくなろう」というアプローチで進めるので少なくとも同僚から抵抗を受けた経験はないかな。昔アジャイル開発で失敗した経験を持つ上司（外野）から抵抗を受けた経験はあるが、言葉を一切使わずに、前述の相談・雑談をムダにすることを続けたら最高の理解者にってくれた。そしておまけに気づいたらアジャイル嫌いも克服してくれていた。
重要なことは、
- 「よくしたい」「うまくなりたい」という思いは一致している
- 相手の感情に寄り添う
ということを念頭にコミュニケーションしていくことだと思う。人間だもの。
プロダクトバックログのグルーミングと見積りについて
11. プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
別にいいんじゃない？
でもステークホルダーの要求を本当に優先すべきなのかはわからないので、そこの優先順位づけができているかは気にするかな。もし御用聞きをしてるだけならそのプロダクトオーナーは不要かと。
あとは可能であれば、その場にチームメンバーも同席するようにしたいかも。「見積もりする必要ない」という見積もりが一番ステキだし、それが判断できるのはチームだけ。
12. チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
新しく準備してもらう必要はなくて、プロダクトオーナーがまわりのステークホルダーに伝えたり、自身で追っかけていたり、考える時に使っている情報や資料を見せてー！って感じかな。
それが残念だと、「そもそも自分たちは何のために仕事をしているんだろう」って気になるので危機感を感じることができるよね。
13. 誰がユーザーストーリーを書くとよいか？
みんな！
プロダクトバックログの優先順位を決められるのはプロダクトオーナーだけなので、プロダクトオーナーに全容を把握してリードして欲しい感はあるけど、書くのはチーム関係者であれば誰でも良いと思います。
14. よいユーザーストーリーとはどんなものか？どんな構造か？
- I ndependent 独立している
- N egotiable 交渉可能である
- V aluable 価値がある
- E stimable 見積もり可能である
- S ized Right (Small) 適切な大きさである（小さい）
- T estable テスト可能である
INVEST（上記の頭文字）であることが教科書的なのかな。
フォーマットはなんでもいいけれど、これまでの経験上作り手目線だと、
- どうなったらできた！って言ってよさそうか
- 誰のためで、どんな価値が、どれくらいありそうか
- （プロダクトオーナーが）どれくらい想いを持っているか
- 作りながら考えてほしいことや決まっていないことなどが明記されている
みたいなことがわかるとすごく嬉しい！
15. 「Readyの定義」には何が含まれているべきか？
とりあえず作り始めることができそうであればいいんじゃないかな。
作る前からわかっていることなんてそんなにないので、Readyにするためにがんばろうとしすぎて時間をかけるよりは、まず作り始めることができるラインを目指して、その分作りながらより良い方向に変えていける余地があった方がステキかな。
そういう意味で見積もりができているってことは、チームがそれなりにイメージできているってことなので、それは含まれていてほしいかも。
16. ユーザーストーリーを時間で見積もらないのはなぜか？
相対見積もりの話かな。
かかる時間は人によって違うので、絶対値である時間で見積もりをするとズレていってしまう。一方でポイント見積もりやSMLのようなサイズ感であれば全員で共通に扱える。あとは時間見積もりにすることでパーキンソンの法則が働きやすくなってしまうってのもあるある。
ただこれも「未成熟なチームはできれば避けた方がいいよ」って話であって、時間見積もりの弊害を理解した上で問題なく扱えるチームであれば時間見積もりでよいと思う。
17. プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
バックログに何枚チケットがあろうと、スプリントのタイムボックスに入るチケットの数が変わるわけではなので、特に何も変わらない。
ただ一方で、時間が経つことでプロダクを取り巻く状況が変わって優先順位を入れ替えたり新たにやりたいことが出てくるのが常なので、「チケット作り過ぎのムダ」みたいなものは生まれやすい。
バックログの下の方のチケットって何ヶ月も触られずにゴミになって、あるタイミングでガベージコレクションされることが多いので、それくらいのつもりでチケットを扱った方がよさそう。
スプリントプランニングについて
18. チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
プロダクトバックログが（少なくとも）スプリントプランニングの段階で常に新鮮であるように、バックログリファインメントをしたり、事前にバックログを確認して気になることはプロダクトオーナーに確認しておいたりするかな。
また、プロダクトオーナーにスプリントプランニングに必ず同席してもらうようにするかな。プランニングの中で出てくるチームの質問に答えてもらうこともそうだし、プランニングする中で実装目線で読み解いていくと「実は今はやらない方がいい」とか「これと合わせるとすごく簡単に終わるかも」とか「コード書かなくても実現できそうだ」とかそういう優先順位が変わりうる情報が出てきたりするんだよね。
19. ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
ビジネスメトリクスに沿っていること。沿っていない場合でも、他のストーリーと重要度を比較できる理由がある程度納得できるかどうか。
「お客さんが欲しいと言っている」
「偉い人に言われたから」
「（特定の）ユーザーからのフィードバックにあった」
「この機能があれば売れる」
みたいなものは受け入れがたいというか、メトリクスになっていないのでもう一歩踏み込んで聞いちゃうかな。
20. チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
プロダクトバックログが適切な優先順位で並んでいるという前提で。
タイムボックスの大きさは決まっているので、基本的にはそこに入る限りはバックログの上からスプリントバックログアイテムにしていく。このアイテムを入れるとあふれるな、って時はそのアイテムは含めない or 優先順位次点以降で入りそうなアイテムをプロダクトオーナーに選んでもらう。
できる限り詰め込まないと損するって考え方は危険なので、
「早く終わったら次のアイテムを着手しておくよー」
「もしかしたらリダクタリングしたり勉強してるかもだけど」
くらいの空気でプランニングできるといいなー。
21. どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
チームの置かれている状況によって変化するものだけれど、
- 0%でないこと
- 50%以上になっていないこと
を気にするかな。
0の時はおそらくチームがパツパツでよくないことが起こりそう／起きていると思うし、割合が高すぎる時はスプリントプランニングが甘かったりプロダクトバックログがジリ貧などの問題が起きている可能性が高い。
22. チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
ああ、いるよねｗ
話しやすい人とかお願いしやすい人にばかり直接お願いしちゃう人。スプリント期間中に「ちょっとお願い」ばっかりする人。
プロダクトオーナーの「どうしたらいいかな？」「ちょっとお願い」を気軽にできる仕組みがなくて特定の個人にばかりお願いしてしまうことが真の問題だと思うので、そこを一緒に作っていくかな。
その際に、まずは状況を正確に把握するために自分が窓口となって困ったら言ってもらうとかはよくやります。タイムボックスや個人アサインしない話や優先順位とかいろいろ正論を言いたくなる気持ちはわかるけれど、ビジネスシーンで「とはいえ」をやりたくなってしまう気持ちも理解できるので、まずは気軽に言ってもらえる仕組みや関係性をつくった上で、1つずつ整理しながらお互いの進め方を理解すり合わせていくことが多いです。
23. チームメンバーによるタスクのつまみ食いをどのように扱うか？
一概に問題とは言えないけど、つまみ食いするくらいなら堂々と食べてほしいかな！
余裕ができて先回りしようとしてくれてるならすごく嬉しいけど、次のに着手してくれればいいよね。もしくはまだ終わってない人を助けてくれた方がチームにとっては嬉しいのかも。
いずれにしてもつまみ食いをする理由を聞いた上で、そのままでいいのか、なにか対処したほうがいいのかを考える。
24. ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
「2日目には確定する」がそもそも予測に過ぎないので、次のスプリントに回すことをおすすめして、それで良さそうならそうしてもらう。もしどうしても入れたいということであれば、スプリントプランニングに余裕をもたせて計画をすることと、不確定な状態なので終わらないかもしれないことを同意してもらった上でいったん受け入れる。
あとはそこまでしたいストーリー（＝重要だと思っている）なので、余裕をもたせてもらった分、ストーリーを確定する作業をチームが手伝う、あるいは相談にのることをそもそも計画に入れてしまうかも。
25. スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
1on1で話す場を作って、
- 今のスプリントプランニングをどう思う？
- なぜムダだと思うの？
- どうしたらいいと思う？
を聴きながらどうすればいいかを一緒に考えるかなー。
スタンドアップやデイリースクラムについて
26. チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
わりと薦めるかも！
別の手段で目的を達成できれば必要ないけど、定期的かつ短時間で顔を合わせる場があることはそこそこ強力だと思ってます。
もちろん制約が強い（サイズが大きい、経験度が低いなど）場合は、スタンドアップの目的を絞ったり期待値はぐっと下げます。
27. なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
全然期待していません。相談したいなって思ったタイミングで相談して、適切な対処ができるチームのほうがステキだよね。
待ってでも言おうとしてくれている分「話す場がなくて言えない」状態よりはマシだけど、スタンドアップやふりかえり待ちになってしまっていると気づいたこと自体が改善チャーーーンスですね。
28. スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
スタンドアップの目的をみんなで確認するかな。報告ってそれ自体はそれほど重要じゃないことが多い（カンバンとか見ればいいよね）ので、目的と手段が合っているかを話し合う場をつくるかも。
なかなか報告癖が抜けない場合は、報告自体を一切やらないスタンドアップをしばらくやってみる。それでみんな困らなければそれでいいよねー！
29. スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
相手の話（理由）を聴く、目的や意図を理解してもらう。
その上で気持ちが変わらないなら、
「どうしたら参加してくれるか」
「どうしても参加してくれないとしたら、スタンドアップの目的を別の方法でどうやって拾えばいいか」
を一緒に考えてもらうかなー。
で、それをチームに提案しましょうという流れに持っていく。
あとはチームにいたくないということであれば、然るべきポジション（マネージャーなど）に相談して対応を任せたほうがよさそう。
30. スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
いなくても大丈夫！
スクラムチームのためのスタンドアップなので、参加したいなら参加してもらっていいけれど邪魔をしたり少しでもチームが余計な気をまわしてしまうなら抜けてもらう（ということを説明して理解してもらう）かなー
31. 分散チーム間のスタンドアップをどのように進めるか？
スタンドアップに限った話ではないですが、同じ拠点に複数人いる場合でもリモートメンバーがいる場合は全員オンラインツールにつないで行います。なぜなら参加者全員のコミュニケーション機会が平等であることがとでも重要だからです。
複数人いる○○拠点のメンバーだけで話が盛り上がって、リモートメンバーが置いてけぼりになるような自体を極力避けたいですよねー！
32. スクラムチーム用の物理カンバンボードをいま書いてください
こんな感じかなー
チームの手で使いやすいように少しずつカスタマイズしていくのが好きなので、最初は一番オーソドックスなやつからはじめることが多いかな。
ふりかえりについて
33. だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
なるべくチームメンバー全員（もちろんプロダクトオーナーも含む）でやりたいなー！
別の目的があって違うサイクルで個別にチームだけでふりかえりをするとかは必要あればやるけれど、全体のふりかえりは全員で進めたいかな。
34. チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
ふりかえりに限らず常に気にするけれど、特にふりかえりはチームの状態が表れやすいと思います。だから当然確認します。
ふりかえりの内容自体から読み取れることも多いし、雑談や対話の様子、表情や取り組む姿勢、笑いの数などたくさんの情報がそこにはあります。
ハピネスメトリクス・ニコニコカレンダー・Fist to Five（Five Fingers）など、見える化して状態を確認する方法もありますが、よいチームを能動的につくりたい人は日頃から人間観察を習慣化しておくのがよさそう。
35. 過去に使ったふりかえりのフォーマットはどんなものか？
覚えている限りで、KPT、YWT、タイムライン、Fun Done Learn、Fun Learn、チームレーダーチャート、6 Thinking Hats、ドラッガー式ふりかえり、ロールプレイングふりかえり、雑談とかかなー！
※オリジナル含む
36. どうやってマンネリを防いでいるか？
あんまりマンネリ化したと感じる経験ないのでわかりませんが、自分自身が人よりも飽きっぽい自信があるので飽きるような状態にならないようにしているかも。
- 飽きそうだったらいったん辞めてどうなるか試してみる
- 毎回同じ方法を続けることにこだわらない
- 雑談の時間を増やす
- 楽しくやることを優先する
とかはよくやっていると思います。
37. チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
あるあるだけど、行動できていないってことは「妥当」じゃないんじゃないかな？チームの課題の優先順位としては妥当かもしれないけれど、やることが具体的でないとか、サイズ感が大きいとか、実現可能性が低いとか。
経験上、どんなに小さくてもいいので成功体験を積み上げていくことがなによりチームの自信につながるので、とことんアクションアイテムのハードルを下げてクリアし続ける状態からはじめることが多いです。
あとはそれでもダメな時は、「なぜ実現できなかったのか」を毎回チームでふりかえって原因分析して都度対策を打っていくこともよい習慣ですね。
人間なので忘れてしまうことはあるので、アクションアイテムはスプリントバックログアイテムとして扱うとか、カンバンの近くにアクションアイテムを常に貼り出してスタンドアップで確認する、などそういう工夫はします。
38. どうやってアクションアイテムのフォローアップを薦めるか？
37でほとんど書いたかな。
あと、「実現したこと」や「できなかったこと」は記録は残すことが合っても管理したり継続ウォッチはしないようにするかな。また同じ繰り返し課題が出てきたとしても、それ自体がチームの状態を表す情報なのでそれでいいと思っています。どんどん溜まっていくことで、「やらなきゃいけない」「全然できていない」というどんよりした気持ちになってしまうのでイヤだなー。管理したいわけじゃないしね！
