event-debrief

イベントの振り返り

開催チームの振り返りを実施します。対象は終了した1回分です。ミーティング、再構成、調査結果、次回の計画につながるログを扱います。内部向けのみで、参加者、登壇者、スポンサーに届くものはありません。

毎回、例外なく実施してください。 このスキルが参考にしているSREのインシデント事後分析の考え方では、重大度のしきい値（SEV1／SEV2、または15分を超えるサービス停止）を基準に事後分析を実施するかどうかを決めます。しかし、その基準はここには当てはまりません。何も問題が起きなかった静かな回であっても、必ず振り返りを行います。目的は、インシデントへの対処ではなく、繰り返し実施する取り組みを改善することです。「問題なかったから、今回は省略しよう」という判断を防ぐためのルールです。

以下の5つはすでに決定済みです。確認して照合しますが、決定を覆してはいけません。

関連スキル	担当範囲	あなたが行うこと
event-feedback	参加者、登壇者、スポンサーからの意見収集	概要を参照します。参加者にアンケートを実施したり、参加者向けの文章を書いたりしてはいけません
event-risk-management	分類体系、スコアリング、対応策	発生した事象を照合し、結果を返します
event-budget	損益、次回の数値	実績と計画を比較し、差異を返します
event-run-of-show	当日の運営	問題が起きたことを生の情報として記録します。再度診断してはいけません
event-market-fit	コンセプトが引き続き需要に合っているか	今回の開催が、このチーム の設定した目標を達成したかどうかを判断材料として示します。開催可否の判断材料にはしてはいけません

上流との境界：開催回をまたぐ傾向は、あなたの担当ではありません。 あなたが作成するのは、1回分の開催日を記録したログです。event-continuous-improvement が各回の情報を集約します。今回の開催を直近2回と比較すると、このスキルが存在する理由そのものと重複してしまいます。

現場で実際に公開されている情報

公開されている主催者向けガイドでは、この話題は多くても数行でしか触れられていません。代わりに、以下で説明する進め方、つまり振り返りを行う時期、参加者、ログを次回の計画に反映する方法は、SREのインシデント事後分析の考え方を、平日に停止するサービスではなく年に1回開催する取り組みに合わせて応用したものです。根拠となる詳細については、references/field-precedent.md を参照してください。

インタビュー

一度に質問するのは1つだけとし、可能な場合は選択式にします。以下のメニューは、効果が出るまでの時間、持続性、労力が大きく異なるため、質問6〜8を設けています。これらへの回答なしに、ユーザーに代わって標準の順序を選ぶことはできません。

1. 終了したのは何回目の開催で、いつ閉場し、何日前のことですか？振り返りと考古学的な調査のどちらを行うかが決まります。
2. チームはイベント開催前に、どのような目標を自分たちの言葉で設定していましたか？文書化されていない場合は、そう伝えてください。レビューは測定ではなく、再構成になります。
3. 誰が正式な役割を担い、誰がその場に参加できますか？ボランティアリーダーを欠いた振り返りでは、その人だけが見ていた一日の半分を見落とします。
4. 次の4つの資料のうち、すでにあるものはどれですか：フィードバックの要約、リスク登録簿、予定予算、進行台本？資料が1つでも欠けていると、実施できない照合作業が生じます。
5. ボランティア主体ですか、それとも有給スタッフがいますか？安全に発言できる内容と、誰にアクションアイテムを割り当てられるかが変わります。
6. 次回の開催に向けた計画は、実際にはいつ始まりますか？その日付が、このスキルの期限です。
7. 単発、最終回、それとも今後何年も続ける予定ですか？終了に向けた開催と、成果を積み重ねる開催では、同じメニューに求めるものが正反対になります。
8. 労力の上限はどのくらいですか：残り何時間で、チームはどのような状態ですか？正直に答えてください。疲弊したチームは、迂回すべきスケジュール上の問題ではなく、最初に見つけるべき課題です。
9. 今回の開催後にリーダーシップを引き継ぎますか？また、イベントは1つの運営体制で行いますか、それとも共通ブランドのもとで複数の都市で開催しますか？
10. 今回の開催では、行動規範に関する報告を何件受け、何件解決しましたか？また、コミュニティにすでに知られているほど目立った報告はありましたか？
11. このイベントは一般公開ですか、それとも非公開／NDAの対象ですか？
12. チームはすでに、別の目的で通年のトラッカーを運用していますか？

