はじめに
こんにちは、WHITEPLUS エンジニアリング部 CX開発Gのhirasushiです。 CX開発Gでスクラムマスターをしています。 この記事では、現在のスクラム開発体制の中で、改善や技術的負債の返済にどう取り組んでいるかを紹介します。
改善/技術的負債への姿勢
CX開発Gでのスクラムは、1週間1スプリント、月曜始まりの金曜終わりというサイクルで実施しています。 月曜午前に振り返り（スプリントレトロスペクティブ）、午後に計画 というスケジュールです。 振り返りではKPTAフレームワークを採用しており、振り返りの最後にActionとして改善のための行動について合意します。
また、振り返りとは別に、毎日の業務内で技術的負債や改善点に気づいたら、その都度課題としてプロダクトバックログを起票するということもしています。 これはスクラムチームの個々人が、気づいたタイミングで行っています。
このように、チーム内では以前から改善や技術的負債に前向きな文化がありました。ですが...
改善/技術的負債返済を実際に実行するのは難しい
チーム内での問題として、Actionとして合意した、プロダクトバックログを起票した、しかし実際に実行されるのはその中の一部...という状態がありました。 原因としては、
- Actionを実行する時間が取れない
- スプリント計画で実行を決定したバックログに比べ、Actionはトラッキングにそれほど力をいれていなかったり、Actionよりバックログを完了させることを優先してしまったり...と、一つのActionの完了までに時間がかかる
- 改善系のバックログを実行できない
- スプリント計画時に、プロダクト課題のバックログのほうが優先され、改善系のバックログは計画に組み込まれない
というものがありました。 ですので、『改善系や技術的負債系のバックログを課題として認識はしているが、なかなかそれに着手できない』という状態となっていました（ストレスが大きい状態です）。
取り組みその1
この解消のために、リファクタリングタイムという時間を週1で設け、その時間内では通常のバックログには手を付けず、改善や技術的負債の返済を行うという取り組みを行いました。 （↓の記事で詳細を紹介しています）
ただ、現在ではこのリファクタリングタイムは行っていません。 それにはいくつか理由がありますが、
- リファクタリングタイムを超える時間が必要な課題に手を出しにくい
- リファクタリングタイム内で終えられなかった課題は次週に持ち越しになる -> 完了までに時間がかかる
- 組織体制変更の影響（他のイベントとのスケジュール調整）
などによります。 では、現在ではどのように改善/技術的負債返済に取り組んでいるのかといいますと...
現在の取り組み
今では、Actionや改善系の課題はプロダクトバックログとして登録した後『改善』カテゴリに入れ、 スプリント計画の際に予定ストーリーポイントの20%程度をこの『改善』カテゴリのプロダクトバックログから取り、計画に組み込むというやり方をしています。
このやり方の利点としては、
- サイズが大きめの改善でも取り組むことができる
- 確実に改善系のバックログを実施できる
があります。
欠点としては、
- プロダクト課題にあてられるストーリーポイントが少なくなる
というものが挙げられます。
このうち欠点に対しては、プロダクトオーナーとも協議の上、
- 改善を行っていくことはプロダクトにとっても必要
- 減少したストーリーポイントでも必要な機能開発は行える
ということを確認し、ストーリーポイントの減少について合意しました。
このやり方を導入してから、毎週着実に改善タスクを実施できるようになりました。 改善系や技術的負債系のバックログを課題として挙げ、それを実際に実行できるというのはプロダクトにとっても良い影響がありますし、開発者としても嬉しい状態です。
今後もスクラムにおいて課題が出てきた場合、このように仕組みを改善していきたいと考えています。
おわりに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。どんな会社か気になった方はオウンドメディア「ホワプラSTYLE」をぜひご覧ください。
オンラインでカジュアル面談もできますので、今回の記事の内容に興味を持っていただけたら、ぜひお気軽にお問い合わせください。
