- イベントマネジメントの心得
- スプリントレビューでは言いたい放題言わせよう！
- スプリントの期間延長は絶対NG 大切なのは原因の究明
- スコープと期限の両方を守るのは難しい
- よいチームを作るためにスクラムマスターができること
- 関連記事
アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。
イベントに関係者が参加してくれない……。そもそも、開発が間に合わなさそう……。
こうした、スクラムマスターが現場で遭遇しがちな疑問や課題を解決するべく、スクラムのコーチとして活躍し、名著『SCRUM BOOT CAMP THE BOOK』の共著者でもある吉羽 龍太郎さんにぶつけてみました。
- 吉羽 龍太郎さん（よしば・りゅうたろう／
@ryuzee）
- 株式会社アトラクタ取締役CTO/アジャイルコーチ。クラウドコンピューティング、DevOps、インフラ構築自動化、アジャイル開発、組織改革を中心にオンサイトでのコンサルティングとトレーニングを提供。Scrum Alliance認定チームコーチ(CTC) 青山学院大学非常勤講師(2017-)。主な著書・訳書に『SCRUM BOOT CAMP THE BOOK』、『レガシーコードからの脱却』『Effective DevOps』など。Webサイト：ryuzee.com
イベントマネジメントの心得
──さて、まずはスクラム順序にのっとり、発生しそうな課題に関してお聞きします。デイリースクラムやスプリントレビューといったイベントは、中には参加を嫌がる人が出てくるようにも思います。このようなときにスクラムマスターはどのように対応すればいいのでしょうか？
吉羽 そうした課題が生まれる背景には、大きく分けて2つの文脈が考えられます。1つは、ステークホルダーが忙しくてスプリントレビューに来られないパターン。これはどんな組織でも起こりえることですね。
ここで考えないといけないのが、“忙しい人たちに、本当に毎週集まってもらう必要があるのか”ということです。必ずしも全員集合する必要はないはずです。例えば、プロダクトのステージや追加した機能の内容に応じて、関係ある人に限定して呼べばいいでしょう。「今回は管理者用の機能を作ったので、サポート部門の人に来てもらったほうがいい」とか、「営業向けの機能を作ったんで、営業部門の人を選んだほうがいい」のように、スプリントバックログに応じて柔軟に参加者を設定すべきでしょう。
── スプリントレビューだからといって常にステークホルダーを全員呼ぶ必要はないんですね。
吉羽 そのとおりです。毎スプリント全部来てくださいと言う必要はない。1時間のスプリントレビューに来ているのに、自分に関係のある話が5分で終わった、となると、誰でも面倒になりますよね。だからスプリントレビューに呼ぶべきステークホルダーを、事前にプロダクトオーナーに選んでもらえばいいんです。
──とはいえ、順不同にいろいろな機能を開発していると、結局のところステークホルダーをたくさん呼ぶことになってしまいそうです。
吉羽 そういう意味ですと、スプリントバックログを作るときに、“今回のスプリントのテーマ”を一緒に考えるのが効果的です。「スプリントゴール」と言うんですけれども、スプリントで達成すべきことを、スローガンのように決めるんです。そうするとテーマが明確になりますし、スプリントレビューで誰を呼ぶべきかも必然的にはっきりします。
──いろんな機能をつまみ食いするんじゃなくて、テーマに沿った機能だけを作ると。
吉羽 テーマを考えるだけなら2～3スプリント先のことも視野に入れられるでしょう。先が見えていれば関連するステークホルダーにはあらかじめ声をかけることができます。なので先にステークホルダーの予定を確保しておいて、用事がなくなったら「やっぱり大丈夫です」と声がけするのも、運用上のテクニックの1つです。
──ありがとうございます。もう1つのパターンについてお教えていただけますか？
吉羽 もう1つは、開発チームのメンバーがイベントに出たがらないシチュエーションです。これは忙しいから、という気持ちはは分かりますが、考え方が逆なんですね。スクラムの場合はタイムボックスという概念があって、イベントのために使う時間をあらかじめキャパシティーから引きます。
例えば“1週間で40時間働ける”という前提があった場合、部内の会議、絶対に書かないといけない資料の作成時間、メールの返信、スプリントプランニング、デイリースクラム、スプリントレビューなどなど、必要な時間を全部引いて、残った時間しか開発に使えない……というアプローチなんです。 “たくさん開発しないといけないから、必須のイベントを減らす”ではなくて、“確保した時間内に収まるタスクしか入れない”のが基本姿勢です。ですから「開発のための時間中心」という考え方を逆転させる必要があります。こうした時間設定をチームに浸透させるのもスクラムマスターの役割のひとつです。
──開発タスクばかり積んでしまったら、スプリント内に収まらないでしょう？と。
吉羽 ただですね、そもそもの話として“スクラムが嫌い”という人もいらっしゃるでしょう。その場合は、スクラムチームで一緒にやるのは難しいから、チームから外すかどうかを開発チームのメンバーと相談する必要がある。1on1などで本音を聞き出して、外したほうがいいのであれば、マネージャーと相談してみるなどの対処が必要になってきます。
スクラムマスターが直接メンバーを外す権限はありませんが、チームメンバーがどう思っているかを聞いたりすることはできますよね。その上でマネージャーにエスカレーションするといった対処は取れます。
──そういった厳しい対処を取るのはなかなか勇気がいりますよね。
吉羽 そのとおりなのですが、デイリースクラムに来る来ないといった規律の部分は、チームのほかのメンバーにも伝染する可能性があります。腕は立つけれどスクラムに馴染めず規律が守れない、というタイプの方がいたら、気にかける必要がありますし、短期的に戦力が減るからといって我慢しないほうがいい。それでチーム全体のスクラムへの認識が壊れてしまうことも十分にありえますから。そうなってしまったら、元も子もなくなってしまいます。
スプリントレビューでは言いたい放題言わせよう！
──スプリントレビューでは、ステークホルダーの皆さんから、プロジェクトに対する意見をいろいろともらいます。が、参加者があまり発言しない場合はどうしたらよいのでしょうか？
吉羽 正直なところステークホルダーには言いたい放題言ってもらってかまわないんです。「いいアイデアだけ欲しい」のように前提を作ってしまうと、発言しにくくなってしまいます。だからステークホルダーには、いいアイデアもよくないアイデアも気にせず好きなように言ってもらえればいい。
スプリントレビューの冒頭で「忌憚のない意見を思ったように言ってほしい。何でもいいから意見をください。ただし、いただいた意見にすべて対応するとは限りません」と、スプリントレビューの目的を共有しておくと進めやすいですね。あとは、匿名チャットで意見を募る方法も有効です。そして、上がってきた意見やアイデアをプロダクトオーナーが取捨選択をするといいでしょう。
──匿名チャットの活用などは、すぐにまねができそうでいいですね。「いいな」と思った指摘やアイデアについては、次のスプリントですぐに取りかかったほうがよいのでしょうか？
吉羽 次のスプリントバックログに入れるかどうかは検討の余地がありますね。ステークホルダーの鶴の一声で毎回次のスプリントに突っ込んでいたら、終わるものも終わらなくなってしまいます。全体性の網羅が重要ですから。「いったん最後まで作って、時間が残ったらやろう」と判断して、プロダクトバックログの下に入れておくことも当然あります。リファインメントのタイミングで、プロダクトオーナーが「やっぱりやりたい」と順番を上げることもありますし。
──では基本的には、ステークホルダーから指摘をいただくのは、それほど気にするようなことではないと。
吉羽 ただし、ステークホルダーからの指摘がもっともだな、と思うようなことがずっと続いているようなら、プロダクトオーナーのアクティビティがどこかで間違っているかもしれません。ステークホルダーとコミュニケーションが足りていない、ビジネスやプロダクトが置かれているコンセプトをしっかりと理解できていないとか、そういった可能性があります。こうした齟齬が続くようなら、スクラムマスターは「何かおかしいな」と気付かないといけない。たまに起こるぐらいならまったく普通のことなんですけどね。
スプリントの期間延長は絶対NG 大切なのは原因の究明
──スプリント内に予定していたタスクが終わらない場合は、スプリントを1日延ばして対応するといった対処法はありなのでしょうか？
吉羽 ダメです。終わらないものは終わらない。スクラムの原則は、タイムボックスは延ばさない、です。そして、タイムボックス内に終わらなかった理由を明らかにして、同じことをやらないようにしよう、です。スプリントレトロスペクティブでチームにとって大きな問題が発覚したら、アクションアイテムを作って直近のスプリントで対応します。
──逆にプロダクトバックログの項目が予定より早く終わってしまった場合は、どうしていますか？
吉羽 これはいくつかオプションがありまして、かなり早く終わってしまった場合は、プロダクトオーナーと相談して次のスプリントでやろうと思っていたプロダクトバックログの項目から、ちょうどいいサイズのものを選んで持ってくる。
もう1つ、チームによっては「時間があればこういうことをやりたい」タスク──ミドルウェアをバージョンアップしたいとかリファクタリングしたいとか──のリストを持っています。時間が余ったら開発チームはこうしたタスクに取りかかる手もあります。
──2つのパターンを選択するうえで何かしらの基準はあったりしますか？
吉羽 それはチームの状況にもよります。 作るもの量がそれなりにあって、まだ残りのタスクが多ければ、前に進めるためにプロダクトバックログをこなしたほうがいいかもしれない。 逆にそこまで切羽詰まっていない状況で、技術的負債がたまっているようなら、先にリファクタリングに取りかかったほうがいいでしょう。どちらも間違いではありません。
──当たり前のことではありますが、状況に応じて選べということですね。
吉羽 僕個人としては、後者のほうが好きです。リファクタリングをしたり新しいツールを試すほうが、その後の作業を早く進められる可能性がありますので。あと、プロダクトオーナーにリファクタリングを提案すると、「いやーでも機能を開発したいんだよ」と言われることが多いです（笑）。だったらたまに早く終わったときくらい、そういうことをやろうと。
とはいえ、なにをすべきかはプロダクトオーナーと相談するのが第一選択です。必ずしも一存で決める必要はありません。
──そういったゆとりの時間が取れない場合は技術的負債にはどのように対応すればいいんでしょうか？
吉羽 これもプロダクトオーナーとの相談にもなるのですが、 あらかじめ、スプリントバックログに入れる項目の割合を決めておくのも1つの手です。例えば機能型のバックログを7割、非機能型──リファクタリング、性能、ドキュメントなど機能とはちょっと外れたところ──のバックログに3割ぐらいの時間を使う、といった具合です。 またゴールデンウィークや年末年始などをはさんでしまい、スプリントが組みにくいタイミングがあります。そういうときに「もう機能は開発しない」と決め、技術的負債に取り組むともありますね。半端なスプリントで技術的負債が解消できるか……はプロダクト次第ではありますが。
──それだけでは解決できないときは、技術的負債の返済だけにスプリントを取ったりすることもあるのですか？
吉羽 そういうこともありえます。一方でビジネス的な観点で見ると、負債解消は成果が見えにくい、取り組む必然性を説明するのが難しいところはあります。プロダクトの状況次第ですが、技術的負債の返済を今やっておかないと大変だ、ということであれば、将来的なリスクを避けるために、と説明して、スプリントに取り入れるといいでしょう。
スコープと期限の両方を守るのは難しい
──スクラムチームの外側、例えばステークホルダーの上司から進行方法や作業ボリュームについて指摘があった場合、スクラムマスターはどのように対応すべきなのでしょうか？
吉羽 スクラムチームの基本的な姿勢は「フィードバックに感謝しつつも、“やるやらない”に関してはすべてに順番を設定する」です。時間もリソースも有限なので、価値の高いところからやるしかありません。なので、外部から意見が来たら、まずは受け取る。そして、チームに持ち帰り皆で話し合えばいいでしょう。
あとはチーム全体にインパクトがあるようなアクティビティを要求されたら、スクラムマスター1人が巻き取る、という手もあります。例えばチームのメンバーに作業時間を詳細に記録しろといった指示があって、それが絶対にやらないとどうにもならないといった場合は、スクラムマスターが独自にまとめて資料化する、のように。
──そういった対応はスクラムマスターがやるんですね。
吉羽 プロダクトを作るのは開発チームなので、チームメンバーの時間は可能なかぎり大事にしないといけない。また、プロダクトオーナーは船頭なので、他の仕事で忙殺されたら開発は進みません。だからこそ、できるアクティビティはスクラムマスターが巻き取る、という判断に意味があるわけです。
──外部からの指摘を突っぱねる、という考え方もありそうですが。
吉羽 参考にするべき指摘もある一方で、無駄に感じられる指摘も往々にしてあるでしょう。後者に関して、指摘への対応がないとリリースができない、という性質のものであれば、「大人だからしょうがない」と割り切り、やるしかない。例えば、よくある例では「ドキュメント、エビデンスを準備してくれ」と言われる。開発自体に影響がないと強行に主張し、無用な対立をしてもしょうがないですから。ただ、開発チームの負担をかけないように配慮するのが第一選択で、そのためには、巻き取れるものならば、なるべくスクラムマスターが巻き取るようにするのがいいでしょう。
──開発終盤で権限の強い人物から指摘が入ることは、やはりあるのでしょうか。
吉羽 そういう状況もこれまで幾度も目にしてきました。特に困るのが、権限の強い人物が開発チームのメンバーに「やっぱりこの機能が欲しい」と直接言いにくることです。こういうときスクラムマスターは、スクラムの原則に忠実に、「それはプロダクトオーナーに言ってくれ」と、開発チームに伝えないといけない。
──組織全体が、アジャイルやスクラムの原則を理解する必要がありそうですね。
吉羽 はい。そして、“アジャイルやスクラムの価値観”をステークホルダーに理解してもらうのも、スクラムマスターの仕事です。アジャイルって何？スクラムって何？今までとどうやり方が変わるの？といったところを理解していただかないと、 ステークホルダーの皆さんがスクラムとは「早い・安い・うまい」手法だと理解してしまっている可能性はありますから。
──スクラムもおいしいところばかりじゃない、と。
吉羽 スクラムの理解に齟齬があると、「あいつらはいつもNoとしか言わない」と誤解されてしまいますので。
──Noと言うのもスクラムマスターの役割のひとつなのですね。
吉羽 アメリカの調査会社の発表によると、開発された64%の機能はほとんど、もしくはまったく使われない機能だと示唆しています。つまり、機能要求も実際は不要なものも多いはずで、「No」と言ったほうがいいシチュエーションは多いんです。
──ステークホルダーからの権限委譲も重要になりそうです。
吉羽 そのとおりです。特にプロダクトオーナーには権限が必要です。機能要求に対する「やる / やらない」の判断、なにを優先して開発するかという判断ができる権限が委譲されていないと、スクラムは回らない。もしプロダクトオーナーがステークホルダーの言いなりのような状況であればそれは健全ではない。スクラムマスターは「組織的な権限委譲がうまくいってないんじゃないか」と指摘する必要があります。
──開発も終盤に差し掛かってくると「ベロシティを上げろ！もっとたくさん作業してくれ」といった声も外部から聞こえてきそうです。
吉羽 上げろと言われても、無理にベロシティは上げられません。チームが出せる速度は決まっていて、すぐには上げられない。もちろん改善に努めるべきですが、明日から倍にする、といったことは不可能です。
──追加の人員を投入する、という判断があるのでは？
吉羽 もちろん選択肢としてはあります。ただし、遅れているプロジェクトに人を足しても、投入した人員がすぐにワークするわけではない。誰でもできるような作業がたくさんあれば、増やす意味はあります。しかし、プロダクトのコーディングといった業務では、キャッチアップのコストが高く、すぐにリターンは得られないでしょう。一方でテスターだけといった、手数がものをいう場合なら有効です。
──現状の作業量は増やせず、人員の追加もあまり効果がない。となると、どのような判断をすべきでしょうか。
吉羽 選択肢は2つです。スコープ（プロジェクト全体で達成すべき機能）を調整するか、期限を延ばすかのどちらかです。先に挙げた、「64%の機能は使われない」という示唆を参照すれば、スコープを減らすほうが現実的でしょう。
プロダクトをいったんリリースしてから延長戦に臨み、できあがった機能を順次リリースする選択肢もあります。マーケットの反応を見ながら、リリースしていけばいい、という判断です。
そもそも、アジャイルの原則に照らせば、大事なものから先に作ります。つまり、リリース間際の時点では、優先順位が低いものを開発しているはずです。であれば、まずはリリースするという判断もしやすいでしょう。
──「ないと絶対やばい」といったものは、この時点で残っていない、ということですね。
吉羽 リリース間際の時点で重要な項目が残っていたら、むしろもっと前のタイミングで「このままいくとまずい」という判断と調整をすべきです。
──残業での対応についてはどのようにお考えですか？
吉羽 リリースが大きなイベントで、かつリリース自体の金銭的な価値が高い。そしてチーム全員が成功させたいと思っている、納得して最後までやりたいと思っている──そういう状況ならば残業も検討すべきだと思います。
チームのマインドセットとスクラムの論理がコンフリクトした際、常にスクラムの論理を優先する必要はないでしょう。
──とはいえ、残業はどこまで認めるかのも、難しいところではありますよね。
吉羽 そのとおりです。ムチを入れるからといって、常に全力で走れません。ムチを入れるなら一瞬だけで、なおかつ、自分たちで納得している場合だけです。 ただし、常に緊急対応のようななやり方をしていると、だんだんチームの中にフラストレーションがたまってきてしまいます。そもそも「残業はできないし、朝早く業務に入れない」といった事情を持つ人もいるでしょう。 だからスクラムマスターは、特定の人が居心地悪く感じていないか注視し、ケアしないといけません。ある日、急に「チームを変わりたい」と言われることもありますから。
よいチームを作るためにスクラムマスターができること
──ここまでお話を伺いしてきて、「よいチーム」を作ることが、スクラムマスターの重要な責務だと感じます。よいチームを作るためにスクラムマスターができること、働きかけるべきことがあれば教えていただけるとうれしいです。
吉羽 難しい質問ですね。よいチームを意図して作るのはすごく大変です。スクラムマスターだけで完結する問題ではなく、チーム内の個々人のモチベーションや資質や性格などに左右されるわけですから。加えて、組織の風通しや、組織内での適切な評価体型の有無など、チーム外の環境にも影響されます。
ただ、よいチームの前提として、Googleも提唱する「心理的安全性」の高さは存在すると考えます。よい話も悪い話もオープンにして、スクラムを進めるにあたって安全に感じられ、忌憚なく意見が交換できる状態を作るのが大事です。 もしも、スクラムマスターがチームがあまり機能していない、と感じたら、まずは心理的安全性を少しでも高められるような活動をしてみるとよいでしょう。
──身もふたもない話ではありますが、そもそもモチベーションが高くないメンバーがいた場合は、どうすればいいんですか？
吉羽 モチベーションは他人が根本的に変えられる問題ではありません。 アサインされたメンバーで「本当によいチームが作れるの？」と感じるようなシチュエーションも、現実にはあるでしょう。これは残念だけどしょうがないんですよ。
メンバーのミスマッチを避けるには、採用というもっと広い問題に向き合わなければなりません。自分たちの“よいチーム”のカルチャーに合う人を頑張って採用するしかありません。
私が過去、Amazonに在籍していたころ、よく言われたのは、「迷ったらやめろ」です。忙しくて人が足りないから採用したい、こんなときに、技術はあるがカルチャーフィットしなさそうな人がいたとしたら、私なら「絶対にやめろ」と言います。
技術力はもちろん大事ですが、同じくらい大事なのは、前向きで明るいパーソナリティです。そういう人がチームに数人いると、チームの雰囲気が変わります。「この人がいるとチームの雰囲気がいつも明るい」というパーソナリティは重要です。 チームの考え方に合う人をゆっくり探していくのが、結局は最速の手段なのだと思います。
──よいチームを作るにはよいメンバーを集めるしかないんですね。
吉羽 自分でチームを作れるんだったら、 よいメンバーを集める！ ソフトウェアは人が作るので、よい人がいたほうがいいものができる。それに後から苦労するんだったら、最初に苦労してよいチームを作ったほうがいい、と思います。 やっぱり。
──心理的安全性を確保することと、スクラムやアジャイルの価値観に合うメンバーを入れることが重要なんですね。
吉羽 そのとおりです。技術は教育できますが、マインドセットを教育するのは難しいのですから。
──「組織の中からスクラムマスターにふさわしい人を選んでください」と言われたら、吉羽さんならどういう基準で選びますか？
吉羽 明るくて、何にでも興味を持てる人がいいですね。そういう人は、周囲と良好な関係を築けるので、率直な意見を言っても悪感情を持たれない。
──最後に、スクラムマスターに求められる素養をお聞かせください。今お話しになったような“何にでも興味を持つ”ことがやはり重要になるのでしょうか？
吉羽 そうですね。それともう一つ、一歩引いて観察できること。これはすごく重要です。当事者意識が強すぎると視野が狭くなってしまうので、スクラムマスターという立場では、全体を俯瞰できるようにならないといけない。そういう視点を持つことで“次は何をやったらいいか”に気づきやすくなりますから。
──ありがとうございました！
関連記事
取材・文・構成：澤田竹洋（浦辺制作所）