参加者と報酬

このスキルの出力を左右する軸は、誰がその場にいて、どのような報酬を受け取っているかです。何を話せるか、誰にタスクを任せられるかが決まります。ボランティア主体：雇用関係が会話を和らげることはないため、率直に話すハードルは低くなりますが、アクションアイテムを引き受けるマネージャーがいません。また、批判されたボランティアは、記録に残らない損失となってボランティア活動をやめてしまいます。有給スタッフ主体：アクションアイテムが業務に含まれる担当者に割り当てられるため、実行に移されやすい構造です。一方で、非難しないという枠組みを明示し、徹底しなければ、振り返りが業績評価に流れがちです。混成（よくあるケース）：この場合は、枠組みを特に明確に示してください。ボランティアと、その人の本業での上司が同じ場にいると、業務量についてボランティアが話す内容が変わります。

ワークフロー

1. インタビューを実施します。何かを予約する前に、深度の段階を選びます。
2. すぐに日程を設定し、早めに実施を確定します。 標準的な間隔はありません。間隔を提案し、チームが解散する前にカレンダーに登録します。
3. 責任を追及しない枠組みを、会場で声に出して冒頭に伝えます ― 問うのは「どんな条件がこれを可能にしたのか」であり、「誰がこれを引き起こしたのか」ではありません。所見では、個人ではなく、ギャップやシステムについて記述します。
4. 分析に入る前に、タイムラインを再構成します。 その回を時系列に沿って振り返ります。まず再構成し、判断はその後です。意見に飛びつく場では、実際の流れではなく、最も声の大きい記憶について議論し直すことになります。
5. うまくいったことと、うまくいかなかったことを、明確に分けて2回に分けて扱います。 まず「うまくいったこと」から始めます。うまく機能したのに名前が挙がらなかった取り組みは、次の回では気づかれないまま廃止されるからです。
6. 既存のものと照合します：リスク登録簿、計画予算、進行表、Q2の目標です。4つを確認し、それぞれの成果物を担当する兄弟スキルに渡します。チェックリスト：references/reconciliation-and-session-agenda.md。
   • チームがKPIの候補を絞り込んでいる場合（samber/dev-event-organizer-skills@event-continuous-improvementで定義されている、担当者とアクションがそれぞれ設定された2～3個のKPI）、この回の各KPIの値を、ここで定めた基準値と照らし合わせます。振り返りでKPIを追加してはいけません。担当者もアクションもない数値は、誰も読み返さない巨大なダッシュボードになるだけです。
   • チームがイベントごとに自己評価による「インパクト強度」を採点している場合は、シーズン開始前に定めた尺度を使って、今ここで採点します。少なくとも2人の運営者が個別に採点し、意見の相違は平均化せずに記録します。
   • 成果を記録します。 この回からすでに生まれた成果 ― 始動したプロジェクト、コラボレーション、設立された企業、見つかった仕事 ― を、それぞれの出典とともに列挙し、samber/dev-event-organizer-skills@event-continuous-improvementの成果ログに渡します。ほぼすべてのハッカソンの回で、少なくとも1社は設立される可能性があります。このような成果は、所見だけを記録するログでは見えません。数か月後にさらに成果が明らかになることを見込みましょう。これは最初の記録であり、全件ではありません。
7. チームの健康状態に関する所見を表面化させ、解決せずに適切な担当先へ回します。 疲弊、1人しか担えない役割、規模が見積もられていない作業負荷は、event-team-structureに渡す構造上の所見であり、あなたが解決するものではありません。
8. 各所見を3部構成で記録します：何が起きたか、その場で何をしたか、次の回で何を変えるか ― 意図的に簡潔にします。形式とエスカレーション基準：references/lessons-learned-entries.md。
9. 未完了の記録にはすべて担当者と期限を設定するか、明示的にクローズします。 放置される記録を作ってはいけません。担当者のいない記録は、教訓ではなく願望です。対応が不要な場合は、無理に対応を作り出さず、「対応不要。その理由は～」と記載します。
10. 所見が新鮮なうちに、会場でチームとして公開方針を決めます。
11. ログ全体を日付入りの1文書としてevent-continuous-improvementに渡し、それぞれの照合作業の成果物を担当する兄弟スキルに渡して、終了します。

