バックエンドエンジニアのミックです。 今回の記事は、「Featureチームのアジャイル開発の軌跡」の続編、第３回目です（前回はこちらの記事）
アジャイルでの振り返りの活動のことをレトロスペクティブ（retrospective）と言い、主にチーム自体やチーム活動、プロセスを振り返る活動のことをいいます。 レトロスペクティブを行う上で、データや図を活用するのはチームでの共通認識を得たり、改善策を見つけ出すためにとても有用なので、どう言った図が振り返りに使えるか、その一例を紹介します。またどういった観点で振り返りを行うことができるかも一例を紹介できたらと思います。
はじめに
アジャイルにおいては、振り返り（レトロスペクティブ）が定期的に行うイベントとして組み込まれています。 レトロスペクティブでは、チーム自体やチームの開発フローやプロセスを振り返ります。
基本的に1〜2週間ほどの短い開発期間を反復していく中で定期的に振り返るので、短期的にはチームの課題や改善をすることはできますが、 チームの現在の状況がチームの目標達成のために適切かどうかは長期的な目線で見ないと認識しづらい時もあります。
チーム自体やチームのプロセスを改善するにあたって、データや図を用いると、共通認識が得られやすいしわかりやすいです。 期間には縛られないですが、特に長期的な目線で振りかえる時にはあった方が振り返りしやすいです。
振り返りのプロセスの中で、どういった図が活用できるのか、振り返りのステップとともに紹介します。
チームの活動を振り返るためには？
1. チームの指標を設定する
チームの活動やプロセスを振り返るためには、主にチームのアウトプット量やパフォーマンス、品質などの開発指標を見据えていく事になりますが、「LeanとDevOpsの科学」では、開発チームのパフォーマンスを図るためには、以下の4つの指標を計測すべきと言われています。
- 変更のリードタイム
- デプロイの頻度
- MTTR（平均修復時間）
- 変更失敗率
効果的に振り返るためには、あるべき姿を明確にする必要がありますが、こういった指標を一つの参考にできますし、そのチームでの現在の課題もチームがどうあるべきかに含められる要素と思います。
2. 振り返りのためのデータを収集する
振り返りのためにデータを収集する目的は主に以下です。
- 参加者が記憶を呼び戻すのに役立てる
- 参加者の共通認識を醸成するのに役立てる
事実、時系列のデータを収集しチームで共有することで、チームでいつ何が起きたのかの共通の理解を得ることができます。 また、事実だけでなく、感情もチームを振り返るためのデータとして収集します。 そうして集めたデータから問題・課題をチームで分析していきます。
収集したデータの可視化の仕方としては、事実と時系列をまとめるのにはタイムラインは便利な手法です。 アジャイルの振り返り手法の一つとして、事実・時系列・感情全てをタイムラインに図解するワークがあります。時系列に起きた事実に合わせて感情の波（エモーショナルグラフ）を図解します
3. 改善点を見つけ出す
振り返りのフレームワークには
など、様々種類があります。
今回は各フレームワークには大きく触れませんが、今回紹介させていただいた手法などいろいろな手法を試して、自分たちのチームに合ったものを見つけるのも良いかもしれません。
自チームでは、短期的にはKPTで振り返りをしています。また、中長期的には、1ヶ月くらい目安にタイムラインとKPTを組み合わせて振り返りをしています。 普段の業務で無理なく行えるようにAsanaのタイムラインを利用して時系列での事実、開発内容やスプリントの妨害項目をまとめているので、参考にしつつ、他をまとめてKPTで振り返るような形です。 利点としては、普段使ってるタスク管理の延長上でタイムラインが残せることと、タイムラインとKPTを組み合わせる事で長期的なProblemとTryを改めて考える助けになります。
4. 改善策を決める
振り返りに慣れていくと、きちんと分析する事までせずTryを決めて終わってしまう事もありますが、根本的な問題を見つけ出してそれに対する改善案をチームとして決定、実施して、改善のプロセスを回すのは、チームの目標を達成するためにチームがありたい方向へ向き直るためには重要な要素だと思います。
特に開発のフローやプロセスに着目したい時には、開発上の手戻りや各プロセスのムダを見つけ出すためにバリューストリームマッピングを使って図解するのは1つの有用な手段だと思います。
バリューストリームマッピング(VSM)とは
バリューストリームマッピングは、トヨタ生産方式の改善手法がもとになった、ワークフローを分析する手法で、顧客に価値を提供するまでにある工程を全て洗い出し、流れ図で一覧し、ボトルネックを明確にし、改善点をあぶり出す事によって、作業効率の向上に役立ちます。
バリューストリームマッピングを行うにあたって、基本となるステップは4つです
バリューストリームマッピングのメリットとしては、
- 実際に行われるプロセスについて共通の理解が得られる
- 開発フロー、作りすぎや管理ミス、プロジェクトの不備などのボトルネックが明確になる
- 個別最適ではなく、全体最適を考えられる
- 改善案の選定がしやすくなる
といったものがあります
例えば、職能横断チームのスクラム体制においては、人数を制限することでコミュニケーションコストの増大を防ぐとともに、職能間での密なコミュニケーションでリードタイムの削減ができる、と言うのが利点の1つと思いますが、バリューストリームマッピングでは、ステークホルダー含めチーム全体のプロセスを可視化できるので、チームの連携で何が問題になっているのか、どう改善できるか、改善のためにどう言ったアクションが取れるか、などについて共通認識を得やすいと思います。
最後に
振り返りをするにあたっては、チームの活動を図で可視化するのが共通認識を作る上ではとても助けになります。 また、短期間で開発のサイクルを回すアジャイルでは、どうしても直近の出来事に注力しがちなので、中長期的な観点で振り返りするのも時には有用かもしれません。 振り返りの際には、時間が経つほど感覚的になってしまう時もあるかと思いますが、チームの活動について改善できていることと改善が必要なこと、双方をフラットに認識する事も、特に大型プロジェクトに取り組んでいたり、チームの立ち上げ時から軌道にのるまでの間などでは、目標への向き直りのために大事な観点かなとも思います。
今回紹介した図には、ワークショップ含め具体的なやり方が一緒になっていたりしますが、重要なのは目的の達成のためにチームの活動を可視化する事だと思うので、原則は原則として重視しつつも、時には形にとらわれずぎず、今のチームの状況にあった方法や形式、ボリュームでの導入の検討もできると良いのかな思います。
あくまで一例として紹介させてもらいましたが、チームの振り返りの仕方についてはこちらの書籍がおすすめです
