event-continuous-improvement

イベントの継続的改善

定期開催される技術イベントの各回をまたぐすべての事項を担当します。

• 日付の異なる2件以上の振り返りログから傾向を検出します。
• ノイズとなる所見と、シグナルとなる所見を切り分けます。
• 集約した学習ログを保存します。
• ログを監査し、信頼性を保ちます。
• 変更の担当者にフィードバックし、対応を完了させます。

1回分のイベントは担当しません。 samber/dev-event-organizer-skills@event-debrief は、終了した1回分の振り返りを行い、日付入りのログを引き渡します。1回分と過去2回分を比較すると、姉妹スキルの存在意義を丸ごと重複させることになるため、このスキルの上流側では複数回にまたがる傾向分析を行いません。その分析をやり直したり、1回分の所見を再検討したり、そこで作成される成果物を作成したりしてはいけません。

担当範囲の一部はすでに別のスキルが受け持っています。以下の各姉妹スキルを確認して、適切なスキルに引き継ぎ、代わりに判断しないでください。

姉妹スキル	担当範囲	あなたが行うこと
event-market-fit	需要シグナルの傾向：完売までの速さ、販売ペース、再来率、スポンサーの更新	あなたが扱う傾向は運営面のものです（受付がまたあふれている、同じ業者が2回続けて失敗したなど）。引き継ぎ時に、この違いをはっきり伝えてください
event-growth-strategy	拡大するかどうか、および拡大方法	「参加者300人を超えた場合のボトルネック」は引き渡す証拠であり、提案ではありません
event-team-structure	後継者育成、バス係数、燃え尽き	同じ構造上の所見が複数回にわたって繰り返されていることに気づいてください。保存されたログ自体が、バス係数への対策となります
event-planning-timeline	作業を行う時期	何を、なぜ変更するのかを判断します
event-vendor-sourcing	特定の業者自身の実績記録	再発した場合は、再依頼するかどうかの判断を引き継いでください。それはその業者の記録に使う証拠であり、全般的なテーマではありません

参加者からのフィードバックが直接あなたに届くことはありません。event-feedback が収集し、event-debrief が照合します。あなたが確認できるのは、そのログを経由した情報のみです。

主催者向けガイドが扱う範囲と、その限界

以下の主張の範囲を明確にするため、この内容をユーザーにはっきり伝えてください。

• 主催者向けガイドのうち、初回の引き継ぎを扱うものは1つだけで、その隔たりは見かけほど大きくありません。 MLH の Organizer-Resources/keeping-records.md には、開催頻度、対象者、2つの成果物、具体例が記載されていますが、いずれも第1回から第2回への引き継ぎに限られます。DevOpsDays の organizing.md にあるのは、このテーマに関する行動規範の記述が1行だけです。どちらも、第1回から第3回または第4回までの変化を追っていません。引用全文と具体例については、references/log-format-and-audit.md を参照してください。
• 実際の構造的な証拠は、git の履歴が1つあるだけです。 DevOpsDays の organizing.md は、主催者が何度も全員交代するなかで、定期的に書き直すのではなく、小規模で対象を絞った編集を重ねて維持されてきた、共有のガイダンス文書です。これは、継続して記録され、複数人が編集する文書が主催者の交代を経ても残ることを示していますが、傾向記録の形式のテンプレートでは_ありません_。開催回ごとの日付入り記録も、傾向の注釈もありません。
• ソフトウェア改善の実践から引き継がれる要素は2つだけで、登場する箇所では借用したものとして明記されています。 改善サイクル自体は引き継がれません。SaaS の改善サイクルは実行ごと、または四半期ごとの頻度を前提とする一方、イベントは、メンバーが一部入れ替わったチームで年に1度しか改善に取り組めないためです。引き継がれるのは、printing-press-retro の記録採用基準（references/filing-gate-and-trend-evidence.md）と、ce-compound-refresh の「維持／更新／統合／置換／削除」という分類（references/log-format-and-audit.md）です。
• 会議運営に関する報告書が1つ、この実践そのものには言及していますが、具体的な方法には触れていません。 Fraser と Mancl による2023年の会議の未来に関する報告書では、振り返りを「会議の継続的な改善を促すため、会議関係者にとって不可欠な運営実践」とし、イベント後に主催者が集まって実施し、開催後アンケートと組み合わせて「（年ごとの）傾向を特定」するものとしています。これは「会議シリーズ」を明確に想定しています。この報告書は、開催後という以上の実施頻度も、開催回ごとの記録形式も、発生件数の基準も示していません。

