はじめに…

皆さんは、開発手法は何を使用していますでしょうか？

今日では、アジャイル開発が主流になっていると思っています。
大手のソフトウェア会社や、請負開発がメインの会社さんでは、ウォーターフォール開発がまだ残っているのでしょうか？
システムを稼働させる様々な要素が目まぐるしく変わる日々において、ウォーターフォールを固持している組織もあるのでしょうか？

とはいえ、多くがアジャイル開発で、その中でもスクラムでプロジェクトを運営している方々が多いのではないかと思います。

スクラムでは、スプリントレトロスペクティブといって、スプリントの最後に振り返りを実施しますが、
この振り返りの改善のポイントがなんとなく見えてきたので、本ブログにてまとめておこうと思います。

振り返りの目的は？

スプリントを２週間と決めると、
２週間に１回、スプリントレトロスペクティブ(振り返り)を実施することになります。

では、その振り返りの目的は、
次のスプリントでは、今回のスプリントの反省点を活かして、
より多くの価値もしくはより大きな価値をアウトプットするために、
改善点を洗い出すことだと思います。

スクラムガイドでは…

スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。

って、書かれています。

一般的な振り返りの手法は、ＫＰＴかなと思います。

世の中には様々な振り返りのフレームワークが用意されているので、プロジェクトの状況によって、いろいろ使い分けると良いと思います。
（詳細は、検索するとたくさん出てきます）

スプリントを継続して進めていると、振り返りでは、以下のような課題が出てきます…。

毎回同じようなＰ(Problem)がでる。
- つまり改善されていない
改善点Ｔ(Try)が、お気持ちの表明になる
- 「頑張ります」みたいな精神論になっている
Ｋ(Keep)が個人の主観
- 「・・・ができて良かった」みたいな具体性に欠ける内容
- 「〇〇さんの××がよかった」みたいな忖度祭り
  - とはいえ、言われた人は気は悪くない
Ｋ(Keep)が当たり前の内容
- 「すべてのバックログを消化できた」みたいなだから何？の内容
そもそもＫ・Ｐ・Ｔのいづれも毎回同じような内容があがる

これらの内容は、振り返りでアウトプットされる内容としてはイマイチです。
でも、内容はともかく、きちんとスクラムイベントやっているということで、
なぜか達成感が出てしまうのです。

こういうのを改善に本気じゃない症候群、
もしくは真剣に考えていない症候群とでも言っておきましょう。

スクラム開発であれば、ベロシティを基準にして、
そこを中心にして、何がよかったか(Keep)、悪かったか(Problem)を導き出したい。

ソフトウェアを開発しているのであれば、その開発した機能をユーザーに使ってもらって、
開発した機能の価値を享受してほしいですよね。
さらに、早くその価値を届けたいですよね。
１回のリリースでより多くの価値を届けたいですよね。
であれば、開発をもっと効率的に早くDONEにしないといけません。

「開発をもっと効率的に」するために、振り返りで「頑張ります」って言われても、
次のスプリントで同じことをする訳ではないので、効率化されるとは限りません。

であれば、開発のプロセスを見直しましょう！ポイントは･･･

開発本来の作業以外が必要になっていないか？
- 本来の価値付与の活動をするために、それをするためにいったん別の何かをしないといけないみたいなやつは排除しましょう！
価値付与が遅くなるポイントを見極める
- 目の前のバックログがベルトコンベアを流れて価値の付与活動が行われているとして、流れが遅くなるポイントを見極め、流れを正常化しましょう！
リスタートしなければならないポイントはないか？
- 他作業のレビューのため、いったん今の作業を手を止めて、レビューが終わればまた元の作業に戻ると「何やっていたっけ」状態でリスタートしなければならないのではないか？
- であれば、リスタートしない仕組み・やり方を模索しましょう！

だと思います。

振り返りをやること自体は、良いことですが、
目的とやり方を見誤ると、ただやっているだけになると思いますので、
プロセスを見直して無駄を排除することを意識するだけで、より効果的に振り返りができると思います。

かく言う私も完全にマンネリ化した振り返りをしていました。

で、とある本を読んで、振り返りをもっと改善しないとと感じました。

いろいろご意見いただけると助かります。