プロダクトバックログとスプリントバックログを分かりやすく繋げる方法
近年、ウォーターフォール開発でなくアジャイル開発(とりわけスクラム開発)でのプロセスが増加しています。
スクラム開発を適切に運営できると、
- スモールスタートができる
- ニーズやデータに応じた仕様変更が柔軟にできる
- チーム力が高まる
という特徴があります。
そのため、変化の激しい現代にマッチしており、最近では主流な開発手法となっています。
一方で、なかなかスクラム開発が上手くいかずにメンバーのモチベーションや品質が低下している現場も多いのではないでしょうか。
この記事では、ブースターラボの経験知を元にして、スクラム開発を成功させるコツを以下のような対象者に向けて紹介していきます。
- デザイナーとエンジニアなど開発者の役割を分けたい組織
- スクラム開発を導入してみたが上手くいかない組織
- スクラム開発を導入しようとしている組織
スクラム開発がうまくいかない理由
メリットの多いスクラム開発ですが、実際の組織への導入には障壁があります。
これは、考え方の浸透不足とプロセスの定義不足が原因であることがほとんどです。
とりわけ、スクラムガイドではプロセスの部分は細かく定義されておらず、導入組織に委ねられる部分が多く、スクラム開発の体験がはじめての組織では難しく挫折してしまい、従来のウォーターフォール開発に戻してしまう組織も多々あります。
例えば、モバイルアプリやWebアプリといったプロダクトにおいて、開発者のロールの中にはエンジニアとデザイナーが必要な場合が多いでしょう。
もちろん、開発のどの工程でも担当できることは強い開発チームになりますが、現実的にはそこまでのレベルに達していないことがほとんどです。
そのため、プロダクトバックログアイテムに、デザイナーとエンジニアで別々の準備完了(Ready)ステータスが存在し、スプリントバックログに入れるプロセスがシームレスになっていないことがあります。
それこそが、スクラム開発が成功していない一つの要因です。
スクラム開発を成功させるプロセス設計の例
それでは、スクラム開発を成功させるためのプロセス設計について、先ほどのデザイナーとエンジニアがいるプロダクトを例にして解説していきます。
以下に、プロセス・プロダクトバックログのステータス・スプリントバックログのステータスについて、最低限のポイントを抑えた遷移図を記しています。
スクラムマスターを記載していませんが、もちろんプロセスを円滑に進められるようにスクラムマスターが支援する想定です。
この図は抑えておくべきポイントのみ記載しています。
そのため、プロダクトや組織の性質に応じてプロセスはカスタマイズしてください。
この中で、プロダクトバックログアイテムにおいて、UIUXが必要なものについては最初にデザインチームによるUIUXデザインを完了させておくことがポイントです。
そうすることで、エンジニアがスプリントバックログアイテムを詳細なタスクレベルまできちんと定義でき、要求・品質・スピードにブレの少ない活動が可能になります。
これによって、チームの責務が分かりやすくなり、自分たちがプロフェッショナルとして遂行すべき役割がより明確になります。
一方で、プロダクトのUIUXはユーザーの接点となる顔のような存在です。
これのレビューにはエンジニアも参加し、実現可能性やコストについて提言すると共に、情報格差を縮めておくことが重要です。
そして、スプリントレトロスペクティブによる振り返りを実施し、プロセスを組織に合うように改善していきましょう。
まとめ
生産現場ではトヨタ生産方式など確立された生産性向上の仕組みがあります。
サービス開発やプロジェクトにおいてはアジャイル開発が一つの方法となります。
そして、スクラム開発においては、スクラムの思想浸透と自分たちの組織に合ったプロセス設計と実行、その改善ができることが重要なポイントです。
【サービス案内】マネジメントを学習したい・学習させたい方へ
開発チーム・バックオフィスチーム等どのような担当でもアジャイルな働き方ができ、チームがいきいきしだす業務マネジメントの仕組みを学べる研修サービスを提供中です。また、チームの目標達成と人材育成ができるマネジメント人材のスキルアップを目的としたマネジメントコーチングサービスも提供中です。
また、生産性向上やDX、組織成長、人材育成が実現できるフレームワークの開発もしています。興味のある方はぜひこちらのドキュメントを一読ください。