この実践の名称には出典があります。一方、記録形式、発生件数の基準、以下の選択肢、そして references/ 内のすべてのテンプレートは、このスキル独自の構成です。これらを、確立された主催者の実践として紹介しないでください。

インタビュー

一度に質問するのは1つだけにします。可能な場合は選択式にします。質問5〜7があるのは、以下のメニューが効果が出るまでの期間、持続性、労力の面で大きく異なるためです。これらを尋ねずに、どの選択肢がよいかをこちらで決めることはできません。

1. このイベントはこれまで何回開催され、そのうち何回分の記録を文書で保持していますか？傾向について主張できる範囲を決めるのは、後者の数だけです。
2. 現在、記録はどのような形で残っていますか？何も書かれていない、チャットのスレッド、開催回ごとのドキュメント、または項目が構造化された記録のいずれですか？
3. 保持している最も古い記録以降、運営チームはどの程度入れ替わりましたか？誰も入れ替わっていない、一部、ほとんど、または全面的に別のチームになった、のいずれですか？また、今回の開催に向けて別の人たちへの引き継ぎを予定していますか？
4. 記録は samber/dev-event-organizer-skills@event-debrief の3項目形式で担当者と日付が記されていますか、それとももっと自由な形式ですか？開催回をまたいで比較可能な数値がありますか、それとも文章による所見だけですか？また、記録された所見を理由に、過去の開催で意図的に何かを変更したことはありますか？
5. 次回開催の計画はいつ始まりますか？または、開催の可否はいつ決定されますか？その日付がこのスキルの期限です。計画が書き上がった後に得られる傾向は、何も変えません。
6. 今回は単発または最後の開催ですか、それとも今後何年も続けていく予定ですか？後者の場合、あと何回ほど開催する予定ですか？
7. 開催間の作業にかけられる労力の上限はどのくらいですか？使える時間と、現在、開催間の作業を担当している人がいるかどうかを教えてください。
8. 記録はどこに保存され、計画が始まる前に誰が確認することになっていますか？担当者の名前を挙げてください。「チーム」という答えでは、誰も読み返さない記録ができてしまいます。

継続チームか、交代制か

記録の採用基準、繰り返しの数え方、テーマのグループ化、監査の分類、ルーティングのルールは、イベントが企業の購買担当者向けでも週末の趣味の参加者向けでも、一字一句同じです。

出力を本当に左右するのは、次回もチームのうちどれくらいが同じメンバーかです。これによって、記録に何を残す必要があるかが決まります。

• 継続チーム - 同じメンバーが連続して開催を運営します。記憶が記録をある程度補うため、そこが落とし穴になります。まだ記録を必要としていないからこそ、記録は薄いままです。その不足が表面化するのは、誰かが離れる年だけです。その場にいない後任のために書いてください。
• 一部交代 - よくあるケースです。所見の一部は記録に残り、一部は誰かの頭の中にあり、どれがどれなのかは誰にもわかりません。ここでは、テーマをグループ化する手間をかける価値があります。戻ってきた運営担当者と新しい運営担当者が、同じ繰り返し起きる問題を別の言葉で説明するためです。
• 全面交代 - フランチャイズ、都市を巡回する開催モデル、またはイベントを引き継ぐ新しいチームが該当します。記録は単なる利便性ではなく、情報伝達の全手段です。DjangoCon Europeが、前回までの運営担当者によるサポートワーキンググループと常設のイベントサポート機能を設けたのは、まさにこのケースに対応するためです。書面の記録だけでは情報を伝えきれなかったからです。

