mcpField
I
iterate-retrospective

iterate-retrospective

github.com/product-on-purpose生産性769747 回インストール4 日前に更新
リポジトリ

iterate-retrospective について

スプリント、プロジェクト、インシデント後や定期的なチームの振り返りを進行・記録するスキルです。意見の共有から優先課題の選定、担当者と期限付きのアクション設定まで支援し、任意で教訓をプロジェクトメモリーに記録できます。

主な機能

  1. 01レトロスペクティブ形式の選択
  2. 02チームの意見収集と分類
  3. 03議論する課題の優先順位付け
  4. 04担当者と期限付きのアクション設定
  5. 05前回の対応確認と教訓の記録

活用シーン

  1. 01スプリント終了時の振り返り
  2. 02プロジェクトやインシデント後の検討
  3. 03チームの関係性と改善点の議論
  4. 04複数回の振り返りにおける約束の追跡

インストール

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

$npx skills add https://github.com/product-on-purpose/pm-skills --skill iterate-retrospective

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
evals/
trigger-fixtures.json
evals/output-scenarios/
sprint-42.md
references/
EXAMPLE.md
TEMPLATE.md

詳細

振り返り

振り返りとは、チームが経験から学び、継続的に改善するための体系的な内省です。うまくいったこと、うまくいかなかったこと、変更すべきことを定期的に検討することで、チームは学習と適応の文化を築きます。価値があるのは、話し合いだけではありません。記録されたアクションと、その後の実行にも価値があります。

使用する場合

  • 各スプリントの終了時(アジャイルチームの場合)
  • 重要なプロジェクトやマイルストーンの完了後
  • 重大なインシデントやサービス停止の発生後
  • チーム内の関係に違和感があり、対処が必要なとき
  • 特定のきっかけがなくても、定期的に(毎月、四半期ごと)
  • 新しいチームメンバーを受け入れ、改善の文化を根付かせるとき

使用しない場合

  • 組織のために、長く残る学びを1つ蓄積したい場合 → iterate-lessons-log を使用します。振り返りはその場のセレモニーであり、ログの記録はその後も残ります
  • OKR サイクルの終了時に評価を行う場合 → measure-okr-grader を使用します
  • 内省の結果、方向転換するか継続するかの判断を下す必要がある場合 → iterate-pivot-decision を使用します
  • 振り返り以外の一般的な会議の要約が必要な場合 → foundation-meeting-recap を使用します

手順

振り返りの進行や記録を依頼された場合は、次の手順に従います。

  1. 背景を設定する この振り返りの対象期間やプロジェクト、参加者、発生した重要な出来事を明確にします。これにより、話し合いの枠組みが定まり、将来の読者が背景を理解しやすくなります。

  2. 形式を選ぶ チームのニーズに合った振り返りの形式を選びます。一般的な形式には次のものがあります。

    • Start/Stop/Continue: シンプルで直接的
    • 4Ls: 好きだったこと、学んだこと、足りなかったこと、望んでいたこと
    • Mad/Sad/Glad: 感情に焦点を当てる
    • Sailboat: 視覚的な比喩(風=助けになるもの、錨=妨げになるもの)
  3. 意見を集める すべてのチームメンバーから気づきを集めます。全員が意見を出せるようにします。発言の少ない人が重要な洞察を持っていることもよくあります。共通するテーマを見つけるため、似た項目をまとめます。

  4. 話し合い、優先順位をつける すべてに対処しようとしないでください。最も影響の大きい項目に話し合いを集中させます。投票や話し合いを通じて、取り組むべき上位2〜3件の課題を特定します。

  5. アクション項目を定める 洞察を、担当者を割り当てられる具体的なアクションに変換します。各アクションには担当者と期限が必要です。「もっとよくコミュニケーションを取る」のような曖昧な改善策は避けます。

  6. 前回のアクションを確認する 前回の振り返りで決めたアクション項目の状況を確認します。完了した項目を称え、未完了の項目を妨げている要因について話し合います。これにより、説明責任が高まります。

  7. 後から参照できるように記録する 重要なポイントを記録し、将来のチームメンバーが参照できるようにするとともに、時間の経過に伴う傾向を追跡できるようにします。

プロジェクトメモリーの契約

.claude/pm-skills.local.md が存在する場合にのみ有効です。ファイルがない場合は、このセクション全体を無視し、 上記の説明どおりに動作してください。

  • 読み込み: 最近の artifacts[] エントリーを読み込みます。これにより、記憶に頼るのではなく、サイクルで実際に生み出されたものをもとに振り返りを行えます。
  • 書き込み: 学びを interpretation アーティファクトとして書き込みます。
  • 方針: memory_auto_append: true が設定されていない限り、エントリー案を提示し、確認を待ってから書き込みます。設定されている場合は追記し、書き込んだ内容を返します。
  • 書き込みの規律: 書き込みの直前にファイルを再読み込みします。提案の作成に使ったコピーから書き込んではいけません。その間にファイルが変更されていた場合は、現在の状態にエントリーを統合し、上書きするのではなく再度提案します。自分のエントリーだけを追加し、それ以外のすべてのフィールドとセクションはバイト単位で変更しないでください。実行時にこれを強制する仕組みはなく、ファイルは gitignore の対象です。そのため、ファイル全体を不用意に書き込むと、復元手段のないまま別のセッションの作業を失うことになります。

振り返りでは、生の観察、パターン、約束事が一度に表面化します。長く残す価値のある部分、つまり学びは、単一のタグの下に記録します。後から読む人はエントリーをどの程度重視すべきか知る必要がありますが、複数の意味が混在したタグでは何も伝わりません。

出力形式

出力の構成には、references/TEMPLATE.md のテンプレートを使用します。振り返りをすべて記入するには、テンプレートの各セクション(概要、前回の振り返りのレビュー、うまくいったこと、改善点、議論のメモ、アクションアイテム、保留事項、指標と傾向、ファシリテーターのメモ、次回の振り返り)を埋めます。

品質チェックリスト

最終版を作成する前に、以下を確認します。

  • すべての参加者に発言する機会があった
  • 良かった点と改善点の両方が記録されている
  • アクションアイテムに担当者と期限が設定されている
  • 前回の振り返りで決定したアクションがレビューされている
  • 振り返りに参加できなかった読者が、このドキュメントだけで決定事項と各アクションの担当者を把握できる

例

記入済みの例については、references/EXAMPLE.md を参照してください。

コメント