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

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

ものすごく長いので（なんせ 38 個あるので）、以下の目次から興味のある質問への回答だけでも見ていただけると嬉しいです。

なお、最初はかなり丁寧に回答していましたが 5 つ目の質問のあたりでこれ終わらないなということに気づいたため、以降はやや簡潔な回答になっています。

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

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

スクラムはプロセスの集まりではないし、スクラムマスターの仕事はプロセスを守らせることではない。

スクラムは、透明性・検査・適応を軸として、継続的な対話を促すフレームワークであるといえる。
たしかにスクラムマスターがプロセスを守るようチームに働きかけることはあるが、それはあくまで、チームとしての成長を促すフレームワークを活用して、建設的な対話と学習を促進することに主眼がある。プロセスを守ることが目的なのでは決してないし、プロセスを守ればうまくいくわけでもない。

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

以下のような兆候があれば、アジャイルがうまくいっている可能性が高い。

• 以前に比べて、「一気にまとめて」ではなく、日々、段階的に不確実性・リスクを下げられるようになってきている。（例: リリースのスコープの確度が週ごとに上がっていく）
• 以前に比べて、重要な課題が広く認識され、建設的な対話によってそれを解決する努力が行われるようになってきている。（例: 欠陥が多発していたことの原因がレガシーシステムのアーキテクチャにあることをチーム全体が認識し、段階的な設計改善やテストによるアプローチを模索している）
• 以前に比べて、チーム全体が、作業ではなく、成果にフォーカスするようになってきている。（例: 「いつまでに実装が完了するか？」「ちゃんとテストを書いたか？」という会話よりも、「この機能を誰が使うのか？」「一番重要なことに取り組めているか？」という会話の量が増えてきている）

また、自分の働きの効果を測るためには、以下のような兆候を見る。

• 前述の「アジャイルがうまくいっている」兆候が見られるか。
• 以前に比べて、自分が指示・指導を行わなくても、自律的に活動して対話を重ね、経験から学んで継続的にプロセスを改善できるようになってきているか。

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

チームや組織の状態によって重点メトリクスは変わるが、一般的には以下のようなメトリクスに注目する。

• デリバリープロセス全体の健全性
  • 要求からデリバリーまでのリードタイム
  • 各プロセスのサイクルタイム
• 局所的な生産性
  • ベロシティ
  • 各種会議・イベントにかかる時間
  • テスト実行にかかる時間
• （内部・外部）品質
  • テストカバレッジ（使い方に注意）
  • コード品質（静的解析ツール等を用いる）
  • QA でのバグ検出率
• チームの健全性
  • 残業時間
  • 発言の頻度・内容（定性的でもよい）

チーム全体としては単一の最重要指標（たとえば、顧客満足度）にフォーカスしながら、そこへ向かうためのプロセスの健全性をいくつかのメトリクスで監視できるとよい。

メトリクスの数値そのものに固執せず、何を知りたいからそのメトリクスを計測しているのかをチームが忘れないようにする。
ボトルネックが移り変わった場合、取得するメトリクスは変更する必要があるかもしれない。

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

以下のような理由が考えられる。

• タスクの粒度が大きく、スプリント計画の正確性が低すぎる。
• レガシーコードが原因で、計画時に想定していなかったタスク（既存のバグやアーキテクチャの問題による追加作業）が発生している。
• 計画時に想定しているほどの稼働時間が取れていない。（例: 1 日 8 時間で計算しているが、会議や休憩時間を除くと実際に稼働できているのは 6 時間程度）
• そもそも、好ましくない対象にコミットメントしている。（例: スプリントゴールや PBI のデリバリーではなく、全タスクの消化をコミットメントしている等）
• スプリント中に発生する課題をタイムリーに認識できていない。
• スプリント中に発生する課題にその都度適応できていない。

以下のような話の切り出し方が考えられる。

• （具体的な事実や数値を示して）このようにコミットメントを守れていないようですが、それは問題ですか？
• そもそも、チームは何をコミットメントしていますか？　何なら確実にコミットメントできそうですか？
• そもそも、なぜコミットメントが重要なのでしょうか？

回答に応じて対話を重ね、開発チームが行きたい方向とスクラムチームとして向かうべき方向とを合わせていく。

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

もちろんよい。
スクラムチーム全体がそれぞれの視点から製品のディスカバリーに貢献することができるし、ディスカバリーに参加していれば、製品への深い理解を持って、創造的かつ効率的に開発することも期待できる。

ただし、開発とディスカバリーとのバランスのとり方がやや難しく、以下のような課題が出てきやすい。

• 製品ディスカバリープロセスに対して、（スクラムフレームワークに支えられた）開発プロセスと同等の透明性・検査・適応を保つのが難しい。
• 複数のステークホルダーや社外のパートナー・顧客等と協働するなかで、スクラムとリズムを合わせるのが難しい。
• ディスカバリーに時間を使えば使うだけ開発に使える時間が減ることがわかっている状態で、適切なバランスを見出すのが難しい。

以下のような指針を試しては、結果を観察して改善しながら、自分たちのチームに合ったやり方を探していく必要がある。

• スクラムの価値や原則を製品ディスカバリープロセスにも適用できないか試してみる。
• 開発でうまくいっているプラクティス（例: 階層化されたバックログ）を製品ディスカバリープロセスにも適用できないか試してみる。
• 全体指標（例: 顧客満足度）と個別指標（例: バックログの品質やデリバリーリードタイム）を適切に設定・監視して、開発とディスカバリーとのバランスを取る。

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

プロダクトオーナーにすべてを任せず、開発チームもプロダクトバックログ周りの作業に関わってよい。チーム全体で補い合って、プロダクトのことに取り組む。スクラムマスター自身がプロダクトオーナーとペア作業することがあってもよいかもしれない。

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

ステークホルダーにはプロジェクトの早期から、頻繁に連絡を取り、ステークホルダーの関与の重要性を説いて理解してもらう。ステークホルダーは忙しいので、ステークホルダー自身にとっても、有効な時間の使い方ができるよう、コミュニケーションのとり方に配慮する。

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

異なる部門にとってのメリットを前面に出しながら、興味を持った一部の人たちと一緒に小さく始めて、理解を育てていく。IT じゃないステークホルダーについても基本は同様で、ステークホルダー自身の関心事にフォーカスする。

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

その上級管理職が重視しているビジネス上の課題を理解し、その課題に取り組むためにスクラムがどう役に立つかを説明する。「透明性・検査・適応」「課題を明らかにする」ことがスクラムの本質ではあるが、それだけでは響かない可能性もあるので、一味つけることも考える。たとえば、ユーザ企業の変化に追従する能力を育てる、開発力の持続的な成長に貢献する、等。（ただし、過度の期待やスクラムへの誤解を植え付ける結果にならないように十分配慮し、一度紹介して終わりではなくその後もフォローアップを続ける）

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

まずは 3 ヶ月だけ続けさせてくれないか、同僚にお願いする。もちろん、その同僚がどのような課題があると思っているのかもよく聞き、それにチームとして正面から向き合っていきたいことも説明する。ステークホルダーがスクラムを理解しているとしても、ステークホルダーにスクラムの適用を命令させるようなことはできるだけ避けたい。

「激しい抵抗」の経験はないが、「本当に Sprint 単位で製品を完成させるようなやり方が成り立つのか？」という懐疑的な態度には出会ったことがある。当時は組織内で初めてのスクラムへの取り組みで、私はスクラムマスターではなく開発者だった。同じチームのメンバーとして課題意識を共有し、日々の活動を通じてさまざまな取り組みを試してはふりかえって改善を重ね、約 3 カ月後には安定した速いペースでインクリメントを届けられるようになった。

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

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

その流れ自体は悪くないが、チームからのインプットは「見積り」だけであるべきではない。チームによる技術的なシーズ・制約事項や、その他のアイデアもプロダクトバックログに取り込んで、チーム全体として最良のプロダクトバックログを作り上げたい。ステークホルダーの言っていることが「正しくない」ことも少なくない。プロダクトオーナーはステークホルダーの御用聞きにならず、視野を広く持って、チームも積極的にプロダクトバックログづくりに協力していくのが望ましい。

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

Scrum には、製品について話し、考えるための Sprint Review という時間があるので、そのタイミングで、前回の Sprint Review 以降にわかった短期から中長期までの製品に関わる新しい情報は、何でも話してもらう。プロダクトオーナー自身が何を話すべきかうまく判断できないようなら、チームが何を求めるかを重視する。それでもうまくいかなければ、まずはプロダクトバックログの内容（全体像・優先順位）に直接関わることから話し始めてもらい、慣れてきたら少しずつ会社の全体戦略やマーケットの状況へと視野を広げていく。

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

プロダクトオーナーが第一候補になるが、誰が書いてもよい。また、ユーザストーリーは書くものではなく語るものである。ユーザーストーリーを「ちゃんと書いて」、「要求仕様」と見なすようなことがないように気をつけたい。誰が書いたにせよ、ユーザーストーリーは語られる。ユーザーストーリーについてチーム全体が会話をし、会話から現れてくる価値を届けるための機能を、開発チームが実装する。

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

一般論として、誰が・（どのような場面で・）何のために・何をしたいのかが書かれていてほしい。
また、ユーザーストーリーは階層化したほうがよい。あるストーリー、を実現するためのストーリー群、を実現するためのストーリー群というふうに階層化する。上位階層のものほど、「何のために」にフォーカスし、下位階層のものほど「何を」にフォーカスする。
一方で、「どうやって」は限定しないようにする。「何を」と「どうやって」の間に境界を引き、「どうやって」のエリアで創造性を発揮できるようにすることが、開発チームが活き活きと働くための重要な条件と言える。
また、ストーリーではなく PBI としては、明確な受け入れ条件が指定されているとよい。それが透明性の担保に寄与する。また、受け入れ条件はできるだけ交渉可能になっていると望ましい。そういったよいユーザーストーリーの条件をまとめた INVEST という用語もあり、有用。

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

INVEST のうち、E、S、T が整っていること。すなわち、「見積り」「適切なサイズ」「完成したことを確認する方法（受け入れ条件）」がすべて満たされていてほしい。
もちろん、Ready 以前に V、つまり価値も定義されていることは前提である。（なお I、N は必須ではないと考えます）

なお、そもそも「見積り」そのものは必須ではなく、デリバリーペースの予測に役立つ何らかの手段があって、アイテムがその要件を満たす状態になっていればよい。（#NoEstimates の人たちが言うように、見積りそのものに価値はない）

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

デリバリーにかかる時間は人によって異なり、チームとしての見積りにするのが難しい。サイズ（作業量）の見積りであれば、認識を合わせやすい。
また、デリバリーにかかる時間はチームの状態によっても変わりやすい。チームが新たに学んだことや、開発を担当するメンバーによって、一度見積もった時間は変化する可能性が高い。
サイズで見積もっておけば、それらの変動要因を吸収しやすい。

加えて、時間の議論は「俺なら 1 時間」「私なら 30 分」といった不毛な会話になりやすい。相対サイズの議論なら、どのような作業が見込まれるかにフォーカスして、ユーザーストーリーに潜む穴を素早く見つけることができる。

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

もちろん、並行して 200 個のチケットに同時に取り組むことはできない。（できたとしても、する意味がない）

多くのアイテムがある場合（つまり、ほとんどの場合）、ユーザーストーリーマッピングのような手法を用いてバックログを階層化して、構造が見えるようにする。
また、プロダクトオーナーは取り組みの優先順位を明確に定めて、時間軸上で近くにあるアイテムほど、チームで精緻に議論するようにする。

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

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

前提として、プランニングまでに優先順位付けされた Ready な PBI が揃うように取り計らう。
チームには、解決手段だけではなく PBI がもたらす価値にフォーカスするよう促し、複雑な実現手段に固執しすぎているようであれば、プロダクトオーナーとの対話を試してみるよう働きかける。
プロダクトオーナーには、スプリントプランニングに同席することの価値を理解してもらい、少なくとも常に連絡可能な状態を保ってもらうよう働きかける。
また、全体を観察し、状況を書き出すなどして見えるようにする。流れの悪いところがはっきりしたら、チーム自身が気づいて解決できることが理想だが、必要に応じて介入してもよい。チームの自律を奪わないよう気をつけながら、情報がチーム内・プロダクトオーナーとの間でスムーズに流れるように取り計う。

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

実装前は、製品ビジョンのどの部分にどの程度寄与する見込みなのかや、期待される収入増加やコスト削減などを、複合的にメトリクスとして用いる。狩野モデルなども有効。価値だけでなく、ROI も重要。プロトタイプを用いてユーザビリティテストを行い、ストーリーの価値を実装前に検証することもできる。

「ステークホルダーがそう言ったから」とか、「（たかだか一人の）ユーザがそう言っているから」といった表面的な理由は受け入れがたい。ストーリーは実装する前によく磨かないと、すぐに機能過多の鈍重な製品になってしまう。