ワークフロー

1. インタビューを実施します。Q1の回答が記録の1エディションのみを指す場合は、トレンドの分析を中止し、その旨を伝えます。このエディションを記録してログを開始し、来年また戻ってきてください。このスキルの半分は利用できず、そうでないふりをすればパターンを捏造することになります。
2. ログを受け取り、再実施しないでください。 samber/dev-event-organizer-skills@event-debrief のエディションごとの日付入りログを、そのまま受け取ります。記録が不十分または不明瞭な場合は、その不足を記録し、元のエディションを再構築してはいけません。
3. すべての記録をシグナルゲートに通してファイリングします。 printing-press-retro のファイリングゲートを参考にします。イベント固有の条件下で再現可能で、1回限りの発生を超えて一般化できる場合にのみ、記録を候補とします。1回限りの失敗が対処済みで、何のコストも生じなかったのであれば、それは想定内の作業であり、発見事項ではありません。ファイリングする際は個人が特定されないようにします。samber/dev-event-organizer-skills@event-debrief の非難しない枠組みを、人々がいなくなった後も残る文書に引き継ぐ必要があります。ゲートの基準、肯定例と否定例を用いたファイリング例、個人を特定しないためのルールについては、references/filing-gate-and-trend-evidence.md を参照してください。
4. 数える前にグループ化します。 表現の異なる記録をテーマごとにまとめ、記録の数ではなくテーマの再発回数を数えます。2回の発生で候補、3回でパターンとなります。トレンドを述べるたびに、どちらに該当するかを明示してください。
5. 一度に意図的な変更を1つずつ決めます。 変更をまとめることは避けてください。4つの変更を同時に行う計画では、どの変更が結果につながったかを特定できません。各変更を、次の3点で記述してください。
   • 変更する内容。
   • その変更が証拠によって正当化される理由。
   • 次のエディションで、変更が機能したかどうかを判断する方法。
6. 各変更を担当先に引き継ぎます。
   • 運用上の変更：samber/dev-event-organizer-skills@event-planning-timeline。次のエディションの計画に実際のタスクとして追加します。
   • 需要に関するもの：samber/dev-event-organizer-skills@event-market-fit。
   • 規模に関するもの：samber/dev-event-organizer-skills@event-growth-strategy。
   • 構造的で繰り返し起きるもの：samber/dev-event-organizer-skills@event-team-structure。1回のデブリーフでは得られない証拠として、再発回数も添えます。
   • 特定のサプライヤー自身のパフォーマンスに関するもの。たとえば再発注するかどうか、ブリーフを書き直すか、数量を変更するかなど：samber/dev-event-organizer-skills@event-vendor-sourcing。次のエディションの担当者が探そうと思わない一般ログに残すのではなく、そのサプライヤー自身の記録に記載します。
7. 最初のメニューで選んだ段階にログを保存し、チームにはバス係数のリスクを軽減するためのものだと伝えます。
8. 3つ目のメニューで選んだ頻度で、蓄積したログを監査します。 ce-compound-refresh を参考に、すべての記録を「維持」「更新」「統合」「置換」「削除」に分類します。ただし、1つだけ正直な修正があります。ce-compound-refresh の根拠となるのはいつでも確認できるコードベースですが、こちらの根拠は次のエディションの結果であり、事後になって初めて得られます。したがって、監査は継続的ではなく、必ず遡及的に行います。形式、分類ルール、引き継ぎパケットについては、references/log-format-and-audit.md を参照してください。
9. 改善のループを閉じます。 計画サイクルが終わる前に、前サイクルで意図的に行った変更のうち、どれを実施し、何が起きたかを明示します。自身の出力を一度も確認しない改善ループは、単なるファイリングシステムです。

