これは Livesense Advent Calendar 2022 DAY 2 の記事です。
はじめに
転職会議事業部でエンジニアをしている、前山です。
アドベントカレンダー2日目の記事です。 今回は、スクラムマスターとして苦しんだ経験について、アンチパターン的に書いてみたいと思います。
スクラムマスターは2年ほど前からやらせてもらっており、今年に入ってから発足したチームで、もっとちゃんとスクラムマスターをやろうと本気で勉強をやり始めたという状況です。 今年の7月にスクラムマスター研修を受講し、認定スクラムマスターの資格を受け取ることが出来、スクラムに対してのチームの状況や自分自身の考え方も変わってきました。 その中での経験を書いていきます。
身を以て学んだアンチパターン
スクラムガイドはとても短くて読めば分かった気になります。しかし実際に導入してみると全くもって上手くいかないことが多いと感じています。 スクラム開始当初に持っていたスクラムに対しての認識違いによる失敗と、その後の対応と現状も含めて書いていきたいと思います。
スクラムが上手くいかなくて悩んでいる方、過去にやって諦めた方でもう一度やってみたいと考えている方の解決のヒントに少しでもなってくれればと思います。 内容には個人の見解的なものも含まれるので、何かご意見などありましたらぜひよろしくお願いいたします。
スクラムガイドを理解したつもりになっていた
スクラムガイドをちゃんと読んでいますか？
これがスクラムの全てだと思います。 ここに書いてあることをやっていないのであれば、それはスクラムではなく、スクラムっぽい何かということになります。 色々なプラクティスが出ていますが、あくまでもこのガイドに書かれていることを上手く実行できるようにするためのものなんです。
スクラムを導入するメリットとして、スクラムイベントで必要なコミュニケーションを行うことで、メンバー間の認識齟齬の解消や問題の早期発見と共有がしやすくなることが挙げられます。 ただ、スクラムイベントは結構な時間を取ってしまうために辛いと感じることがあると思います。 よくあるアンチパターンとして、毎日そんなに大きな問題は発生しないからとデイリースクラムを2日に1度にしたり、振り返ることなんてないと言ってレトロスペクティブを短くする、或いはスキップするなどがあります。これにより、そのうちにスクラムイベント自体を全く行わなくなったり、参加しない人が出てくるなどして、コミュニケーション量の低下や偏りが発生しやすくなります。
デイリーの中で進捗の話をするだけでも自分が認識していない影響範囲を誰かが気づいてくれるかもしれません。振り返ることがないというのは振り返りの方法に問題があるだけかもしれません。
とにかくまずはスクラムガイドの通りにやってみることが成功する近道だと考えます。 私の経験としても、悩んでいる時は書かれている通りに実行できていないことが多くありました。 何度も読み返してみて、ここから解決のヒントを探していくのが良いと思います。
スクラムによってリリースが早くできるわけではない
スクラム開始したので、これで予定通り終わる！これでもっと早くリリースできる！と思っていませんか？
スクラムガイドには「スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤している」と書かれています。 スクラムはそもそも複雑で曖昧な事に対して立ち向かうためのツールで、その過程で発生するリスクを早く発見して修正を行うためのものというのが正しいと思います。 もしかすると、ウォーターフォールと比べると問題の早期発見と解決のおかげで早く終わることはあるかもしれませんが、結局問題自体が消えるわけではないので、その解決コストは必要となります。
私もスクラム導入当初は、早くリリースできるという希望を抱きながらやっていました。 しかし実際にスクラムを導入してみると、イベントをどのように進めればいいのかが分からず時間がかかってしまったり、 プロダクトバックログアイテムについて話す中で考慮漏れや他の検討事項が出たために纏まらなかったりと全く開発を進められていないように見え、むしろ時間がかかってしまっているのではと疑問に感じることが続いていました。
これらの問題について、デイリーやレトロスペクティブで話して解決方法をチームで出していくことで少しずつ改善していきました。 イベントの進め方については、イベントの目的やそれを達成するためのアジェンダやTODOリストを作成し、何をするためのイベントなのかをチーム全員が認識できるようにしました。（下記のスクショ参照）イベント中に出た検討事項は、別のプロダクトバックログにアイテムとして追加したり、そのプロダクトバックログ自体を見直すようにしました。
おかげで少しずつイベント時間が減りましたし、チームで問題を解決していったことで問題提起がしやすい環境になるという効果もあり、取るべきコミュニケーションを取りやすくなったと感じています。
また、今だからこそ分かるのですが、導入当初はイベントの進め方が分からずに時間を食ってしまうものです。どんなフレームワークでも導入当初は学習コストが必要ですし、 イベント中の検討事項についても結局はどこかで話さないといけません。思いの外時間がかかっても、それは必要な時間なのだと割り切るようにしましょう。
見積もりを約束にしてはいけない
見積もりを約束（リリース日など）として使用していませんか？
2020版のスクラムガイドには見積もりについては触れていません。2017版ではあったのですが消されています。 これは見積もりを約束として使用されないようにするという理由があるそうです。
私も、ストーリポイントで見積もりを行い、1スプリントの平均をベロシティとして使用し、その達成具合を成果にしていました。 これを行うと、あるスプリントでの進捗が悪かった場合の振り返りで、見積もりが甘かったという話が出てくることがあり、その後見積もりを多めにし始めます。 そうすると今度は進捗が良くなるのですが、結局実際の進捗はどちらも変わっていないのが現実で、何の意味もない見積もりが生まれていました。 本来は振り返りで、進捗が悪くなった原因が何なのか（他の検討事項が発生したとか、影響範囲が想定以上になったとか）や、それに気付くタイミングや共有するタイミングは適切だったか、次回以降に同じようなことが発生した場合のアクションをどうするかを考えるべきです。
このような反省を活かして現在では、Tシャツサイズ（XS、S、M、L、XL）を用いてプランニングポーカーを行って、プロダクトバックログがどれくらいの作業量なのかの認識合わせのみを行なっています。 作業量の基準として、Mだとスプリント内でほぼ確実に完了可能なもの（約束はしません）、Lだとスプリント内で終わらせるのはちょっと難しそうだけどでも出来るかもしれない、というように定義しています。 各開発者の中で考えているサイズが違っていた場合は、作業内容の確認を行って、認識齟齬を無くしていくためのツールとして使用しています。
おかげで進捗の良し悪しについて話すよりも、もっと本質的なチームの課題について話すことが増え、意味のある振り返りになっています。
リリース日については、経験上からある程度の目安（３、４ヶ月後くらいとか）やデッドラインはありましたが、それを約束はできないということをステークホルダーに知ってもらい、開発を進めていく中で少しずつ具体的な日時を決めていきました。 もしもデッドラインを超えそうなことが見えてきた場合は、要件を絞るということをあらかじめステークホルダーとも話していました。
約束が出来ないということは組織によっては大変難しいかもしれませんが、スクラムでやる以上はこの事をステークホルダーに理解してもらうのが必須だと考えます。 そもそも、どんな手法で開発しても問題は発生しますし、対応の選択がコストしかない場合には結局リリース日は延びることになりますしね。 先にステークホルダーに理解してもらっておく方が気は楽だと思います。
プロダクトオーナーはスクラムチームメンバーでありお客様ではない
スプリントレビューは、開発者がプロダクトオーナーに対してレビューをする会になっていませんか？
スクラムガイドには、スプリントレビューは「スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う」と書いてあり、「スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される」とあります。 チームメンバーであるプロダクトオーナーも開発者と一緒に進捗を把握していて、開発者と一緒になってステークホルダーにレビューをする必要があります。
私のチームもプロダクトオーナーに対してレビューを行なっていました。 そうなると、プロダクトオーナーはスプリントレビューのみで進捗を把握することになるために、スプリント中に問題に気付きづらい状況になり、手戻りが発生しやすくなります。 そして、プロダクトオーナーがステークホルダーと同じ立場となっていくため、開発者がプロダクトオーナーにお伺いを立てるような状況となり、とりあえず雑にでも相談すれば良さそうなものを相談すべきかを検討してから相談するという状況も発生し、コミュニケーションコストがかかるようになっていきました。
これを解決するために、プロダクトオーナーが中心となってスプリントレビューを主催するようにし、バックログの細かい部分の確認はスプリント中にプロダクトオーナーに都度行うようにしました。 おかげでプロダクトオーナーと開発者のコミュニケーション量が増え、プロダクトオーナーが自然に進捗を把握できるようになってきています。 プロダクトオーナーと開発者がチームメンバーとして一緒にプロダクトを作成している感が少しずつ出来てきていると思います。
プロダクトオーナーと開発者の間に壁や溝ができないようにしたいですね。
ロール（プロダクトオーナー、スクラムマスター、開発者）の兼任は出来るだけやめた方が良い
ロールを兼任していて自分の役割は何なのか混乱していませんか？
ロールの兼任についてはスクラムガイドに明記されているものではありませんが、アンチパターンとして取り上げられがちです。理由としては上の通りですが、自分がどのロールで行動しているのかが分からなくなり混乱してくるためです。
実際に最初の頃の私もスクラムマスターと開発者を兼任しているために、特にスクラムイベント中にこの混乱で苦しんだ経験があります。 とはいえ、リソース的に仕方がない場合もあると思いますので、兼任している場合にはイベント中はどれかのロールに集中するのが良いと思います。 現在、私もイベント中は基本的にスクラムマスターとしてのロールで臨むようにしており、開発者として分かるような話も分からないフリして話したりもします。 あとは、会話中にプレフィックスを付けて「スクラムマスターの立場としては」「開発者の立場としては」というようにすると良かったりします。 これによって混乱が少なく進められているのでオススメの方法だと思います。 当然ですが、「お前この話わかってるだろ？」という感じにならないためにも、チームメンバーにはあえてそのように振る舞っていることは伝えた方が良いです。
ただし、プロダクトオーナーとスクラムマスターの兼任だけは絶対避けるべきです。
プロダクトオーナーはステークホルダーとの交渉を行い要件を決める役割を持っています。 スクラムマスターはプロダクトオーナーとステークホルダーとの交渉によって発生した開発への障害の盾となる役割を持っています。 この障害が発生した場合に、高確率でプロダクトオーナーの立場が勝ち、結果としてチームの崩壊がはじまっていくということになります。 実際に私がこの状況を経験したことはありませんが、容易に想像できます。 これはスクラムマスター研修内で教わったことで、とても大事なことだと思ったので書かせて頂きます。
最近は、兼任するのであればそれぞれのロールを別のチームでやった方が良く、スクラムマスターはAチームで、開発者はBチームでやるというように出来ればこの問題は避けやすいかも？と思いました。 試したことはないので、機会があればやってみたいと思います。
プロダクトバックログは会話ツール
プロダクトバックログを、プロダクトオーナーがプロダクトバックログアイテムの作成と管理をして、開発者はそれをタスクとして受け取って消化していくものと勘違いしていませんか？
上記のように使用するのであれば、それはスクラムではなくてウォーターフォール的になっていると思います。 スクラムガイドには「スクラムチームが⾏う作業の唯⼀の情報源である」とあり、「スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する」とあるように、 プロダクトオーナーと開発者が常にコミュニケーションを取りながら、何をやろうとしているのか、何からやっていくべきなのかの認識合わせをして、決めていく必要があります。 つまり、プロダクトバックログはプロダクトオーナーと開発者の会話ツールとして使用するべきものなのかなと思います。
私もはじめは勘違いしており、プロダクトオーナーから降りてくるタスクをタスクチケットボードのように扱っていました。 結果、プロダクトオーナーとの会話は最低限のものになり、スプリントレビューをプロダクトオーナーに対して行うようになり、プロダクトオーナーが開発者のお客様になってしまいました。そうなるとさらにコミュニケーションが取りづらくなります。例えば、開発者から見て些細な問題と思い報告していなかったものをリリース直前にプロダクトオーナーが知って、それが実は結構クリティカルなために急遽修正してからリリースしなければならないというような、コミュニケーション不足による問題と思われることが発生していました。
これを、プロダクトオーナーにはプロダクトバックログアイテムを思いついたら作成してもらうようにし、開発者も思いついたものを自由に作成出来るようにし、作成したらそれをチームで共有するようにしました。 また、プロダクトバックログの状況を更新＆認識合わせをしやすくするために毎週1時間はリファインメントを行うようにしました。（現在2週間スプリントで回しています）プロダクトバックログアイテムの内容によってはこの1時間では足りないこともあるので、別の時間を設けることもあります。 これにより、チーム内での会話が必然的に増えて自然と問題の共有もしやすくなり、最初と比べると認識齟齬による修正などは減っていきました。
コミュニケーションは大事。
まとめ
読んでいただきありがとうございます。 皆さんにとって、何かヒントになることがありましたら幸いです。
スクラムを導入してみて分かったことは、スクラムが組織に合わせてくれることは無く、組織がスクラムに合わせていかないと絶対に失敗すると感じました。 ステークホルダー、プロダクトオーナー、開発者、スクラムマスターが全員スクラムについて理解していくことで、ようやく上手く回り始めます。 そういう意味でも、スクラムをある程度順調に導入できているのは、今の組織のおかげなのだと感謝しかありません。 あらためて、協力していただいている転職会議事業部の皆さんありがとうございます。
まだまだチームとしても改善点はありますが、スクラムは継続していき、また何か面白いことがありましたらブログで書いてみたいと思います。
