はじめに

こんにちは，Shoheiです。

今回は「スクラムマスターは開発をやってもいい？」とういうテーマで記事を書いていこうと思います。

現在，都内のSaaS系スタートアップ企業でエンジニアとして所属していながら，現在スクラムマスターとしてスクラム開発の改善に努めています。

回答

スプリントレビューでは，そのスプリントで積み上げたプロダクトのインクリメント（価値提供できる単位の追加開発）についてレビューしてもらいます。

例えば「サービス管理者がサービスへのアクセス状態からユーザー行動を知りたい」というスプリントゴールを掲げたスプリントについて考えてみます。

このゴールを達成する手段としては、例えば「レポート機能を作る」や「アクセスログをCSVファイルとしてダウンロードする機能を作る」など様々な達成方法が考えられます。

スプリントレビューでは、この達成した手段についてのレビューや細かな機能の仕様についてレビューをするのではなく、この機能や仕様によってスプリントゴールを達成できているかどうか、についてレビューを行います。

例えばレポート機能によってスプリントゴールの達成を実現しようとした場合、スプリントレビューで議論されることは、

今のレポート内容でユーザー（サービス管理者）は本当にユーザー行動を知れるのか

他に必要な情報がないか

レポート機能（情報の見せ方）がそれを達成するために必要十分か

など、実際のユーザーが昨日に感じる価値についての話題になると思います。

もしかすると、ステークホルダーからのフィードバックによりレポート機能よりも、CSVファイルに書き出してもらえた方がユーザーの使い勝手が良く、機能を一から作り直し、なんていうこともあるかもしれません。

そうならないためにもスクラムメンバーはバックログリファインメントや毎回のスプリントレビューにおいて、ユーザーの本当に求めている価値について理解を深めていく必要があります。

しかし、一つ注意しなければいけないことがあります。

ステークホルダーのフィードバックが必ずしも正解であるとは限らない、という点です。

ステークホルダーがこう言ったから仕様を変えました。は絶対にあってはなりません。

ステークホルダーは重要な人物ではありますが、サービスのリリースゲートや仕様の決定者ではありません。

スプリントレビューで得られたフィードバックは参考となる情報ではありますが、必ず厳守しなければいけない情報ではありません。

その点注意しましょう。