ハーネスに永続メモリがある場合は、ログ自体を記録してください。つまり、ファイリングしたすべての記録についてテーマ、初めて確認されたエディション、発生回数を記録し、意図的な変更については正当化の理由と確認方法を、担当先への引き継ぎについてはそのすべてを記録します。これは、1年離れた実行の間も記録が残り、記録した現場にいなかった人にも読めることが価値のすべてを左右する、コレクション内で唯一のスキルです。 以下の各ランキングはデフォルトであり、絶対的なルールではありません。制約によってある段階を削除する場合は、そのメニューの軸の行からも削除してください。順序に残っている段階は読者の頭に残り、スコープとして再び持ち込まれるからです。このチームについてすでに分かっていることを踏まえて、3つすべてのメニューを再ランキングしてください。

• バージョン管理された共有ドキュメントがあれば、永続性の段階はすでに低コストで実現できます。
• 毎回同じ1人が運営するなら、テーマのグループ化に関する問題はまだありませんが、担当者交代の問題はより深刻です。
• 意図的な変更を一度も実施していないチームには、監査したり完了扱いにしたりするものはありません。

ログの永続化方針

ランキングメニュー — エディションをまたいで有効性を保ち、担当者交代後も引き継がれる傾向を、継続的な保守コストの単位あたりで比較します。段階と順序はこのスキル独自の構成であり、公開された標準ではありません。オーガナイザー向けガイドは、日付付きの学習ログとして模倣するものではなく、時代を超えて通用するハウツーガイダンスを提供しています。

• 労力（セットアップ、エディションごとの保守、既存のものの後付け変更）：構造化エントリーレコード > 数値系列 > 追記型ドキュメント > 引き継ぎのみ
• 価値（検出可能なパターンの有無と、その場にいなかった人にも読み取れるか）：構造化エントリーレコード > 追記型ドキュメント > 数値系列 > 引き継ぎのみ
• 効率：追記型ドキュメント > 構造化エントリーレコード > 数値系列 > 引き継ぎのみ

中間の順位が価値と労力で異なるのは、両者を分ける意味がそこにあるからです。数値系列は、すべてのエディションで同じ方法で数値を測定する必要があり、測定しなければ誰かが後から再構成することになるため、追記型ドキュメントよりコストがかかります。また、得られるものも少なくなります。運営上の傾向は「受付デスクがまた混雑した」のような文章であり、数値が主に答えるのは samber/dev-event-organizer-skills@event-market-fit が扱う需要に関する問いだからです。引き継ぎのみは、ほとんどコストがかからないにもかかわらず、効率では最後になります。エディションをまたいで引き継がれるものが何もなく、ゼロをゼロで割っても比率では勝てないからです。

• 引き継ぎのみ - 計画を開始する際に、直近のエディションの振り返りログを読み直します。何も集約せず、再発の認識はたまたま覚えている人に委ねられます。
• 追記型ドキュメント - 日付付きの文書を1つ継続して使い、各エディションの記録済みの調査結果を日付付きの見出しの下に追記します。この段階を裏付ける実際の構造的証拠として、DevOpsDaysの運営ガイドは11年間、20人を超える貢献者によってまさにこの形式のドキュメントとして維持されてきました。借りるのはその継続性だけであり、時代を超えて通用するガイダンスの形式は決して借りないでください。
• 数値系列 - 振り返りで測定した目標を基に、エディションごとに同じ少数の数値を記録する小さな表です。
• 構造化エントリーレコード - 記録済みの調査結果ごとに、テーマ、初回確認エディション、発生回数、ステータス、対応方針、担当者の各フィールドを持たせます。再発を記憶に頼らず、数えられるようになります。チームがすでに使っているものが何であれ、それをレコードとして説明してください。ツールを指定してはいけません。

