スプリントレトロスペクティブ導入で見えた、継続的改善文化の醸成

はじめに

ソフトウェア開発の現場では、チームの生産性と品質を継続的に向上させることが極めて重要です。これは、チームの規模や業界を問わず、普遍的に当てはまる原則かと思います。私たちのチームも、この原則に基づいて改善に取り組んできました。

まず、私たちのチームの状況から説明しましょう。最初、私たちは3〜5人程度の小規模なチームで、多くのメンバーが複数の役割を兼任していました。多くの成長途上のチームと同じように、開発プロセスを改善するためにスクラムの要素を一部取り入れていましたが、理想的とは言えないものでした。

具体的には、プロダクトオーナー（PO）やスクラムマスター（SM）の役割が明確に定義されておらず、結果として本来のスクラムとはかけ離れた運用になっていました。さらに問題だったのは、スプリントレトロスペクティブを実施していなかったことです。そのため、チームの改善サイクルが実質的に機能していませんでした。

また、最も大きな課題の一つとして挙げられるのが、チームメンバー間のドメイン知識の理解度に大きな差があったことです。その差は開発プロセスに深刻な影響を与え、遅延や誤解を引き起こしていました。例えば、プランニングなどでドメインの理解が不十分なために議論についていけずに十分に貢献できないメンバーもいました。

このような状況の中で、定期的な振り返り活動が欠如していたため、多くの問題が長期間にわたって未解決のまま蓄積されていきました。本来ならスプリントレトロスペクティブを通じて早期に発見し対処できたはずの課題が時間の経過とともに深刻化し、結果としてチームの生産性低下と団結の弱体化を引き起こしていったのです。

このような状況を改善するため、スプリントレトロスペクティブのチームへの導入を推進することにしました。

以下のセクションでは、スプリントレトロスペクティブの導入プロセスについて、特に、直面した課題や採用したフレームワーク、そしてこの取り組みがチームの動きと全体的なパフォーマンスにもたらした変化について説明していきます。

スプリントレトロスペクティブ導入のプロセス

スプリントレトロスペクティブを効果的に導入するにあたり、まず私たちは重要な準備段階を踏みました。

a) スクラムの理解を深めるセッション

チーム内でスクラムに対する理解度にばらつきがあり、それが以前のスクラム実践の形骸化につながっていました。そこで、スプリントレトロスペクティブ導入に先立ち、スクラムの基本概念や原則、各イベントの目的などについて、チーム全体で学び合うセッションを開催しました。

このセッションでは、知識の共有だけでなく、各メンバーの経験や疑問点も積極的に取り入れ、ディスカッション形式で理解を深めていきました。これにより、チーム全体でスクラムの本質的な価値と目的を共有し、お互いの視点を理解することができました。

b) スプリントレトロスペクティブの価値を探るセッション

次に、スクラムの中でもスプリントレトロスペクティブが特に不足していたことを認識し、その価値を共に探るディスカッションを実施しました。ここでは、継続的改善におけるスプリントレトロスペクティブの役割や、チームの成長にどのように寄与するかについて、チームメンバー全員で意見を出し合いました。

c) DPA（Design the Partnership Alliance）の実施

準備セッションを終えた後、私たちはDPAという手法を用いて、「どのような雰囲気でふりかえりを進めたいか」「その雰囲気を作り出すために何をするか」という2点についてディスカッションを行いました。このプロセスにはFigJamを活用し、チーム全員が意見を出し合える環境を整えました。

d) フレームワークの選定

DPAの結果を基に、私がいくつかのスプリントレトロスペクティブのフレームワークを選出し、チームで試行錯誤を重ねました。試してみたフレームワークは以下の通りです：

1. Stop, Start, Continue

2. Good & New!

3. Win Session

4. GPT (Good, Problem, Try)

5. 感謝

6. Fun! Done! Learn!

7. 象・死んだ魚・嘔吐

それぞれのフレームワークについて、チームでの実践を通じて以下のような感想を得ました：

