mcpField
R
Retrospective Facilitator

Retrospective Facilitator

github.com/jmsktm生産性10204 回インストール40 週間前に更新
リポジトリ

Retrospective Facilitator について

Retrospective Facilitatorは、アジャイルのふりかえりを実施し、継続的な改善につなげるチーム向けのスキルです。複数の形式、進行方法、改善事項の優先順位付けと追跡を扱い、心理的安全性と非難ではなく学びを重視します。

主な機能

  1. 01複数のふりかえり形式
  2. 02意見収集とテーマ整理の進行
  3. 03根本原因分析と優先順位付け
  4. 04アクション項目の作成と追跡
  5. 05対立、沈黙、非難への対処

活用シーン

  1. 01スプリント後のチームふりかえり
  2. 02インシデントの検証と根本原因分析
  3. 03前回のふりかえりで決めた改善事項の追跡
  4. 04緊張や参加不足があるチーム議論への対応

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jmsktm/claude-settings --skill retrospective-facilitator

インストール後、Claude Code で/retrospective-facilitatorを入力して読み込まれたか確認します。

詳細

レトロスペクティブファシリテーター

レトロスペクティブファシリテーターのスキルは、継続的な改善につながる効果的なレトロスペクティブの実施をチームに支援します。構造化された形式、ファシリテーションの手法、フォローアップの仕組みを提供し、レトロスペクティブが単なる不満を述べる場ではなく、実行可能な気づきを生み出せるようにします。

このスキルは、心理的安全性を高め、生産的な議論を導き、チームのフィードバックからパターンをまとめ、改善策の優先順位付けを促し、アクションアイテムの追跡と完了を徹底することを得意としています。

レトロスペクティブファシリテーターは、継続的な改善というアジャイルの原則に従います。定期的に、うまくいっていることと、うまくいっていないことを振り返り、具体的な改善策に取り組みます。目指すのは、非難や不満ではなく、学びと行動です。

主なワークフロー

ワークフロー 1:レトロスペクティブの準備

会議の前に:

  1. レトロの形式を選ぶ

    • チームの雰囲気と状況を考慮します
    • マンネリ化しないように形式を変えます(毎回同じ形式を繰り返さないでください)
    • 状況に合わせて形式を選びます:
      • 苦戦しているチーム:Sailboat、Speed Car
      • ベロシティが良好なチーム:Start/Stop/Continue、4 L's
      • インシデント後:Timeline、Fishbone
      • 新しいチーム:Hot Air Balloon、Mad/Sad/Glad
    • 形式に応じた資料を準備します
  2. データを確認する

    • スプリントの指標(ベロシティ、バーンダウン)
    • 完了した作業とコミットした作業
    • バグの件数と品質指標
    • チームの満足度スコア
    • 前回のレトロのアクションアイテム(実行されたか?)
  3. 場を整える

    • 会議室を予約するか、オンラインボード(Miro、Mural、FigJam)を用意します
    • タイマーとコラボレーションツールを準備します
    • 選んだ形式に合わせてセクションを作成します
    • 全員が平等に参加できるようにします
  4. チームにリマインドする

    • 時間と場所を記載したリマインダーを送ります
    • レトロの形式を事前に共有します
    • 考えをまとめて参加するようチームに依頼します
    • 心理的安全性と相互尊重を重視することを伝えます

**出力:**選んだ形式とデータの確認を反映した、準備済みのレトロ環境。

ワークフロー 2:レトロスペクティブセッションの進行

時間枠:2週間のスプリントで60分

フェーズ 1:場を整える(5分)

目的:安心できる場を作り、注意を集中させます

  1. チームを歓迎し、目的を伝えます
  2. レトロのルールを確認します:
    • ベガスルール:ここで話したことは、ここだけにとどめます
    • 非難せず、学びに焦点を当てます
    • 全員の意見を平等に扱います
    • 相手に善意があると考えます
  3. 簡単なチェックイン:スプリントを表す言葉を一つ挙げます
  4. 前回のアクションアイテムを確認します(実行されたか?)
フェーズ 2:データを集める(15分)

目的:チームの観察や感想を集めます

  1. レトロの形式と各セクションを紹介します
  2. 黙って書き出す(5~10分):
    • 各自がボードに付箋を追加します
    • 一般論ではなく、具体例を挙げるよう促します
    • この段階では、質より量を重視します
  3. 読み上げて分類する(5分):
    • すべての項目を手短に読み上げます(まだ議論はしません)
    • 類似するテーマをまとめます
    • ファシリテーターまたはチームメンバーが分類できます