ハーネスに永続メモリがある場合は、次を記録します。

• 日付入りのログそのもの
• この回の評価に用いた目標
• KPI候補の値、インパクト強度のスコア、記録した成果
• 担当者と期限を含むすべてのアクション項目
• どの所見をどの兄弟スキルに回したか

次の回の振り返りは、白紙ではなく前回の未完了項目から始まります。そして、この引き継ぎリストは、samber/dev-event-organizer-skills@event-continuous-improvementが後から再構成できない唯一の入力です。

以下の各ランキングはすべてデフォルトであり、絶対的な決まりではありません。状況や実行者によって変わります。制約によって段階を1つ削除する場合は、そのメニューの軸の行からも削除してください。並び順に段階が残れば、読者の頭にも残り、スコープとして再び持ち出されます。このチームについてすでにわかっていることを踏まえて、3つすべてのメニューを再度順位づけします。

• 職場でスプリントの振り返りを行うチームは、努力の軸が想定するよりはるかに低いコストで、より深い振り返りの段階を実施できます。
• 公開用の振り返りレポートを出す慣習があるイベントは、すでに公開メニューのデフォルトの段階にあります。
• 共有トラッカーを年間を通じてすでに運用しているチームでは、追跡メニューの不足している選択肢をほぼ無料で実施できます。新たな定常業務ではなく、既存の習慣だからです。
• 1人が3つの役割を担うチームでは、深さメニューが得ようとしている知見がすでに生み出されています。

振り返りの深さ

段階別メニュー — チームに残されたエネルギーあたりのコストで、次回の開催を実際に変える知見を順位付けしたものです。3つの順位付けはいずれも、公開されている標準ではなく判断に基づいています。主催者向けガイドには、振り返りの形式が定められていません。

• 労力（時間、日程調整、ファシリテーション）：複数トラックの文書レビュー > トラック別セッション > 事前の文書共有＋1回のセッション > 1回のセッション
• 価値（失われずに得られる知見）：複数トラックの文書レビュー > トラック別セッション > 事前の文書共有＋1回のセッション > 1回のセッション
• 効率：事前の文書共有＋1回のセッション > 1回のセッション > トラック別セッション > 複数トラックの文書レビュー

優越性チェック：4段階、6組、厳密な優越関係はゼロ — これは構成上のみ整っている状態であり、構成上整っているだけでは合格になりません。 価値と労力の順位は同じなので、1つの要因が6組すべてを阻みます。より多くの知見を得られる段階ほど、チームの作業時間が必ず増えます。どの組にも、他の軸が妨げにも救済にもなりません。効率の順位は、以下の説明に基づいています。

価値の上位2段階は労力でも上位2段階なので、効率では順位の中ほどが逆転します。イベント直後は時間が制約となり、トラックごとの調整は、そこから得られる詳細さ以上の割合で負担が増えます。

• 1回のセッション - 60～90分の会議を1回行い、日付入りのログにその場で記録します。
• 事前の文書共有＋1回のセッション（デフォルト） - 指名された各役割の担当者が事前に良かった点／悪かった点のリストを提出し、セッションでは情報を集めるのではなく議論します。これにより、発言しにくい主催者の知見も得られ、最初に発言した人の意見が場を支配するのを防げます。
• トラック別セッション - ワークストリームごとに振り返りを行い、その後、統合セッションを1回行います。指名されたワークストリームのリードが実際に独立して作業していた場合、つまり、何が起きたかを知る全員が同じ部屋に集まることがない場合に昇格させます。
• 複数トラックの文書レビュー（不足している段階） - トラック別セッションに加え、各トラックの文書を作成し、統合して開催全体のレポートにします。価値と労力の両方で最上位となるため、効率では決して選ばれません。Q9に基づく昇格条件：リーダーシップの引き継ぎがある（新しいチームが文書記録を引き継ぐ）場合、または、系列イベント／複数都市で開催されるイベントで、姉妹イベントの主催者がお互いのレビューを読む場合です。

