2022-10-19

スクラムでプロダクトバックログの改善に取り組んでいる話

hono3bono3

　こんにちは、バックエンドエンジニアの@hono3bono3です。 7月より入社しました。趣味は猫です。よろしくお願いします。

スクラムの改善に取り組んでいる話

　先日、スマートショッピングのエンジニア本部ではメンバーの増加に伴いチームの再編が行われました。自分も入社直後に配属されたチームからは異動となり、新たにスクラムを採用しているプロジェクトにアサインされました。　チームは社内PdMメンバーがプロダクトオーナーを、その他エンジニア本部のメンバーがスクラムマスターと開発チームを担うという構成で、日々のデイリースクラムやスプリントプランニング、レビューと振り返りを2週間のスプリントで実施していました。夏のはじめ頃に新規プロジェクトとして始動してから5スプリントほどが経過し、いろいろ見えてきた課題も多くなってきている状況でした。そこで、今回のチーム再編を機にスクラムの運用方法を見直すことにしました。

これまでの振り返りと課題分析

レトロスペクティブはKPT形式で運用されていました。直近のレトロスペクティブでは次のようなプロブレムが提起されていました。

スプリントレビューが進捗報告会のようになっている
プロジェクトの全体感と現在地がわからない
タスクの具体的な作業がわかりづらい

　各メンバーは「タスクをこなしているものの、スケジュール感や仕様共有のやり方などでなんとなく不安がある」という状況でした。　そこでこれらのプロブレムを元に現在のチームの活動を分析し、トライとしてプロダクトバックログの改善に取り組むこととなりました。

それまでのバックログは、以下のような運用になっていました。

1つのプロダクトバックログアイテムがスプリントをまたがって消化されている
プロダクトバックログが各工程毎のタスクの一覧になっている
完了の定義・優先度が曖昧、または可視化されていない

それぞれ、以下のような問題がありました。

1. ひとつのプロダクトバックログアイテムがスプリントをまたがって消化されている

　当初は、大きなひとつの機能をひとつのプロダクトバックログアイテム（以下PBI）として管理していました。スプリントでは、その機能のうちバックエンドやフロントエンドなど各工程が今スプリントでやる分を宣言し実施するという流れになっていました。　これらは、一度のスプリントで終わる大きさではないため複数スプリントをまたがって消化される状態になっていました。

　そのため「どこまでやるか」という前提の共有が曖昧になり、具体的な作業の見えづらい状態になっていました。また、実装工程が終わった機能であってもテスト工程が完了していない（＝仕掛かりのまま残り続ける）ため、長期間リリース可能にならないという問題がありました。　テスト工程は最後にまとめて実施する計画になっていたため、後から追加のバグ修正が大量発生するという状況も徐々に現れ始めていました。このような状況は、「実装が終わっているのでなんとなく終わった感があるけど実際はまだ終わっていない」という曖昧な状態が続くため、心理的な負担が大きくメンバーが不安になりやすい状態といえます。

2. プロダクトバックログが各担当者毎のタスクの一覧になっている

PBIは機能単位のほか、各工程のタスクベースで作成されているものがありました。これらはバックエンドのタスクリスト、フロントエンドのタスクリストというように別々に管理されており、各メンバーがプロダクト進行中に気づいたタスクを自身の担当の一覧に追加するという運用になっていました。

工程別に管理されたタスク一覧

　各メンバーが気づいた時にすぐタスク化できるというメリットがある一方、担当毎の工程視点のタスクが多くなり、プロダクトオーナーが優先度の判断しづらいものが多くなっていました。また工程視点の言葉で作成されているため、担当外のタスクだと何が行われているか分かりづらくスプリントレビューも進捗報告のようになり意見がしづらく、フィードバックが出づらい状態になりやすいです。

3. 完了の定義・優先度が曖昧、または可視化されていない

　各PBIは、機能などについて仕様書はあるもののタイトルのみで完了条件が定義されていないまま登録されているものが多くありました。また、「何を、いつ頃に」という優先度が明確に定義されていませんでした。

　そのため、新たに発生した要件について「今対応策を考えるべきか」の検討が曖昧なままミーティングが開催され、リリース自体はもっと後でよいということが後で発覚するということがありました。一方で直近で取り組んでいるタスクについての仕様検討が十分に詰められておらず、確認・手戻りが度々発生していました。

やったこと

　これらは自工程の作業管理のしやすさだったり、PBIの起票ルールが簡素なことでメンバーが報告しやすいというメリットがありました。一方で、工程毎の部分最適が積み重なることによって全体では「プロジェクトとしてどこまで終わっているかわからない」などの各メンバーの課題感、不安感につながっていったものと考えられます。　まとめると、作成物ではなくタスクに着目する運用になっていたといえます。各メンバーが自工程に特化して作業効率を上げていくと、工程間での作業量や進捗状況に差が生じてしまい、仕掛りが増え、作りすぎのムダ、早すぎる最適化などが発生します。

