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

ryuzeeさんの記事で紹介されていたスクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。

38個すべてに一度に答えていこうとするとかなりハードですが、1日1個ずつこつこつと、回答をしていっています。
この回答は、年月を重ねることに変わっていくかもしれません。
2019/12時点の回答がこちらです。

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

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

スクラムマスターはプロセスを順守する・させるためだけの存在ではありません。プロセスを順守する行為は「どのように行うのか（How）」を守らせることに注力してしまいがちですが、「なんのために行うのか（Why）」のほうを重視すべきです。
アジャイルにおけるチームの成功は、「よいプロダクトを作り最大の価値を生み出すこと」と「チームの成長」だと考えます。これらは時によってはプロセスを守らせることと反発します。組織や現場の形に合う「チーム」や「スクラム」の形があり、その形は規定されたプロセスから離れていくためです。この「よいチームの形」「よいスクラムの形」を見つけていくためのファシリテーションをするのがスクラムマスターだと考えます。

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

「組織」をどの広さで解釈するかにも回答が異なります。
それぞれの解釈によって回答します。

「組織」を「部」「本部」「企業」として解釈した場合

うまくいっている兆候について

• 価値の高いプロダクトが、短いサイクルに則ってリリースし続けられていること
• 組織のありかた、働き方、プロセスなどについて、従業員同士で定期的に話し合われ、カイゼンが行われていること
• 組織のミッション・ビジョン・ゴールが共有され、同じ方向を向いて仕事が出来ていること

自分の働きが成功している兆候について

• 自分（スクラムマスター）がいなくても、自発的に上記の「うまくいっている兆候」が継続されていること
• 自分が別の可能性を提示したとき、従業員が理由（Why）に立ち戻って考え、従業員なりの考えを示せること
  • これは別の可能性へと方向を転換してもよいし、転換しなくてもよい
  • いわれるがままに「促される」のではなく、自分たちの考えを持って、検討し、進められることが大事

「組織」を「あるプロダクト・プロジェクトに関連する人たち」として解釈した場合

うまくいっている兆候について

• プロダクトの仮説検証結果や要件などの情報が、組織全員に共有され、話し合われていること
• 価値の高いプロダクトが、短いサイクルに則ってリリースし続けられていること
• プロダクトに関する技術的負債を先んじて潰す動きができていること
• プロダクトの機能を拡充するだけでなく、保守の負担を減らす、機能を減らすなどの検討が出始めること
• Devサイドのメンバーが自発的・積極的にBizサイドのメンバーと情報交換をしていること

自分の働きが成功している兆候について

• 自分（スクラムマスター）がいなくても、自発的に上記の「うまくいっている兆候」が継続されていること
• スクラムマスターからのティーチング・コーチングによってだけでなく、外の知識を自発的に吸収し、新しいプロセスやプラクティスを生み出し、実践しようとしていること

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

全プロジェクトに適応できる必須のものがあるか、と言われると微妙ですが、追跡したほうがよいかな、と思うものは以下の通りです。開発チームの成熟度によっても変わってくるので、チームのタックマンモデルに従って成熟度別に記載します。

チームの形成期～混乱期（チーム結成後0か月～3か月）

• プロダクトバックログはINVESTに近づいているか
  • INVESTになっていないプロダクトバックログは、DONEにならない可能性が高まる。また、コミュニケーション不足である可能性もある。徐々にプロダクトバックログがINVESTになっているかを追跡するのはよい。
• プロダクトバックログの全体像が見えているか
  • 見積もりが粗くとも、全体像が見える化されているかどうか。全体像が見えないままプロジェクトを進めていくと、着地点が見えないためチームへの心理的負担も上がるほか、プロダクトのステークホルダーへの説明もしにくくなる。
• ふりかえりのアクションがSMARTかつ実現されているか
  • チームの初期段階において、大事なのはカイゼンが行われること。ふりかえりを毎Sprint実施し、その結果が少しずつチームの表れているかを確認します。

チームの統一期（チーム結成後3か月～6か月）

• 技術的負債が定期的に消化されているか
  • 技術的負債が積み残されたまま放置されていないか。技術的負債は、リリースに近づくにつれてボディーブローのように負荷が高くなっていく。少しずつ解消していけるのが望ましい。
• プロダクトバックログの着手からリリースまでのリードタイム
  • リリースは、本番環境へのリリースだとよいが、検証環境やステージング環境へのリリースでも構わない。
  • リードタイムが長い場合は、そもそもプロダクトバックログの切り方が適切でなかったり、チームのコミュニケーションがうまくいっていないため開発スピードが出ていない可能性がある。
  • また、属人化が進んでいる場合は、局所的にリードタイムが長くなる傾向にある。
