👀概要
パーソルホールディングス デジタル開発部 SBUデジタル開発室の武田です。
今回は、とある開発チームの開発プロセスを改善し、自走するスクラム開発チームとなるまで伴走した話について紹介します。
👨👩👧👦対象者(Who)
- パーソルホールディングスの内製開発についてご興味がある方
- スクラム導入、改善を推進されている方
📌関連リンク
🗒️目次
- 背景
- 開発プロセス改善
- PBI細分化・可視化
- プランニングポーカー
- スプリントプランニング
- 開発チーム内相互レビュー
- 開発プロセス改善結果
- ベロシティ可視化
- 自己効力感向上
- 自走するスクラム開発チームへ
- 開発を軌道に乗せるために取り組んだこと
- 前提条件を早期に整える
- 開発に集中できる環境を整える
- 本当に作るべきものが何かに向き合う
- 決断コストを減らす
- まとめ
📝 内容
背景
SBUデジタル開発室には3つの開発チームがあります。
私は、そのうちの1つの開発チームにTL(テックリード)として入り、バックオフィス業務を省力化する生成AIプロダクトの開発に取り組むことになりました。
プロダクトを開発するに当たり、私が入った開発チームには、以下の目標がありました。
- 開発チームで開発を主導できるようになりたい
- 開発チームの生産性を正確に計測できるようにしたい
そこで、開発チームに入り、少しずつ開発プロセスを改善していきました。
開発プロセス改善
開発チームが自律的に開発を進められる土台を築くために、以下の取り組みを行いました。
PBI細分化・可視化
PO(プロダクトオーナー)が起票したPBI(プロダクトバックログアイテム)を全て確認し、各メンバーが迷わず取り組めるようにFE/BE/インフラといった担当レベルで細分化したり、内容や完了条件を詳細化したりしました。
次に、開発メンバー全員が開発の全体感や方向性がわかるよう、PBIの依存関係を整理し、可視化しました。
プランニングポーカー
開発メンバー全員で集まり、詳細化したPBIを確認し、各PBIへの解像度を高めました。
そして、プランニングポーカーで、チームとしてのベロシティを計測できるように、開発メンバー全員で各PBIのストーリーポイントを見積もりました。
スプリントプランニング
PBIの依存関係を確認し、開発メンバー全員で開発の全体感を把握するようにしました。
また、スプリントで取り組むPBIを開発メンバー全員で決めました。
開発チーム内相互レビュー
属人化を防ぐために、開発メンバー全員で各PBIの成果物をレビューするようにし、各メンバーがPBIで何に取り組み、成果物として何を作成したかを全員で把握するようにしました。
開発プロセス改善結果
開発プロセスを改善した結果、明確な変化が現れました。
ベロシティ可視化
これまで正確に測れていなかったベロシティを計測できるようになりました。
ベロシティが計測できるようになったことで、開発チームとして各スプリントで取り組めるストーリーポイントを把握し、実績値ベースで次スプリントの計画が立てられるようになりました。
自己効力感向上
開発プロセスを改善した結果、プロジェクト開始から徐々にベロシティが向上し、開発メンバーのモチベーションアップにつながりました。
また、各メンバーのPBIやプロジェクトに対する解像度が上がり、プロダクト開発を前進させている当事者意識とコミットメント感覚の醸成につながりました。
自走するスクラム開発チームへ
プロジェクト終盤、私が別プロジェクトをメインで担当することになり、徐々に軸足を移すことになってしまいましたが、開発チームは自律してプロダクト開発を完遂しました。
PBIの詳細化や見積もり、レビューといった一連のイベントを自律して回すようになり、自走するスクラム開発チームへと進化しました。
開発を軌道に乗せるために取り組んだこと
開発プロセス改善の他に、プロダクト開発を成功に導くために、取り組んだことについても紹介します。
ここでは、開発を軌道に乗せるために取り組んだこと（スクラムでいうインペディメントの除去）について記載します。
前提条件を早期に整える
PBIを詳細化する際に、前提条件が決まらないと取り組めないPBIであることが判明した場合は早急にPOに確認するようにしました。
開発に集中できる環境を整える
開発メンバーが開発に集中できるように、PBIの整理やセキュリティ関連の社内手続き、BI構築調整などの開発以外の割り込みタスクを引き取りました。
本当に作るべきものが何かに向き合う
実は、今回開発したプロダクトですが、初回のユーザーレビューでユーザーからこのままでは現場でプロダクトは使われないと評価されました。
翌日のデイリーですぐPOに「開発メンバー含めコンセプトを一から一緒に考えませんか？」と打診し、全員で本当に作るべきものが何かを話し合い、コンセプトを見直しました。
その結果、次回のユーザーレビューで受け入れられ、最終的にユーザーからご評価いただくに至りました。
決断コストを減らす
プロダクトの効果測定のためにBIを構築する要件があったのですが、調整難航によりペンディングとなっていました。
そこで、取り得るアーキテクチャ案をメリット、デメリットとともに比較表として整理し、POに提示しました。
判断材料を整えることでPOの決断コストを下げ、調整を前進させることができました。
まとめ
この記事では、開発プロセス改善による自走するスクラム開発チーム立ち上げと、プロダクト開発の障害を取り除くための取り組みについて紹介しました。
今回ご紹介した内容が、皆さまのスクラム開発のヒントにつながれば幸いです。