スクラムマスターとプロダクトオーナー。チームがうまくいく動き方は？ ─ ”とはいえ”シリーズ #5「スプリント編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第5回のテーマは「スプリント」です。後編では、「要件定義スプリント」や「リリース前テストスプリント」についての考え方や、スクラムマスターとプロダクトオーナーのチームとの関わり方についてお話します。

前編はこちら

スクラムガイドについて

スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。

「スプリント」について

「スプリント」について、スクラムガイドにはこのように解説されています。

スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。
一貫性を保つため、スプリントは１か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。

スプリントでは、

スプリントゴールの達成を危険にさらすような変更はしない。

品質を低下させない。

プロダクトバックログを必要に応じてリファインメントする。

学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。

スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも１か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。
スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。

出典：スクラムガイド

…とはいえ、実際の現場ではガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。

話し手

中村洋　Yoh Nakamura

株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
※発表資料「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。

新井剛　Takeshi Arai

株式会社レッドジャーニー取締役COO
CSP(認定スクラムプロフェッショナル)、CSM(認定スクラムマスター)、CSPO(認定プロダクトオーナー)
プログラマー、プロダクトマネージャー、プロジェクトマネージャー、アプリケーション開発、ミドルエンジン開発、エンジニアリング部門長など様々な現場を経て、全社組織のカイゼンやエバンジェリストとして活躍。現在はDX支援、アジャイル推進支援、CoE支援、アジャイルコーチ、カイゼンファシリテーター、ワークショップ等で組織開発に従事。勉強会コミュニティ運営、イベント講演も多数あり。
Codezine Academy ScrumBootCamp Premium、機能するチームを作るためのカイゼン・ジャーニー、今からはじめるDX時代のアジャイル超入門講師
著書「カイゼン・ジャーニー」、「ここはウォーターフォール市、アジャイル町」、「いちばんやさしいアジャイル開発の教本」、「WEB+DB PRESS Vol.111 見える化大作戦特集」

「要件定義スプリント」や「リリース前テストスプリント」のように、○○だけするスプリントってない？

新井：
スクラムの教科書には反するかもしれませんけど、プロダクトゴールを見据えた上でフィードバックがもらえるのであれば、一時的な「要件定義スプリント」や「リリース前のスペシャルテストスプリント」をチームの判断でするのは問題ないんじゃないでしょうか。

ただ、単なるフェイズの区切りとしての「要件定義スプリント」には反対です。

中村：
プロダクトをつくるためには、ある程度骨格を決めないといけませんから、要件定義と言われるものを2〜3週間やることはよくあります。

そのときに気をつけたいのは、「要件定義はし続けるもの」ということです。
要件って一度決めたら変えてはいけないというものではないし、常にフィードバックが発生しながら変わるものだということを前提に置いておかないと、一時的なフェイズに詰め込んだりして、がんばりすぎちゃうような気がします。

新井：
そうですよね。要件定義のフェイズですべて決められたら良いけど、実際は決められないし、スプリントを回していくうちにいろんな情報が得られて解像度がどんどん上がっていくので、一時的に作り込みすぎちゃうと無駄が発生することもあります。その辺はもったいないかな。

中村：
「リリース前テストスプリント」も、「最後にテストするからこれでいいよね」となってしまうと、リスクを先延ばしすることになるのであまり良くないですね。
そこに至るまで自動テストなどで品質がある程度担保されていて、その上での最終チェックならいいんですけど。

新井：
リスクの先延ばしっていうのは良い表現ですね。

中村：
「この二週間はユーザーインタビューしまくろう」っていうような時間の使い方を、チームが意思決定することもありますね。

新井：
ビルの外に出て情報を得に行くっていうことですね。そういうところにプロダクトの価値を高める本質が隠れていたりするので、大事です。

中村：
「リリース前テストスプリント」の後に「バグ修正スプリント」っていうのも時々見かけますが、そうではなくスプリントごとにテストをして、バグを発見したら次のスプリントで必要に応じて倒すようにしたいですね。

そもそも、バグだから全部直さないといけないというマインドは見直した方がいいんじゃないかなと思います。

参加者コメント：
集中的にリファクタリングするスプリントとか？

中村：
コメントありがとうございます。
私としては、こういうのも基本的にはプロダクトバックログに入れておきたいところです。
プロダクトオーナーが中心となって、適切な時期にスプリントに投入するようにしましょう。
その結果として、集中的にリファクタリングするスプリントができるのは問題ないと思います。

Message from coaches

フィードバックとプロダクトゴールをきちんと押さえているなら、一時的な「イレギュラースプリント」もOK。
要件定義はし続けるもの。どんどん解像度が上がっていくので、最初から作り込みすぎないようにしよう。
「リリース前テストスプリント」をする場合でも、リスクを先送りせず都度自動テストなどで品質を担保しておこう。
バグ修正やリファクタリングは、適切な時期にバックログに入れて取り組もう。

スプリントごとに予測可能性が上がることは嬉しいけど、とはいえ、日々の活動に集中しがち

新井：
人間の心理的に、タスクを追いかけたくなるのは分からなくもないです。

中村：
自分のタスクを減らすことにフォーカスしすぎず、意識的に自分たちを俯瞰して見る時間を持てるといいですね。そのためのテクニックが必要です。

新井：
スプリントゴールを達成できそうか、もっといい方法がないか、みんなで話し合ったり考えたりする機会として、デイリースクラムを活用できたらいいですね。

あと、スクラムガイドにもありますが、スプリントレビューのタイミングでプロダクトゴールが達成できそうかを話し合うような時間はすごく大事かな。赤、青、黄と信号になぞらえてみるのもいいですよ。

中村：
「ちょっと目線を上げて遠くを見てみない？」ということを、スクラムマスターが伝えるのもいいですよね。それがスクラムマスターの役割でもあります。

とはいえ、スクラムマスター自身も日々の活動に集中してしまっていることが多いのでしょうか。

新井：
スクラムマスターとしての経験も、ある程度必要なのかもしれませんね。

スクラムマスターとプロダクトオーナーが、例えばスプリント前の30分くらいの時間を使って、予測可能性を高めることやプロダクトゴールについて雑談的に話せると理想かな。
そういうことができているチームは、運営がうまくいっているなと感じます。

中村：
フォーメーションとしては、スクラムマスターはチームが俯瞰的な視点で見られるように促す役割で、プロダクトオーナーはプロダクトゴールやインクリメントが健全な状態かどうかを話し合える環境を作る、という感じでしょうか。

Message from coaches

スクラムマスターを中心に、自分たちを俯瞰して見る時間を意識的に持とう。
スクラムマスターとプロダクトオーナーは、予測可能性やプロダクトゴールなどチームの全体像について定期的に話す機会を持とう。

1 2