なお理想の世界では、ユーザーストーリーは直ちにデリバリーされ、アプリケーションやプラットフォームから直接取得できるメトリクス（滞在時間、コンバージョンレート、アクションの成功率、そのストーリーに紐づく機能の販売数等）に基づいて価値を確認できる。ただし実際は、複数のストーリーが同時にデリバリーされたり、直ちに取得できるメトリクスがなかったりする。その場合、大域的であったり定性的であったりするメトリクス（顧客満足度やユーザビリティテストの結果など）を頼りにすることになる。

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

前提として、PO が価値に基づいて優先順位をつけているはずだが、何らかの理由で調整が必要になった場合の話として理解します。
基本スタンスは問いかけ。PO にも、チームにも、「どうしたいですか？　それはなぜ？」と問いかける。見解が一致すれば、めでたし。多くの場合、価値・PO がやりたいこととコスト・チームができることとのトレードオフになりやすい。その場合、対立構造にならないよう、事態をお互いの目で見るように促す。ちょっとした思い込み（「このように実装する必要がある」とか）を取り除くだけで、PO とチームの双方が納得できる最善の道が開けることもある。

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

目安としては、2 割程度。ただし、そもそもそれらのタスクをどの程度明示的に扱うかはチームによる。リファクタリングや新しい技術の調査は、通常の PBI への取り組みの範疇でできていれば、それでもいい。できていない場合に、最大 2 割程度まで、別途時間を確保したり、PBI として定義して、リファクタリングやバグ修正、技術調査等に取り組むようにする。それらの取り組みが 2 割よりも多くなると、ステークホルダーの期待に十分応えられなくなってくる可能性が高い。

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

チームに自己裁量権を認めることで最大の成果を届けられることを説明し、理解してもらう。また、個人にストーリーやタスクを割り当てようとする理由を聞き出して理解し、その理由となる課題を解決するようなアプローチを一緒に考える。

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

チーム全体にリードタイム・サイクルタイムの概念を説明し、理解してもらう。また、タスクのつまみ食いは表面的な事象で、別の課題が隠れている可能性もある。たとえば、T 型のスキルセットになっておらず、実施できるタスクが限られているなど。そういった場合、ペア作業の導入が有効かもしれない。いずれにせよ、個別事象（タスクのつまみ食い）にこだわりすぎず、マインドセット、チームとしての目標、スキルやプラクティスといった様々な面からアプローチする。

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

スプリントの透明性の確保のために、そのようなアイテムはスプリントバックログに入れないのが望ましい。そのため、プロダクトオーナーにはそのアイテムを今スプリントに入れる必然性があるのかどうか、確認する。また、入れる場合のリスクも説明して理解してもらう。それでも入れるという判断をする場合、これは特殊なオペレーションなので、チーム全体としてそうすることの影響を理解し、試してみることへコミットした状態にする（注意: そうすることへの「完全な同意」や、そのアイテムを確実に届けることへのコミットではない）。そうしておけば、その結果への検査と適応がレトロスペクティブのときにやりやすくなる。

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

いくつかの戦略が考えられる。

• なぜ時間の無駄だと思うのかよく聞いて、対話する
• スプリントプランニングがチームにとってどのように役立つと見込まれるのか、よく説明する
• チーム全体でそもそもプランニングをやるべきか、どうやるべきか話す場を設ける
• ひとまず協力してくれないか、お願いする
• プランニングをやる・やらない（最小限にする）の両方を試してみることを提案する

おおむね上から順に試してみる。 チームの状態や相手の反応によって、対応を切り替えていく。

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

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

（「スタンドアップ」というのが日次の定期ミーティング、Daily Scrum のことだと想定して回答）
まずはやってみて、しばらくは続けてみることを薦める。
どんなチームにとってもリズムを作ることは重要で、スタンドアップによって日次のリズムを作ることができる。また、頻繁な検査・適応の機会があることで、さまざまな課題を見つけ、対処していける。

人数が多い場合、「3 つの質問」のようなフォーマットにはこだわらず、短時間で最大限の効果が得られるようなやり方を見つけ出していく必要はある。スタンドアップが難しいほどチームの人数が多い場合、そもそもチームの分割を行ったほうがよいかもしれない。

もちろん、達人揃いのチームで、既にスタンドアップよりもよい検査・適応の方法を編み出している場合は、無理強いはしない。（もっともその場合、そのチームは Scrum フレームワークにもこだわっておらず、ScrumMaster の役割も典型的なものとはだいぶ異なっていると想像される）

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

