ふりかえりとスクラムイベントの改善。新チーム結成から半年間の軌跡

SEARCH WRITEのプロダクトマネージャーをしている吉継と申します。もとは開発者としてSEARCH WRITEに参画していましたが、半年ほど前に新チーム体制になりプロダクトマネージャーの役割になりました。
新チーム体制では、今までうまくいっていたやり方がうまくいかなくなったり、メンバー間のプロダクトへの理解の差からくるコミュニケーションエラーが発生したりと多くの課題に直面しました。
開発者ではなくプロダクトマネージャーの視点で、これらの課題にチームでどう立ち向かって解決していったかをまとめました。みなさんのチームに何か1つでも持ち帰っていただければと思います。

弊社ではスクラムチームにおけるプロダクトオーナーの役割をプロダクトマネージャーが担っています。もちろん開発業務だけではなく、カスタマーサクセスとの連携やロードマップの作成・リソース管理などのビジネス領域、画面仕様の設計などのUX領域の業務も担当しています。

半年前と比べると、開発のサイクルがうまく回っているなという実感を持っています。もう少し具体的にお話しすると、プロダクトマネージャーの目線では以下のような変化がありました。

• 開発者と開発内容の共通認識を作りやすくなった
• スプリント計画に大きなズレがなくなった
• 運用業務なども含めて作業の透明化が進み、差し込み対応などの隠れタスクがなくなった

これらの要因として、スクラムイベントの改善を続けたことが大きかったのではないかと考えています。特に、リファインメントとプランニングのあり方は半年前と比べて変化しています。この記事では、私たちが現在のスクラムイベントの形にたどり着くまでの過程を書き記すことができればと考えています。

ここで重要なのは、全ての改善は週次のチームふりかえりのアクションとして行われた点です。スクラムイベントのあり方に決まった正解があるのではなく、チームの個性や状況に応じてうまくいく形を見つけていくことが大切だと考えています。あくまで１チームの例としてご覧いただければと思います。

スクラムチームの状況

SEARCH WRITEは、2021年12月現在でリリースから約2年のプロダクトです。2021年の4月から6月にかけて、別のプロダクトチームが発足し、大規模なメンバーの入れ替えが発生しました。私がプロダクトマネージャーになったのもそのタイミングです。その結果、新たなチームメンバーでスタートを切ることとなりました。 

成熟度の高いこれまでのチームではうまくいっていたやり方でも、うまくいかなくなってしまうことが多々ありました。具体的には次のような問題を抱えていました。

• 運用業務などの流れを全員が把握できていないため、一部のメンバーに隠れタスクが発生してしまっていた
• プロダクトの理解度に違いがあるため、開発内容の認識や見積もりの精度にメンバーごとの差が出てしまった

そのため開発を進めると同時に、ふりかえりを通してプロセス改善を行う必要がありました。

ふりかえりでのスクラムイベント改善の軌跡

第一話：隠れタスクをなくすには？

課題

運用業務やリリース作業など、一部の業務が暗黙的に行われている状態でした。そのため、開発メンバー間でお互いが何の作業をしているのか把握できておらず、スプリントを正確に見積もれない問題が発生していました。また、仮にタスク漏れなどが発生しても気がつけないリスクも孕んでいました。

背景には、毎日のデイリースクラムで開発チケットは確認されているが、運用業務などには触れられていないことがあるのではないかと考えました。

アクション

以下のルールを取り決め、徹底するようにしました。

• スプリントで行うすべての業務はリファインメントに持ってくる
• リファインメントに持ってくるプロダクトバックログアイテムは誰が作成しても良い
• カンバンボード上に漏れなく業務を並べる

リファインメントで共有されていないものは原則着手することができません。またリリース作業やドキュメント作成といった暗黙化されがちだったタスクも含めて、全てタスク管理を行うようにしました。

結果

デイリースクラムの場だけで、運用業務なども含め、スプリント内で対応する必要がある業務を全て把握できる様になりました。

第二話：開発内容の認識を合わせるには？

課題

次に発生した問題が、開発内容の共通認識が取れていないことでした。細かい仕様などの認識が合っておらず、スプリントの終盤になってそれに気づくことが何度かありました。経験の長い一部のメンバーに頼りきりになっていたことが原因の一つでした。

アクション

リファインメントで新たなバックログアイテムの共有を行う際に、以下の手順を取り入れました。

1. 作成者が必ず、開発を通して得られるリターンと完了条件を説明する
2. チーム全員でストーリーポイントでのサイズ感の相対見積もりを行う

相対見積もりでは、1, 2, 3, 5, 8, 13の数字を「せーの！」でチャット上に入力します。数字にズレがある場合は意見が一致するまで議論します。絶対見積もりでは、それをもとに人日単位での必要工数を見積もります。

相対見積もりだけでなく絶対見積もりも行う理由としては、各リファインメントごとにストーリーポイントの基準はまちまちなので、プランニング時におしなべて判断できる基準が必要となるためです。

リファインメントで議論後のバックログアイテムの例

結果

全員が以下の共通認識を持った上でスプリントを開始することができるようになりました。

• どういった目的やメリットがある開発なのか
• 満たさなければならない要件は何か
• どれくらいの作業工数が発生する見込みか

