スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた

──今日は、若いエンジニアの方々がスクラムマスターになるためのノウハウについてお伺いしたいと思います。まずはスクラムがどういうものなのか、教えてください。

吉羽　アジャイル開発にはカンバンやエクストリームプログラミング（XP）など、いろいろなやり方があり、その中の1つの手法がスクラムです。ある調査では、アジャイル開発に携わる人のうち、7割くらいが何らかの形でスクラムを使っていると回答しています。

──7割ですか、すごいですね。

吉羽　アジャイル開発をやるとなると、最初に選択肢に挙がるのがスクラム、と言えるほどに一般的な手法でしょう。では、スクラムってどんなものかというと、『スクラムガイド』というドキュメントで定義されています。ここには、こんなことが書かれています……「軽量・理解が容易・習得は困難」と。

『スクラムガイド』における定義そのものはコンパクトで決めごとはそんなに多くない。スクラムでは何が決められているかというと、役割が3つ、イベントが5つ、作るものが3つ。3・5・3、これだけなんです。

▲以降、吉羽さんによる詳解があるが、スクラムガイドで定められた、役割、イベント、作成物は上記サマリー資料の通り。拡大、ダウンロードなどして参照してほしい。

【スクラムの基礎知識】3つの役割を理解する

──3・5・3ですか。分かりやすくていいですね。「3つの役割」とはどんなものなんですか？

吉羽　プロダクトオーナー、開発チーム、スクラムマスター、これが3つの役割です。

まずプロダクトオーナーが何をするのかというと、プロダクト・製品の持ち主で、「自分たちがどのような製品を作るのか」をリードします。プロダクトを作ろうとすると、やりたいことはたくさん出てきますが、お金も時間も限られているので、全部はできません。なので、どれをやる・やらない、何を先にやるかといったことを誰かが決めないといけない。それを担うのがプロダクトオーナーの主たる役割です。

ときに、外部の方から製品に対してさまざまな注文が入ることもあるでしょう……。その人たちとあらかじめ調整をしておいたり、場合によっては指示・指摘に反論したりといった、ステークホルダーマネジメントもプロダクトオーナーの重要な仕事です。

──なるほど、次に登場する開発チームは……その名のとおり開発の担当ですよね。

吉羽　製品のWhat（なにを作るか）やWhy（なぜ作るのか）を扱うのがプロダクトオーナーの仕事とすると、このWhatを形にする、つまりHow（どう作るのか）が開発チームの役割です。一般的に3～9人で構成されることが多いですね。設計から開発、テスト、リリースまで、スクラムの場合はすべて1つのチームでやります。

──では、スクラムマスターはどのような役割を担っているのでしょうか？

吉羽　スクラムマスターは、“スクラム”の仕掛けがうまく回るように何でもやる人、開発のプロセスに対して責任を持つ人です。例えばスクラムをやり始めたばかりのチームだと、「スクラムってこういうものですよ」と教えるのも仕事になりますし、後述するイベント・会議をファシリテーションしてみたり、プロダクトオーナーと開発チームが対立したら仲裁してみたり……、と、スクラムをうまく回すために、一歩引いて、全体を見てあげるのがスクラムマスターです。

【スクラムの基礎知識】5つのイベントを理解する

──次は実際の進め方ですね。「5つのイベント」ではそれぞれ、どんなことをするんですか？

吉羽　イベントと表現すべきか難しいですが、1つ目のイベントとして定義されているのがスプリントです。アジャイル開発では1週間や2週間など、一定の時間で区切って開発を繰り返します。このひとつの開発期間をスプリントといいます。残りの4つのイベントは、全部スプリントの中に入ります。スプリントはコンテナのようなものなんです。

──スプリント内ではどんなイベントを実施するのですか？

吉羽　アジャイル開発ってよく「ひたすらコード書きまくるんでしょ？」とか「設計もしないんでしょ？」みたいに言われます（笑）。しかし、実際はスプリントをどう過ごすのか、きっちり計画を立てるんです。それが、スプリントの最初におこなうスプリントプランニングで、「今スプリントでは何をやるのか」「どうやるのか」といった話をします。