• 発生したバグ・障害の発生から解消までのリードタイム
  • プロダクトバックログのリリースまでのリードタイムと同様。発生から解消まで、としているのは、必ずしも優先順位が高くなければ放置されていても構わないが、リードタイムが長いことに気づけば、ROIを見据えたうえで放置をする判断となっているか、を見直すきっかけになってくれる。

チームの機能期（チーム結成後6か月～）

• 新しい学びや知見を吸収し、プロダクトに活かし続けているか
  • Learning Sessionのような学びの時間やゆとりなど、チームに常に新しい情報を入れ続けて、現状に満足せずにカイゼンしつづけていられるか
• Undoneが減らせているか
  • Definition of Doneを広げ、Undoneを減らし続ける努力をしているか。このためには、自動化など様々な技術を使う必要がある。常に自分たちの状況を改善しつづけているか、のバロメータにもなる。

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

考えられる理由

• スクラムチームが対象のプロダクトに最大限注力できる環境が作られていない（割り込みや掛け持ちなど）
• コミットメントがPOから無理やり押し付けられたものである
• オーバーコミットが常態化している
• プロダクトバックログがReadyになっていないままスプリントを開始している
• 属人化により特定のメンバーに負荷が偏っている
• スプリントゴールが設定されていない

どのように指摘するか

まずは以下の2つから始めます。

• プロダクトバックログをReadyにする
• 現状のチームの実力を踏まえて、オーバーコミットをやめる

問題にあるような状態が常態化してしまっているチームの場合、チームが疲弊してしまっており、満足に結果を出せていない場合も十分考えられます。まずは出来ることを確実に進めていく方向に舵を切ります。
これまでの結果をチーム（開発チーム・PO）に見せたうえで、着実に実績を積み重ねていくよう促します。

一方、リリースまでまもなく、高稼働で働かざるを得ない環境の場合は、話は別です。
現状を認識したうえで、このペースで開発を進めた結果リリース時にどうなるのか（そもそもリリースできるのかも含めて）をPOへと共有し、リリース延期か、このまま突き進むのかの判断をします。突き進む場合は時間を割いてでもプロダクトバックログの明確化は行い、現状の見える化は開発チームのパワーが足りなければ、SMが担当します。
毎日細かく状況を確認する「確認タイミング」をいくつか設け、そこでチームに情報を共有しながら、すべきことを逐次追っていきます。

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

積極的に参加すべきだと考えています。
（勿論、ディスカバリープロセスに注力しすぎてデリバリできないのは論外ですが）
プロジェクトやプロダクト開発の初期フェーズであれば、ユーザーへのヒアリングや、ディスカバリーのためのワークショップ、プロトタイプ作成など各種作業に関わります。
なお、ディスカバリーに関する最終決定はPOです。開発チームがディスカバリーのワークショップに入ると、どうしても開発側の技術的な細かな意見に引きずられてしまいがちですが、ROIを追求してよいプロダクトを開発できるよう、必要に応じてスクラムマスターがフォローするとよいかと思います。

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

プロジェクト・プロダクトの時期や性質によって、どこでボトルネックになるのかが変わってきます。ケース別に考えていきます。

POが注力できない

ボトルネックになる原因の多くが、コミュニケーションです。そもそもPOが100%そのプロダクトに対して注力できていなかったり（別のプロジェクトと兼務していたり）、POと開発チームとが一緒にいられる時間が少なく、プロダクトバックログについて十分に話せない場合が挙げられます。
この問題では、プロダクトオーナーが出来る限り開発チームとコミュニケーションを取れるよう、各部署との調整をしたり、プロダクトオーナーに合わせて開発チームの動き方・リズムを組みなおします。
また、一定の期間であれば、POと開発チームの橋渡しとしてSMが動いてもいいと思います。この施策は長期的に見るとコミュニケーション面でマイナスに働きますので、双方がうまくコミュニケーションを取れるような働きかけを続けていきます。

プロダクトバックログがReadyになっていない

要件を確定させるのに時間がかかり、Readyになっていないプロダクトバックログが複数あり、開発チームへとバックログが渡せない状態です。優先順位が確定していなかったり、受入条件が明示されておらず、開発に着手できないような問題が発生します。原因として、単純にPOの余力がない場合、POがプロダクトバックログを重要視しておらず注力していない場合などがあります。
前者の場合は、開発メンバーがPOに協力し、全員で重点的にバックログリファインメントを実施して、プロダクトバックログをReadyにする活動を実施します。POが参加できない場合は、既出の情報で想定でプロダクトバックログをINVESTにして、POへと持ち掛ける方針でもいいでしょう。
後者の場合は、POへの教育が必要です。プロダクトバックログがReadyでない結果なにが起こるのか、を伝え、POに働きかけます。

