はじめに
HITOTSU株式会社の河村康治です。
みなさん、チームで振り返りやっていますか？？振り返りは会社やチームに応じて考え方が違いますが、僕は振り返りすごい大事だと思っています。今回は日頃お世話になっている Findy Team+ を使ってチームで振り返りしたらすごく上手く回りだしたので、紹介したいと思います。
そもそも振り返りはなぜ必要？
アジャイル開発チームの中にも振り返りを実施していない会社も何社かありました。また振り返りをやってはいるものの、何か課題や問題ある〜〜？？と聞くくらいでサラッと終わるスクラムもあります。会社や文化によって振り返りの位置付けは様々です。僕が感じる振り返りの良さは、褒め合う文化の形成、弱音を吐きやすくする環境作り、個人の課題を共有・組織の課題に昇華することかなと思っています。
褒め合う文化の形成
スプリントのサイクルの中では課題点や問題点に焦点が集中しやすいですが、意外と感謝を伝える場面や褒め合う場面が少なかったりします。振り返りの中で、「XXさんの実装すごい綺麗で勉強になりました！」や「実装難しくて悩んでたけど、XXさんに相談したら解決できた！ありがとうございます」などの意見が出てきます！メンバーからメンバーに感謝を伝えることや褒め合う文化が生まれると、チームの雰囲気が良くなるので作業がやりやすくなります！
弱音を吐きやすくする環境作り
開発を追い込んでる時期は結構しんどくなりやすいですよね。また一部の人がしんどい状況が生まれている場合でも、雰囲気を壊したくないから我慢して作業し続けるなどが発生します。一時的にならまだしも定常的に我慢をし続けるメンバーがいたら、これはやばいです😅 離職やチーム崩壊につながりかねないです。まぁ、離職やチーム崩壊は極論なんですが、そもそもしんどい思いをし続けるのって嫌じゃないですか。だから、まずは弱音を吐いて課題をチームで共有し、その後組織で解決しましょうという流れを作っていきましょう。
個人の課題を組織の課題に昇華する
個人で解決できない事も組織の課題に昇華すれば解決できることは多いです。
例えば、レビューに時間がかかり個人のタスクが遅延する課題があったとします。個人では、作業時間を増やすという根性論の解決策しか取れませんが、組織の課題に昇華すれば「レビューのタスクを巻き取る」や「レビュー会を実施しレビュー負荷を下げる」、「そもそもRv負荷が下がるように、要件や設計は事前にすり合わせる」、「RvしやすいようにPRを細かく切る」など様々な手が出せます。個人で解決できない事でも、組織の課題に昇華することで課題解決しやすいので、振り返りで解決策を立案します。
振り返りの流れ
では、普段どのように振り返りを実施しているのかについて説明していきます！
Activitiyの定量評価→チームサーベイのアンケート結果の確認→個人ワーク→意見の共有→投票→意見の深掘り→Action管理の流れです。(下記図を参照)
Activitiyの定量評価
Findy Team+ を元に、Jiraのチケット作成数やPR数、Rv数が意識せず収集・分析されます。定量評価する場合、数値化するのに労力を使い、結局分析まで至らないケースが過去に経験あったので、収集されるだけでもすごいいいなと感じております！
実際にどんな数値を観測しているかを記載していきます。
→ダッシュボードですね。手っ取り早くメンバーの状況が見れるので、重宝しています。
→チーム詳細です。チームとして開発した量が数値化されます。PR作成数やRvまでの時間等を先週の数値と比べて変化があったかを見ていきます。ここで大事なのは、数値が低下したから悪いのではないということです。数値はあくまで判断基準の1つで、変化があったことに対しての議論の起点にしか過ぎません。調査や仕様のすり合わせに時間を使えばPR数やコミット数が減っているのは自然なことですし、プロダクトの詰めの段階に入れば細かくPRを作っていくのでPR数は増えます。開発フェーズに応じて数値は変化していくので、数値はあくまで判断基準で数値のいい・悪いは人の判断で決めます。
逆に数値は下がっているけど、説明できないような状況が起きている時は、数値が下がっている事に焦点を当てて話し合うことはいいと思います！
→PullRequestの振り返りです。PullRequestでは、 変更行数 や オープンからRvまでの時間 を中心に見ています。変更行数が多い場合フロー効率の低下やRv負荷が高くなるので、そこら辺を中心に見ています。変更行数は200行~400行が心地よい範囲なので、400行を超えるコードがあれば、何か問題が発生していないかを確認します。ここでも変更行数が多いからダメというわけではなく、開発者が開発しやすい粒度なのか、Rv負荷がかかっていないかなどを中心に話し合っています。オープンからRvまでの時間は 24時間 を超えたらまずいとしています。レビューしにくいPullRequestなのか、それともレビューアーがRvに時間を当てられないのかなどを聞いたりしています。
チームサーベイの活用
チームサーベイは、SPACEフレームワークに基づいた 匿名性が担保されたアンケート調査 です。チームメンバーに15個の質問を回答してもらいます。アンケートは5分程度で完了するので、忙しい中でも無理なく実施できます。
→最近の僕のイチオシの機能です！😊 匿名性が担保されているので、メンバーが感じていることがアンケートに反映されます。
SPACEフレームワークの指標
- Satisfaction and Well-being（満足度と幸福感）
• チームメンバーが仕事にどれだけ満足しているか、ストレスが少なく働けているか。
• 例: エンジニアのモチベーション、ワークライフバランス。 - Performance（成果）
• チームや個人の成果がどれだけの価値を生んでいるか。
• 例: リリースのスピードや顧客満足度。 - Activity（活動）
• チームや個人がどれだけの活動をしているか。
• 例: コードのコミット数、プルリクエストの数。 - Communication and Collaboration（コミュニケーションと協力）
• チームがどれだけ円滑に連携できているか。
• 例: チーム間の情報共有の頻度、ミーティングの質。 - Efficiency and Flow（効率性とフロー）
• リソースをどれだけ効率的に使い、無駄なく作業が進んでいるか。
• 例: タスクの完了時間、ボトルネックの有無。
チームサーベイでアンケートは取れても結局どう活かしていけばいいのか？？という課題にぶつかります。これは本当に悩みました😅 アンケートも取って分析もできた。で、次どうすればいい？という事で悩みました。でもチームメンバーにアンケート結果を共有したところ、意外な反応が出てきました。それは、弱音を吐きやすくする環境作り ができたことです。
辛いことや弱音を吐いていこうと言っても、結構言いづらいものです。ただ、匿名性が担保されたアンケート結果を元に、こんなアンケート結果が出てきているのだから苦しんでいる人がいるんじゃないか？僕も実は苦しい部分を感じていて...みたいな感じで、アンケート結果から自分の辛いと感じている部分を柔らかく伝える部分ができてきました。これはすごい！👍いいことだなと思っています。本音の部分が出てくるから、メンバーに寄り添えるしみんなで解決していこうという文化が生まれてきます！！
個人ワーク
振り返りは Miro で実施しています。KPTに沿って振り返りを実施しています。
振り返りは下記テンプレートに沿って実施しています。
まずは各個人の名前のついた付箋に、今回のスプリントで感じたいいことや課題点などをざっくばらんに書き込みます。時間は大体７分間くらいでやり切ります。
意見の共有・投票
個人ワーク後は種類別に分別された箇所(上記図の赤枠部分)に移動させていきます。移動が完了したら、ファシリテータが付箋の内容を読み上げます。この時、ファシリテータは黙々と読み上げるのでなく、適度にメンバーに話題を振っていくことが重要です。最初の一言目を言えると今後の発言も言いやすくなるので、メンバーに偏りが出ないように全員に意見を仰ぐようにしています。
付箋を全部見終わった後は、投票に入ります。1人3票で付箋に投票していきます。投票の基準は各個人に任せているのですが、この後の議論のテーマになるので共感できることや課題に投票数は集まりやすいです。実際に投票後の振り返りの結果は下記写真のようになっています。
投票数に応じた課題の深掘り
投票の結果を元に、議論をしていきます。大体30分~1時間を目安に実施しています。投票してくれた人がまずどんな事を感じたのかを簡単に説明してもらいます。その後、投票に入れた人の意見を聞いたり、議論を深掘りしていきます。この時、議事録を画面共有しながらやるのがコツです。議事録がないと議論が発散した場合、あれ？そもそも何でこんな話題になったんだっけ見たいなことがあるので。議論の内容を可視化しながら認識齟齬が発生しないように進めていきます。最後にNextActionまで決めて完了です。
Action管理
振り返りで決まったNextActionが実際に行動できているかを管理します。いつも個人ワークを始める前にNextActionの管理をしています。ここでもFindy Team+のAction管理を使っています。
最後に
いかがでしたか？振り返りは課題の解決だけでなく、感情の共有やチームの雰囲気作りをするためにもいいなと思っています！！
Discussion