特にスタンドアップを待つことを期待はしない。スタンドアップはコミュニケーションを限定するものではなく、促進するものであり、スタンドアップがあることを理由に日常のコミュニケーション（を通じた透明性・検査・適応の実践）が妨げられてはいけない。（スタンドアップに使われるのではなく、スタンドアップを使う）
いま助けが必要なら、いま求めるべき。

もちろん、緊急性のない事項に関しては、即時ではなくスタンドアップや他の機会に共有してもかまわない。
そのあたりはチームのバランス感覚になるが、一般的に（必要以上に）スタンドアップを待ちがちになりやすいと思うので、そうなってしまっていないか、ScrumMaster が気を配っておくとよい。

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

その人は、なぜ報告セッションにしたいのだろう？　もしかしたら、それがミーティングのやり方だと思いこんでしまっているだけかもしれない。だとしたら、スタンドアップの目的を繰り返し説き、場合によってはリードを代わってもらって実践してみせる。チームメンバーにとってほしいアクションを伝えるような話し方を意識してもらったり、逆にあえて雑談をしてもいい。いわゆる進捗会議とは違うということが伝わるようにする。
それでも納得しなかったり、何か別の理由がある場合、その理由にチーム全体として向き合う。なんのためにスタンドアップをやるのかを考え、チームとしての答えを出す。

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

スタンドアップは短時間なので、それほど無駄だとは思われにくいはず。にもかかわらず無駄だと思われるなら、スタンドアップ自体に問題がある可能性が高い。スタンドアップが機能不全に陥っていないか。まずはそちらの可能性からアプローチする。と同時に、その人がスタンドアップを無駄だと思う理由にも注目して、対話する。その人個人にとってスタンドアップがどのように役立つ（役立ちうる）か、チームにとってはどうか、それぞれにフォーカスしながら話してみる。
なお、朝にスタンドアップをしている場合、遅刻については単純に朝が苦手な人の可能性もあるので、場合によっては時間の変更も検討する。「時間どおりに来るのが当然」と決めつけず、現実を見てチームにとって最善のやり方を模索する。

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

そもそも、変える必要があるとは限らない。ステークホルダーとのコミュニケーションは難しい問題だが、ステークホルダーの多忙度合いによっては、週次の Sprint Review で精一杯ということもありうる。無理をして毎日スタンドアップに参加してもらうことがよいとは限らない。

ステークホルダーにスタンドアップに参加してもらう合理性があり、かつ現実的に参加できそうということであれば、シンプルにその理由（合理性）を伝え、参加をお願いしてみる。おそらく何らかの理由で難しいということになるので、スタンドアップの時間帯を変える、日次ではなく隔日、等の選択肢も含めてチームとステークホルダーの折り合う場所を探る。

もっとも、そこまでするなら、スタンドアップにこだわらず、ステークホルダー専用の時間を設けるほうがよい可能性もある。原則としてスタンドアップはチームのためのミーティングなので。

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

タイムゾーンが同じであれば、音声ないしビデオでつなげば事足りる。音声や映像でつながった状態を保つことはチームの相互理解にも寄与するので、できればそうしたい。

タイムゾーンが異なる場合、どれくらい異なるかにもよるが、チャットの使用を検討したほうがよい可能性がある。おそらく、チーム専用の Slack チャンネルで各自定形の質問（「3 つの質問」のような）に答えてもらうようなかたちになる。https://geekbot.com/ のようなソリューションも役に立つかもしれない。

チーム自体が 2 拠点に分かれている（例: 東京に 5 人、大阪に 4 人）ような場合、拠点ごとにスタンドアップを行い、要点を Scrum of Scrums のようなかたちで共有し合う、という手もある。各拠点では通常のスタンドアップの感覚でやれる一方、離れた拠点のチーム全員の詳細はわからなくなるなど一長一短あるので、そのやり方が効果的かどうかには特に気を配っておく必要がある。

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

たとえば、以下のような構成が考えられる。

案 1

Todo	Doing	Done
...	...	...

案 2

PBI	Tasks	Doing	Done
...	...	...	...

案 3

Idea	Ready	Developing	Developed	Testing	Tested	Delivered
...	...	...	...	...	...	...

気をつけるポイントは以下。

• 個人ごとのレーンは設けず、アイテムごとにレーンを設ける
• Doing の列は狭く（WIP が増えすぎないようにする）
• 必要があれば、明示的に WIP 制限を設ける
• ただし、個人的には最初はシンプルなものから始めるほうが好みです。