「チーム」が1人か2人の場合は、トラック別の段階を降格させるのではなく、両方とも削除してください。2人で5回のトラック別セッションを行うのは、形式だけのものです。

レトロスペクティブ用テーブル

1回の会議で議事録は作れますが、サイクルを通じて開いたままにする継続的なテーブルがあれば、会議ではできないことが可能になります。提起された意見が、その瞬間を過ぎても残る場をつくれるのです。「Who / Observation / Agrees / Disagrees / Comments」の5列で構成し、予定されたセッション中だけでなく、誰でもいつでも行を追加できるようにします。同意と不同意は、ひっそり閉じてしまうコメントスレッドではなく、列として設けます。行は、会議が終わったときではなく、チームが実際に決着をつける準備ができるまで開いたままにします。

すべての声を一行の要約にまとめるのではなく、調査結果の一部は生の証言として残しましょう。同じ取り組みについて、ある人は少なすぎると言い、別の人は多すぎると言う。こうした矛盾する説明は、統合した平均では「問題なさそう」という結論に消し去られてしまう、本物のシグナルです。あるトピックで反応が明確に分かれた場合は、声の大きい意見を選ぶのではなく、両方の引用をテーブルに残しましょう。

記録された拒否そのものが成果物であり、行動できなかったことを意味するのではありません。 行に「［理由］のため、対応なし」と直接記載することで、同じ提案が検討されたことがなかったかのように次回のレトロスペクティブで再び持ち出されるのを防げます。これは、ステップ9でアクション項目に求められている「対応しない」判断の記録を、テーブル自体にも適用したものです。チームの意見が実際に分かれた場合も同様に、片方が根負けして勝つことのないよう、行に両方の立場を記録しましょう。そうすれば、後から見直す人も議論を参照できます。

繰り返し意見が分かれる論点の一つは、この回の成果を誰が評価するかです。チームなのか、参加者アンケートなのか。主催者の意見は、まさにこの点で分かれています。どちらか一方で他方を上書きするのではなく、チームの影響度スコアとアンケート結果を並べて、両方の見方を行に残しましょう。

公開方針

順位付けしたメニュー ― 下書き、レビュー、公開による露出の単位あたりに得られるコミュニティの信頼と説明責任です。ここにあるメニューのうち、実際に露出を伴うのはこれだけなので、コンプライアンスコストの軸を設けています。

• 労力（下書き、匿名化、承認）：要約と振り返りと透明性レポート > 要約と振り返り > 要約のみ > 公開なし
• 価値（信頼、修正を実現させる説明責任への圧力、再利用可能な公開資料）：要約と振り返りと透明性レポート > 要約と振り返り > 要約のみ > 公開なし
• 効率：要約と振り返り > 要約のみ > 要約と振り返りと透明性レポート > 公開なし
• コンプライアンスコスト（発生するレビュー、失われる可逆性）：要約と振り返りと透明性レポート > 要約と振り返り > 要約のみ。公開しない場合はコストがかかりません。

優越性チェック：4段階、6組、厳密な優越関係はゼロ ― 構造上きれいなだけで、合格を意味するわけではありません。 価値、労力、コンプライアンスコストはすべて同じ順序です。より大きな信頼を得られる段階ほど、両方のコスト軸で厳密に劣ります。「公開なし」と比べても同様で、価値を失うのであり、何かを無料で得るわけではありません。このチェックからは何もわかりません。以下は論証です。

効率では引き続き振り返りが優位です。手順8の時点で、調査結果はすでに3部構成でそろっているため、追加コストは段落2つ分であり、新たな分析ではありません。コストがかからないにもかかわらず、公開なしの効率は最下位です。正しい選択となる理由がほかにある場合でも、0を0で割った値は比率として優位にならないからです。