形式の例:

  • Start/Stop/Continue
  • Mad/Sad/Glad
  • 4 L's(Liked/Learned/Lacked/Longed For)
  • Sailboat(Wind/Anchor/Rocks/Island)
  • Plus/Delta
  • Timeline
フェーズ 3:気づきを導き出す(15分)

目的:パターンを見つけ、根本原因を理解します

  1. テーマを特定する:

    • どのクラスターに最も多くの項目がありますか?
    • どのようなパターンが見えてきますか?
    • 意外な点や新たな気づきはありますか?
  2. 議論する:

    • 上位3~5つのテーマを掘り下げます
    • 根本原因を探るために「なぜ?」と問いかけます(5つのなぜの手法)
    • 全員が発言できるようにします
    • ファシリテーターは議論が生産的に進むようにします
  3. 優先事項に投票する(任意):

    • 各自に3~5票を与えます
    • 対処するうえで最も重要な課題に投票します
    • 改善の取り組みに焦点を当てやすくなります
フェーズ 4:実施することを決める(15 分)

目的:具体的な改善策に取り組むことを決定します

  1. 改善策を 1~3 件選びます:

    • 投票と話し合いに基づいて選びます
    • 具体的で、実行可能な内容にします
    • 次のスプリント内に達成できる内容にします
  2. アクションアイテムを作成します:

    • 改善策ごとに、次の点を確認します:
      • 具体的に何をするか
      • 誰が担当するか
      • いつまでに完了するか
      • 成果をどう確認するか
    • SMART 基準(具体的、測定可能、達成可能、関連性がある、期限が明確)を使用します
  3. コミットメント:

    • チームでアクションアイテムに合意します
    • スプリントバックログまたは追跡システムに追加します
    • 進捗確認のリマインダーを設定します
フェーズ 5:終了する(10 分)

目的:前向きな雰囲気で締めくくり、次のステップを確認します

  1. まとめます:

    • 主な気づきを振り返ります
    • アクションアイテムと担当者を確認します
    • 参加と率直な意見に感謝します
  2. レトロスペクティブを振り返ります:

    • 簡単なフィードバック:「このレトロスペクティブは、1~5 の尺度でどれくらい有益でしたか?」
    • この形式の良かった点は何ですか?
    • 今後のレトロスペクティブを改善するには、何が必要ですか?
  3. 感謝を伝えます:

    • チームメンバー同士で感謝を伝え合うよう促します
    • 貢献や努力を認め合います
    • 前向きで、今後につながる雰囲気で締めくくります

成果物:担当者と期限を設定した、具体的なアクションアイテム 1~3 件。

ワークフロー 3:アクションアイテムをフォローアップする

スプリント中:

  1. アクションアイテムをスプリントバックログに追加します
  2. スタンドアップまたはプロジェクトボードで追跡します
  3. スプリント中盤に進捗を確認します
  4. アクションアイテムが滞っている場合は、障害を取り除きます

次回のレトロスペクティブで:

  1. 最初に前回のアクションアイテムを確認します
  2. 完了した項目を称えます
  3. 未完了の項目がある場合は、その理由を話し合います
  4. 未完了の項目を継続、破棄、変更するか決めます

毎月:

  1. 作成したアクションアイテム数と完了した数の傾向を確認します
  2. 改善策に効果が出ているか評価します
  3. 完了率が低い場合は、レトロスペクティブの進め方を調整します
ワークフロー 4:難しい状況に対処する

対立や緊張が生じた場合:

  • 感情が表れていることを認めます
  • レトロスペクティブのルールをチームに再確認します
  • 非難ではなく、学びに焦点を戻します
  • 感情的になっている話題は、別の話し合いのために保留します

チームが沈黙している、または参加意欲が低い場合:

  • 「何が起きていますか?」と確認します
  • 別のアクティビティ(例:タイムライン、描画)を試します
  • 安心して話せる雰囲気を作るため、まず自分の気づきを共有します
  • 匿名での意見提出を検討します

毎回同じ問題が出てくる場合:

  • そのパターンを明確に認めます
  • 根本原因をより深く分析します
  • チームで解決できない場合は、マネジメントにエスカレーションします
  • 以前のアクションアイテムが適切な対応だったかを問い直します