開発スピードが要件の決定スピードを超える

プロダクト開発後期にありがちな問題です。開発チームのスピードが向上し、POがプロダクトバックログを生み出すスピードを上回ってしまうようなケースです。この場合は、1か月に1度、全員でプロダクトの今後について検討する場を設け、一定期間の開発タスクを保持できるようにします。市場の調査などが追い付かない場合（単純にPOの人手が足りない場合）は、POを増員することも検討してよいでしょう。

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

アクセスするための前提として、スクラムチームの周りにどんなステークホルダーがいるのかを、把握している必要があります。インセプションデッキの「お隣さんを探せ」や、ステークホルダーマップを全員で作るなどして、スクラムチームを取り巻く環境を可視化します。
また、どのステークホルダーへとアクセスできるのか、という権限の問題も存在します。小規模なプロダクトの場合、多くの場合、ステークホルダーへアクセスするための権限は開発チームまたはPOが持っていることが多いでしょう。どこまでアクセスしてよいのか、という権限についても、RACIやDelegation Porkerなどによって可視化されていれば、スクラムチーム自身で動きやすくなります。
大規模なプロジェクトやプロダクト開発、また、多くの部署に跨る横断的なプロダクトの場合、適切なステークホルダーへのアクセスパスをチームが持っていないこともあります。可能であれば、プロジェクト・プロダクト開発のキックオフの際にステークホルダー全員を集めてアジャイル・スクラムに関する認識合わせをしたり、コミュニケーションパスを整理しておくことで、この問題は解消しやすくなります。ただ、そううまくいかない場合もありますので、そうした場合は、部署やチームを横断的に動きやすいSM・POがステークホルダーとの調整をし、その際に開発チームを巻き込みます。権限を徐々に委譲していき、スクラムチームとして動きやすい状況を作り出します。

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

プロジェクト・プロダクト開発の場合と、それ以外（組織変革）の場合とで分けて考えます。

プロジェクト・プロダクト開発の場合

もしプロジェクト・プロダクト開発における最初期フェーズであれば、ステークホルダー全員に対して、アジャイルに関する研修を実施するとよいでしょう。決裁権限を持つステークホルダーがこの研修の場に参加できれば最高ですが、「時間がない」「（明言はされないが）価値を感じない」といった理由で参加を見送られるケースもあります。この場合は、決裁者向けの説明資料を持って、決裁者としてどのように動いてほしいのか、その結果どのような利益がもたらされるのか、を説明します。

また、定期的にアジャイルに関する知識・考え方を展開するための場（Learning Sessionや勉強会など）を設けて、関係者を巻き込み続けることが大事です。SMが在籍するチームだけでなく、プロジェクト・プロダクト開発のステークホルダー全体、そしてそれを包含する組織レベルにまで、こうした「知識共有のための場」があるということを発信し続け、興味を持ってもらうことが大事です。普段参加していない人にも定期的に「来てほしい」と声掛けをしたり、そうした人が参加しやすいような日程時刻に変更して、徐々に人を巻き込みます。
こうした活動を部門・ITなど関係なく実施することで、プロジェクト・プロダクト全体に徐々にアジャイルのマインドが浸透していきます。

組織変革の場合

徐々に浸透するための戦略を取ることが、波紋が起きにくく、浸透しやすいと考えます。
SMが組織変革を担う場合、まずは部門を横断するために仲間を見つけるところから始めます。先述の「知識共有のための場」を告知して開き、他部門の「少しでも興味を持っている人」「問題を感じている人」を探してアクセスします。そして、その人を起点に少しずつ広げていくような戦略を取ります。
また、上記のようなボトムアップの活動だけでなく、トップダウンでの活動も必要です。
部門のリーダー層・マネジメント層にまで上記活動の存在を知ってもらったら、その部門内で研修や勉強会を開催してもらえるよう、部門内のメンバーから部門内のトップ層へ掛け合ってもらいます。（もし、SMにコミュニケーションパスがあれば、直接掛け合うのもよいでしょう）

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

上級管理職が「アジャイル」に関して興味を持っている場合と、そういった考え方に抵抗がある場合とで紹介の仕方を変えます。

上級管理職が「アジャイル」に関して興味を持っている場合

