TechとPoemeの間

Qiita に書かないエンジニア業の話

非スクラムチームに贈る「ふりかえり」の処方箋

最近のソフトウェア開発チームの多くは,スクラムフレームワークを適用していなくても,いわゆる「アジャイルなプラクティス」に則ったイテレーティブな開発スケジュールを持っている組織が多いのではないかと思います.
自分もそのような組織に幾つか属してきた中で,周囲のやり方やインターネット上で見られる事例を形だけ適用してイテレーション *1 の「ふりかえり」*2 を行っているもののうまくいかない,という組織をこれまで多く見てきました.本稿では,特にスクラムには特に精通していないチームに向けて,スクラムから得られる知見や,自分がこれまでスクラムに取り組んできた中での経験を元に,よく見受けられるパターンと,それに対する処方箋をまとめようかなと思います.

時間内に議論が収まらない

チーム規模やイテレーションの長さに対して,どういうことが起きたか,何が問題だったか,どう改善するかという話が,予め予定したタイムボックスで終わらないというケースを良く目にします.

スクラムのルールを規定している Scrum Guide では,1ヶ月のスプリントの場合,スプリントレトロスペクティブの長さは最大4時間まで と定義しています.
単純計算が成立するのかも議論するべきポイントかもしれませんが,例えば1週間のスプリントのふりかえりを30分でやって足りている感じがしないという場合,「単純計算で言えば最大1時間使っても不自然ではない」と思うのも一策つかもしれません.組織によっては,「会議は1時間でスケジューラ上の予約する」のが暗黙的なパターンになってるといったケースも多いかと思いますが,それに引っ張られないことが大事だと思います.
スクラムのパタン・ランゲージをまとめている Scrum Pattern Community も,スプリントレトロスペクティブについて 「たっぷりと時間を取らないと,問題の根本にあるより深い問題にまでたどり着くことができない」と解説しています.
原則として会議は短いに越したことはないし,チーム全体のファシリテーションスキルが高ければ短い時間で収めることも可能でしょうが,ふりかえりに関しては長く時間を取って,タイムボックスを守るプレッシャーを比較的少なくするほうがチームの改善を促す観点では得策なのかなと思っています.

ふりかえりに参加するステークホルダーの苦しみを聴くのに心が痛む

例えば組織の中に,ソフトウェアを開発するチームと,そのソフトウェアを用いて収益を上げるビジネスチームがあり,ソフトウェア開発を行うという文脈でふりかえりを行うとします.ふりかえりにビジネスメンバーが参加し,「xxx の機能がないから営業がはかどらない」とか「xxx の機能が欲しい!」という改善要望や問題点が挙がり,ソフトウェアの開発者やリーダーが心を痛めたり,「そんなの言ったって人手が足りないよ」という気持ちになってしまったり,エンジニアは技術的な改善について議論したかったり,というケースが有ると思います.

スクラムには,スプリントを終了させるときに行うイベントが2つあります.ひとつは「スプリントレビュー」,もうひとつが「スプリントレトロスペクティブ」です.この2つには明確な違いがあります.
スプリントレビューは,チームの外側にいるステークホルダを呼び,スプリントの成果を確認した上で,プロダクトを良くするためには今後どうするべきかをスクラムチームとステークホルダーを交えて議論することが目的です.
一方で,スプリントレトロスペクティブでは,参加者はスクラムチーム *3 のみで,話題とするのはチームの生産性についてです.
特に組織が「エンジニアリング」と「ビジネス」に分かれている場合,この2つを適切に使い分けることが重要なのだと思います.当然ながらエンジニアとビジネスがプロダクトについて会話することも大事ですが,それを行う場を「ふりかえり」と称し,エンジニア単体でエンジニアリングの問題点について話す場所がなくなってしまうのを防ぐのが重要だと思います.

リードメンバーの独壇場になってしまう

他のメンバーが頭を捻って考えたアクションや改善策を,技術的に長けたリードエンジニアが否定してしまったり,チームリーダーがトップダウンで解決策をバンバン挙げてしまうケースもしばしば見受けられます.短期的な問題解決という意味では悪くないのかもしれませんが,チーム全体の学習の促進や,変化に対応した自己組織化されたチームを作るという長期的な視点では問題となるケースが有るでしょう.
技術や業務知識でチームをリードしている人が体制上チームリーダーとなることは何も問題は無いでしょうが,仮に彼らがファシリテーションスキルを充分に持ち合わせていない場合,リーダーだからとふりかえりの司会にしてしまうことは良い選択とは言えません.