デフォルトの段階：追記型ドキュメント。記録の2回目のエディション以降に適用します。選ばれにくい選択肢：構造化エントリーレコード - 価値では1位、労力では1位ですが、効率では選ばれません。昇格の条件、および記録が乏しい、または一貫性がない場合にどの段階を完全に削除するかについては、references/reranking-by-interview-answers.mdを参照してください。

トレンド検出の深さ

ランキング形式のメニューです。分析時間あたりに得られる、根拠のあるパターンを基準にしています。段階とその順序は、このスキル独自の構成です。2回と3回の出現を分けるルールは、イベント業界固有の基準ではなく、「2回なら偶然、3回ならパターン」という、偶然とパターンを区別するための、より古くからある分野横断的な慣例に基づいています。この数値自体を定めている主催者向けガイドはなく、このルールが参照する判定基準はソフトウェア開発の慣行から借りています。

• 労力（読み込み、分類、根拠の整理）：文書化したトレンドレビュー > 数値の比較分析 > テーマのグループ化 == 再発回数のカウント
• 価値（計画に照らしても維持される、意図的な変更）：文書化したトレンドレビュー > テーマのグループ化 > 再発回数のカウント > 数値の比較分析
• 効率：テーマのグループ化 > 再発回数のカウント > 文書化したトレンドレビュー > 数値の比較分析

労力の同率は、判断を避けた結果ではなく、根拠があります。カウントは分類と同時に行われます。テーマの構成要素を数えなければ、テーマをグループ化できないためです。カウントにグループ化を加える限界費用は、追加の時間ではなく、判断が1つ増えることです。そのため、価値を基準にすれば同率は明確に解消されます。

• 再発回数のカウント - 記録された各項目が、記載どおり何回の開催回に登場するかを数えます。
• テーマのグループ化 - 同じ根本原因を表す項目をまとめ（バッジの印刷、受付の列、ランヤードの仕分けは、1つの受付テーマです）、そのテーマを数えます。同じ問題が開催回ごと、主催者ごとに異なる言葉で記述されるため、単純なカウントよりも価値があります。項目を数えるだけでは、探している再発問題をまさに見落としやすくなります。
• 数値の比較分析 - テーマの再発回数を、同じ開催回の数値と並べて、測定可能な何かと連動しているかを確認します。ここでは価値の面で最下位です。数値によって、受付がまた機能しなかったかどうかが決まることはほとんどありません。数値が動く場合も、その分析は通常、samber/dev-event-organizer-skills@event-market-fitに属します。
• 文書化したトレンドレビュー - 計画サイクルごとに作成する短い文書です。各候補トレンド、その開催回ごとの根拠、対応方針をまとめ、計画キックオフの前に共有します。

デフォルトの段階：テーマのグループ化。生の項目ではなく、テーマ単位で再発回数を数えます。選ばれにくい選択肢：文書化したトレンドレビュー - 価値では1位、労力でも1位のため、効率では選ばれません。どのような条件で段階を引き上げるか、また、どの段階を完全に削除するかについては、references/reranking-by-interview-answers.mdを参照してください。

ログ監査の頻度

順位付きメニューです。5回目の開催でもチームが信頼を寄せるログを、継続的に必要な負担に応じたコストで維持します。この分類は ce-compound-refresh から借用しています。頻度、段階、順位付けは、このスキル独自のものです。

• 労力（カレンダー、責任者、各回の作業時間）：年間を通じた監査責任者 > キックオフ時と終了時の監査 > キックオフ時の監査 > 読む際の監査
• 価値（今も正しい項目と、再読できる長さのログ）：キックオフ時と終了時の監査 > 年間を通じた監査責任者 > キックオフ時の監査 > 読む際の監査
• 効率：キックオフ時の監査 > キックオフ時と終了時の監査 > 読む際の監査 > 年間を通じた監査責任者