• Stop, Start, Continue：「Stop」の観点が特に有効でした。やることよりやらないことを明示する方が実行に移しやすいと感じました。ただし、全体的に書きにくさは否めませんでした。
• Good & New!：ポジティブな面を共有するには良いですが、課題を抽出しにくいという欠点がありました。また、「New」でない重要な課題も存在するため、視野が狭くなる可能性がありました。
• Win Session：成果の共有と称賛には有効でしたが、デイリースクラムやスプリントレビューなど、他のスクラムイベントの内容と重複する傾向がありました。
• GPT：最も多くの意見が出され、観点のバランスも良好でした。特に、Tryの見直しを習慣化することで、継続的な改善サイクルを回すことができそうだと感じました。
• 感謝：チームの雰囲気を良くし、互いへのリスペクトを育むのに非常に効果的でした。時間が許せば毎回実施したいと思えるほどでした。
• Fun! Done! Learn!：「Fun」という視点は新鮮でしたが、私たちのチームにとっては発言を抽出しにくい観点でした。課題発見や自己検査のモチベーションが高い我々にとっては、少しミスマッチな面がありました。
• 象・死んだ魚・嘔吐：非常に効果的でした。チーム内で共通認識があるにもかかわらず言い出せなかった問題や、個人の理解不足などが明らかになり、重要な気づきを得ることができました。 しかし良い雰囲気を保ち続けるためのカロリーが少々高いかなと思いました。

これらの試行錯誤を経て、最終的に以下の2つの手法を採用することになりました：

1. 月1回の開催：「象・死んだ魚・嘔吐」フレームワーク

2. 毎スプリント（1週間ごと）：GPT（Good, Problem, Try）

これらの手法の選定には、「どれだけ多くの意見が出ているか」という視点を重視し、チームの現状と目標に合わせて、最も効果的だと思われる方法を選びました。

この段階的なアプローチにより、チームメンバー全員がスクラムとスプリントレトロスペクティブの重要性を理解した上で、新しい取り組みを開始することができました。これがその後のスプリントレトロスペクティブの導入、チーム改善の基盤となりました。準備段階を経て、いよいよ具体的なスプリントレトロスペクティブの実践に移ります。採用したフレームワークの詳細と、その実施方法について説明していきます。

フレームワークの採用

象・死んだ魚・嘔吐

月1回の開催で使用するこのフレームワークは、チーム内の隠れた問題や本音を引き出すのに効果的です。以下の3つの観点でふりかえりを行います：

• ①🐘 象(部屋の中の象): 誰もが認識しているが口に出さない問題。
• ②🐟 死んだ魚: 放っておくと大変なことになる問題。
• ③🤮 嘔吐: 胸の中に秘めている問題。ぶっちゃけ。

このフレームワークを通じて、チームメンバーが胸の内に抱えていた問題や思いが明らかになり、スプリントレトロスペクティブの時間では「何でも言える空気感」を醸成することができました。

GPT（Good, Problem, Try）

毎週のスプリントで使用するこの手法は、私が大学院時代に所属していたプロジェクトチームが考案したものです。以下の項目で構成されています：

• Good：そのスプリントで良かったこと
• Problem：そのスプリントで問題と思ったこと
• Try：問題に対する改善点・改善方法・アンサー

実施にあたっては、以下のルールを遵守します：

1. 箇条書きで記入する
2. 後で参照しやすい場所に記録する（Notionの折りたたみ機能など）
3. ProblemとTryは同じ欄に記入し、TryはProblemに対してネストして書く
4. Tryは赤字など、Tryであることが分かるように表記する
5. 個人とチームで主語別に欄を分けて記入する
6. イベントの冒頭で、前回のTryを振り返る時間を設ける

最後の点が特に重要です。各GPTセッションの始めに前回のTryを振り返ることで、継続的な改善サイクルを維持し、メンバーの責任感を向上させ、試みた改善策の効果を評価することができます。

このGPT手法は、シンプルながら効果的なフレームワークとして、私たちのチームのニーズに合致しました。大学院での経験を実際のプロジェクトに適用できたことは、私にとっては非常に意義深いものでした。

スプリントレトロスペクティブ導入後の変化

スプリントレトロスペクティブを導入した結果、チームに顕著な変化が見られました：