その後、開発に入りますが、「あとよろしくね」と任せっきりにするわけにもいきません。スプリントの最終日に、「実は全然できてません」となったらまずいですよね。なので、このまま進めて大丈夫なのかチェックするデイリースクラムを毎日おこないます。ゴールの達成が厳しい……と判断したら、軌道修正をしたりスコープ（やるべきことの範囲）を調整したりといった対処を取ります。

──毎日定点チェックをするわけですね。

吉羽　そうです。スプリントの最後の日には、スプリントの成果を確認するスプリントレビューが待っています。これはチームの中だけでレビューをするのではなくて、上司や営業担当といったステークホルダーを呼んで、スプリントの成果をレビューします。

なんのためにするのかというと、フィードバック受けるためです。気に入ったか・気に入らないか、もっとこうしたらいいんじゃないのとか、そもそも作ったものは利用者の問題を解決しているんだろうか……そういうようなことを議論します。

──最後、5つ目のイベントが残っています。

吉羽　スプリントの最後にやるのスプリントレトロスペクティブという、舌をかみそうな名前のイベントです（笑）。「振り返り」とも呼ばれますが、直近の期間を振り返って、自分たちのやり方がよかったのか悪かったのか、悪かったのならどこを改善すると次のスプリントをもっとうまく進められるのかといったことを話し合います。

【スクラムの基礎知識】3つの作成物を理解する

吉羽　残りの3つが「作成物」といわれているものです。これは「成果物」ではなくて「作成物」と呼ぶことに注意してください。

作成物でまず用意しないといけないのが、プロダクトバックログです。「これを作りたい」「あれは絶対にないとまずい」といった機能性の要求をまとめたもので、要は“やりたいことのリスト”です。重要なものから上から順に並んでいて、よくエクセルに表としてまとめていたりしますね。

いわゆるウォーターフォール型の開発だと、最初に要件定義をし、製品のゴールを決め、見積もりをして、発注するという形で進めます。一方、アジャイル開発の場合は、フィードバックをもらって、場合によっては途中でリリースするかもしれないし、製品のゴールが変わる可能性もある。ですから、初期のプロダクトバックログが、フィードバックや競合製品の影響で、「やっぱりあれもやろう」と項目を追加したり「これはいらない」と削除されたりもします。

──開発期間中、プロダクトバックログは常に変わっていくんですね。

吉羽　はい。そして、プロダクトバックログの中から“今回のスプリントで何をやるか”をスプリントプランニングで決めます。また、開発チームは抽出された項目を見て、具体的なタスクに分解します。ここで生まれた「このスプリントでやること」のリストが2つ目の作成物にあたるスプリントバックログです。 最後、3つ目の作成物はインクリメントです。これは分かりやすくて、プロダクト開発ならソフトウェアです。開発者の方はお分かりかと思いますが、インクリメントという言葉には“1増やす”という意味があります。時には「この機能はいらん！」と削除することもありますが……。

──スクラムで決められていることってこれくらいなんですね。たしかにこれは理解するのは簡単かもしれません。ただ、具体的にどうしたらいいの？という疑問も湧いてきます。

吉羽　そうでしょう。スクラムガイドには枠組みは書いてあっても、具体的な方法は書いてありません。スクラムガイド自体も、数年にごとに更改されていますが、「ちょっとHowっぽいよな」といった箇所は徐々に削られています。それだけに、実際にやろうとしたときに、「で、どうやるの？」といった疑問がついて回る。そこが難しいところなんです。

スクラムを“現実的に”実践する手法

見積もりは誰のもので、誰が作るのか

──では、スクラムを進める上での具体的なToDoについてお伺いしていきたいと思います。まずはプロダクトバックログと見積もりですよね。プロダクトバックログを作るのはプロダクトオーナーの仕事なのでしょうか？