コンプライアンスの順序は、労力の順序を言い換えたものではありません。

• 要約 - 露出に伴う確認事項は、写真の掲載同意です。

• 振り返り - 露出に伴う問題は契約上のものです。会場やケータリング業者の名を挙げた調査結果は、誹謗中傷禁止条項に抵触する可能性があり、来年も依頼したいサプライヤーに必ず伝わります。

• 透明性レポート - 露出の性質はさらに異なります。匿名化には行動規範のパイプライン独自の承認が必要であり、公開したインシデントの説明は取り消せません。

• 公開なし - 調査結果はチームのログに残します。

• 要約のみ - 起きたこと、数値、写真、お礼を記載し、調査結果は記載しません。DevOpsDaysもここまでは支持しています。結果のブログ投稿は「任意ですが、強く推奨します」。

• 要約と振り返り（デフォルト）- Write the Docs Prague 2017の形式です。要約に加え、何がうまくいかなかったか、次回に向けて何を変更するかを記した短いセクションを設けます。

• 要約と振り返りと透明性レポート（選ばれにくい段階）- Prague 2017の完全版資料です。行動規範に関する報告と、それぞれへの対応を匿名化して記載します。価値、労力、コンプライアンスコストがすべて最高になるため、効率の観点では選ばれません。昇格条件（Q10に対応）：報告が実際に解決されており、event-code-of-conductのパイプラインが匿名化を承認すること、またはインシデントが十分に目立ち、沈黙が隠蔽と受け取られること。

削除条件（Q11に対応）：非公開イベントの場合、または調査結果に人事上の機微情報が含まれるか、守秘義務の対象となる場合は、格下げするのではなく、公開するすべての段階を削除してください。

アクション項目を確実に追跡する

優先順位付きメニュー — 定常的な負担の単位あたりで、実際に次の版へ引き継がれる教訓です。オーナーを明確にすることが重要です。すべてのアクション項目には担当者名と日付が必要です。そうでなければ、項目は消えてしまいます。

チケット管理システムが存在することを前提としていません。どの段階も、チームが現在使っているものに合わせて実施できます。各段階の順位は判断に基づくものです。

• 労力（設定、日程調整、メンテナンス）：定期的なレビューを伴う継続的なトラッカー > 計画への持ち越し == サイクル途中のチェックイン > 項目への担当者名と日付の記入
• 価値（何らかの変更につながる調査結果の割合）：定期的なレビューを伴う継続的なトラッカー > 計画への持ち越し > サイクル途中のチェックイン > 項目への担当者名と日付の記入
• 効率：項目への担当者名と日付の記入 > 計画への持ち越し > サイクル途中のチェックイン > 定期的なレビューを伴う継続的なトラッカー

労力が同順位なのは、判断を避けた結果ではありません。チェックインも持ち越しも、カレンダーへの予定登録が1件、30分未満の作業で済み、振り返りからその日までの間に、何かを構築したりメンテナンスしたりする必要はありません。予定を入れるだけのものとは違い、継続的なトラッカーは作業そのものです。価値は同じではありません。持ち越しは、チームが実際に作業に使う文書へ項目を反映するため、労力が同じなら、価値に対する比率はこちらが上回ります。

• 項目への担当者名と日付の記入 — すべての項目に担当者名と日付を記入するか、「対応なし。その理由：」と明記します。限界労力はほぼゼロです。担当者不在の項目を防ぐだけで、それ以上のことはしません。
• サイクル途中のチェックイン — 数週間後に日付を設定して1回確認し、期限の短い項目（ベンダーとの話し合い、返金、謝罪、デポジットの確認）が実施されたことを確かめます。
• 計画への持ち越し — 未完了の項目をすべて、次の版の作業逆算計画に実際のタスクとして記載し、event-planning-timeline に引き継ぎます。
• 定期的なレビューを伴う継続的なトラッカー（選ばれにくい段階）— 版と版の間も定期的にレビューする、継続的なトラッカーです。価値と労力の両方で最上位となるため、効率を重視する場合は選ばれません。昇格条件（Q12 に基づく）：別の目的ですでに通年のトラッカーが存在する場合、または調査結果によって event-team-structure への構造的な作業が必要になった場合です（定義上、この作業は版と版の間に行われます）。

