スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた

• イベントマネジメントの心得
• スプリントレビューでは言いたい放題言わせよう！
• スプリントの期間延長は絶対NG　大切なのは原因の究明
• スコープと期限の両方を守るのは難しい
• よいチームを作るためにスクラムマスターができること

アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。

イベントに関係者が参加してくれない……。そもそも、開発が間に合わなさそう……。

こうした、スクラムマスターが現場で遭遇しがちな疑問や課題を解決するべく、スクラムのコーチとして活躍し、名著『SCRUM BOOT CAMP THE BOOK』の共著者でもある吉羽 龍太郎さんにぶつけてみました。

イベントマネジメントの心得

──さて、まずはスクラム順序にのっとり、発生しそうな課題に関してお聞きします。デイリースクラムやスプリントレビューといったイベントは、中には参加を嫌がる人が出てくるようにも思います。このようなときにスクラムマスターはどのように対応すればいいのでしょうか？

吉羽　そうした課題が生まれる背景には、大きく分けて2つの文脈が考えられます。1つは、ステークホルダーが忙しくてスプリントレビューに来られないパターン。これはどんな組織でも起こりえることですね。

ここで考えないといけないのが、“忙しい人たちに、本当に毎週集まってもらう必要があるのか”ということです。必ずしも全員集合する必要はないはずです。例えば、プロダクトのステージや追加した機能の内容に応じて、関係ある人に限定して呼べばいいでしょう。「今回は管理者用の機能を作ったので、サポート部門の人に来てもらったほうがいい」とか、「営業向けの機能を作ったんで、営業部門の人を選んだほうがいい」のように、スプリントバックログに応じて柔軟に参加者を設定すべきでしょう。

── スプリントレビューだからといって常にステークホルダーを全員呼ぶ必要はないんですね。

吉羽　そのとおりです。毎スプリント全部来てくださいと言う必要はない。1時間のスプリントレビューに来ているのに、自分に関係のある話が5分で終わった、となると、誰でも面倒になりますよね。だからスプリントレビューに呼ぶべきステークホルダーを、事前にプロダクトオーナーに選んでもらえばいいんです。

──とはいえ、順不同にいろいろな機能を開発していると、結局のところステークホルダーをたくさん呼ぶことになってしまいそうです。

吉羽　そういう意味ですと、スプリントバックログを作るときに、“今回のスプリントのテーマ”を一緒に考えるのが効果的です。「スプリントゴール」と言うんですけれども、スプリントで達成すべきことを、スローガンのように決めるんです。そうするとテーマが明確になりますし、スプリントレビューで誰を呼ぶべきかも必然的にはっきりします。

──いろんな機能をつまみ食いするんじゃなくて、テーマに沿った機能だけを作ると。

吉羽　テーマを考えるだけなら2～3スプリント先のことも視野に入れられるでしょう。先が見えていれば関連するステークホルダーにはあらかじめ声をかけることができます。なので先にステークホルダーの予定を確保しておいて、用事がなくなったら「やっぱり大丈夫です」と声がけするのも、運用上のテクニックの1つです。

──ありがとうございます。もう1つのパターンについてお教えていただけますか？

吉羽　 もう1つは、開発チームのメンバーがイベントに出たがらないシチュエーションです。これは忙しいから、という気持ちはは分かりますが、考え方が逆なんですね。スクラムの場合はタイムボックスという概念があって、イベントのために使う時間をあらかじめキャパシティーから引きます。

例えば“1週間で40時間働ける”という前提があった場合、部内の会議、絶対に書かないといけない資料の作成時間、メールの返信、スプリントプランニング、デイリースクラム、スプリントレビューなどなど、必要な時間を全部引いて、残った時間しか開発に使えない……というアプローチなんです。 “たくさん開発しないといけないから、必須のイベントを減らす”ではなくて、“確保した時間内に収まるタスクしか入れない”のが基本姿勢です。ですから「開発のための時間中心」という考え方を逆転させる必要があります。こうした時間設定をチームに浸透させるのもスクラムマスターの役割のひとつです。

──開発タスクばかり積んでしまったら、スプリント内に収まらないでしょう？と。

吉羽　ただですね、そもそもの話として“スクラムが嫌い”という人もいらっしゃるでしょう。その場合は、スクラムチームで一緒にやるのは難しいから、チームから外すかどうかを開発チームのメンバーと相談する必要がある。1on1などで本音を聞き出して、外したほうがいいのであれば、マネージャーと相談してみるなどの対処が必要になってきます。

スクラムマスターが直接メンバーを外す権限はありませんが、チームメンバーがどう思っているかを聞いたりすることはできますよね。その上でマネージャーにエスカレーションするといった対処は取れます。

──そういった厳しい対処を取るのはなかなか勇気がいりますよね。

吉羽　そのとおりなのですが、デイリースクラムに来る来ないといった規律の部分は、チームのほかのメンバーにも伝染する可能性があります。腕は立つけれどスクラムに馴染めず規律が守れない、というタイプの方がいたら、気にかける必要がありますし、短期的に戦力が減るからといって我慢しないほうがいい。それでチーム全体のスクラムへの認識が壊れてしまうことも十分にありえますから。そうなってしまったら、元も子もなくなってしまいます。

スプリントレビューでは言いたい放題言わせよう！

──スプリントレビューでは、ステークホルダーの皆さんから、プロジェクトに対する意見をいろいろともらいます。が、参加者があまり発言しない場合はどうしたらよいのでしょうか？

