開発プロセスのメタ振り返り

ここ数年で開発プロセスの改善を試行錯誤してきたのですが、一番大事なのはきちんと振り返りをすることだなあと最近感じています。
私が所属するチームでは過去に（ほぼ）スクラム開発方式を採用しており、一度手放した後、現在少しずつスクラムに回帰しつつあるという状況です。この過程を振り返り、今の考えに至った経緯を書いていきます。

概要

• 振り返りはしなければならない。
• 全てのものに意味があるということはないが、振り返りが全てのものに意味を持たせる。（主観）
• プロダクトを成長させるための戦略をチームの軸として持っておき、振り返りが戦術的な意味に閉じないようにしたい。

想定読者（私が意見をほしい読者）

• アジャイル開発に興味がある人
• スクラム開発に興味がある人
• プロダクトマネジメントに興味がある人
• プロジェクトマネジメントに興味がある人

開発プロセス（振り返りのやり方）の変遷

• スクラムでスプリントレビューとレトロスペクティブをしていた
• レトロスペクティブをしなくなった
• スプリントレビューをしなくなった
• スプリントレビューほか、突発的に振り返りをするようになった

スプリントレビューとレトロスペクティブをしていた時

私が現在のチームにジョインした時です。
多少チームの状況に合わせていましたが、7, 8割ぐらいスクラム開発方式に沿っていたと思います。
正直なところ私はスクラムイベントの意義をまだ理解できておらず、形式的に参加していた状態でした。

良かったこと

• スプリントレビューにより、チームメンバーが新規機能やプロダクトの状況を知ることができた。相互にフィードバックできた。
• スプリントレビューがあることにより、スプリント期間内にタスクを完了させるという納期の意識が高まった。
• レトロスペクティブという、プロダクトチームの業務の進め方について誰でも意見できる場があった。

良くなかったこと

• 企画職含めほぼ全員がレトロスペクティブに参加していたため、意見の確認だけで時間を使い、アクションまで決められることが少なかった。
• 一つ一つの意見について深掘りできなかったので、アクションも場当たり的なものになることがあった。

スプリントレビューはしていた時

チームの体制やメンバーの変化の影響もあり、全体的にミーティングが多くプロダクトの改善にリソースが割けていない状態になっていました。
また、バッグログにチケットが溜まり、今必要な機能開発ができない状況になりかけていたので、もっと新機能に時間をかけられるようにしようというのがチームの総意となっていきました。
必要な改善は都度やろうということで、レトロスペクティブをスキップするようになりました。

良かったこと

• ミーティングの時間が減り、実装に使える時間が増えた。
• プロダクトの今の状況への意識が高まった。

良くなかったこと

• チーム全体を見る視点の振り返りがなくなり、改善活動は個人に任される状況になった。
• 個人個人の改善活動に一貫性がなかった。
• 振り返りをしようという意識が薄れていった。

雰囲気で振り返りをしていた（していない）時

気がつくと、スプリントレビューで共有することのスコープが広がっており（実装を伴わないプロダクトの改善など）、共有事項ばかりでフィードバックし合う時間が取れず、スプリントレビューの役割が形骸化していました。
ついにスプリントレビューもスキップすることになり、重要なことは都度チーム内で共有しようということになりました。
スプリントという単位があまり意味をなさなくなったので、Story Pointsによるベロシティの管理をしなくなりました。
スクラムをほとんど手放し、カンバン方式に近い開発スタイルになっていました。

良かったこと

• のびのび実装できた。

良くなかったこと

• 納期の意識がかなり低くなった。
• リリース情報など、共有したつもりになることが多く、改めて共有し直すことが増えた。
• 結局余分なコミュニケーションが増えた。

振り返りこそが全てだったんだ...と思った時（現在）

全然開発プロセスよくなっていないなあ...とぼんやり考える中で、今までにしてきたのはその場しのぎに過ぎなかったのでは？と思うようになりました。
振り返ってみると、最近「振り返りをしなくなっている」ことに気が付きました。
ここまでの変化によってもたらされた危機意識から、スプリントレビューなど部分的にスクラムの要素を復活させました。
その他エンジニアの業務に注目すると、個々の実装についての振り返りを意識的に増やしました。

良かったこと

• 改善すべきことの根本に意識を向けるようになった。
• 機能開発や改善活動について、なぜそれをするのか、そのやり方がベストなのか、という問いが投げかけられるようになった。
• Story Pointsも復活させ、エンジニアのチームと個人の両方のリソースの意識が高まった。
• 改めて、実装後の指標の変化の測定の意識づけができた。

良くなかったこと

• 開発プロセスを部分的に変える実験の最中なのでまだコミュニケーションロスがある。

まとめ

スクラムを一度やめて再度スクラムに回帰しつつあるのですが、一度離れたことによって、「スクラムの何が良かったのか」と、「以前のスクラムには何が足りなかったのか」に気付けました。
良かったのは、振り返りがプロセスに組み込まれていたことで、足りなかったのは、振り返りの中で根本的な課題にまで触れられなかったことではないかと思います。
振り返りから生まれたアクションによる改善が感じられないことにより、振り返りという行為への信頼が薄れていったのかもしれません。

何かを改善する時は思いついたことを早く試したくなることもありますが、問題の根本を分析して最善の手段を検討するのが結局近道になるんじゃないかと今は思っています。そのためには何をするにしても振り返りを行い学習していくことが必要だと思います。
当然振り返りをするためには記録を残しておく必要があるのですが、そのために効果的にドキュメントを残したり指標を測定したりすることについては別途良いやり方を考えなければと考えています。
動機づけが難しいところですが、振り返りパワーを感じられるようになれば記録モチベも上がるのかなあなどと思ったり思わなかったりします。