アジャイルな考え方やマインドを実現し、開発を行うための、最も標準的なプロセスである、というように説明します。スクラムの概要、全体像を示し、徐々に詳細化していく、といった、スクラムを学ぶ研修に近い方法で説明を行います。また、スクラムにより実現されることと実現されないことも述べます。

上級管理職が「アジャイル」に関して抵抗がある場合

いきなり「スクラム」という単語は使いません。透明性・検査・適応といったスクラムの特色から、現時点で採用している手法（おそらくウォーターフォールであることが殆どでしょう）の進め方からどこを少しずつ変えていくのか、という伝え方を取ります。
話をしながら少しずつ興味を持ってもらったり、安心感を得てもらったうえで、「スクラム」という手法のことを紹介します。

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

戦略について

「スクラム」の何に関する適応への抵抗か、をまず確かめます。私の経験上、多くの場合はスクラムのイベント（コミュニケーション）の時間が長いことへの不満や、スクラムという「未知」のプロセスの適応に関する漠然とした不安に起因します。この2つの場合を取り上げて説明していきます。

「スクラムのイベント（コミュニケーション）の時間が長いことへの不満」への対処

スクラムに必要なイベント（デイリースクラム、スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブ、プロダクトバックログリファインメント）にスプリント中に多くの時間が割かれ、開発が出来る時間が少なくなってしまい、成果が出せなくなるというエンジニアの心理に基づいた不満です。この場合は、抵抗している人の属性や状況にもよりますが、

• ①イベント（コミュニケーションの時間）を最初は多めに取り、スプリントレトロスペクティブで少しずつチームの状況に合わせてカスタマイズ（時間を減らす）していく方法
• ②イベントの時間を抵抗する人の要望通り少なめに取り、スプリントレトロスペクティブで少しずつチームの状況に合わせてカスタマイズ（時間を増やす）していく方法

のどちらかを採用します。どちらの場合も、スプリントレトロスペクティブの時間だけは、有用性を強く述べたうえで必ず確保し、改善していきます。多くの場合、私は①の方法を採ります。これは、①のほうがコミュニケーションの重要性を認識してもらいやすいほか、あとから時間を確保するのは難しいという2つの理由からです。②の方法の場合は、プロダクトの状況に余力があり、チームをゆっくりと変えていくことが可能だと分かっている場合のみです。②では十分なインクリメントが作成できず、スプリントが失敗する可能性が高まります。一度失敗してから学習するというタイプの方が多い場合は、②のほうが効果的だと考えますが、あまりこの戦略は採用しません。

「スクラムという「未知」のプロセスの適応に関する漠然とした不安」への対処

これは、スクラム自体がこれまでの開発手法と根本は変わらないはずだ、というところから安心感を得させ、納得してもらう戦略と、「やってみて、ダメだったら元に戻す」という考え方を伝えて前に進む戦略を同時に行います。
前者の戦略は質問「9. 上級管理職にどのようにスクラムを紹介するか」と同じ回答になります。
後者の戦略は、「まずはやってみようよ」という意識へと持っていく方法です。短い期間でのスプリントの実施で、スクラムを適用してうまくいかなかったプロセスは元に戻す（または改善する）という保証をすることで、安心感を持たせます。人は、「変えさせられる」ことに大きな不安を感じますが、「自分から変わる」ことには多少の不安で済みます。いつでももとに戻せるという安心感を持つことで、一歩前に進むことができるようになります。なお、この戦略を取ったプロジェクトで、結局すべて元に戻す選択をしたプロジェクトはありませんでした。

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

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

よいです。
ただ、要求をそのままプロダクトバックログ項目として作成して本当にそれでいいのか？という疑問は浮かびます。ステークホルダーとコミュニケーションしながら、POとしてROIを最大化させるための検討をし、その結果がプロダクトバックログ項目として生み出されるようなフローのほうが、プロダクトにとっては望ましいことだと考えます。
そして、プロダクトバックログ項目はステークホルダーの要求からのみ生まれるものではなく、POが主体で生み出す場合もあり、開発チームが生み出す場合もあります。様々な場所から生み出されるプロダクトバックログを使って、様々な人とコミュニケーションを取り、スクラムチームとして今後すべきことを検討する、というのがよい姿だと思います。
また、POが見積もりを求めずに、開発チームが自発的に行ってもよいでしょう。"No Estimate"のような考え方もありますので、チームの成熟度によっても、一概に「こうすべき」というプロセスはないと考えます。

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