スクラムでは,「プロダクトオーナー」という役割と「スクラムマスター」という役割が分かれていることで,取り組むプロダクト開発について責任を持つ役割と,ファシリテーションスキルを発揮してチームの自己組織化を手伝う役割が分かれています.ふりかえりに特化して言えば,聞き役に回れるような人を「チームリーダー」とは別にファシリテーターとして置くことは検討に値するでしょう.

また,ファシリテーターをチームメンバーが順番に担当することで,チーム全体のファシリテーションスキルを向上させるのも良い取り組みだと思います.このときに注意するべきなのは,ファシリテーション自体に対して継続的にフィードバック出来る人がチームにいて,ファシリテーターを順番に回すのも単なる「当番」や「仕方なくやるべきこと」なのではなく,ファシリテーションスキル向上という目的が共有されていることだと思います.

ふりかえりで出た改善アクションが取り組まれない

ふりかえりを始める際に,前回のふりかえりでチームが決めた改善策やアクションが全く取り組まれていないケースが多くあります.この状況を改善するためにチェックするべきポイントは2つあると思います.

改善策は「実行可能」か,または「追跡可能」であるか

「xxx に気をつける」「xxx するようにする」という改善策は,どうなったら完了したと言えるかが分からない点で「アクション」ではありません.振り返りで決めた「アクション」は,次のイテレーションでのタスクの1つとして「取り組んだ」か「取り組めなかった」かを明らかにできるようにするべきです.
2017年の Scrum Guide の改訂では,スプリントバックログの中に,前スプリントのレトロスペクティブで上がった改善策のうちの優先度の高いものを少なくとも1つ含めるべきだという記述が追加されました.これはスクラム実践者の中でも好みが分かれるところですが,常にチームの見えるところに置かれるスプリントバックログやカンバンにアクションが書いてあり,デイリースクラムでその取組を確認できるようにするというのは現実的な解決策だと思います.

また,アクションではなく,なんらかのメトリクスに落とし込むことも解決策でしょう.例えばチームがソフトウェアの機能開発をする際に自動テストを書かないという問題が上がったとしたら,「テストを書くように気をつける」のではなく,「各機能開発時に追加された自動テストのテストケースを可視化する」という解決策で,実際に書かれたテストケースを追跡可能にするのは,アクションの第1歩として有効でしょう.まずは現状を可視化して,チームの意識や認知に働きかけるという作戦です.

ここらへんの「振り返りの続け方」に関しては,中村洋さんが Regional Scrum Gathering Tokyo 2018 にてトークした 「ふりかえり」の始め方と続け方 // Speaker Deck が大いに参考になるかと思います.

speakerdeck.com

ふりかえりで出したアクションで全てを解決させようと期待しない

これは個人的に大事だと思っているのですが,ふりかえりで上がる問題には,1つのアクションを実行することで簡単には解決しないような問題も多くあるのではないかと思います.そんなときに大事なのは,ふりかえりで全ての解決策を考えたりするのではなく,少し問題を和らげるファーストステップをアクションとしてまず取り組んでみることだったり,複雑でまだチームが原因を理解しきれていないな問題を少しでも明らかにするためのアクションを考えることなのではないかと思います.

結論

ということで,「なんとなくやっているふりかえり」から「上手く回るチームのふりかえり」に昇華させる方法として最近自分が感じていることを挙げてきました.チームがスクラムに取り組んでいないとしても,スクラムのプラクティスの背後にある価値観や原則を知ることで意図を理解することは有用なんじゃないかと思います.
「みんなやっているから」とか「以前からやっているから」という理由でふりかえりに惰性で取り組むことは簡単ですが,少しコツを得ることで良くすることが出来るのではないかと思います.

自分がかつて所属した組織でやってたレトロスペクティブに関しては,以下のような記事も書いているので,参考にしてみてください.

t-and-p.hatenablog.com

*1:以下では,スクラムに限らないイテレーション開発の際に「イテレーション」と呼び,スクラムの文脈でのイテレーションスクラムの語彙に則り「スプリント」と呼びます

*2:イテレーション」と「スプリント」という呼び方と同様,スクラムに限らない場合に「ふりかえり」,スクラムの文脈のふりかえりを「レトロスペクティブ」と呼びます

*3:プロダクトオーナーがレトロスペクティブに参加するかどうかは,チームが決めます.