はじめに
はじめまして。スタイル・エッジのOと申します。
現在、あるプロジェクトにてプロダクトオーナー(PO)を務めております。
本プロジェクトでは、試験的にスクラムを導入し、1年以上にわたり運用を続けてきました。
しかし導入当初は、スクラムの経験者が一人もおらず、手探りでのスタートだったため、うまくいかないことも多くありました。
今回は、スクラムを導入する中で直面した課題と、それに対してどのように改善を進めてきたのかを、ナレッジとしてご紹介いたします。
同じような悩みを抱えている方の参考になれば幸いです!
スクラムでうまくいかなかったこと
デイリースクラム(朝会)が進捗報告だけの場になっていた
デイリースクラムの目的は、その日の作業を明確にし、計画を調整し、問題があれば迅速に対処することです。
一般的には15分程度が推奨されており、シンプルで効果的なミーティングであるはずですが、当時は以下のような課題がありました。
- 各々の進捗報告のみで終わってしまい、チーム全体に共有すべき情報が時々、漏れていることがあった
- タスクをホワイトボードで共有していたが、構成に課題があり「誰が」「どれくらいの量の作業をしているのか」が分かりづらかった
- 誰が何をしているのか分からないため、自然とフォローの意識も希薄になっていた
- 「処理中」の中に多様なステータスが混在し、タスク状況が読み取れなかった。開発中なのか?コードレビュー中なのか?検証中なのか?が分かりづらかった
- 1人ずつ「今日やること」を順番に話していくだけで、30分以上かかっていた。話すことに時間がかかって、スプリントゴール達成に向けた協力や相談ができていなかった
各メンバーのタスク共有用ボード
このように毎日メンバー全員が集まる時間を確保していましたがあまり効果はなく、「チームでプロダクトを作る」というよりは、「各々が自分の作業を進めているだけ」の状態に陥っていました。
違和感は覚えつつも、何が原因か分からず、スクラムに詳しいメンバーもいなかったため、デイリースクラムを漫然と続けていました。
しかし、スクラムマスターがチームに加わったことで、少しずつ改善が進み始めました。
デイリースクラムの改善
全体で共有すべき事項をまとめる「全体共有欄」を設け、最初にそこを確認する運用に変更しました
これにより、全体共有すべきことを先に話すようになり、連絡漏れも減りました全体共有欄 メンバー別にタスク管理できるページを作成しました
メンバーごとの作業量が可視化され、誰がどれくらいの量の作業をしているか把握しやすくなりましたタスク管理欄 2の改善で忙しい人や困っている人がわかりやすくなり、自然とフォローも増えていきました
ステータスでタスク状態が可視化され、各メンバーのタスク進捗状況が一目で把握できるようになりました
例として「処理中」でまとめていたステータスを「着手中」「クライアント確認中」「リリース待ち」と細分化しました当日の予定を記載しておき、共有したいことをピンポイントで伝えるようにして時間短縮しました
今日の予定や共有したいこと欄
この工夫により、メンバー同士が「困っていること」「相談したいこと」などを話す時間を確保できるようになりました
その結果、課題が発生したときに相談→早期解決が可能になりました
現在は2週間のスプリントで運用しており、1週目の金曜日には「予定通りリリースできそうか?」を朝会で確認しています。
難しそうな場合は、優先度をつけてリリース対象を見直す運用に変更しました。
上記改善により毎スプリント、クライアントに価値を提供できる状態になり、クライアントから良い評価も頂けるようになりました。
デイリースクラムの課題は解決した一方で、リファインメントにも課題がありました。
リファインメントでプロダクトバックログアイテムの見直しが進まない
リファインメントの目的は、プランニング前にプロダクトバックログアイテム(PBI)の内容を確認し、疑問点を解消することです。
しかし、当時の私は「リファインメント前にPBIをどのような状態にするべきか」や「プランニングに必要な情報は何か」といった基本が明確でなく、効率の悪い進め方をしていました。
具体的には、次のような課題がありました。
- 「各ロール(PO・デザイナー・開発メンバー)がどのタスクを担当するのか」が可視化されておらず、1スプリントの各ロールごとのタスクがわかりにくかった
- 優先度が高いPBIが多く、その全てのPBIをリファインメントで説明できるよう準備していたため、時間がかかっていた
- 優先度は数値で管理していたが、スプリント内での優先順位が明確になっていなかった
- デザイナー向けの説明に開発メンバーが長時間付き合う必要があり、非効率だった
POになったばかりということもあり、リファインメントがうまく進まないことで、プランニングも滞り、悪循環が続いていました。
リファインメントの改善
リファインメントについては以下のような改善を実施しました。
- 各ロール(PO・デザイナー・開発メンバー)が「次スプリントで何をやるか?」を可視化しました
これによって1スプリント内のチーム全体のタスクがパっとみてわかるようになりましたリファインメントの改善 - POは次スプリントに向けたPBIに絞って準備をするようにしました
- タスクの優先度を可視化し、POがMUSTでリリースしたいタスクはどれか?といった話をリファインメントで相談するようにしました
タスクの優先度は左側の方が高い - POとデザイナーが定期的に打ち合わせを行い、事前に次スプリントのPBIを確認するようにしました
これにより、リファインメント当日は開発メンバーへの説明に集中でき、理解促進や疑問解消に注力できるようになりました
結果として、PO自身の業務時間にも余裕が生まれ、クライアントとのコミュニケーションや現場課題の発見に、より多くの時間を充てられるようになりました。
終わりに
ここまで、スクラムイベントで直面した課題と、その改善策についてご紹介してきました。
私自身、スクラムの経験が浅く、迷うことも多々ありましたが、「まずは基本を知ることの大切さ」を強く実感しています。
最近では、優先順位の付け方やレトロスペクティブの進め方についても、さらなる改善に取り組んでいます。
今後も試行錯誤を重ねながら、より顧客にとって価値の高いプロダクトを作るために、チームに合ったスクラム運用を目指していきます。
一緒に働く仲間を募集しています!
スタイル・エッジでは、共に働いてくれる仲間を募集しています! もし興味をお持ちいただけましたら、ぜひ採用サイトをご覧ください!