スクラムチームが自信をもってアウトカムとスプリント活動に集中するためのコツ

講演資料

#RSGT2023 での講演資料です。再演のご依頼などお気軽にご連絡ください。

社内やイベントなどでの講演や、書籍・記事・社内報などでの執筆を承ります。まずはお気軽にご連絡ください。

簡単解説

軽く補足をしておきますが、今回本編では「カンバン」という言葉も文字列も使っていません。これはあくまでスクラムでのスプリント活動とアウトカムへの貢献が主だからですが、愚直にカンバンのプラクティスを実践するというのが良いというわけでないという暗示的なものでもあります。What/How→Who/Whyになり、柔軟性がないままにカンバンのプラクティスを採用すればいいというわけではないからです。また、カンバンガイドにある用語と言葉を変えている点については、カンバンガイドにて、用語は現場に合わせて使えばよく、コンセンサスがとれていればよいという旨が書かれており、現場が一番わかりやすい言葉を用いているため、セッションでも現場の言葉を用いました（極端な例: WIP制限→トランキーロ）。

補足記事

複雑さの歩き方

複雑さがある世界でものを作り続けたり、問題を解決するにはどのようなアプローチがよいのでしょうか。私は、Cynefin Framwork (クネビンフレームワ...

いただいた質問に対する回答（一部）

PBI=アウトカムでしょうか

いいえ、PBIはプロダクトゴールに対する仮説です。仮説はリリースし、検査しはじめて価値があるかがわかります。アウトカムとは、顧客やユーザーの成果です。エビデンスベースドマネジメント（EBM）では、「現在の価値」（CV）として「顧客やユーザーは幸せか？」という問いを例に示しています。漠然とした問いに感じるかもしれませんがそうではありません。幸せかというのは、明確な理由と根拠が必要となります。アウトカムとはそういうものです。ちなみに、PBIの一つ一つに対して価値があるか、アウトカムを提供できているかの検査はあまり意味がないことが多いです（手間がかかりすぎる割に十分に検査できない）。アウトカムを提供できているかは、インクリメント（≒現在提供しているプロダクトそのもの）で検査すべきです。インクリメントは、プロダクトゴールへの踏み石なので、スプリントレビューで今まで提供できているアウトカムとこの後提供できそうなアウトカム、そして今後のスプリントでの仮説（PBI）の検査と適応を行うイベントです。

余談ですが、アウトカムを意識したPBIを作りには、インパクトマッピングをひとつの方法としておすすめします。ただし、インパクトマッピングそのものではなく、アウトカムを交えた拡張インパクトマッピングを強くおすすめしています。アウトカム（の仮説です）を意識することでPBI（の仮説です）をより鮮明にできますし、仮説の検査にも活用できます（仮説が間違っていたという気づきの価値もあります）。

スプリントでは、一つのPBIを開発するスタイルでやっていましたが、複数のPBIを開発することがあるのでしょうか

スクラムでは、通常、スプリントゴールを設定し、そのゴールを達成するためのPBIを候補に挙げていきます。したがって、必然的にPBIを複数組み合わせてゴールを目指すことになります。また、ゴール達成のためのPBIが一つであったり、少数であり、スプリントの期間（固定長）に余裕があるならば、他のPBIも選出してもいいですね。ただ、ゴール達成は最優先とすべきです。また、他のPBIを選出する際は、おそらくレトロスペクティブででた改善活動、そして、技術的負債やインペディメント（障害物）の除去、バグなどの欠陥の修正が選出されることも多いです。

講演では、１スプリントで１つのPBIを作れるようにすることを最優先しましょうと話をしました。背景は、スプリントを盲目的にトレンド通りの1週間や2週間に設定して、それなのに、一つのPBIすらスプリント内で終わらないということが多いからです。講演では時間の都合でいろいろと解説を意図的に省いたのですが、１スプリントで1つのPBIを作れるようにするためには、そのPBIに集中できることもとても大切ですが、そのための共同作業の仕方の模索や、次のスプリント以降のためのリファインメントにとても時間を使うことがありえます。また、スプリントが1週間であろうと、2週間であろうと必要ならばスプリントプランニングに最大時間の8時間を要してもいいのです。大事なのは何を成し遂げたいかです。

チームのメトリクスは、数値化されないといけないのですか: そんなことはありません。定性的なものはとても大切です。ただし、定量化できるものも大切です。どちらか一方あればいいという話ではないです。チームの中だけを見ればまず定性的なものがあると立ち上げや改善意欲につながります。内発的動機を絶やさないために定性的なものを測ることは重要です。しかしながら、チームの外からは定量的なものを求められます。そして、チーム内でも本当はより客観的なデータを求めています。経験的アプローチでは客観的なデータと観察により意思決定していくことが多くなるからです。したがって、定性的なもの、定量的なもののどちらも必要となります。今回の講演では、負担なく定量的なデータを収集できる点で、サイクルタイムとWIPを測ることとそれで得られるヒントについてお伝えしたにすぎません。
参考: アジャイルメトリクス〜良い指標・悪い指標・酷い指標

PBIだけでなく、（PBIの）タスクのサイクルタイムやWIPも測った方がいいでしょうか: タスク自体は、アウトカムや価値に直結しないので、まずはPBIの単位で十分です。もしタスクまで測らないといけない事態だとしたら、きっとそれはサイクルタイムやWIPを測ったり、WIP制限したりする以前に何をするべきなのかがチームで足並み揃っていなかったり、計画のために作業してしまっているのかもしれません。測りたいのは、価値につながるかどうかであると捉えると、タスクまで測る必要があることは少ないと思われます。

ストーリーポイントとベロシティではダメなのでしょうか

ダメではありません。何のためにストーリーポイントを用いて、何のためにベロシティを記録しているのかですし、そこから何を学びたいのかが漠然としているならば、一度立ち止まって考えてみてください。

講演では、「（ポイントを用いた）プランニングポーカーはリファインメントで大きさの予想をすること、そこでもっている各メンバーのインサイトを共有できることは価値があるけど、スプリントや先の予測に使わない方がいいかも」と言及させていただきました。意図は、ポイントは相対的な見積もりにすぎず、それはアウトプットのためのものだからです。ポイントが大きければ価値が高いわけではないのに、大きな数字のものを選択してしまったりすることがあるからです。例えば、ベロシティの平均が18ポイントのチームがあったとしたときに、（スプリントゴールに関連しているが大前提ですが）11のPBIと、5のPBIが2つと、3のPBIが4つあったとします。ポイントが大きい方がよいと捉えてしまうと、11+5+3の合計3つのPBIを選択してしまうかもしれません。その結果、11のPBIに苦戦したことで、そのスプリントで価値を一つも提供できなくなってしまうこともあり得ます。3*4+5*1の合計5つのPBIを選択していたら、少なくとも1つの価値は提供できたのかもしれません（そう言い切れるわけではないですが）。そのため、ポイントをベースにしていると数の大きさに惑わされてしまうことがあります。『あと何スプリントで、このPBIは完成するの？』といったステークホルダーからの問いに対しても、プロダクトバックログの優先順位とポイントで見てしまうと、大きなポイントの振り幅の大きさを無視して、「６スプリント目で提供できます！」とか言ってしまいそうになります。それよりも、READY（準備完了な）なPBIの個数で予測を立てる方が建設的ではないでしょうか。

せっかくストーリーポイントを使っているので進捗もポイントで測りたい: ダメではありませんが、支援先ではおすすめしないことの方が多いです。理由は一つ前のQ&Aと同様で、ストーリーポイントはPBIの主観的なサイズを示しているに過ぎません。アウトプットのための指標です。特にストーリーポイントでバーンダウンチャートを運営するのは規模の大きなものに気を取られがちであり、進捗を十分に把握したいのであれば、それは不向きです。ちなみにバーンダウンチャートは終わった作業の可視化に使えるのはもちろんではありますが、「チームがあとどれくらいスプリントゴールに向かって作業できるのか」を知るのが一番効果的です。残された時間でより価値に繋げることが大切であり、スプリントプランニングで立てた計画どおりにすることがスプリントの目的ではないからです。

WIP（仕掛かり中の作業）をどう測ったらいいか

WIPは、着手しているがまだ終わっていない作業を指します。今回のコンテキストでのWIPはPBIに適用します。PBIのタスクに対して適用しない理由は先のQ&Aの通りです。

「着手」と「終わっていない」はカンバンでは、「開始点」と「終了点」と表現します。したがってWIPは、開始しているが、「終了点」に到達していない作業の個数です。

例えば、そのスプリントで10個のPBIを完成させたいとします。この10個のPBIをスプリントの開始と同時にすべて着手しはじめたら、WIPはいきなり10になります。完成したPBIが1つでれば、WIPは9になります。WIPとサイクルタイムの関係性としては、WIPがあればあるほど、サイクルタイムは長くなる傾向があります。これはリトルの法則からも十分わかりやすいです。リトルの法則とは、「サイクルタイムの平均＝WIPの数の平均 / スループットの平均」です。分子がWIPなので、多ければサイクルタイムは延びます。また、スループットはすぐに改善できるものではないですから、その点でもWIPを減らす、適切な量に制限することはサイクルタイムの短縮につながるので、とても戦術として理にかなっています。

では、WIPをどうはかるのかというと、デイリースクラムなどでその時のWIPを数えればいいです。または、タスクボードを使っているならば、それで着手して完成していないPBIの数を数えればいいです。それらを記録しておけばいいです。講演では、累積フロー図（CFD）を紹介しています。この図があれば、任意の日付のWIPを容易に把握できます。

長沢智治

講演・執筆承ります

社内やイベントなどでの講演や、書籍・記事・社内報などでの執筆を承ります。まずはお気軽にご連絡ください。

連絡する

フィードバックのお願い！

フィードバックもぜひいただきたいです。

フィードバックもぜひいただきたいです。感想、チームで共有してみた反応、チームでやってみた実情とかとか。 #RSGT2023
— 長沢智治 Tomoharu Nagasawa (@tnagasawa) January 11, 2023

本記事の執筆者:

長沢智治 - アジャイルストラテジスト

サーバントワークス株式会社代表取締役
プロフェッショナルスクラムトレーナー（PST）《日本人初》
Agile Kata Pro 認定トレーナー《日本人初》
DASA 認定トレーナー（プロダクトマネジメント、DevOps）

認定トレーナー資格

『EBM実践ガイド』「プロフェッショナルアジャイルリーダー』『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など翻訳・監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール