先日スクラムマスターは間違いなく必要だなと思う経験をしたので、文章を書いておきます。
背景：明確なスクラムマスターを置かない
僕が通う筑波大学には、チームを組んでプロダクトを企画立案し、スクラムを用いてアジャイルに開発をするという授業があります。僕はこの授業を大変気に入っており、学部3年生のころから修士1年生の今まで、3年連続で関わっています。
今年の10月からは、修士1年の大学院生4人でチームを組み、「レジ前でどの決済手段で支払うべきか迷う数秒間を消し去る」ようなサービスを作っています。4人のうち僕を含む2人はこの授業との関わりが深く、必然的にスクラムもある程度身に付いています。残る2人は知識としてはスクラムを知っているけれど身に付いているわけではない、といったレベルです。
僕たちのチームでは、チーム結成からしばらくの間(2ヶ月程度)、明確なスクラムマスターを置いていませんでした。もともと見知った4人のチームだし、比較的小規模のチームだし、明確なスクラムマスターがいなくてもスクラムは回ると思ったのです。また、メンバーの半数がスクラムを良く知っているので、スクラム的に困ったことがあればこの2人がスクラムマスター的にチームの行動を修正できると思っていたというのもあります。
結果的に、我々のチームはプロダクトオーナー1名+開発チーム3名という体制でプロダクトを作っていくことになりました。
起こったこと
見た目上は上手く動く
最初のスプリントを開始してから「やはり明確にスクラムマスターを置こう」という結論に至るまで、我々のチームのスクラムは見た目上は上手く動きました。見た目上、というのは、スクラムイベントを実施したり、プロダクトバックログを整備したり、スプリントバックログを管理したりすることはできた(できているように見えた)、ということです。実際、なにかイベントを省略するような方向にチームが動いたり、イベントが長引きすぎて開発時間が圧迫されるというような問題が起こったりすることはありませんでした。スクラムの見た目が上手くいったのは、この開発が授業の一環であるということもあり、チーム全員の「スクラムをやるんだ」という意識が強かったという理由が大きいと思います。
また、この授業では我々チームを観察して神の視点からアドバイスをくれるメンターや教員という存在がありますが、彼らからスクラムの取り回し方について特に大きな指摘をされた記憶も無く、客観的に見てもスクラムっぽい何かは動いていたのだと思います。
プロダクトバックログがブレる
我々のチームにはたしかにプロダクトバックログは存在し、そこにはプロダクトバックログアイテムが順序情報を持って並んでいたのですが、その順序の論理的背景をプロダクトオーナーしか正確に理解できていないという状況に陥りました。プロダクトオーナーはスプリントプランニングの際に毎回どういう理由でその順序でプロダクトを作るのか説明するのですが、開発チームとしてはその説明がイマイチ腑に落ちないのです。開発チームからもいくつか質問や指摘が出るのですが、毎回毎回延々と議論をするわけにもいかず、最終的には「まぁプロダクトオーナーがそう言うなら……」といった空気でタスクスライスに取り掛かっていました。
いま振り返って考えてみても、開発チームの懸念は間違いではなかったと思っています。我々のプロダクトはモバイルアプリで、アプリ起動の導線として「アプリアイコンのタップ」か「ホーム画面ウィジェットのタップ」が設定されています。後者のウィジェット起動はプロダクトオーナーの意向で比較的早期に実装されていましたが、プロダクト全体として見れば、ウィジェット起動による嬉しさ(=価値)を提供できていないような気がします。ウィジェットの実装はもう少し後で良かった、それよりも先に実装すべきものがあった、というのが現在のチームの認識です。
このように、プロダクトバックログのコンテキスト、文脈が上手くチーム内で共有できておらず、プロダクトバックログが(ひいてはプロダクトそのものが)ブレるというのは我々が直面した課題です。
開発チームがブレる
開発チームは、毎回スプリントの最初にプロダクトオーナーを交えてスプリントの計画を立てます。我々のチームも例外ではなく、このスプリントプランニングは比較的丁寧に行っていたと思います。プロダクトオーナーから次回のレビューまでに達成したいプロダクトバックログアイテムを示され、開発チームはプロダクトバックログアイテムをタスクに分割して作業量を見積もり、スプリント内での達成が難しそうであればプロダクトオーナーと協議して妥協点を探る、という基本的なプランニングを確実にこなしていました。
プランニングはそれなりに時間をかけて行われていたにも関わらず、我々のチームでは、作業内容の微妙なズレやコードの衝突が頻発しました。「この関数なんだっけ」「めっちゃコンフリクトしちゃった」というような会話が毎スプリントのように行われ、スプリントが進むと謎のデッドコード(=プログラム中の実行されない部分)が生まれてしまったりもしました。
上手くいっていたかのように見えたプランニングですが、実は開発チームの中で真の意味での合意が取れていなかったのです。このように開発チームは毎スプリント微妙にブレ続け、無駄の多い開発を続けてしまいました。
対策したこと・結果
我々のチームは、見た目上は上手くスクラムが動いているように見えるにも関わらず、プロダクトや開発がブレるという事態に陥りました。プロダクトに関しては毎回スプリントゴールをより明確にしようであったり、開発に関してはコードレビューを徹底しようであったり、いろいろなカイゼン案がでましたが、どれも根本的な処方箋にはなりませんでした。
最終的に、我々に足りないのはスクラムマスターではないかというチームメンバーの発言にもとづき、専任のスクラムマスターを置くことにしました。チームにメンバーを追加することはできないため、開発チームのうち一人(僕)をスクラムマスターに転任させることになりました。開発チームの頭数が減るとチームの直接的な推進力が落ちてしまうのではないかという懸念もありましたが、結局、ほとんど専任でスクラムマスターを置くことになりました。
スクラムマスターを置いた結果、これまでに出ていたようなチームの症状はかなり改善されました。スクラムマスターを置いた日のレトロスペクティブ(振り返り)を見ても、「コミュニケーションを良く取れた」「専任のスクラムマスターを置くのは良かった」「スプリントプランニングで詳細に詰めることができた」などのポジティブコメントはあったものの、「開発力が足りなかった」といった当初予想されていたネガティブコメントは上がりませんでした。
現在のところ、我々のチームとしては、スクラムマスターの設置は非常に効果のあった施策として受け入れられています。
考えたこと
スクラムマスターはプロダクトオーナーの伴侶である
我々のチームでこういった経験をするまで、僕はスクラムマスターを「チームがスクラムガイドから逸脱しないようにするコーチ」だと思っていました。このような認識から、スクラムを知識として知っているチームではスクラムマスターは不要なのではないかと考えてさえいました。しかし、スクラムガイドに「スクラムマスターは、さまざまな形でプロダクトオーナーを支援する」「スクラムマスターは、さまざまな形でスクラムチームを支援する」とあるように、スクラムマスターはプロダクトオーナーや開発チームを支援するためにいるのです。
スクラムマスターは、プロダクトオーナーの最高の壁打ち相手であるべきだと思います。プロダクトオーナーはプロダクトに集中するあまり、自分の頭の中だけで論理を完結させてしまいがちです。スクラムマスターはそんな孤高なプロダクトオーナーから話を聞き出し、プロダクトオーナーの考えを開発チームが納得できるようなプロダクトバックログに落とし込むことを支援する必要があります。
もちろん、こうした壁打ち相手を開発チームが行うことができれば良いとも思います。しかし開発チームはスプリント期間中開発に忙しく、プロダクトそのものを責任を持って考えることは難しいです。また、開発チームの人数は一般に複数人ですから、開発チームと壁打ちをするときは自然とミーティングの開催が必要になります。ミーティングはヘビーで取り回しづらいイベントです。であれば、日常業務としては、プロダクトオーナーはスクラムマスターとの対話を通してプロダクトやプロダクトバックログを洗練させ、開発チームとはスプリントプランニングの場で深く議論をするほうが効果的で健康的でしょう。
このように、スクラムマスターはプロダクトオーナーの伴侶であるべきだと考えます。
スクラムマスターは開発チームの伴侶である
孤高なプロダクトオーナーに対比して、開発チームは文字通りチームです。チームで物事に取り組むに当たって最も重要なことは、チーム内で質の高い合意を取ることです。このためにプランニングの会議を行うわけですが、人間というのは難儀な生き物で、当事者として会議に参加すると、何も物事を理解していないにも関わらず何か分かった気分になってしまうものです。ここで必要なのがスクラムマスターです。
スクラムマスターはスプリントプランニングの会議に非当事者として参加します。スクラムマスターは開発をしませんしプロダクトバックログに対する責任も負っていませんから、非当事者です。スクラムマスターは非当事者のファシリテーターとして会議を客観的に俯瞰し、不明点がありそうなメンバーがいたら質問を促し、自分自身が理解できていないポイントがあれば話題を掘り下げ、会議の参加者に真の意味での理解を促します。
またスクラムマスターはスプリント期間中開発チームを眺め、非当事者の視点から、改善できるところが無いか観察します。サッカーの中継を見ていると、「なんであんな開いてるスペースに走り込まないんだよ！」「どう見ても今シュートできただろ！」と怒り出したくなるシーンを多数見かけます。しかしフィールドに立つ選手たちは、そんな状況を露知らず、地面をかけずり回っています。スクラムでは、フィールドをかけずり回る開発チームを観戦し、「いまシュートいけそうだよ」と直接声をかけられる観客、スクラムマスターが存在します。
スクラムマスターはプロダクトオーナーの伴侶であると同時に、開発チームの伴侶でもあるべきです。