非難や責任の押し付けが起きた場合:

  • システムやプロセスの問題として捉え直します
  • 「これが起きることを許した条件は何ですか?」
  • 「これを防ぐにはどうすればよいですか?」と、今後に焦点を移します

クイックリファレンス

アクションコマンド/トリガー
レトロスペクティブを実施する"facilitate retrospective"
形式を選ぶ"suggest retro format"
アクションアイテムを確認する"check retro action items"
レトロスペクティブのテンプレート"create retro board for [format]"
対立に対処する"retro facilitation help"

ベストプラクティス

  • 形式に変化をつける:毎回同じ形式を使わないようにします。新鮮さが保たれ、さまざまな気づきが得られます
  • 心理的安全性を最優先する:安心して発言できなければ、率直なフィードバックではなく、当たり障りのない同意しか得られません
  • 時間を厳守する:参加者の時間を尊重します。だらだらとした 90 分より、集中した 60 分のほうが効果的です
  • 前回のアクションを確認する:アクションアイテムが一度も実行されないなら、なぜ新たに作成するのでしょうか?
  • 改善策は最大 1~3 件にする:すべてを解決することはできません。焦点を絞ることで勢いが生まれます
  • 具体的にする:「コミュニケーションを改善する」では曖昧です。「毎日午前 10 時までにスタンドアップを行う」なら実行可能です
  • 省略しない:定期的に実施することで信頼と習慣が築かれます。「話すことがない」と感じても省略しません
  • ファシリテーターを交代する:ファシリテーターが変わると、新たな視点と活気が生まれます
  • 意見ではなくデータを使う:指標を使って、現実に基づく話し合いにします
  • 学びに焦点を当てる:「誰が失敗したのか?」ではなく、「何を学んだのか?」を問いかけます
  • 良かった点にも感謝する:問題だけに注目せず、成果や強みも認めます
  • 最後までやり遂げる:アクションアイテムが一度も完了しなければ、チームはプロセスを信頼しなくなります

レトロスペクティブの形式

1. Start/Stop/Continue

最適な用途:汎用的で、どのチームにも使えます

カテゴリー:

  • Start:これから始めるべきことは何ですか?
  • Stop:やめるべきことは何ですか?
  • Continue:続けるべきことは何ですか?

ファシリテーター向けのヒント:

  • 「Continue」は忘れられがちです。良い取り組みを積極的に挙げてもらいましょう
  • 「Stop」の項目に直接対処する「Start」の項目がないか確認しましょう
2. Mad/Sad/Glad

最適な用途:難しいスプリントの後など、感情が高ぶっているとき

カテゴリー:

  • Mad:何に苛立ち、腹が立ちましたか?
  • Sad:何にがっかりしましたか?
  • Glad:何がうれしかったですか?

ファシリテーター向けのヒント:

  • 感情を受け止めながら、改善へとつなげられます
  • 「Glad」にも同じだけ時間を割き、否定的なことだけに注目しないようにしましょう
3. 4 L's

最適な用途:学びを重視するチーム、新しい取り組みの後

カテゴリー:

  • Liked:何がうまくいきましたか?
  • Learned:何を学びましたか?
  • Lacked:何が不足していましたか?
  • Longed For:何があればよかったと思いますか?

ファシリテーター向けのヒント:

  • 「Learned」から、ナレッジ共有につながる知見が得られます
  • 「Longed For」から、チームのニーズや願いが明らかになります
4. Sailboat

最適な用途:戦略的な思考や、中長期的な計画

カテゴリー:

  • Island:私たちの目標
  • Wind:前進を助けているものは何ですか?
  • Anchor:足止めになっているものは何ですか?
  • Rocks:今後どのようなリスクがありますか?

ファシリテーター向けのヒント:

  • 認識を合わせるため、共通の目標であるIslandから始めましょう
  • 視覚的なたとえが、創造的な思考を促します
5. Speed Car

最適な用途:チームが速く進んでいるものの、無謀になっている可能性があるとき

カテゴリー:

  • Engine:何が前進の原動力になっていますか?
  • Parachute:何が進みを遅らせていますか?
  • Bridge:何が前進を助けていますか?
  • Wall:どのような障害が立ちはだかっていますか?

ファシリテーター向けのヒント:

  • 促進要因と減速要因の両方に注目できます
  • ペースや持続可能性について話し合うのに適しています
6. Plus/Delta

最適な用途:シンプルで短時間の振り返り

カテゴリー:

  • Plus (+):何がうまくいきましたか?
  • Delta (Δ):何を変えるべきですか?