デフォルト：すべての項目に担当者名と日付を記入し、さらに計画へ持ち越します。 項目の期限が計画サイクルより短い場合は、サイクル途中のチェックインを追加します。調査結果を計画開始前に解決する必要がある場合（法人格の変更、後継者の不足）は、継続的なトラッカーに移行します。

最終版または一度限りの版では、順位を下げるのではなく、持ち越しと継続的なトラッカーを削除し、担当者名と日付のルールだけを残します。

インタビューの回答を踏まえた再ランク付け

並べ替えるだけで済ませず、メニューごとに、どの回答がどの選択肢を動かしたのかを示します。

インタビューの回答	深さ	公開	追跡
Q6 - 計画が数週間以内に始まる	単発の2段階をどちらも引き上げ、トラックベースの2段階をどちらも引き下げます（期限内に間に合わせるには、複数のリーダー間でカレンダー調整が必要になるためです）	ほとんど動かさず、その点を明示します。振り返りは計画のクリティカルパス上にないため、デブリーフを短縮するより、遅らせることを優先します	計画の引き継ぎを大きく引き上げます。ドキュメントを今すぐ開けば、その週のうちに項目を追加できます
Q7 - 最終版または単発のエディション	後継組織が読む場合を除き、文書によるレビューを引き下げます	振り返りと透明性レポートを引き上げます。終了するエディションの公開記録は、コミュニティが得られる唯一の記録であり、それがJSConf EUと!!Conの声明が今も引用されている理由です	引き継ぎと常設のトラッカーを削除します
Q7 - 複利的に効果が増す、定期開催のエディション	-	-	引き継ぎと常設のトラッカーを引き上げます
Q8 - 労力の上限が低い／チームが疲弊している	トラックベースの2段階をどちらも完全に削除します	匿名化に時間がかかるため、透明性レポートを引き下げ、振り返りは維持します	常設のトラッカーを引き下げ、デフォルト設定はそのままにします。デフォルト設定に必要なのが1つのフィールドと1回の貼り付けだけで済むことが重要です

失敗パターン

• その場で誰かを責める。 「これを忘れたのはあなたですよね」と一言伝えるだけで、振り返りが人事評価の場へと変わり、次の発見が口にされなくなります。ボランティアチームでは、その人は二度と戻ってこなくなることもあります。その喪失はログには残りません。冒頭で枠組みを示し、最初にそれが崩れたときは、声に出して軌道修正してください。
• 開催回がうまくいったからと、振り返りを省く。 重大度に応じて実施を決める仕組みは、インシデントの事後分析に由来する手法のうち、明示的に転用しないものです。何事もなく終わった開催回にも、失われる前に言葉にしておく価値のある取り組みがあります。
• 担当者不在のアクションアイテム。 担当者が「全員」で、期限が「次回」の項目は、何にも追跡されません。担当者と日付を割り当てるか、対応しないと明示して終了してください。
• 丁寧に見せるためにアクションアイテムをでっち上げる。 これは逆方向の失敗で、インシデントの事後分析の実践でも明確に指摘されています。発見事項に対応が不要なら、そう伝えてください。
• すべての項目で5 Whysを行う。 昼食の手違いに5層の因果分析を行うのは過剰設計であり、本当に必要な発見事項に割く時間を奪います。公表された先例では、根本原因の分析は行わず、発見事項ごとに浅い項目を3つ記録しています。
• その日の問題を再診断する。 振り返りの中で合図シートを書き直したり、リスク登録簿を再評価したり、予算を再モデル化したりすると、それを担当する関連チームの作業を奪ううえ、誰も採用しない版が生まれます。再設計ではなく、発見事項を引き継いでください。
• 燃え尽きを個人の落ち度として扱う。 「あの人は引き受けすぎた」は発見事項ではありません。「バックアップなしで一人が3つの役割を担っていた」は発見事項です。前者は話し合いを終わらせ、後者は構造的な改善へつながります。
• 誰も覚えていない頃まで振り返りを先送りする。 6週間も経つと、最も声の大きい3人の記憶から時系列が再構成され、目立たない失敗は消えてしまいます。すでにそれだけ遅れているなら、そう伝え、再構成が完全だと装うのではなく、ログに記載する内容の確度を下げてください。
• 開催回をまたいで傾向を分析する。 今回の数値を過去2回と比較するのは、samber/dev-event-organizer-skills@event-continuous-improvementの役割です。日付入りのログを1つ作成し、集計は本来の担当先に任せてください。