1. オープンなコミュニケーション：「ぶっちゃけ話」が自然に出るようになり、チーム内の本音のコミュニケーションが活性化しました。
2. 問題の早期発見・解決：見えない課題を抱えにくくなり、問題が大きくなる前に対処できるようになりました。
3. チームコラボレーションの向上：メンバー同士がお互いの課題や強みをより理解するようになり、協力とサポートが活性化したように思います。
4. 責任感の増加：「Try」項目の定期的なレビューにより、メンバーが改善へのコミットメントに対してより責任を持つようになりました。
5. 継続的改善文化の醸成：チームがプロセスや実践を常に改善する方法を探るマインドセットを発展させました。

これらの変化により、チームの一体感が増し、より効率的な開発が可能になりました。スプリントレトロスペクティブは、チームが定期的に作業を振り返り、問題に対処し、改善を実施するための構造化されたプラットフォームを提供し、全体的なチームの生産性向上に貢献しました。

導入時の苦労と乗り越え方

スプリントレトロスペクティブの導入には、いくつかの課題がありました。最も大きな問題は、スプリントレトロスペクティブを開催する時間の確保でした。既存の会議や業務で時間が埋まっている中、新たな取り組みのための時間を捻出するのは容易ではありませんでした。

この課題を乗り越えるために、チームのリーダーを中心に以下の対策を講じました：

1. 既存の会議の棚卸し：チームリーダー主導のもと、必要性の低い会議や重複している会議を特定し、整理しました。
2. 会議の効率化：チームリーダー主導のもと、議題の事前共有や時間制限の設定など、既存の会議をより効率的に運営するよう努めました。
3. スプリントレトロスペクティブの重要性の説明：私たちは協力して、チームメンバーやステークホルダーに対してスプリントレトロスペクティブの重要性と期待される効果を丁寧に説明し、理解と協力を得ました。

これらの取り組みにより、スプリントレトロスペクティブのための時間を確保することができました。チームリーダーの支援と主導的な役割が、この過程で非常に重要でした。リーダーの理解と協力があったからこそ、組織的な変更を円滑に進めることができたのです。

また、この経験を通じて、新しい取り組みを導入する際にはチーム全体の協力だけでなく、リーダーシップが不可欠であることを学びました。スプリントレトロスペクティブの導入は、単なるプロセスの変更ではなく、チーム文化の変革でもあったのです。

今後の展望

スプリントレトロスペクティブの導入により、チームの雰囲気や問題解決能力は大きく向上しました。しかし、私たちの目標はここで止まるものではありません。今後は以下のような長期的な目標に向けて、さらなる改善を進めていきたいと考えています：

1. 技術力と実装速度の向上：継続的な学習と技術共有を通じて、チーム全体の技術力を高めていきます。
2. ドメイン知識の均一化：チーム内でのナレッジ共有を強化し、メンバー間の知識の差を縮めていきます。
3. プロジェクトマイルストーンの達成：
   • 数ヶ月後：プロトタイプリリース
   • 数ヶ月後：本番リリース
   • 数年後：理想の事業構想に適したプロダクト群の実現
4. スプリントレトロスペクティブの更なる改善：現在の手法の効果を定期的に評価し、必要に応じて新しい手法を取り入れるなど、常に最適な形を追求します。

まとめ

スプリントレトロスペクティブの導入は、私たちのチームに大きな変革をもたらしました。オープンなコミュニケーション、問題の早期発見と解決など、多くのポジティブな変化が生まれました。

しかし、これはあくまでも始まりに過ぎません。スプリントレトロスペクティブを通じて得られた気づきや改善策を、実際の開発プロセスに反映させていくことが重要です。また、チームの成長に合わせて、スプリントレトロスペクティブ自体も進化させていく必要があります。

最後に、スプリントレトロスペクティブの成功には、チームメンバー全員の積極的な参加と、オープンで建設的な態度が不可欠です。これからも、より良いプロダクトを作り出すために、チーム一丸となって改善を続けていきたいと思います。

最後に

AI Shiftではエンジニアの採用に力を入れています！
少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？
（オンライン・19時以降の面談も可能です！）

【面談フォームはこちら】
https://hrmos.co/pages/cyberagent-group/jobs/1826557091831955459