吉羽　正直なところステークホルダーには言いたい放題言ってもらってかまわないんです。「いいアイデアだけ欲しい」のように前提を作ってしまうと、発言しにくくなってしまいます。だからステークホルダーには、いいアイデアもよくないアイデアも気にせず好きなように言ってもらえればいい。

スプリントレビューの冒頭で「忌憚のない意見を思ったように言ってほしい。何でもいいから意見をください。ただし、いただいた意見にすべて対応するとは限りません」と、スプリントレビューの目的を共有しておくと進めやすいですね。あとは、匿名チャットで意見を募る方法も有効です。そして、上がってきた意見やアイデアをプロダクトオーナーが取捨選択をするといいでしょう。

──匿名チャットの活用などは、すぐにまねができそうでいいですね。「いいな」と思った指摘やアイデアについては、次のスプリントですぐに取りかかったほうがよいのでしょうか？

吉羽　次のスプリントバックログに入れるかどうかは検討の余地がありますね。ステークホルダーの鶴の一声で毎回次のスプリントに突っ込んでいたら、終わるものも終わらなくなってしまいます。全体性の網羅が重要ですから。「いったん最後まで作って、時間が残ったらやろう」と判断して、プロダクトバックログの下に入れておくことも当然あります。リファインメントのタイミングで、プロダクトオーナーが「やっぱりやりたい」と順番を上げることもありますし。

──では基本的には、ステークホルダーから指摘をいただくのは、それほど気にするようなことではないと。

吉羽　ただし、ステークホルダーからの指摘がもっともだな、と思うようなことがずっと続いているようなら、プロダクトオーナーのアクティビティがどこかで間違っているかもしれません。ステークホルダーとコミュニケーションが足りていない、ビジネスやプロダクトが置かれているコンセプトをしっかりと理解できていないとか、そういった可能性があります。こうした齟齬が続くようなら、スクラムマスターは「何かおかしいな」と気付かないといけない。たまに起こるぐらいならまったく普通のことなんですけどね。

スプリントの期間延長は絶対NG　大切なのは原因の究明

──スプリント内に予定していたタスクが終わらない場合は、スプリントを1日延ばして対応するといった対処法はありなのでしょうか？

吉羽　 ダメです。終わらないものは終わらない。スクラムの原則は、タイムボックスは延ばさない、です。そして、タイムボックス内に終わらなかった理由を明らかにして、同じことをやらないようにしよう、です。スプリントレトロスペクティブでチームにとって大きな問題が発覚したら、アクションアイテムを作って直近のスプリントで対応します。

──逆にプロダクトバックログの項目が予定より早く終わってしまった場合は、どうしていますか？

吉羽　これはいくつかオプションがありまして、かなり早く終わってしまった場合は、プロダクトオーナーと相談して次のスプリントでやろうと思っていたプロダクトバックログの項目から、ちょうどいいサイズのものを選んで持ってくる。

もう1つ、チームによっては「時間があればこういうことをやりたい」タスク──ミドルウェアをバージョンアップしたいとかリファクタリングしたいとか──のリストを持っています。時間が余ったら開発チームはこうしたタスクに取りかかる手もあります。

──2つのパターンを選択するうえで何かしらの基準はあったりしますか？

吉羽　それはチームの状況にもよります。 作るもの量がそれなりにあって、まだ残りのタスクが多ければ、前に進めるためにプロダクトバックログをこなしたほうがいいかもしれない。 逆にそこまで切羽詰まっていない状況で、技術的負債がたまっているようなら、先にリファクタリングに取りかかったほうがいいでしょう。どちらも間違いではありません。

──当たり前のことではありますが、状況に応じて選べということですね。

吉羽　僕個人としては、後者のほうが好きです。リファクタリングをしたり新しいツールを試すほうが、その後の作業を早く進められる可能性がありますので。あと、プロダクトオーナーにリファクタリングを提案すると、「いやーでも機能を開発したいんだよ」と言われることが多いです（笑）。だったらたまに早く終わったときくらい、そういうことをやろうと。

とはいえ、なにをすべきかはプロダクトオーナーと相談するのが第一選択です。必ずしも一存で決める必要はありません。

──そういったゆとりの時間が取れない場合は技術的負債にはどのように対応すればいいんでしょうか？

吉羽　 これもプロダクトオーナーとの相談にもなるのですが、 あらかじめ、スプリントバックログに入れる項目の割合を決めておくのも1つの手です。例えば機能型のバックログを7割、非機能型──リファクタリング、性能、ドキュメントなど機能とはちょっと外れたところ──のバックログに3割ぐらいの時間を使う、といった具合です。 またゴールデンウィークや年末年始などをはさんでしまい、スプリントが組みにくいタイミングがあります。そういうときに「もう機能は開発しない」と決め、技術的負債に取り組むともありますね。半端なスプリントで技術的負債が解消できるか……はプロダクト次第ではありますが。

──それだけでは解決できないときは、技術的負債の返済だけにスプリントを取ったりすることもあるのですか？

吉羽　そういうこともありえます。一方でビジネス的な観点で見ると、負債解消は成果が見えにくい、取り組む必然性を説明するのが難しいところはあります。プロダクトの状況次第ですが、技術的負債の返済を今やっておかないと大変だ、ということであれば、将来的なリスクを避けるために、と説明して、スプリントに取り入れるといいでしょう。

スコープと期限の両方を守るのは難しい

──スクラムチームの外側、例えばステークホルダーの上司から進行方法や作業ボリュームについて指摘があった場合、スクラムマスターはどのように対応すべきなのでしょうか？