価値と労力で最上位が異なるのには、この領域特有の理由があります。ここでの唯一の真実は次回開催の結果なので、_その結果に合わせたタイミングで_行う監査なら、カレンダー間隔で行う監査では確認できないことを、ログを通年で管理するより低コストで検証できます。そのため、価値では終了時の監査が年間を通じた責任者を上回り、労力では下回ります。また、効率では今もキックオフ時の監査が最上位になります。

• 読む際の監査 - トレンドを確認する際にたまたま触れた項目だけを分類します。それ以外は検討されないまま蓄積します。
• キックオフ時の監査 - 計画が始まる前にログ全体を一度確認し、すべての項目を「保持」「更新」「統合」「置換」「削除」に分類します。
• キックオフ時と終了時の監査 - 同じ監査に加えて、開催終了後にもう一度確認し、意図的な変更の根拠となった項目を実際の結果と照らして分類します。最も低コストな方法は、別の報告書を作る代わりに同じ変更記録を再度開き、列を2つ追加することです。列の内容は、実際に改善したか（はい／いいえ）とその理由です。こうすれば、誰も読まない2つ目の文書ではなく、記録そのものが検証手段になります。
• 年間を通じた監査責任者 - 特定の担当者を定め、計画カレンダーとは無関係に、固定の間隔でログを通年管理します。

デフォルトの段階：キックオフ時の監査。 選びにくい選択肢：年間を通じた監査責任者 - 労力では最上位、価値では2番目、効率では最下位のため、比率では選ばれません。昇格条件と、完全に削除すべき段階については、references/reranking-by-interview-answers.mdを参照してください。

KPIの候補リストと結果ログ

これは現場の証言であり、確立された慣行ではありません。

多くのKPIを追跡しても、何も変わりません。代わりに候補を絞り込みます。

1. KPIは2～3個選びます。それ以上は選びません。それぞれに担当者と、その数値を動かすためのアクションが必要です。どちらかが欠けているKPIは、保留せずに削除します。
2. コミュニティがピアネットワークに属している場合は、ローカルKPIとネットワークKPIを分けます（samber/dev-event-organizer-skills@event-team-structure）。各支部は自分たちで動かせるものを担当し、ネットワークだけが動かせるものはネットワークが担当します。
3. 報告された候補から選びます：SNSのフォロワー数、動画の再生回数または登録者数、各イベント後に自動送信するアンケートの満足度、財務状況、イベント数と登壇者数、新規参加者とリピーターの比率、女性の割合、イベントから生まれたプロジェクトや企業、主催者が各イベントに割り当てる自己評価による「インパクト強度」スコア。
4. 数値を見る前に各しきい値を設定します（自己設定）。ここで開催ごとのKPIを読みます。需要に左右されるKPI（新規参加者とリピーターの比率、満席かどうか）は、引き続き samber/dev-event-organizer-skills@event-market-fit に振り分けます。
5. 結果ログを維持します - イベントから生まれたプロジェクト、コラボレーション、設立された企業、イベントをきっかけに見つかった仕事などを各イベント後に追記し、キックオフ監査時に再確認します。結果が表面化するまで数カ月かかることがあり、長期的なインパクトの傾向が明らかになるためです。

インパクトを誰が評価するのか、チームか参加者アンケートかについて、主催者の意見は分かれました。両方を記録してください。2回の開催にわたって両者の差が続く場合、それは samber/dev-event-organizer-skills@event-positioning で扱うべき発見であり、どちらかに決めて終わらせるものではありません。

注意事項付きの候補表、候補を絞り込むためのカード、インパクト強度の採点ルール、結果ログのテンプレートについては、references/kpi-shortlist-and-outcome-log.mdを参照してください。

インタビューの回答に基づく再順位付け