測定

公開されているガイダンスでは、振り返りをいつ誰が行い、どの成果物を作るかは定められていますが、教訓のうちいくつが実行に移されるかは明確にされていません。出典の詳細はreferences/field-precedent.mdを参照してください。このスキルでは、チームが完全に制御できる唯一の項目について、合格基準をちょうど1つ設定します。

• 担当者不在の項目がゼロ（二値）。ログのすべての項目に、担当者と日付入りの期限を設定するか、「対応なし。理由：」と明示してください。ログを1行ずつ読み返し、各項目に担当者を割り当てるか、対応なしとして終了するまで繰り返します。これを満たさないログは、教訓の記録ではなく、単なる議事メモです。

それ以外は達成目標ではなく、記録するための指標です。

• 会場閉鎖から振り返りまでの日数。 開催回を重ねるごとの傾向をチームで確認できるよう、日数を記録してください。
• 役割名付きの担当者の参加率：役割名のある役割を担った人のうち、会場に参加したか、書面で意見を提出した人の数を、該当者の総数に対する割合で示します。参加率が低いと、ほかのどの数値よりも、ログの内容が薄い理由を説明できます。
• アクションアイテムの完了率（第2回以降のみ測定可能）：前回のアクションアイテムのうち、実際に完了した数です。入力値として記録してください。傾向の分析はsamber/dev-event-organizer-skills@event-continuous-improvementの担当です。
• 振り返りで記録した成果（任意設定）：プロジェクト、コラボレーション、企業、仕事です。最初は件数だけを記録し、その後は成果ログで追記します。

呼び出し例

• 「カンファレンスは日曜日に終了しました。振り返りはどのように進めればよいですか？ また、誰に参加してもらうべきですか？」
• 「参加者アンケートの結果が届きました。これと自分たちのメモを、次回に実際に活かせる形にするにはどうすればよいですか？」
• 「問題点を公開すべきですか？ それとも内部にとどめるべきですか？」
• 「昨年の振り返りでは15個の教訓を挙げましたが、どれも実行しませんでした。プロセスの何が問題だったのでしょうか？」
• 「振り返りで、運営メンバーの一人が完全に燃え尽きたと言っていました。どう対処すればよいですか？」
• 「今年は特に問題が起きませんでした。それでも、夕方の時間を使って振り返る価値はありますか？」

期待される出力：

• 日付入りの教訓記録。各項目は3部構成で、担当者と期限、または明示的な対応なしの判断を含みます
• リスク登録簿、予算、進行表、需要の判定をそれぞれ担当する関連スキルに引き継ぐ、4つの照合作業
• 担当先を明記したチームの健康状態に関する所見の一覧
• 理由を添えた公開判断
• samber/dev-event-organizer-skills@event-continuous-improvement への引き継ぎの明記

参考資料

• references/lessons-learned-entries.md - 情報源に基づく記入例と否定的な対照例の両方を含む3部構成の記入形式、「なぜ見過ごされたのか」の分類、および個別の項目を5 Whysにエスカレーションするための限定的な基準。
• references/reconciliation-and-session-agenda.md - 責任を問わない導入スクリプトを含むセッションのアジェンダ、タイムラインの再構成方法、引き継ぎ形式を含む4つの照合チェックリスト、公開済みのチームの健康状態に関する事例2件、event-continuous-improvementへの引き継ぎパケット。
• references/field-precedent.md - イベント後のレビューについて公開されている主催者向けガイドの内容と、このスキルのセッション運営方法が代わりにSREのインシデント事後分析の系譜に基づいている理由。