吉羽　プロダクトバックログの最終責任者はプロダクトオーナーですが、見積もりの責任者は開発チームです。実際に開発をしない人が見積もった数字は、見積もり通りにはなりませんから。ですから、アジャイル開発では原則として、プロダクトの制作を担当する開発チームが見積もります。そして開発チームが出す見積もりに対して、プロダクトオーナーは原則的に口を出すことはできません。

──そうなんですね！

吉羽　もちろん、「ちょっと見積もりが大きすぎるんじゃない？」と相談することはできますが、「やり方は変えずに、その内容を半分の時間でやれ」といったことは言えない。開発チームは自分たちの能力に基づいて見積もっているので、尊重されないといけないんです。

ただ、「見積もりが大きすぎてビジネスの観点から無理がある」こともあるでしょう。そういうときはプロダクトオーナーと開発チームで相談して、別の手やなんらかのソリューションを考える必要があります。とにかく、理由もなく半分の時間でやってくれ、半分の金額でやってくれとなんてことを言ってはいけない。これが重要です。

フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法

──スクラムならではの見積もりの作り方はありますか？

吉羽　アジャイル開発では「経験主義」といって「やってないことは分からないし、将来のことは約束できない」という考え方が基本です。なので、開発中に何度も、スプリントごとに見積もります。

最初にプロダクトバックログを見ながら、各項目にどれくらいの時間がかかるかざっと見積もりを作って、だいたいの規模感を推定しますが、それはあくまで推定にすぎず、決して“約束”ではありません。で、何度かスプリントをやってみて、開発チームの力量や要素技術の使い方、過去の実績などの情報が増えてくれば、どんどん正確な見積もりに更新していけるわけです。

──毎スプリント、見積もりを見なおすって大変じゃありませんか？

吉羽　頭から最後まで全部見なおすのは大変なので、必要な箇所だけ見積もるのがポイントです。プロダクトバックログは上から順番に重要な項目が載っていて、逆に言うと、下のほうにあるのは優先度が低く、やるかどうかさえ分からない。

一方、上のほうにある項目は、次のスプリント、次の次のスプリントで取りかかるので、中身がある程度具体的になっていないと、すぐに「何やればいいんだっけ？」となてしまいます。そうならないように、バックログリファインメントという手入れを定期的に実施します。これは直近でやりそうな項目を重点的に見なおす活動で、中身を見なおしてみたり、項目が大きすぎる場合は分割したりします。バックログリファインメントのタイミングで見積もりも見なおすことが多いですね。

──見積もりにはやはり人月や人日といった数字を使うんですか？

吉羽　スクラムでは見積りに使う単位は決められていませんが、私は人月や人日といった数字は使いませんね。見る人によって、1人日がどのくらいのタスク消費量なのか解釈が異なる、いわば一人歩きしやすい指標だからです。それに、チームの成長を見込んだ数字でもありません。アジャイル開発は同じチームでずっとやるんで、同じタスクをやるにしても、最初のスプリントでかかった時間と、10スプリント後でかかる時間は違ってくるはずです。人日や人月にすると、そこって見えづらいんですよね。

──では、具体的にどういう数値を見積もりで使っていますか？

吉羽　チームが1スプリントで作れる量は「ベロシティ」というポイントで表します。プロダクトバックログの各項目の作業量をポイントで表して、その合計が全体の見積もりとなるわけです。

以前は1，2，3，5，8，13……といったフィボナッチ数列をよく使っていたんですが、最近ではそんなに細かくポイント設定しません。「Tシャツ見積もり」と言って、S，M，L，XLみたいな感じで、数パターンに分けてポイント換算する、そんな感じでラフにやることも増えていますね。

──タスクのサイズが4つしかないんですね。それで正確に見積もれるものなんですか？

吉羽　アジャイルの見積もりは、極端に言えば「どうせ外れるよね」という考え方です。だから見積もりに過剰に時間をかけても仕方がない。すばやく見積もって、新しい情報が入ったらもう一度見積もることが重要で、そのために素早く判断できるTシャツ見積もりを使っているんです。