ふりかえりについて

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

第一には、チームのためのものと考える。特に成熟していないチームには、心理的安全を保ちながらふりかえりを行える場が必要なので、はじめはチームの関心にフォーカスした方がよい結果を導きやすいと思う。

とはいえ、プロダクトオーナーが参加していけない、ということではない。プロダクトオーナーは参加しても黙っていてもらう、という手もあるし、悪影響が顕在化するまではチーム全体のすることに任せるという手もある。
逆に、プロダクトオーナーが明らかにふりかえりの場でのチームの心理的安全に悪影響を及ぼしているようであれば、プロダクトオーナーに丁寧に説明し、ひとまず不在にしてもらう、というケースも考えられる。

全体の流れとしては、顧客をはじめとするステークホルダーやエンドユーザのことまでを考えたふりかえりになるのが理想なので、時間がたつにつれてプロダクトオーナーまでを含めたふりかえりにしていけると望ましい、と考える。

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

チームの健全性には日々気を配るが、ふりかえりはよいタイミングなので、確認しておきたい。指標としては、遅刻、欠勤、残業時間、ふりかえりの場での発現頻度・長さ・内容、ふりかえりに臨む態度、メンバー同士の関係性、ふりかえりの話題におけるよいこと・悪いことや、技術的なこと・それ以外のことの割合等に注目する。スナップショットではなく、中長期的な推移にも気を配る。
テクニックとしては、チェックインで今の気分を言ってもらったり、ふりかえりのフォーマット自体を気分にフォーカスしたものにする、普段から記録をつけてもらい（例: ニコニコカレンダー）それをふりかえりの場にも持ち出す、等が考えられる。

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

基本的に、「場を設定する、データを収集する、アイデアを出す、何をすべきかを決定する、レトロスペクティブを終了する」の 5 フェーズでデザインする。

主要なプラクティスとしては、週次のふりかえりでは KPT、よかったこと/モヤモヤすること/嫌なこと、スターフィッシュ（KPT 進化版）等。

プロジェクト等中長期のふりかえりでは、タイムラインを使うことが多い。

それぞれのアクティビティについて、大きく分けて各自黙って付箋やホワイトボードに書いてもらう時間をとるスタイルと、声に出してもらってファシリテータが書き留めていくスタイルがある。前者の方が効果的な場合が多いが、そういったワークを好まない人がいそうな場合や、試してみる目的で、あえて後者にしてみることもある。

データの収集においては、できるだけ客観的な事実をすばやく思い出せるよう工夫する。過去には、チームボードのスナップショットをプリントアウトして張り出したり、チームの日記を張り出したり、日付で区切られたチームボード（チームの Sprint における活動の記録がそのまま貼り出されている）自体の前でふりかえりを行ったりしたことがある。

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

ゴールを共有した一体感のあるチームだと、たしかにマンネリになってくることがある。そういうときは、あえてゴールに直接はあまり関係ないことを試してみる、イベントの進め方もちょっと変えてみる（ファシリテーターを変える、プロセスを変える、等々）、イベントに普段は呼ばないゲストを招いてみる、といったことをやる。

そういう「ちょっと試してみる」ことをやりやすいように、スプリント期間はできるだけ短いほうがよい。

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

なぜ行動できていないのかにもよるので、観察から自分なりに原因を見極めると同時に、チームになぜできていないのか、できていないことに対してどう考え、どうしたいか考えてもらう。場合によっては、実際に行動できるよう自ら手助けするのもよいかもしれない。たとえば、進捗の確認（「やってないようですが、やらなくて大丈夫ですか？」といったキュー出しのようなこと）を行ったり、アクションアイテムをプロダクトバックログに含めるよう PO とも協働したり、といったことが考えられる。

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

アクションアイテムが SMART になっていれば、その指標にもとづいて適宜確認するとよい。タイミングとしては、Daily Scrum や Retrospective などがちょうどよい。遅くとも Retrospective では必ず前回のアクションアイテムのふりかえりを行うようにする。
達成できていた場合、さらによくするための追加のアクションがあるかを考え、あれば行うし、なければいったんチームとしてのフォローアップは終わりにする。（とはいえ、重要なアクションであったり、継続性に不安がある場合、スクラムマスターで独自に追跡するのもよいかもしれない）
達成できていなかった場合、アクションの有効性（今でも妥当なアクションか）や達成できなかった原因をチームで調べ、継続・変更・廃止などの、次のアクションにつなげていく。