その結果、仕様に関する認識のズレなどが大きく減少し、チームで課題点や実装方針に関する議論も活発に起こるようになりました。

第三話：キャパシティの正確な見積もり

課題

認識違いなどがなくなり、少しずつ安定したアウトプットを出せるようになってきました。しかし、次にキャパシティに関する問題が発生しました。スプリントでチームのキャパシティを超えた量に着手してしまい、計画していたチケットを一部完了できなかったり、高負荷状態が続いてしまったりということがありました。

アクション

スプリントプランニングで、開発メンバーの共有カレンダーを見ながら、別業務などを考慮した上でのスプリントのキャパシティを見積もるようにしました。また、スプリントを管理するシート上で、それぞれのプロダクトバックログアイテムの担当者達と完了予定日を当てはめ、確認したキャパシティを超えないかを再度確認するようにしました。

結果

キャパシティを超えた量のスプリント計画をすることがほとんどなくなりました。また、各個人の工数から完了予定日を事前に見積もることで、デイリースクラムで検査できるようになり、チームでスプリントの動き方を再考することができるようになりました。

第四話：開発者に方向性を示すには？

課題

キャパシティを正確に見積もることができるようになり、しかしスプリント内で何らかの障害が発生した場合、計画変更を余儀なくされる場合があります。その際に、どのプロダクトバックログアイテムから優先すべきなのかという議論がなされていないという課題がありました。

アクション

プロダクトマネージャーがスプリントを管理するシートにスプリントゴールを明記するようにしました。少なくとも2~3スプリント先までのスプリントゴールを設定します。

スプリント管理シートとスプリントゴールの例

結果

これまで1ヶ月単位でのプロジェクトごとのロードマップを引くかたちでプロダクトマネジメントを行っていたのですが、それに加えてスプリントゴールを示すことで開発チームに対して今後の方向性を示すことができるようになりました。

また、想定外の事態が起きた場合には「スプリントゴールの達成のためにどう動けばよいか」という議論がチーム全体で行われるようになりました。

第五話：プロダクトバックログと優先順位

課題

スプリントゴールを設定するようになり、開発サイクルはかなりうまく回るようになっていました。しかし、毎回のプランニングでプロダクトバックログアイテムの優先順位を議論しきるのは難しく、新しく追加されたものがどうしても優先されてしまう傾向がありました。プロダクトゴールへのインパクトを評価したうえで、常に優先順位をアップデートする必要がありました。

アクション

リファインメントで共有済みのプロダクトバックログアイテムを、優先順位が高い順番に並び替えられる仕組みを作成しました。毎スプリントのリファインメントの際に、並び替えする運用を行いました。

上記のようなボードで上から優先順位を表しています。

結果

プロダクトバックログの並び替えを行うことで、「上から順番に開発していけばよい」という状態を作ることができました。またバックログと優先順位を全員がいつでも見られる状態で共有することができ、さらに見通しが立てられやすくなりました。 

そして辿り着いた現在のスクラムイベントの流れ

2021年12月現在のSEARCH WRITEチームのリファインメントとプランニングの流れは以下の通りです。なお、木曜日スタートの1週間をスプリント単位としており、リファインメントは火曜日に、スプリントレビューとふりかえり、プランニングは水曜日に実施しています。またプロダクトバックログアイテムはカンバン方式にてチケット管理を行っています。

リファインメントの流れ

1. 現在のスプリントで着手したプロダクトバックログアイテムのサイズ感の見直しを行います。もし当初の見積もりと違った場合、チームで議論の上、実際のサイズ感に改めます。
2. 新しく追加するプロダクトバックログアイテムを持ち寄り、その内容を作成者が説明します。その際、以下のルールを徹底しています。
   • プロダクトバックログアイテムは誰が作成しても良いですが、スプリントで行うすべての開発はリファインメントに持ってくる必要があります。リファインメントで共有されていないものは原則着手することができません。
   • プロダクトバックログアイテムごとに、必ず解決したい課題とプロダクトに対するリターンを明記する必要があります。
   • プロダクトバックログアイテムごとに、必ずDone条件(完了の定義)を明記する必要があります。
3. ストーリーポイントでの工数の相対見積もりを行います。
4. ストーリーポイントをもとに工数の絶対見積もりを行います。
5. プロダクトバックログアイテムの優先順位を見直します。

プランニングの流れ

1. 開発メンバーの共有カレンダーを見ながら、別業務などを考慮した上でのスプリントのキャパシティを見積もります。
2. 次のスプリントゴールを確認します。
3. 「スプリント管理シート」に、次スプリントで着手するプロダクトバックログアイテムを記載します。その際に完了予定日と担当者を記入し、キャパシティを超えていないかを確認します。

まとめ

この記事を通して伝えたいことは、ふりかえりを通して改善を続けることの大切さです。

スクラムガイドを読むだけでは理解が及ばなかった部分がたくさんありました。
しかし、実際に直面した課題に向き合いながらよりよいチーム開発を目指し続けた結果、自分たちの納得できるスタイルを築くことができたなと思います。

もちろんこれがゴールではなく、終わりのない改善を続けていきたいと考えています。