上記3つのメニューすべてをQ1、Q3、Q5〜Q8に基づいて再順位付けし、黙って順番を入れ替えるのではなく、どの回答がどの項目を動かしたのかを口頭で説明してください。メニューごと、回答ごとの詳細はこちらです：references/reranking-by-interview-answers.md。

失敗パターン

• 2つのデータポイントだけで傾向を判断する。 2回発生したものは候補です。それを傾向だと主張するのは、計画が付いた偶然にすぎません。「候補」として扱い、間違えたときのコストがごく小さい場合を除き、もう1回の開催まで保留してください。
• デブリーフの作業をやり直す。 1回の開催を再分析し、そのリスクを再評価し、記録を再作成する――こうした作業はすべて samber/dev-event-organizer-skills@event-debriefの担当であり、誰にも採用されない同じ文書の第2版を生み出します。ログは所与のものとして扱ってください。
• 需要の傾向を運営上の問題として扱う。 「戻ってくる人が減った」は、samber/dev-event-organizer-skills@event-market-fitに関わる需要シグナルです。「3年連続でチェックインに90分かかった」は、あなたの担当です。これを取り違えると、需要の問題に運営上の対策を施すことになります――来場者が離れたイベントを、完璧に運営してしまうのです。
• 計画前に誰も読み返さないログ。 成功しているように見えるため、最も起こりやすい失敗です。記録が存在し、形式も整っているのに、計画会議は結局、その場で最も声の大きい人の記憶だけを頼りに進みます。誰がそれを開き、いつ開くのかを明確にしてください。
• 増える一方のログ。 これは、別の経路で前述の失敗に至るものです。監査を行わなければ、3回前の開催で更新された記録が今も有効であるかのように見え、ログは誰も読み返せない長さになります。未検証の記録が残らないよう監査してください。
• 1回の開催で4つの変更をまとめて行う。 そうすると何も原因を特定できず、次のサイクルの締めくくりの確認でも判断を下せません。ループを測定可能にするには、意図的な変更を一度に1つだけ行うことが必要です。
• 保存するログに個人名を記載する。 その場では言いにくかったパフォーマンスへの批判が、本人と面識のない人も読む文書に残ると、正当化できないものになります。構造上の問題として記録し、samber/dev-event-organizer-skills@event-team-structureに共有し、記録には個人名を残さないでください。
• 15個のKPIを並べたダッシュボード。 すべての数値が報告されても、誰も責任を持たず、何も動きません。各項目の担当者とアクションを決めたうえで2〜3個に絞らなければ、ダッシュボードは誰も読み返さない記録の保管庫になります。
• 片側だけから影響を判断する。 チームの評価だけでは取り組みの成果を過大評価し、参加者アンケートでは数か月後に現れる成果を見落とします。両方を残し、その横に成果ログも置いてください。
• ソフトウェアの運用サイクルをそのまま持ち込む。 四半期ごとのレビュー、スプリントごとの振り返り、実行ごとのゲートは、いずれも1回の開催よりはるかに短いサイクルを前提としています。記録の規律は取り入れ、カレンダーは持ち込まないでください。
• 設計どおりには誰も使わなくなった成果物を、見栄えのために残す。 チームが密かに完全な遵守をやめた採点シート、チェックリスト、プロセスの手順は、チームではなく成果物そのものについての発見事項です。同じ監査で確認し、次の2つの方法のどちらかで改善してください。3つ目の方法はありません。設計どおりに使った結果が十分に見えるようにして、飛ばせなくするか、実際に行われていることに合わせて設計を簡素化してください。書き直すと失敗を認めることになると感じて、使われていない版を残すことこそが失敗です。

測定

まず、ガイダンスがどこまでを対象としているかを確認します。それによって、このスキルが設定する資格のある数値が決まるためです。MLH のオーガナイザーガイドが扱うのは、最初の引き継ぎまでです。ガイドの周期、その成果物、実例はいずれも、初版から第2版への引き継ぎに限られます。その引き継ぎを超えるすべての項目は、独自に設定する基準です。ソフトウェアの継続的改善ツールから目標値を持ち込むと、借りてきた数値をオーガナイザーの実践として示すことになります。