いくつかの情報の候補を記載します。
いずれの情報も、顧客とチームが密にコミュニケーションがとれていたり、十分に透明性が担保され可視化いれば、プロダクトオーナーを介さなくてもよいでしょう。

• 顧客・マーケットからのフィードバック。顧客とどんな会話をして、どんな反応があったか。マーケット（市場）からの反応はどんなものだったか。
• 顧客・マーケットとの繋がりの状況。会話・やりとりがどのようなステータスか。
• 売り上げや利益。毎週・毎月、チームの作ったプロダクトがどのように市場に活用されているかを知る。
• 懸念事項。POが抱えている懸念はないか、チームに明らかにしてもらい、協力を申し出る。

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

誰でもよいです。
よいユーザーストーリーになっているかをチーム全員で話し合うとよいでしょう。

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

INVESTなプロダクトバックログになっていることが、よいユーザーストーリーの1つの特徴です。

• Independent:独立している
• Negotiable:交渉可能な
• Valuable:価値のある
• Estimable:見積もり可能である
• Sized Right:適切な大きさである
• Testable:テスト可能である

最も大事で、最も難しいのが、Valuableだと思います。
ユーザーストーリーを実現した時、そのユーザーストーリー単体で価値を出すようにするためには、ユーザーストーリーの分割の方法を「縦割り」（フィーチャーに対して機能A, B, Cを実現して初めてリリース可能となる形）から「横割り」（フィーチャーに対して機能A, B, Cのうち、A-1, B-1, C-1の小規模を実現すればリリース可能となる形）へと変えなくてはいけません。ウォーターフォールで慣れている開発者が、アジャイルへとシフトするときに一番問題となるのはこの部分でしょう。

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

以下の要素は必ず入っていたほうがよいかと思います。

見積もり済みであること。見積もりがされていないバックログは、十分に話し合いがされていない可能性があります。
優先順位が決定済みであること。たとえスプリントの中でも、優先順位は一様につけられているべきです。スプリントごとに何の価値を最大化させるのかを話し合える状態にしておく必要があるでしょう。
受入条件の認識があっていること。いかにタスクに分割されていたとしても、受入条件を満たさず、タスクのみを消化してしまい結果価値が出ない、という状態は避けるべきです。
適切な粒度に分解されていること。1スプリントで必ず終わるような粒度に分割されていると、毎スプリント価値を届けられるようになりますし、何よりチームのモチベーションも上がりやすくなります。

また、以下の要素は入っているとよりよいと思います。

デモの方法が規定されていること。作ったユーザーストーリーをどのようにデモするのかが決まっていると、実装のイメージも湧きやすくなり、テストもしやすくなります。また、スプリントレビューの時に迷わずに済みます。

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

ユーザーストーリーを時間見積もりのデメリットと、ユーザーストーリーを相対見積もりをするメリットそれぞれを説明します。

絶対見積もりをするデメリット

**「時間見積もりをしても、実施する人によって時間は大きく異なる」点と、「時間見積もりをしてもキャパシティに基づくコミットが予測しづらい」**点の2点の側面があります。
時間見積もりの場合、タスクまたはプロダクトバックログ項目を時間（人日など）で見積ろうとします。多くの場合、この見積もりはリードタイムで行われがちです。待ち時間も含めてしまっているため、リードタイムとプロセスタイムに乖離があるタスクほど、見積もりが当たりにくくなります。
プロセスタイムで見積ったとしても、今度は自分たちのキャパシティ（稼働できる時間）の見積もりが難しいという問題にぶち当たります。１つのプロダクトにフルコミットならいいのですが、多くの場合、定例や個別の打ち合わせ、休暇等で、毎週のキャパシティは大きく可変します。
計算したキャパシティに収まるように、タスクの量を調整できたとしても、また問題が発生します。割り込みが発生したり、想定できていなかった追加タスクの発生で、結果としてキャパシティ以上の時間がかかってしまうのもよくある話です（パーキンソンの法則）。

相対見積をするメリット

人は、絶対的な指標での見積もりが苦手です。「あのビル何メートルある？」「あのおもちゃいくらだと思う？」という質問に対して、数値で見積もろうとしても大抵あたりません。
ただ、相対的な指標での見積もりは得意です。「あのビル、隣のビルの何倍の高さ？」「あのおもちゃ、隣のおもちゃと比べて何倍くらい高いと思う？」というのは、比較する対象の属性が近ければ近いほど見積もりの精度が上がりますし、属性が異なっていても比較する指標が一緒であれば、比較がかなり容易になります。

