開発と振り返り

開発業務を進行する上で、日々の改善を行うための"振り返り"はかかせません。
しかしながら、その振り返りが中だるみしたり形骸化してしまって困ったことはありませんか？

もしかして、その飽きの原因は「いつも同じ振り返り手法を使用している」ことにあるかもしれません。
開発のフェーズが変わるにつれて、解きたい課題・問題も様々です。
そんな変化する課題に対して、振り返りの手法も適切に使い分けすると良いでしょう。

この記事では、弊社開発チームが取り組んでいるシチュエーション別で使い分けている振り返り手法をいくつかご紹介します。

各振り返りについて

本記事では4種の振り返りをご紹介させていただきます。

3ヶ月を1期として、期や開発進捗のシチュエーション別に振り返り手法を使い分けます。

期の始まりで①未来KPTを実施し、ベースとしては毎週②KPTをスプリント毎に実施します。
機能開発の中期では③帆船の振り返りを行って、残りの開発にスパートを掛ける準備をし、
開発が終了した際には④バリューストーリーマッピングで開発プロセス全体を振り返ります。

では一つずつご紹介します。

実施時期	対象メンバー
期初	開発

期の初めに行う振り返りです。手元に今期のスケジュールや目標がある状態で取り組みます。

通常のKPTと同様にKeep/Ploblem/Tryの行を用意します。**通常のKPTと異なるのは、現状ではなく、未来の振り返りを行うこと。**参加者には「既に今期全力で走りきった後」と思い込んで、未来の今期の振り返りをしてもらいます。

KEEPとPLOBLEMは下記のような観点で、意見を出してもらいます。

KEEP：「最高の未来〜開発が爆速進行、新機能は機能すべて公開でき、全部顧客に価値が届きました。この3ヶ月、何がよかったでしょう？」
PLOBLEM：「最悪の未来〜リリース遅延は遅延。障害は発生。悲惨な状況になりました。この3ヶ月、何が良くなかったでしょうか？」

最高と最悪の未来。２つの時間軸にタイムトラベルしたとロールプレイして実施してください。
魅力的な最高の目標と、避けるべき最悪の問題。両者を期の最初に洗い出すことで、チーム内で最初の一歩を踏み出すための意思統一が深まります。

実施時期	対象メンバー
スプリント毎	開発

スプリントレトロスペクティブをKPTで毎週実施しています。
※ 詳しい実施方法は下記の記事が参考になります

弊チームではスプリントを2週単位で回していますが、課題はなるたけ早く察知したいので、スプリントの中日にも振り返りを実施しています。
Keep/Ploblem/Tryの堅苦しさを感じ、下記のような言い換えを行って意見交換を行っています

Keep ⇛ よかったこと / がんばったこと
Ploblem ⇛ なんかもやもやすること / たいへんだったこと
Try ⇛ やってみたいこと / 挑戦したいこと

実際に言葉の力は偉大で、小さな意見や軽い意見も出しやすくなっています。

実施時期	対象メンバー
開発中期	開発

開発中期に、リリースまでにスパートをかけたいタイミングでは**"帆船の振り返り"**を行います。

プロジェクトを帆船に見立て行う振り返り手法です。
まずは下記のような帆船の絵を用意します。

「中心に帆船を描く。帆に推している追い風と、その向かう先に島を描く。
帆船の向かう先の海底に岩礁と、帆船から伸びている錨を描く」

参照元：[miro.com]The guide to retrospectives – remote or in person
https://miro.com/guides/retrospectives/how-to-run-sailboat-retrospective

各キーワードはPJTにまつわる事柄を示しており、これに準ずる形で振り返りを進行していきます。

帆船：チーム。PJT。
島：ゴール、目標、この振り返りのお題目
追い風：チーム、PJTにとっての追い風
岩礁：ゴールに到達するための不安要素、リスク(未来)
錨：ゴールに到達するための阻害要因(現在)

流れとしては島を定め、その後各要素を意見出しします。
　1. ゴール(島)を定める
　2. ゴール(島)に到達する帆船にとっての『追い風』『岩礁』『錨』を洗い出す

絵の上に直接付箋を張っていくやり方がポピュラーです。リモートで行う場合はMiroやGoogle Jamboard等のオンラインホワイトボードサービスを使用すると良いでしょう。
弊チームでは各キーワードを行で整理してGoogle スプレッドシートで進行しています。

開発進行を取り巻く漠然とした不安要素を明確にし、ゴールまでの道筋を適切に整理することができます。
タスクの漏らしを防ぎ、ボトルネックになりそうな点は注意を促し、リリースまでのスパートを掛ける準備が整います。

実施時期	対象メンバー
リリース後	チーム全体(PdM、デザイナー、開発)

リリースが完了したら、今回の開発全体をバリューストーリーマッピングを使用して振り返っています。

要件定義から、顧客に届くまでのソフトウェア開発サイクルを可視化する手法で、各フェーズで起きた事、かかった時間、情報と人の流れを一枚の図に落とし込み整理します。

※ 詳しい実施方法は下記の記事が参考になります。

各種振り返りは週次で行う事が多いため、その時々の問題に対してTryを設定することが多いですが、この手法では開発全体を見た上でどのプロセスにボトルネックかを検知し、全体最適を図れることが特徴です。

以上、シチュエーション別に使い分ける振り返り手法をご紹介してきました。
実際はこのルーティンが完全に固まっているわけではなく、新しい振り返りは柔軟に取り入れています。試してみて、あまりうまく回らないこともあるかもしれませんが、そのときは失敗を"振り返って"次に活かす気持ちでチャレンジしています。

もしこの記事を読み、軽い気持ちで「この振り返りやってみよ！」と興味を持ってくれれば幸いです。
良い振り返りライフを