スプリントレビューとレトロスペクティブの違いを「不確実性」の観点から解説してみた!
はじめに
こんにちは!メンバーズでスクラムマスターをしている小島です。
この前あるチームからスプリントレビューについての質問を受けた時に、実はこの2つのイベントの目的や位置付けの違いをちゃんと理解できてない人は多いのかも?という発見があったので解説記事を書いてみました。
前提
スクラムは複雑な問題を対象としている
まず前提としてスクラムは何をしようとしているのかについてお話ししておきます。
スクラムガイド2020を見てみると、スクラムの定義の中に以下のような記載があります。
スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。スクラムガイド2020 p.4
「複雑な問題に対応する」という文言が重要なキーワードです。
「複雑」と聞くと自分はクネビンフレームワークを思い浮かべますが、不確実な世界を確実に生きる カネヴィンフレームワークへの招待(著:田村洋一)
の中には「複雑」についての以下のような説明があります。(※厳密に言うと書籍内では「複合」についての説明になっていましたが、大きく意味が異なるわけではないため気にせず先へ進んでください。)
因果関係がわからず複雑で、時間が経過してからの後知恵でしかわからないもの。ベストプラクティスや定石はない。ひもとくことができない。やってみないとわからない。流動的で予測ができない。ひとつの小さな変化が予想のつかないさまざまな反応に次々とつながっていく。
不確実な世界を確実に生きる カネヴィンフレームワークへの招待 p.16
要は「複雑な問題」とはやってみないと何が正解かわからない問題ということです。
スクラムはこういった複雑な問題を考えればわかる問題にしていくことで、チームや組織が継続的に価値を創出できる状態を作ることを目指しています。
プロダクト開発における複雑な問題とは
では、プロダクト開発において複雑な問題とは具体的にどのようなものでしょうか?エンジニアリング組織論への招待(著:広木大地)の「不確実性」に関する説明が自分は参考になるのではないかと思いました。
不確実性とは、「わからないこと」です。私たちがわからないことには、未来と他人があります。未来の不確実性は、ソフトウェアをどのように作るかという方法不確実性と何のためにソフトウェアを作るのかという目的不確実性に分かれます。また、他人の不確実性は通信不確実性といい、コミュニケーションが不確実であるために情報の非対称性や限定合理性が生まれてしまいます。
そして、不確実性は、「不安」を生み出します。わからないものは自分を脅かすかもしれないと本能で感じてしまうからです。不安は、コミュニケーション不確実性に変わり、それは未来の不確実性を増大させます。エンジニアリング組織論への招待 p175
ちょっと長いので要約すると、複雑な問題=不確実性は
- 何を作れば良いか(目的不確実性)
- どうやって作れば良いか(方法不確実性)
- どうやって他者と認識ずれを無くすか(通信不確実性)
のように分類できるよねと言ってます。
本題
前置きが長くなりましたが、本題です。
これまでの内容を整理すると、スクラムは前述の3つの不確実性を低減するための方法が定義されていると考えることができ、スプリントレビュー・レトロスペクティブと不確実性の対応関係は以下のように整理することができます。
![](https://images.microcms-assets.io/assets/0b7e26d405ac43a2bb794b29dd552427/f6f02672f5b542e9ac065ce05a72ec6c/image1.jpg?fm=webp)
どちらも不確実性を低減する目的であることは共通していますが、その対象が異なります。
スプリントレビューは「何を作れば良いか?」、レトロスペクティブは「どうやって作れば良いか?」の不確実性が対象です。
また、スプリントレビューはスクラムチームとステークホルダー、レトロスペクティブはスクラムチームに所属するチームメンバー同士のコミュニケーションの機会を提供することで「どうやって他者と認識ずれを無くすか」の不確実性にも対処しています。
このように整理すると、これら2つのイベントの重要性が理解できるのではないかと思います。
余談
「レビュー、レトロ以外の場でも目的不確実性・方法不確実性に対処しているんじゃないの?」
そう思った方いるんじゃないでしょうか。
これはその通りで、あくまでスプリントレビュー・レトロスペクティブは各不確実性に対処する代表的な場と考えると良いと思います。スプリントの中で行うあらゆる活動がこれらの不確実性の低減に繋がっています。
あとは、スプリントレビューの場でも開発プロセスの課題についてステークホルダーと話し合うことで方法不確実性に対処してもいいし、その逆も然りです。
スクラムの型は重要ですが、それに従うことが目的ではないはずです。
さいごに
今回はスクラムにおいて重要なイベントであるスプリントレビューとレトロスペクティブの違いについて「不確実性」の観点から解説してみました!
この記事を書いた人
![小島啓輔](https://images.microcms-assets.io/assets/0b7e26d405ac43a2bb794b29dd552427/3124dbc79cb541bba8ff07764821f8bd/%E3%81%93%E3%81%97%E3%82%99%E3%81%BE%E3%81%95%E3%82%93%E3%82%A2%E3%82%A4%E3%82%B3%E3%83%B3.png)
関連記事
- スクラムにおける既存職種のあり方について考えてみた(後編)
Hideki Ikemoto
- スクラムにおける既存職種のあり方について考えてみた(中編)
Hideki Ikemoto
- スクラムにおける既存職種のあり方について考えてみた(前編)
Hideki Ikemoto