また、「規模」による見積もりの場合は、「負の側面」で説明した問題は発生しにくくなります。経験則に基づいた「自分たちはこれだけできた」という規模量（Story Pointなど）は、時間と比べて変動量が相対的に小さくなるためです。割り込みや想定外のタスクすら、規模見積もりの変動範囲に収まります。

さらに、「規模」による見積もりをするために、チームはコミュニケーションをより多く取るようになります。チーム内での規模の認識を合わせるためです。その結果、不測のタスクは徐々に減り、見積もり精度が上がっていくでしょう。

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

チケットが何個できたとしても、優先順位の順に実装していくだけです。
もし、今後必ず必要になるであろう調査等や、リファクタリングなどの「技術的負債」のチケットがある場合は、機能の実装のためのプロダクトバックログだけに追われてしまわないよう、計画的に実施できるように優先順位を付けて実施していきます。

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

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

スプリントプランニングの最初に、スプリントゴールを決めます。
このスプリントで何を実現するのか、どんな価値を届けるのかを話し合うことによって、最も価値のあるストーリーは何かを考えるようになります。

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

「スプリントプランニングにおけるユーザーストーリーの価値の判断」という意図での質問として回答します。
まず、ユーザーストーリーが実現すべき優先順位順にスプリントの中に取り込まれようとしているかを確認します。この優先順位は、**プロダクトが生み出す価値（ROI）**の順に、戦略的に並び替えられている必要があります。なお、ユーザーストーリーがどんな価値を生み出すか、はスプリントプランニングではなく、プロダクトバックログリファインメントですでに話し合われていることが望ましいです。
そして、プロダクトの価値とは直接結びつきませんが、ユーザーストーリーがINVESTになっているか、Readyな状態になっているかも重要です。これらの状態になっていないユーザーストーリーは、そのスプリントで価値を届けられない可能性が高まります。

受け入れがたいメトリクスは、実現が簡単かどうか（フィージビリティ）、**今すぐにやらなければならないかどうか（緊急度）**といったものです。これらのメトリクスが意味がないとは言いませんが、実現が簡単かどうかだけで判断すると、全く価値の生み出さないプロダクトを開発して、いたずらに時間を浪費してしまったり、本来開発すべき実現の難易度の高いストーリーを後回しにして、挑戦のための時間を奪います。
また、緊急度のみで判断をするのも危険です。障害対応など、ユーザーに影響を与えかねないものは、ROIを判断したうえで今すぐにでも着手したほうがよいですが、「顧客に言われたから緊急度高」のようなユーザーストーリーが多発しているのであれば、適切なコミュニケーションを顧客とスクラムチームとで取れているかを確認する必要があります。フィージビリティや緊急度は、あくまで優先順位を決めるための属性の1つであり、そのメトリクス1つのみで判断するのは危険です。

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

私が経験してきた多くの場合、POや顧客から開発・リリースに向けた圧力がかかっている場合、チームのコミットメントの権限が侵されます。圧力をかけたところで出来上がる価値の総量には変化がないこと（むしろ悪化する恐れがあること）、実際のこれまでのスプリントの結果などを見せ、極力チームが自分たちの手でコミットメントが行えるようにファシリテートします。
また、余裕がないスクラムチームほど、NO.19のような「受け入れがたいメトリクス」でのユーザーストーリーの選択をしがちです。PO・開発チーム双方に働きかけ、「今、チームが実現すべきものは何か」「実現したいものは何か」という観点で話し合いを設けるようにします。

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

それぞれ属性が違うため、分けて説明します。

リファクタリング

意図的にリファクタリングの時間を取るのであれば、5%程度だと考えます。リファクタリングはチームのルーティーンや、スプリントのDefinition of Doneの一項目として入っているのが望ましく、意図的に時間を取らなければならない（＝「リファクタリングをする」というプロダクトバックログが存在する）状態が続くのであれば、開発の仕方を見直したほうがいいと考えます。

重要なバグの修正

これは毎週のスプリントの中に必ず入るものではないため、適切な時間というものはないと考えます。重要なバグなのであれば、優先順位の高いプロダクトバックログとしてスプリントに入ってくるだけであり、定常的に時間を割くものではないでしょう。
定常的に行うような状態になっているのであれば、プロダクトの品質が悪いことを示していますので、新しい機能の開発とバグの改修のどちらを優先するのか、プロダクト全体の戦略を見直す必要があるでしょう。

新しい技術やアイデアの調査

これは、毎週のスプリントのなかの10～20%程度の時間を割くのが適切だと考えます。Learning Sessionのような学びのための先行投資の時間と、スパイクのようなプロダクトの未来に直結する先行投資の時間の両方にバランスよく時間が割り振られるべきです。なお、前者に関しては、チームに余裕のあるうちから習慣化しておいたほうが、チームの成長を加速させます。

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