──規模が大きくなればなるほど、誤差が大きくなるものですしね。

吉羽　あと見積もりで大事なのは、開発チームが作れそうかどうかを判断できるか、です。直近のスプリントで作るものは、開発チームのメンバーが見て「こうすれば作れる」というところまで、中身がきちんと理解できるかどうかが重要なんですよね。

──見積もりは、開発チームの中で担当者を決めて作ったりするものなんですか？

吉羽　僕は開発チームの全員でやるべきだと思っています。「ベテランじゃないと分からないから」といって属人的に進めたら、若手はタスクの中身がよく理解ができず、言われたとおりの作業をするしかなくなってしまいます。開発チーム全員の見積もり感覚を集約するのは、最初は大変ですけど、若手が理解できるようにしていくためにも、見積もりをみんなでやる必要はあると思います。

スプリントの期間は1週間が計画しやすくておすすめ

──見積もりが完了したら、スプリントに入って実際に開発をしていくわけですよね。スプリントには4つのイベントが含まれるというお話でしたが、それぞれのイベントにどれくらいの時間を配分すべきか、お教えいただいてもよろしいでしょうか？

吉羽　スクラムガイドでは「タイムボックス」という考え方を示していて、各イベントにあてるべき時間もしっかり定義されています。スプリントは最大4週間。スプリントプランニングは5％。デイリースクラムは何があっても1日15分ですね。スプリントレビューは、スプリントプランニングの半分の2.5％。スプリントレトロスペクティブは3時間以内で、スプリントの時間が短くなれば、それに応じて短くする。

──スプリントの期間は1～4週間の間で幅がありますが、どれくらいの期間を採用することが多いでしょうか？

吉羽　僕は1週間スプリントでやることがほとんどです。スクラムを初めて経験するお客さんには、必ず「1週間でやろう」と提案しています。1週間スプリントの場合だと、スプリントプランニングに2時間、スプリントレビューに1時間、スプリントレトロスペクティブに1時間、といった時間配分でやることが多いです。あとはバックログリファインメントに4時間くらいは使っています。

──1週間をおすすめするのはなぜなんですか？

吉羽　フィードバックサイクルが早くなるのがいちばんの理由です。また、そもそもの話として、“長い計画”を立てるのって難しいんですよ。例えば1週間の献立を考えることができても、1カ月ぶんの献立を考えるのは大変です。1週間と短めに設定することで、1スプリント内で対応すべきプロダクトバックログの項目数も減り、計画が立てやすくなります。もう1つ、1週間ってリズムがすごくいいんです。毎週同じ曜日に同じイベントがあるんですよ。

──なるほど。月曜日にスプリントプランニングをして、金曜日にスプリントレトロスペクティブがある、といった具合ですね。

吉羽　そうです。身体にリズムが染み込みやすいし、「今スプリントはペースが遅い」といった異常にも気付きやすいといったメリットがあります。

スプリントプランニングの極意。タスクの粒度は小さければ小さいほど扱いやすい

──最初のイベント、スプリントプランニングを始めるときの注意点を教えてください。

吉羽　リファインメント（プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすること）や準備が不足した状態でスプリントプランニングに入ってはいけない、ということですね。準備不足だと、タイムボックスを守れなくなります。本来、スプリントプランニングは2時間で終わらせなければならないのに、「半日かけても終わらない、翌日続きを……」みたいなことになりがちです。

──こういう事態を避けるために、スクラムマスターはどうすべきなのでしょうか？

吉羽　プランニングをうまくやろうと思ったら、事前にプロダクトオーナーに「プランニングの準備していますか？」と一言アテンションするだけで違います。スクラムチームにも、「プロダクトバックログ、リファインメントしていますよね？」とか、「プロダクトバックログの上位項目、準備完了していますか？」といった確認を、常日頃からやっておくとスムーズに進みます。

