スクラム開発の難しさと工夫

スクラム開発で新規サービスの開発をしているのですが、難しいなと思う部分と、それにどう対処しているかについて、1つピックアップして書いていければと思います。ご参考になればうれしいです！

スクラム開発の進め方

まず、スクラム開発の進め方について簡単に記載しておきます。
スクラムチームでは、優先度を明確に機能開発を進めていき、毎スプリント（1週間や2週間という単位で区切った開発期間）が終わったときに、リリースできる状態を目指します。

もちろん本当にリリースするには、機能として不十分かもしれないですが、プロダクトの品質を定義したDoD（Definition of Done）は都度担保しながら開発を行います。

機能や技術的改善要素に優先度をつけて記述したもののことを『プロダクトバックログ』と呼びます。

スクラムチーム内では毎回、開発の優先度が明確で、リリースできる品質を担保しながら、開発を進めるのです。

スクラム開発で難しいなと思うこと

そんな中、難しいなと思っているのは、『スクラムチーム外のステークホルダーとのコミュニケーション』です。

毎スプリントが終わるたびに、ステークホルダー含め、プロダクトをさわってもらい、改善につながるような意見をもらいます。色んな立場から色んな意見が出ます。

特に、発言権の強い人が「xxという機能をすぐに開発してほしい」といった場合に、「○○さんが言ったから」という理由だけで優先度を変えていると本来終わるはずだった別の機能の開発が終わらなかったり、全体に影響が出てきます。

ステークホルダーの方々は、スクラムチーム内で決めている優先度をあまり意識しているわけではないので、
「xxという機能を用意するには、yyという機能開発とのトレードオフになります。現時点で最も投資対効果が高いのはyyの開発なのでxxの開発は次スプリント以降で対応します」
と交渉できるか、がポイントになってきます。

工夫していること

とはいえ、いつも交渉がうまくいくとも限らないです。
そこで、自分はレビューや意見を、エクセルオンラインに記載してもらい、それにプロダクトオーナーが返信する形を導入しました。

こうすることで、
・レビュアーが、いつでも自分の意見を伝えることができるという安心感がある
・レビュアーが、伝えた意見に対して、スクラム内でどう検討が進んでいるのか分かる
という状態を作ることができました。

結果、『すぐにxxという機能を～』といった話にはなりにくくなったように感じます。

その他にもプロダクトバックログを見てもらいながら、優先度の根拠を説明する、などもやりますが、上記のちょっとした工夫はなかなか良かったなと思ったので共有させて頂きました。

以上、少しでも皆さんの参考になったら、うれしいです。

今後もスクラム開発の難しさや工夫していることをシェアしていければと思いますので、また読んで頂けるとすごく嬉しいです。

コメントやスキも励みになるので、もらえたら喜びます！最後までお読みいただきありがとうございました！