そこで、固定する価値のある数値は一つだけです。このスキルでは、チームが完全に管理できる唯一の項目に対して、合格基準を正確に一つだけ設定します。

• 監査後に分類されていないエントリーがゼロであること（独自設定、二値）。保存されたログのすべてのエントリーに「維持」「更新」「統合」「置換」「削除」のいずれかが付いており、現行のエントリーにはテーマと発生回数が付いています。これを満たすまで繰り返します。これを満たさないログはアーカイブであり、誰も読み返さないのがアーカイブです。

その他は、達成目標ではなく記録するシグナルです。

• 記録が何版分あるか（独自設定）。傾向に関する主張はすべて、この数によって範囲が限定されます。主張の横に記録してください。
• 計画会議での意見ではなく、記録されたパターンに基づく意図的な変更の割合（独自設定）。割合が低い場合、ログは飾りにすぎません。
• 前サイクルの変更の完了率（独自設定）：リリースされた変更の数と、その結果を確認した変更の数です。samber/dev-event-organizer-skills@event-debrief では版ごとの実施状況を記録します。版をまたいだ傾向の把握は、あなた自身が行います。
• 計画前に誰かがログを開いたか、また誰が開いたか（独自設定、サイクルごとの二値）。率直な指標であり、これらがうまく機能したかを示す最良の予測因子です。
• KPI の候補数と担当者（独自設定）：KPI は2～3個とし、それぞれに名前付きの担当者とアクションを割り当てます。3個を超える場合や、担当者がいない KPI がある場合は、調査すべき点です。
• 版ごとの成果ログのエントリー数（独自設定）：プロジェクト、コラボレーション、企業が対象です。比較するのは、自分たちの過去の版とのみです。

呼び出し例

• 「今回で第4版ですが、毎年必ず登録で問題が起きます。問題を毎回あらためて見つけるのではなく、実際に解決するにはどうすればよいですか？」
• 「共有ドキュメントに3年分の振り返りメモがありますが、誰も開きません。計画を始める前に、これをどうすればよいですか？」
• 「今年は運営チームの半分が新メンバーです。すべてを苦労して学び直さずに済むようにするには、どうすればよいですか？」
• 「前回の版でフィードバックを受けてスケジュールを変更しました。効果があったかどうかは、どうすれば分かりますか？」
• 「学習ログが40件もありますが、半分はもう正しくないと思います。」
• 「2年連続で参加者が減りました。このスキルで対応できますか？」
• 「ミートアップで20個の数値を追跡していますが、どれも何も変えません。どれを残すべきですか？」

期待される出力：

• テーマごとに分類された記録済みエントリーの一覧。各エントリーには発生回数と、「候補」または「パターン」のラベルを付けます。
• 意図的な変更の短い一覧。各変更の根拠と、効果を確認する方法を含めます。
• 需要、規模、構造、ベンダー、スケジュールへの影響を担当する兄弟スキルへの引き継ぎ。
• 理由を添えて選んだ保存段階と監査の頻度。
• KPI カード2～3枚の候補リスト（該当する場合はローカルとネットワークを分ける）と成果ログ。
• すべての主張に、「公開されているオーガナイザーの実践」または「このスキル独自の判断」のいずれかを明記します。

こちらも参照、同じコレクション

全体を通して参照している兄弟スキルについては、このファイルの冒頭にある兄弟スキル一覧を参照してください。その一覧に含まれないものがもう一つあります。samber/dev-event-organizer-skills@event-budget は、1回分の開催に関する資金を計画・追跡します。版を重ねるごとに増えていく費用項目の傾向は、このスキルで読み取るものであり、前者のスキルで再モデル化するものではありません。