あと、開発チームはどうしてもタスクや仕様の細部が気になりがちです。プランニングでのコミュニケーション粒度が細かくなりすぎているようだったら、スクラムマスターは、「その話題はあとで開発チーム内で詰めよう」と促すことも、初期の段階では重要です。

──プロダクトバックログのリファインメントで、“ここだけは押さえておけ！”というポイントはありますか？

吉羽　「開発が始まってから何度もプロダクトオーナーに質問しなければならない状況を避けろ」と、僕はよく言っています。とはいえ、すべてを微に入り細に入りリファインメントするのは不可能ですし、時間の無駄です。「おおよそできそうかな」とみんながある程度自信を持てるぐらいまでの案配が目安ですね。

──スプリントプランニングでは、プロダクトバックログから今回のスプリントでやるべき項目をいくつか取り出し、それを具体的なタスクに洗い出して、スプリントバックログに落とし込んでいくんですよね。ただ、洗い出すタスクの粒度は、プランニングする人によってばらつき生まれるように思います。認識をそろえるためのコツはあるのでしょうか。

吉羽　“仕事するうえで、いいタスク”の特徴は「SMART」というに頭字語に集約されます。SMARTとは……

• S ＝ Specific：やることは具体的であれ
• M ＝ Measurable：「測定可能」という意味。終わっているかどうかが判断できるものであれ
• A ＝ Achievable：保有スキルで達成可能であれ
• R ＝ Relevant：「目標に関連した」という意味。プロダクトバックログの実現に関連するものであれ
• T ＝ Timeboxed：「時間の枠が決まっている」という意味で、作業時間がきちんと見積もられている状態であれ

こうしたキーワードの頭文字をとったものです。このSMARTを大事にしよう、と私はよく伝えます。

──開発チームがタスクを洗い出すときは、この5つの観点を意識してもらうように、スクラムマスターは促すというわけですね。

吉羽　そうです。もう1つ、タスクは粒度が小さければ小さいほど扱いやすいんです。タスクが1時間くらいのボリュームで、“何をやったら終わり”なのか明確になっている状態が理想です。

“1日のタスク”とは、どこまでやったら終わりなのか分かりにくいものです。スクラムガイドには「タスクは1日以内のサイズにしろ」と書いてありますが、実務においては、1日でもまだ粒が大きい。僕が支援するケースだと、「基本的に1，2時間に収まるサイズにしよう」と伝えています。

──タスクを細かくするための時間もどうしても必要になってきそうですが……。

吉羽　たしかにそこはジレンマではあります（笑）。ただ、例えばWebアプリケーションを作る場合だと、タスクのパターンはだいたい決まっています。“細かく作る”と言っても慣れていくに従って、テンプレートに入力するようになっていくので、あまり恐れる必要はないでしょう。

タスク管理の基本は「壁」と「付箋」。だれが見ても内容が理解できるのが大事

──タスクを管理するためのツールには、どのようなものを使っていますか？　最近ではTrelloなどのアプリが人気のように思いますが。

吉羽　開発チームが全員、同じオフィス・同じ部屋にいる場合は、よく壁を使っています。古典的ですが、壁に付箋を貼ってタスクを管理しています。

──Webアプリじゃないんですね。

吉羽　その理由はいくつかありまして。1つはツールに項目を入力するのが面倒なこと。いちいち入力画面を開いていろんな項目を入力するより、付箋に書いてバッと貼ったほうが圧倒的に楽なんです。僕が関わったあるチームでは、「チケットシステムに入れる時間が無駄」とはっきり言っています（笑）。

もう1つ、Webアプリは、立ち上げて、必要な情報にたどり着くまでクリックして、といったように、意識して“見よう”と思わないと見ないんです。 しかし壁ならば、目の前を通れば絶対に目に入るので、 見たくないものでも目を背けられないんです。よく目にすれば、何かおかしいことがあったらすぐに気付きやすい。文字通りの見える化が重要で、僕は壁を使うことが多いですね。

