フリーランスITエンジニアと案件・企業をつなぐマッチングサイト
スキルアップ

スプリントレトロスペクティブの進め方|目的・タイムボックス・改善の扱い方

公開日 更新日 この記事は約6分で読めます
スプリントレトロスペクティブの進め方|目的・タイムボックス・改善の扱い方

スプリントレトロスペクティブはScrumの4イベントの中でも進め方が現場ごとに割れやすい。Scrum Guideの定義に沿って目的・5つの検査対象・改善策の扱い方を整理し、フリーランスが案件で初参加するときの振る舞い方、BP企業側が社内チームに定着させる進め方の両方をまとめた。

スプリントレトロスペクティブは「スプリントを終える」イベント

Scrum Guideは、スプリントレトロスペクティブの目的を「品質と効果を高める方法を計画すること」と定義している。スプリントの終わりに置かれ、このイベントを終えることでスプリントそのものが完了する、という位置づけがScrum Guideの原文にある。スプリントレビューが「成果物の検査と今後の適応」を扱うのに対し、レトロスペクティブは「チームの働き方そのもの」を検査対象にする点が違う。

タイムボックスは、1か月のスプリントであれば最大3時間が基準になる。スプリントの期間が短くなれば、イベントの時間もそれに応じて短くする、というのがScrum Guideの考え方であり、具体的な時間は固定の表ではなく「スプリントの長さに比例して縮める」という原則で決まる。この原則をそのまま当てはめると、2週間スプリントでは上限3時間の半分にあたる1.5時間程度、1週間スプリントではさらにその半分の45分程度が実務での目安になる。2週間スプリントの現場で「1時間も話すことがない」「逆に3時間かけても終わらない」という声が出るのは、この比例の原則と時間の目安が共有されていないことが多い。

目安の時間は、話すだけで終わらないように区切って使う。2週間スプリントの1.5時間であれば、前回決めた改善策の進捗確認に10分、その回で深掘りする検査対象の選定に20分、選んだ対象についての話し合いに40分、次のスプリントに持ち込む改善策の確定に20分という順序で配分すると、時間切れで改善策が決まらずに終わる事態を避けやすい。1週間スプリントの45分であれば、進捗確認5分、対象の選定10分、話し合い20分、改善策の確定10分まで圧縮する。

何を検査するのか — Scrum Guideが挙げる5つの対象

Scrum Guideは、Scrum Teamが検査する対象を「個人、相互作用、プロセス、ツール、そしてDefinition of Done」の5つと定義している。これはチェックリストというより、話し合う範囲を示すものだ。

  • 個人:各メンバーの関わり方、相談のしやすさ、作業負荷の偏り
  • 相互作用:チーム内のコミュニケーション、役割分担、情報共有の仕方
  • プロセス:スプリント中の進め方、見積りの精度、割り込みの扱い方
  • ツール:使っているタスク管理・CI/CD・コミュニケーションツールが働きやすさを妨げていないか
  • Definition of Done:完成の基準そのものが実情に合っているか、見直しが必要か

この5つを毎回均等に扱う必要はない。そのスプリントで一番詰まった対象を深く掘るほうが、レトロスペクティブの目的である「効果を高める方法を計画する」ことに近づく。毎回同じフォーマット(KPT・星取表など)を機械的に回すだけでは、5つの対象のうち話しやすい1つだけに話が偏りやすい。

深掘りする対象を選ぶときは、次の基準で絞り込む。1つ目は、そのスプリント中に同じ問題が複数回起きた対象を優先する基準(頻度)。2つ目は、見過ごすと次のスプリントの遅延や品質低下に直結する対象を優先する基準(影響度)。この2つで絞れないときは、参加者がそれぞれ5つの対象から1つを選んで挙手し、最も票を集めた対象を掘るという決め方で進める。

改善策はどう扱うか — 「次に何を変えるか」まで決めて終える

Scrum Guideは、チームが「最も効果的な改善を特定し、最も影響の大きい改善は可能な限り早く着手する」ことを求めている。さらに、その改善策は次のスプリントのスプリントバックログに追加されることがある、とも述べている。つまりレトロスペクティブは、問題を挙げて共有するだけでは目的を満たしておらず、次のスプリントで実際に着手する項目に落とし込むところまでがイベントの範囲になる。

実務でよく起きるのは、話し合いの場では盛り上がるが、改善策が誰の作業にも紐づかずに次のスプリントで忘れられるケースだ。改善策をスプリントバックログに1項目として入れる、担当者を決める、次回のレトロスペクティブで「前回決めた改善はどうなったか」を最初に確認する、という3点を押さえると、話し合いが実際の行動に変わりやすくなる。

フリーランスがBP先の案件で初めてレトロスペクティブに参加するとき

役割ごとの振る舞い方(プロダクトオーナー・スクラムマスター・開発者それ�ぞれがレトロスペクティブでどう動くか)は役割を解説した別記事で扱っているため、ここでは参加者全体に共通する振る舞いに絞る。