ストーリーやタスクのやり方を決めるのは開発チームであって、プロダクトオーナーではありません。タスクの割り当てよりも、別のこと（プロダクトバックログをReadyにするなど）に注力するように伝えます。また、開発チームには、どんなタスクの進め方をしてスプリントゴールを実現しようとしているのか、プロダクトオーナーに相談するようにし、双方向でのコミュニケーションが行われるように促します。

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

つまみ食いすることで、以下のような問題が確実に引き起こされます。

• タスクの切り替えによるコンテキストスイッチのコスト
• WIPが膨れ上がることによるフロー流動性の低下
• 現在の進捗が分かりづらくなる

このような問題が、チームの中で明らかなボトルネックになっているのであれば、まずはフローの可視化を行いましょう。
タスクボードを作り、可視化することで、WIPに大量にタスクが溜まっていることに気づくでしょう。それでなにが引き起こされるかは、デイリースクラム時点で判明したり、スプリントの結果として現れます。この結果を見て、チームは自分で問題に気づき、次第にチームはカイゼンする方向へと向かうでしょう。

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

以下の3つのやり方が考えられます。状況やチームの練度に応じて使い分けます。

• ①Readyでないプロダクトバックログアイテムはスプリントのスコープに入れない。次回のスプリントで対応する。
• ②Readyでないプロダクトバックログアイテムはスプリントのスコープに入れずに保留しておき、Readyになった時点で、スプリントのスコープ内のプロダクトバックログアイテムと入れ替える。
• ③ある程度のバッファを持たせたうえで、プロダクトバックログのみをスプリントのスコープに入れておく。スプリントバックログへの分解はしない。

いずれの場合も、スプリントの途中で再計画が発生しますので、基本的にはこのような事態が起こらないように、出来る限りスプリントの前にReadyにする活動を行います。

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

スクラムチーム全員がそのような態度を取る場合は、そもそもスクラムへの理解と共感が少なく、スクラムを「やらされている」と感じるためでしょう。
スクラムの導入初期で、そもそもスクラムチームがスクラムに関して積極的ではない場合は、スクラムを学習・体験する研修やワークショップから始めます。ある程度の理解を持ったうえで、まずは「経験してみる」ところから始めます。2-3回やってみて、自分たちに合わないと感じたり、利益を得られていないと思うのであれば、そもそもスクラムがそのチームの文化にあっていない可能性もありますし、スクラムにこだわらず、別のやり方に変えてもいいと考えています。
ただ、スプリントプランニングでプロダクトバックログアイテムの設計を行い、明確にチームが何をすべきかハッキリした状態を作り出すことを何度か経験すれば、時間の無駄だと感じることは少なくなるはずです。

一部のメンバーがスプリントプランニングに参加しない状態が発生した場合は、そのメンバーを除いた状態でスプリントを継続したときに、何が起こったかスプリントレトロスペクティブで確認します。そのメンバーの影響でチーム全体のスピードが下がったのであれば、チームが自発的にその状態をなくすためのアクションを考え始めます。

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

※以下の質問では、質問文の中では、「スタンドアップ＝デイリースクラム」という解釈で回答します。
ただし、回答文の中では以下のように区別して回答します。

• 「スタンドアップ」＝立ってミーティングを行う行為
• 「デイリースクラム」＝スクラムのイベント

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

必ずは薦めません。デイリースクラムをする必要はない（それ以上のことができている）場面もあるためです。

例えば、2-3人などの少人数のチーム。この場合は、そもそもデイリースクラムがなくてもよいかもしれません。密にコミュニケーションをとれており、スプリントの状況が常に把握できており、適宜再計画が出来ているような（所謂モブプログラミングを習慣としているような）チームでは、デイリースクラムをせずとも、状況の共有は行えます。

スタンドアップという意味でも、必ずスタンドアップでする必要はありません。

例えば、リモート環境で働いているチーム。ネットワーク越しにスタンドアップで多なう必要はありません。リモート環境の場合は、リモート環境でも共有できるタスクボード（JIRAやTrelloなど）でやり取りすることが多くなるでしょう。その場合、全員がコミュニケーションがしやすい姿勢で行えばよいだけです。

ただ、上記の環境はある程度の練度があり、スクラムへの理解が深いチームであることが前提です。もしスクラムを始めたばかりの場合は、まずはFace to Faceで、デイリースクラムを、スタンドアップで試してみて、徐々にチームの最適な形に沿うように改善を進めていきます。

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

期待しません。誰か一人に困っていることがあると、チーム全体のスループットが低下します。
最悪、デイリースクラムにて困っていることを救い上げることができる、というだけであって、その周期は短ければ短いほどよいでしょう。
コミュニケーションが密にとれているチームであれば口頭ですぐに連携すればよいですし、チャットなどで気軽に聞いてもよいでしょう。また、困っていることを表現するようなカンバンボードを作るのもよいでしょう。チームの現状に合わせて、様々なコミュニケーションの仕掛けを施したり、自分たちで行えるように促します。

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

プロダクトオーナーまたはスクラムマスターがこのような「デイリースクラムをリードする人」になりがちです。こうしたとき、デイリースクラムは誰かへの報告の時間ではなく、スプリントゴールの達成状況の検査・適応のための場であることを教えます。
また、よくあるケースとしては、開発メンバーがスクラムマスターのほうを向いて情報の共有をしている場合です。この場合は、「開発チーム全員に共有すること」を開発チームに意識させることや、「スクラムマスターが開発チームの視界に入らないようにする」ことなどを行います。
また、スクラムマスターがあえてデイリースクラムに参加しない、というのもよいでしょう。

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

基本方針は No. 25 のスプリントプランニングの問題と同様です。
協力的ではないメンバーがなぜ協力的でないのかを突き詰めれば、自然と解決策は見えてくるはずです。そもそもがそのメンバーの参加しにくい時間である場合もありますので、そうした場合はデイリースクラムの時間を変更して、全員が来やすいようにしましょう。

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

ステークホルダーが開発チームの外のメンバーのことを指すのであれば、変える必要がありません。問題ないと思います。
逆に、ステークホルダーが積極的に参加し、チームに口出しをしているようであれば、改善する必要があります。

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

（地理的に）分散しており、もし可能であれば、場所ごとにクロスファンクショナルチームを形成するようにします。その場合は、分散しているそれぞれのチームごとにスタンドアップを行います。
分散しているメンバーが1つのチームの中にいるのであれば、リモート環境で行えるような工夫をします。

互いの顔やタスクボードが見えるようにして物理ボード上で行ったり、JIRAやTrelloなどを使いながら行う場合もあります。

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

TODO, WIP, DONE。
基本はこれだけです（※これだとタスクボードと変わりませんが）。
チームのValue Streamの中に、「カンバン」の要素を取り入れる「工程」が存在するのであれば、カンバンボード上に表現します。

個人的に、WIPはチームの人数以下に絞るほうが好きです。

ふりかえりについて

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

誰でも参加してよいです。
ステークホルダーが参加する場合には注意しましょう。あくまでスクラムチームのカイゼンの場であり、ステークホルダーが参加すると、ステークホルダーの思いを押し付ける場になりがちです。

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

ふりかえりの中で出てきた意見を見れば、チームが健全な状態かは判断できます。
以下のようなポイントがふりかえりの中で確認できるとよいと考えます。

• 自分たちの良いところ・悪いところをどちらも自己認識できているか
• コミュニケーション・コラボレーションがうまくとれているかどうか
• アクションが毎回実行され、着実にカイゼンされていっているか

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

正確な数を数えてはいませんが、手法ごとのバリエーションを加味すると最低でも300以上のフォーマットで実施しています。

各手法に関しては ふりかえりを拡張する「ふりかえりチートシート」を参照してください。
また、ふりかえりに関する様々な考え方は、ふりかえりに関する記事まとめを参照してください。

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

手法を変えます。
また、手法を変えずとも、質問の仕方を変えたり、場作りの方法を変えるだけでもマンネリは防げます。

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

「妥当だが行動できない」というのが、妥当ではない証拠ではないでしょうか。
そもそもアクションがSMARTになっているかどうかを確認しましょう。
SMARTは

• Specific : 具体的な
• Measurable : 計測可能な
• Achievable : 達成可能な
• Relevant : （問題・課題に）関連のある
• Timely / Time-bounded : 即効性のある・すぐにできる / 期限のある

の頭文字を取ったフレームワークで、ふりかえりのアクションをより具体的にするための活動の1つです。

38. どうやってアクションアイテムのフォローアップを薦めるか？

ふりかえりのアクションは、スプリントプランニングでスプリントバックログに含めて、チームの活動の一番最初に実行します。
また、実行結果は、ふりかえりの最初に効果判定をします。
例えば、KPTであれば、Keep/Problemのなかでアクションの結果がどうだったかを確認できます。