ただ使うべきツールは環境にもよりますよね。リモートワークの方がいるのなら、Jiraを使ってもいいしGitHubを使ってもいいと思います。注意したいのは、入力項目は全部入れるは必要ない、ということです。本当にチームとして必要な情報だけでいい。

──ツールに使われないように気を付けないといけませんね。

吉羽　 「ちゃんと全部入力しておけばあとから分析できるじゃん」と考える人もいますが、実際のところ分析されることは極めて稀です（笑）。目的があって集められたデータには価値がありますが、目的なく集めたデータはほとんど活用されることはありません。

他にも、プロダクトバックログの場合、専用ツールよりもGoogleのスプレッドシートを使用するチームのほうが多い印象です。スプリントバックログは開発チーム内で情報を共有できればいいので、TrelloやMiroといった、比較的操作が楽で入力項目が少ないツールを使うチームが多いです。

──入力する情報をできるだけダイエットしろってことですね。必要最低限の情報ってどんなものが挙げられますか？

吉羽　それは難しくて、チームの成長によってツールの使い方は変わります。付箋でもプロダクトバックログでも、“みんながそれを見て同じことを想像できる”ことが最優先で、きちんと共有できるのであれば、記号だっていいわけです。成熟したチームでは、実はタスクはすごく雑に作られているケースがあります。「DB」としか書いていなかったりとか。

──単語だけでいいんですか!?

吉羽　文脈が共有できているので、それだけで通じるわけです。分からなければ、勝手に会話を始めて、自分たちで解決する。こうしたコミュニケーションコストを下げるためにも、チームの成熟度を上げることが重要です。

しかし、これができたばかりのチームだと、タスクの具体的な完成条件まで書かないと、作業が先に進まない。タスクの書き方はチームの状態にあわせて変えていくべきものなのです。 何でも細かく書けばいいというものではないし、かといって全部を荒く書くのもまずい。

タスクを細かくすればデイリースクラムもうまくいく

──デイリースクラムではどのようなことを話し合うのでしょうか？

吉羽　2016年までのスクラムガイドでは、デイリースクラムにおいて、以下の3つの質問をしなさい、とが書かれていました。

• スプリントのゴールを達成するために、きのう何をやっていたか？
• スプリントのゴールを達成するために、きょう何をやるか？
• スプリントのゴールを達成するために、障害となることは何かあるか？

ですが、2017年の改定で少し変わりまして、「この3つの質問を使うこともある」という書き方に変わっています。3つの質問が大事なのではなく、このまま進めて大丈夫かどうかを確認できればいいからです。

もちろん慣れていない人たちは、3つの質問から始めればいいでしょう。慣れている人たちならフリーディスカッションでもいいですし、チームによっては自分たちで質問を追加しているケースもあります。そこはチームでカスタマイズしていけばいい。

──なるほど。デイリースクラムのよくある失敗例にはどのようなものがありますか？

吉羽　よくあるアンチパタンは、「きのうこれこれやりました。今日はこれやります。困っていることは特にありません」と、全員がオウムのように報告するケースです。こんな報告を聞いても、こっちは「うそでしょ？じゃあ何で終わらないの？」となることが非常に多い（笑）。

──そういうときスクラムマスターは、どのようなことを促すといいのでしょうか？

吉羽　ここで大事になるのが、先ほど説明したタスクの粒度設定です。タスクの粒度が大きいと、「今日も引き続きAという作業をやります」という報告になりがちで、進捗の課題が検知しにくい。

しかし、タスクの粒度が1～2時間のサイズだったら、昨日と今日でやることに必ず差分が生まれるはずで、なにか問題が起きていても気付きやすいです。

──タスクの粒度を細かくしておくと、デイリースクラムをうまく進めやすいと。

吉羽　進捗度合いも、先ほど説明した“壁で見える化”しておけば一目瞭然なんですよ。デイリースクラムの目的は“スプリントゴールを達成できそうか”を診断することなので、それが分かるように設計すべきなのです。決して“やっている作業”を報告する場ではないんですよ。