ファシリテーター向けのヒント:

  • 手早く、わかりやすく進められます
  • 時間が限られているときに使いましょう
  • Deltaは「minus」よりも否定的な印象が薄い言葉です
7. Timeline

最適な用途:大きなイベント、インシデント、複雑なスプリントの後

手順:

  1. スプリントやイベントのタイムラインを描きます
  2. 各参加者が重要な出来事を追加します
  3. パターンや転換点を特定します
  4. 何を学び、何を変えるべきか話し合います

ファシリテーター向けのヒント:

  • 複雑な状況を再構成するのに役立ちます
  • 同じ出来事に対する異なる見方が明らかになります
8. Hot Air Balloon

最適な用途:新しいチームや大きな変化の後

カテゴリー:

  • Hot Air:何が私たちを押し上げていますか?(強み、機会)
  • Sandbags:何が私たちの重荷になっていますか?(課題、障害)
  • Storm Clouds:どのような外部の脅威がありますか?
  • Clear Skies:今後どのような機会がありますか?

ファシリテーター向けのヒント:

  • チームビルディングや共通のビジョンづくりに適しています
  • 内部要因と外部要因の両方を考慮できます

5 Whys Technique

根本原因分析に使用します:

  1. 問題を明示します
  2. 「なぜこれが起きたのですか?」と尋ねます → 回答
  3. 「なぜ[回答]が起きたのですか?」と尋ねます → 回答
  4. 根本原因が明らかになるまで、3〜5回繰り返します
  5. 根本原因に対処するアクションアイテムを作成します

例:

  • 問題:本番環境でテストが失敗した
  • なぜ? → ステージング環境でコードをテストしていなかった
  • なぜ? → ステージング環境が停止していた
  • なぜ? → 障害を検知する監視がなかった
  • なぜ? → インフラの監視を優先していなかった
  • アクション:インフラの監視とアラートを導入する

Action Item Template

**Improvement**: [Brief description]

**Action**: [Specific thing we will do]
**Owner**: [Name of person responsible]
**Due Date**: [When will this be complete]
**Success Criteria**: [How we'll know it worked]

**Example**:
Improvement: Reduce context switching during sprint
Action: Implement "No meeting Thursdays" for deep work
Owner: Sarah (Engineering Manager)
Due Date: Start next sprint (Feb 15)
Success Criteria: Team reports 4+ hour uninterrupted work blocks on Thursdays

ファシリテーションのアンチパターン

よくある次の間違いを避けてください:

  • ファシリテーターが主導しすぎる:あなたの役割は導くことであり、すべての答えを示すことではありません
  • アクションアイテムを省略する:アクションのない振り返りは、ただの愚痴になってしまいます
  • フォローアップがない:アクションを一度も見直さなければ、チームは取り組むのをやめてしまいます
  • 毎回同じ形式にする:内容が古びて、先が読めるようになります
  • 議論を予定時間内に終わらせない:時間を区切ることは、相手への敬意を示します
  • 明らかな問題に対処しない:明白な問題を無視すると、信頼が損なわれます
  • 個人の問題にする:人ではなく、システムやプロセスに焦点を当てます
  • アクションが多すぎる:1~3件が現実的です。10件では負担が大きすぎます
  • 改善案が曖昧:「コミュニケーションを改善する」では具体的な行動につながりません
  • 忙しいときに省略する:「振り返りをする時間がない」という姿勢は、改善が重視されていないことを示します

心理的安全性チェックリスト

振り返りの前と最中に、次の点を確認してください:

  • チームがフィードバックは秘密として扱われると理解している
  • 全員の声が平等に聞かれている
  • 異論を述べても歓迎され、安全である
  • 非難や批判がない
  • 失敗が学びの機会として扱われている
  • リーダーシップが弱さを見せ、オープンである姿勢を示している
  • 正直に話したことへの報復には、相応の結果が伴う
  • 必要に応じて匿名で意見を出せる

統合ポイント

  • スプリントプランナー:各スプリントの終了時に振り返りを予定する
  • タスクマネージャー:振り返りのアクションアイテムをタスクとして管理する
  • プロジェクトプランナー:学びを今後の計画に反映する
  • チームメトリクス:データを活用して議論に役立てる
  • ナレッジベース:重要な学びやパターンを記録する
  • 継続的改善:振り返りを通じて見られる傾向を、プロセスの変更に反映する

コメント