BP先の案件に途中から参加する場合、レトロスペクティブは「チームの働き方の検査」であることを踏まえて振る舞うと、早く受け入れられやすい。

  • 初回は聞き手に回り、既存メンバーがどの対象(個人・相互作用・プロセス・ツール・Definition of Done)について話しているかを観察する。チームごとに重視する対象が違うため、先に把握してから発言したほうが的を外さない
  • 自分が気づいた課題は、個人を名指しで批判する形ではなく、プロセスやツールの話として提起する。Scrum Teamが検査する対象自体がプロセス・ツールを含んでいるため、この言い方のほうが議論に乗りやすい
  • 改善策が決まったら、自分の担当分は次のスプリントバックログに反映されているかを確認する。BP先のルールに不慣れなうちは、決まったことが自分のタスク管理に反映されているかどうかが抜けやすい

レトロスペクティブは評価の場ではなく、次のスプリントの進め方を決める場だと理解しておくと、発言のハードルが下がる。

BP企業側が社内のScrumチームに定着させる進め方

企業側の担当者がレトロスペクティブを形だけのイベントで終わらせないためには、次の3点が効く。

  1. タイムボックスをスプリントの長さに合わせて見直す。1か月スプリントの上限(最大3時間)を基準に、2週間スプリントなら1.5時間、1週間スプリントなら45分を目安にする。長いスプリント用の時間をそのまま短いスプリントに当てはめると長すぎる
  2. 5つの検査対象(個人・相互作用・プロセス・ツール・Definition of Done)のどれかに話が偏っていないかを確認する。ファシリテーター役が、長期間話題に出ていない対象がないかを見る。偏りがあれば、頻度(同じ問題が繰り返し起きている対象)か影響度(見過ごすと遅延・品質低下に直結する対象)のどちらかを基準に、意図的にその対象を取り上げる
  3. 決まった改善策の進捗を次回の冒頭で確認する運用を固定する。これにより「レトロスペクティブで話したことが変わらない」という不満が減り、イベント自体の信頼が積み上がる

外部のフリーランスエンジニアが参加するチームでは、レトロスペクティブの進め方がチームによって違うと、参加者が毎回最初から様子を見ることになり、改善のサイクルが遅くなる。進め方を社内で文書化しておくと、新しく加わる人の立ち上がりが早くなる。

三本柱との関係

Scrumの三本柱(透明性・検査・適応)とその土台になる五つの価値基準は、役割や全体像を解説した別記事で扱っている。ここでは三本柱のうち、レトロスペクティブが「検査」と「適応」をどのように実行するイベントかに絞って触れる。検査する対象(個人・相互作用・プロセス・ツール・Definition of Done)が決まっていなければ検査自体が成立せず、検査した結果を次のスプリントバックログに反映しなければ適応が成立しない。レトロスペクティブの進め方に迷ったときは、「どの対象を検査したか」「その結果、次のスプリントで何を変えるか」の2点に立ち返ると、イベントの目的から外れていないかを確認しやすい。

フリーランスの案件探しを、コンシェルジュがサポート

無料会員登録で、スキルやご希望に合った案件のご紹介から参画まで担当コンシェルジュがサポートします。

RELATED

「スキルアップ」の他の記事

デイリースクラムを15分で終わらせる実務ガイド|目的・よくある失敗・運用の直し方
スキルアップ

デイリースクラムを15分で終わらせる実務ガイド|目的・よくある失敗・運用の直し方

デイリースクラムは15分のイベントだが、報告会になったり時間が延びたりする現場は多い。Scrum Guideが定義する目的・参加者・構造の条件に沿って、15分に収まらない原因と直し方を整理した。フリーランスが案件で初参加するときの振る舞い方、BP企業側で運用を固定する手順もまとめた。

続きを読む →
参画初日にJiraボードを読み解く——スクラム/カンバン、列、スイムレーン、WIP制限の確認順
スキルアップ

参画初日にJiraボードを読み解く——スクラム/カンバン、列、スイムレーン、WIP制限の確認順

新しい案件の初日、Jiraボードの「見た目」だけで進捗を判断すると誤読する。ボードの種類・列のマッピング・スイムレーン・WIP制限の4点を、Atlassian公式ドキュメントの定義に沿って最短で確認する順番を解説する。

続きを読む →
プロダクトオーナー・スクラムマスター・開発者 ― Scrum Guideで確認する3つの役割
スキルアップ

プロダクトオーナー・スクラムマスター・開発者 ― Scrum Guideで確認する3つの役割

募集要項の「スクラムマスター経験」「PO経験」は、Scrum Guideが定義する役割とずれて使われることがあります。原典の定義と募集要項の実例を並べ、フリーランスが面談で確認する質問、BP企業が要件を書き換える際の表現の変え方を整理します。

続きを読む →