──その目的をきちんと認識しておくことが重要なんですね。「ずいぶん時間かかっているけど大丈夫」と促すこともスクラムマスターの役目なのでしょうか？

吉羽　 そういう確認をスクラムマスターがしてもいいのですが、本来は他の開発チームのメンバーが、「ずいぶんハマっているけど、手伝おうか？」と言える状態にするのが理想です。

デイリースクラムは、必ずしもスクラムマスターが出なければならないイベントではありません。開発チームが自主運営できなければスクラムマスターが横に立ってサポートする必要がありますが、たまにのぞくぐらいでもいい。あくまで開発チームのためのイベントなんです。

──スクラムマスターはいなくてもいいのですね。

吉羽　チームが慣れていない状態だと、開発チームがスクラムマスターを囲み、報告するただの儀式になりがちですが、デイリースクラムはスクラムマスターに報告する場ではありません。

さらに言うと、スクラムマスターが関心を持つべきは、「進捗」ではなく、「プロセスがきちんと稼働しているか」です。進捗を把握すべきは開発チームのタスクです。 ですから、スクラムマスターはデイリースクラムに対して、後ろから見守る、というスタンスでいいのです。一歩引き、あまりにもおかしな状態だったら介入するイメージです。

──開発チームが自身で課題を解決することをサポートするのがスクラムマスターの役割であると。

吉羽　そうです。それがスクラムマスターの使命です。スクラムマスターの理想型は、最終的には自分がいなくても、開発チームとプロダクトオーナーがうまくコミュニケーションし、プロダクトが生み出される状態です。自分がいなくても回るスクラムチームを作る、という状態が目標です。

スプリントレビューにはインクリメントがあればいい……というわけではない

──続くイベントはスプリントレビューですね。この場では、スクラムマスターはどんな役割を果たすのでしょうか？

吉羽　スプリントレビューの主催者はプロダクトオーナーです。プロダクトオーナーがステークホルダーを呼んだうえで全体の説明をしたり、開発チームがデモをしたりしますが、全体を支援するスクラムマスターです。議論が白熱しすぎたら落ち着くよう促したり、ステークホルダーが「やり直せ！」などと強権を振りかざしたら「まあまあ」といなしたり。

──スプリントレビューではどういったトラブルが起こりがちですか？

吉羽　そもそもやり方が間違っているケースが見られます。多いのは、プロダクトオーナーが開発チームのインクリメントをそこで初めて見るといったシチュエーションですが、これはよくないです。ステークホルダーに見せてフィードバックをもらう場なので、プロダクトオーナーはスプリントレビューの前までに完成したかチェックしておくのが望ましいのです。

また、なんの準備もなしにスプリントレビューに臨むのも間違いです。作成物だけがあればいいわけではありません。「今回見せるものはこういうものです」、「全体の進捗状況はこういう具合です」など、説明資料も多少は必要になるでしょう。またデモはどういう手順でどういうシナリオで誰がやるのか、という段取りもしておく必要があります。

スプリントレビューが始まる前にちゃんと準備ができているか、スクラムマスターは確認しておいたほうがいいですね。これも初期におけるスクラムマスターの重要な仕事です。

──ステークホルダーとのやり取りでは、どんなことに気を付けるべきでしょうか？

吉羽　スプリントレビューでは、声が大きいステークホルダーが延々としゃべり続けるといったシチュエーションは止める必要があります。逆にまったくフィードバックをくれないステークホルダーの場合、「気になるところはありませんか？」と発言を促す必要があります。こうした役割はプロダクトオーナーが担ってもいいですが、スクラムマスターもスプリントレビューの価値を最大化できるように支援します。

振り返り手法には変化をつけ、“お葬式化”を防ごう

──スプリントレトロスペクティブはいわゆる振り返りですよね。これもスクラムを始めたばかりの頃はなかなかうまく機能しそうにありません。スクラムマスターはどういった点に気を付ければよいでしょうか？

