reviews-retros-reflection

レビュー、振り返り、内省

目次

1. ワークフロー
2. 振り返りの形式
3. よくあるパターン
4. ガードレール
5. クイックリファレンス

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Retrospective Progress:
- [ ] Step 1: Set the stage (context, psychological safety)
- [ ] Step 2: Gather data (what happened)
- [ ] Step 3: Generate insights (why it happened)
- [ ] Step 4: Decide actions (what to change)
- [ ] Step 5: Close and follow up (commit, track)

ステップ 1：場を整える

期間や対象範囲を定め、前回のアクションアイテムを確認し、心理的安全性を確保します（プライムディレクティブ：「知識、スキル、リソース、状況を踏まえて、全員が最善を尽くした」）。手短なレビューには、resources/template.md を使用してください。複雑なチームの振り返りには、resources/methodology.md を参照してください。

ステップ 2：データを集める

対象期間に関する事実を集めます。指標（ベロシティ、バグ、インシデント）、イベント（リリース、障害、意思決定）、感情（チームの活力、士気）などです。収集方法については、振り返りの形式を参照してください。

ステップ 3：洞察を導き出す

パターン、根本原因、予想外の出来事を特定します。症状から原因へと掘り下げるために、「なぜ？」と問いかけます。根本原因を探る手法（5 Whys、フィッシュボーン図、タイムライン分析）については、resources/methodology.md を使用してください。

ステップ 4：アクションを決める

最も効果の高い改善策に投票します（ドット投票、SMART 基準）。SMART なアクションを 1〜3 件定めます（具体的、測定可能、担当者が明確、現実的、期限が明確）。アクションの質を判断する基準については、よくあるパターンを参照してください。

ステップ 5：締めくくり、フォローアップする

アクションに取り組むことを約束し、確認の場を設定して、参加者に感謝します。アクションの完了率を追跡します（目標：次回の振り返りまでに 80% 超を完了）。終了前に resources/evaluators/rubric_reviews_retros_reflection.json を使って自己チェックします。最低基準：平均スコア 3.5 以上。

振り返りの形式

Start/Stop/Continue（シンプルでバランスの取れた形式）：

• Start：何を始めるべきですか？
• Stop：何をやめるべきですか？
• Continue：何がうまくいっていて、続けるべきですか？
• 使用する場面：一般的な用途、新しいチーム、時間が限られているとき（30 分）

Mad/Sad/Glad（感情に焦点を当てた形式）：

• Mad：何に不満を感じたり、腹を立てたりしましたか？
• Sad：何にがっかりしましたか？
• Glad：何がうれしかったですか？
• 使用する場面：困難な期間を振り返るとき、士気を高めるとき、表面化していない問題を明らかにするとき

4Ls（包括的な形式）：

• Loved：何がよかったですか？
• Learned：何を学びましたか？
• Lacked：何が不足していましたか？
• Longed for：何を望んでいましたか？
• 使用する場面：大規模なプロジェクトの終了時、四半期ごとのレビュー、深く掘り下げたいとき

Sailboat/Speedboat（比喩を使った形式）：

• 風（推進するもの）：何が私たちを前進させていますか？
• いかり（妨げるもの）：何が私たちの足を引っ張っていますか？
• 岩（リスク）：どのような危険が待ち受けていますか？
• 島（目標）：私たちはどこへ向かっていますか？
• 使用する場面：戦略計画、進捗の可視化、部門横断チーム

タイムライン（時系列形式）：

• タイムライン上に出来事を配置し、好調な点と不調な点を示して、パターンを特定します
• 使用する場面：長期間（四半期）、複雑なプロジェクト、共通認識が必要なとき

よく使われるパターン

パターン 1：スプリントのふりかえり（アジャイル）

• 頻度：1～2 週間ごと
• 所要時間：45～90 分（スプリントが短いほど、ふりかえりも短くなります）
• 焦点：プロセスの改善、チームの力学、技術的なプラクティス
• 形式：Start/Stop/Continue または Mad/Sad/Glad
• アクション：プロセス改善を 1～3 件、技術的な改善を 1 件

パターン 2：プロジェクトの事後検証

• 頻度：プロジェクト／フェーズの終了時
• 所要時間：90～120 分
• 焦点：繰り返すべきこと、避けるべきこと、システム上の問題
• 形式：4Ls またはタイムライン
• アクション：ドキュメントの更新、プレイブックの変更、対処すべきスキルの不足

パターン 3：週次チームレビュー

• 頻度：毎週（金曜日に行うことが一般的）
• 所要時間：15～30 分
• 焦点：成果、障害、翌週の優先事項
• 形式：自由形式（成果／障害／優先事項）
• アクション：障害の解消、成果を称える、最優先の 3 項目について認識を合わせる

パターン 4：インシデントのふりかえり

• 頻度：重大なインシデントの発生後
• 所要時間：60 分
• 焦点：責任追及をしない分析、システムの改善
• 形式：タイムライン＋5 Whys
• アクション：インシデント対応の改善、監視／アラート、再発防止

ガードレール

心理的安全性：

• プライムディレクティブ：「何が分かったとしても、その時点で知っていたこと、スキルや能力、利用可能なリソース、置かれていた状況を踏まえれば、全員が最善を尽くしたのだと理解し、心から信じます。」
• 人ではなく、プロセス／システムに焦点を当てる
• 責任追及、批判、防衛的な態度を避ける
• 異なる意見を歓迎する
• ふりかえりで話した内容は、ふりかえりの場にとどめる（他の人にも役立つ内容は除く）

品質基準：

• アクション項目は SMART にする：具体的、測定可能、担当者が明確、現実的、期限が設定されている
• 完了状況を追跡する：次のふりかえりまでにアクションの 80% 超を完了する（80% 未満の場合、アクションが多すぎるか、実行へのコミットメントが不足しています）
• ファシリテーターを交代する：毎回異なる人が担当し、偏りを防ぐ
• 議論に時間制限を設ける：行き詰まらないよう先に進み、時間があれば再検討する
• 投票で焦点を決める：ドット投票を使って、議論するトピックの優先順位を決める

よくある落とし穴：

• アクションが多すぎる：アクションが 5 件を超えると、どれも実行されなくなります。影響の大きい項目を 1～3 件に絞ります。
• アクションが曖昧：「コミュニケーションを改善する」→ ❌。「月曜日までに #eng-sync で毎日 15 分のスタンドアップを実施する」→ ✓
• フォローアップがない：前回のふりかえりのアクションが無視されると、信頼が損なわれ、ふりかえりが形だけのものになります
• 責任追及の文化：非難し合うと、人々は正直に話さなくなります
• 毎回同じ問題が出る：繰り返す問題が改善しない場合は、リーダーシップにエスカレーションします

クイックリファレンス

リソース：

• 手軽なふりかえりの形式：resources/template.md
• ファシリテーションの手法：resources/methodology.md
• 品質評価基準：resources/evaluators/rubric_reviews_retros_reflection.json

5 段階のプロセス：場を整える → データを集める → インサイトを導き出す → アクションを決める → 締めくくる

主な形式：

• Start/Stop/Continue：汎用、30 分
• Mad/Sad/Glad：感情の整理、45 分
• 4Ls：深いふりかえり、60 分
• Sailboat：視覚的／戦略的、60 分

アクションの品質：SMART 基準＋合計 5 件未満＋完了率 80% 超

心理的安全性：プライムディレクティブ＋責任追及をしない＋機密保持