また、1〜3は相互に関連していると考えられます。

PBIがスプリントをまたがるほど巨大なため、完了条件が定義しきれない PBIが一スプリントで終わらず完了条件が曖昧になっているため、各工程の進捗管理に最適化されていく各工程に最適化されているため工程毎のタスクが切られ、チーム全体での優先度が判断できる人がいない（別工程が何をやっているかわからなくなる）。逆に、チーム全体の優先度が曖昧なため、各担当者が自身の判断したタイミングで自身のタスクを消化するようになる。

なので、一度に改善する必要があると判断し、次スプリント開始に合わせて以下のような運用に変更しました。

プロダクトバックログの役割を再定義する

プロダクトバックログは、単なる作業者の進捗管理ボードではなく、チームのコミュケーションの源泉となるツールとして活用するよう方向性を定めました。

まずは以下のようにPBI作成ルールの取り決めを行いました。

目的が誰にでもわかるように書く
直近で取り組むものは、1つのスプリントで完結する粒度にする
各PBI同士の優先度を常に明確にする
完了の定義を明確にする

　また、各工程ごとに別れていたタスク一覧を、シンプルにTODO・進行中・完了のみに集約しました。既存のPBIについては各担当者にヒアリングし、プロダクトオーナーが内容を判断できるようにタイトル・説明文を再定義し直しました。チームが取り組んでいるタスクを誰にでもわかるように意識することでコミュニケーションが生まれやすくなります。これにより、全てのアイテムの優先度をプロダクトオーナーが比較できるようになり、優先度の高い順に並べ直すことができるようになりました。また、他のメンバーからも次のリリース予定までに何を作るべきか・作らなくてもよいかが明確になり、開発状況に応じたタスクの交渉がしやすくした。また、プロダクトの状況がチーム内外から見ても分かりやすくなりました。

並行して、プロダクトオーナーと一緒に直近のスプリントで取り組むプロダクトバックログアイテムを一度のスプリント内におさまるように分解しました。完了の定義を「リリース可能な状態のもの」とし、各アイテムの受け入れ条件を明示するようにしました。

　これにより、スプリント毎にリリース可能な成果物を出すというフローに変化しました。常にリリースされ仕掛かり品が減ることで、スプリントのタスクに集中できることが期待されます。

これらを実施した上で、プロダクトオーナーと日々の業務として

次回のプランニングまでに開発者が着手を円滑に進められるように完了条件を定義する
直近で着手予定のPBIはリリースが可能な単位でユーザーストーリーを分割し、優先度をつける

を意識的に行い、日々のメンテナンスで維持していく必要があることの認識合わせを行いました。

運用変更にあたっての懸念事項

部分最適を全体最適に変えていく際、多くの場合「これまでよりしんどい......」といった、面倒を感じる場面や負担が増える人が出てきます。作成ルールのひとつ「PBIは目的が誰にでもわかるように書く」や「完了の定義を明確にする」は、慣れるまでは戸惑いやすい作業のひとつです。技術改善などの開発のみが取り扱う作業は普段専門用語で会話されることが多く、ユーザー目線の言葉に置き換えることが難しいものも少なくありません。そのため、問題に気づいた時すぐバックログに追加できる状態になっていないと、忙しい時つい後回しになりがちです。時間がかかっているうちに他タスクの割り込みで中断されそのまま忘れられてしまったりといったことも起こりやすくなります。報告の仕組みが機能しないままプロダクトオーナー・開発チームそれぞれだけが持つ知識量が多くなってしまうと、優先度の判断がされない・リリース時期直前になって発覚し炎上するなどのリスクにつながります。

共通理解の領域以外が広いほど、プロダクトのリスクが高い。

以前の各工程毎のタスク一覧を持つ運用では、気づきをタスク化しやすいというメリットがあり、それを失いたくはありませんでした。そこで形式を気にせず誰でも追加できる場所を新たに作り、懸念事項はすべてそこに報告するルールにしました。追加された内容は後ほどプロダクトオーナーがヒアリングし、PBIとして新たに作成するという作業を追加しました。プロダクトオーナーの負担増が課題になる可能性がありますが、チームが今の運用に慣れるまでスクラムマスターが重点的にサポートして対応していく方針です。これまでのところ、メンバーからのアラートも以前同様スムーズに共有され、うまく回っていきそうな手応えを感じています。

まとめ

　もともと問題意識・改善意欲の高いメンバーが揃っていたため、運用ルールの変更は比較的スムーズに受け入れられました。優先度が明確になったことでプロダクトの予定の見通しが良くなったように思います。　今後やりづらい面が見えてきたり別の問題点が出てくることかと思いますが、チームが失敗を経験することがあらかじめ組み込まれていることがスクラムの良いところだと思います。新たに出た課題はレトロスペクティブや日々の会話を通じて引き続き改善していけたらと思います。