吉羽　よくある失敗パターンは、「いつも同じやり方で振り返る」ですね。KPTという「Keep・Problem・Try」の三象限で捉えるフレームワークがよく使われていて、毎週KPTをやっているチームもあるでしょう。ただ、実はスクラムガイドでは「振り返れ」と書いてあるだけで、やり方が決められているわけではありません。

振り返りだからといってKPTを毎週やっていると、マンネリ化します。こういうときスクラムマスターは、チームの状況に応じた“やり方”を提案したほうがいいですね。

──振り返りのやり方を変えるんですね。

吉羽　やり方を変えることで、視点も変わります。だからスクラムマスターは、チームの抱えている状況を見つつ、「きょうはこんなやり方をしてみたらどうかな？」とチームに提案してみるといい。ただ、押し付けてはいけなくて、あくまで提案ではありますが。

──チームの状況にあわせて振り返りのやり方を柔軟に変えていいんですね。

吉羽　柔軟でいいんです。KPTではなく、「きょうはこのテーマについてみんなで話し合おう」でもいい。振り返って次に生かすアクションアイテムを出せばいいんです。それを次のスプリントのスプリントバックログに入れて活用するわけです。

やり方は決して1つではありません。スクラムマスターはそういうスプリントレトロスペクティブのやり方の引き出しを持っておくと便利です。定期的に発生するイベントはとにかくマンネリ化しやすいものです。、毎回同じやり方をすると毎回同じような問題が出てきますが、すぐに改善できないことも当然ありえます。そうするといつまでも同じ問題が出てきてしまい、どんどんコミュニケーションが喪失していき暗くなっていきます。僕は暗い感じの振り返りのことを「お葬式」と呼んだりもします（笑）。

──それは言い得て妙ですね（笑）。「お葬式」を防ぐにはどうしたらいいんでしょうか？

吉羽　振り返るときは、あえて、幅広い話をしないほうがいいでしょう。あれもこれもではなく、必ず1個ずつ片付ける。「今の自分たちにとって最大の問題って何だろう？」といった質問をスクラムマスターが振り、本当に重要な問題をあぶり出し、チーム全員で修正にかかったほうがいいでしょう。

「本当は目を向けたくないんだけれども、解決しないわけにはいかない」といった課題から優先して取り組んでいけば、チームのパフォーマンスは加速度的に上がっていくでしょう。

──ただ、そういう課題ってなかなか口にしづらい雰囲気もあります。メンバーが抱えている重要な課題をうまく引き出すにはどうしたらいいんでしょうか？

吉羽　僕がコーチングする場合、「今より倍のボリュームをこなせるようになるには何をすればいいんだろう？」とか「もし自分が魔法使いで何でも1つ制約を外せるとしたら何を外す？」といった質問をしています。

目先の小さい問題ばかりを片付けていても仕方がありません。また、小さな問題ばかり扱っているとそれに時間をとられ、肝心な問題に関しては、スプリントレトロスペクティブの冒頭で「前回挙げたアクションアイテム、どこまでできたか確認してみましょう」と聞いても、「どれもやってません」となってしまいます。絶対に避けるべきシチュエーションです。タスクをこなしても、プロジェクトは大きなインセンティブが得られていなことと同義です。

重要なのは自分たちにとってインパクトがある課題に取り組むことです。そういう課題が出ない振り返りなら、やり方が悪いとスクラムマスターは考えるべきですね。

──ありがとうございます。ひと通り、それぞれのイベントにおける注意点がわかりました。お話をうかがうほどに、一筋縄ではいかないスクラムを実践するには、スクラムマスターには柔軟性が求められることを感じます。

吉羽　前回お伝えしたとおり、スクラムマスターに向く人は、いろいろな関係者やシチュエーションに対して前向きな興味を持てる人です。興味を持って、工夫していければ、チームに適したスクラムの運用法が見つかると思います。ぜひ、視野を広く持ってスクラムマスターの仕事に臨んでほしいです。

──ありがとうございました！

本記事は2020年3月に実施された取材をもとに構成しています。

取材・文・構成：澤田竹洋（浦辺制作所）