foundation-meeting-agenda

会議アジェンダ

会議アジェンダは、会議の前に参加者の期待値をそろえるための、参加者向けの構成文書です。「何を話し合うのか、各トピックの担当者は誰か、時間をどう使うのか、何をもって完了とするのか」に答えます。ユーザーが個人的に行う戦略的な準備である会議ブリーフとは異なり、アジェンダは参加者と共有し、会議の構成と進行に焦点を当てます。

このスキルは、Meeting Skills Family に属します。Meeting Skills Family Contract に準拠しており、この契約では、共通のフロントマター、ファイル命名規則、go モードの動作パターン、およびすべての会議スキルに共通する出力要件を定めています。

使用する場面

• 部門横断の作業セッション、プロジェクトのキックオフ、ステークホルダーレビュー、意思決定会議を進行または主催する場合
• 参加者が3人を超える、または30分を超える会議
• 毎回新たな枠組みが必要な定例会議（1対1の面談、チームの定例会など）
• 望ましい成果を明示することで、取り組みが脱線するのを防げる、イニシアチブの中間段階での調整

使用しない場面

• ユーザーの準備が個人的かつ実務的なもの（立ち位置の検討、ステークホルダーの見立て、依頼事項など）の場合は、代わりに foundation-meeting-brief を使用します。
• 会議がすでに終了している場合は、会議後の要約に foundation-meeting-recap を使用します。
• ユーザーが会議に参加しなかった人に結果を共有したい場合は、会議後に foundation-stakeholder-update を使用します。

手間をかけずに実行

ファミリー契約に従い、このスキルは質問攻めにして処理を止めることはありません。既定の流れは次のとおりです。

1. 提供されたすべての入力（トピック、参照ファイル、参加者リスト、制約）を読み取ります
2. 不足している値を推定します（トピックのキーワードから会議の種類を判断、所要時間の既定値、トピックの表現から目的を判断、コンテキストから参加者の役割を判断）
3. 推定内容を簡潔に提示し、go の一言、または修正を受け付けます
4. アジェンダを作成します

--go を指定して呼び出された場合は、推定内容の提示を省略し、既定値（所要時間30分、会議の種類 other など）を使って直接出力します。ユーザーがすべての値をあらかじめ提示している場合、確認のステップはありません。

推定の確度が重要な入力について著しく低く、妥当な既定値もない場合に限り、処理を止めて質問します。これはまれなケースです。

会議の必要性チェック

このスキルは、「これは会議にする必要があるでしょうか。それとも非同期で対応できるでしょうか？」という明示的な質問から始まります。

v1.1.0：このチェックでは、同期で行う価値があることを明示する必要があります。 次のうち少なくとも1つが挙げられた場合に限り、会議の必要性チェックを通過します。

• 検討すべきトレードオフ。複数の選択肢があり、どれを選ぶか定まっていない
• 解決すべき対立。意見が食い違うステークホルダーが明確になっている
• 共同作成。会議中に、参加者が一緒にホワイトボードで検討したり文書を作成したりする
• 関係構築。初めてのステークホルダー会議、相互の認識合わせ
• ブロッカーの解消。時間的制約のある問題解決

どれにも当てはまらない場合、このスキルは非同期での代替手段（文書での共有、ドキュメントレビュー、Slack の投票）を提案し、アジェンダの代わりに「非同期で対応する方法」をまとめた1ページの短い資料を作成します。

v1.0.0 のこのチェック（「トレードオフのない単独担当者による意思決定」「純粋な情報共有」「5人を超える参加者の、状況報告のみの定例会」）は、簡単に回避されていました。ユーザーが参加者を5人にとどめたり、トピックに「意思決定」と付け加えたりしていたためです。より厳格な v1.1.0 では、非同期での対応が優先されるようになっています。ユーザーは引き続きこの判断を覆すことができます。

このチェックは foundation-meeting-brief と共有されており、会議後のスキル（recap、synthesize、stakeholder-update）では実行されません。

手順

会議のアジェンダを作成するよう求められた場合は、次の手順に従います。

1. 会議が不要かどうかを確認する 上記のトリガーパターンを適用します。ユーザーの目的が該当する場合は、非同期での代替案を提案し、例外を認めるか確認します。明示的な例外の指定があった場合にのみ、手順 2 に進みます。

2. 入力を解析して読み込む トピックまたは目的を読み取ります。指定されたすべての @file 参照を読み込みます。参加者リスト、時間の制約、リンク先のドキュメントを抽出します。

3. 不足している値を推定する 次の推定ルールを適用します。

   値	推定元	デフォルト
   会議の種類	トピックのキーワード、参加者の職位の構成	other（確信度が低い）
   所要時間	トピックのドキュメントに明記されている場合（まれ）；種類を中程度以上の確信度で推定した場合は、会議の種類ごとのデフォルト	v1.1.0：種類ごとの所要時間（ファミリー契約を参照）。30 分は other、1-on-1、exec-briefing、customer-call の場合に限ります。キックオフ = 60 分、作業セッション = 60 分、意思決定 = 45 分など。
   目的	トピックの表現	推定し、概要に明記
   参加者の RACI	職位、トピックの担当者を示す手がかり	すべての推定を明記
   期待される成果	目的と会議の種類に関するヒューリスティクス	仮案を提示

   重要な推定に関するゲート条件（v1.1.0）：参加者の RACI または期待される成果の確信度が「高」未満の場合、「ゼロ摩擦での実行」セクションのファミリー契約に従い、実行モードの概要で ⚠ を付けて明記します。

4. 実行モードの推定概要を提示する 推定した値を確信度マーカー付きで表示します。続行するには go を受け付けます。修正の指示があれば反映します。修正後は再度推定し、概要を提示します。

5. 時間枠を設けたトピック一覧を作成する 会議の種類に応じたバリエーションを適用します（下記を参照）。各トピックの時間を調整し、合計が会議の所要時間と一致するようにします。トピック一覧が所定の時間を超える場合は、そのことを明示して調整方法を尋ねます（黙って時間を削ってはいけません）。

   各トピックには、次の項目を含める必要があります。

   • 種類タグ：Discussion | Decision | Information | Working
   • 担当者（氏名またはチーム）
   • 目標（何をもって完了とするか）
   • 割り当て時間
   • 事前資料へのリンク（ある場合）

6. 参加者の事前準備を指定する 必須の準備事項を、リンクと推定所要時間とともに列挙します。より詳しい背景を知りたい参加者向けに、推奨コンテキストを追加します。各参加者が何を提供するのかを明確にするため、「次の準備をして参加してください」という期待事項を追加します。

7. 保留項目とロジスティクスのプレースホルダーを追加する 保留項目は、会議中に挙がった議題外の項目を記録するためのプレースホルダーです。ロジスティクスには、参加リンク、必要な資料、録画の担当者を記載します。

8. 値を入力して TEMPLATE.md を出力する 最終成果物からガイダンスの引用ブロックをすべて削除します。

9. 出力を検証する

   • フロントマターの形式が、ファミリー契約の共通基本フィールドとアジェンダ固有フィールド（meeting_duration_minutes、desired_outcomes）に準拠していること
   • トピックの時間の合計が会議の所要時間と一致していること（許容誤差は ±2 分）
   • 期待される成果が少なくとも 1 つ記載されていること
   • 会議が不要かどうかの確認結果が Generation context に記録されていること

会議タイプのバリエーション

ステップ 5 で適用します。各バリエーションでは、会議の目的に合うようにトピックリストを組み替えます。

• 1-on-1：継続的な構成です。前回の項目、今回のトピック、成長や能力開発、障害を扱います。デフォルトは 30 分です。
• standup：順番に状況を共有し、エスカレーション事項や必要な決定を扱います。デフォルトは 15 分です。
• planning：コミットメントに重点を置き、対応可能な作業量と依存関係を確認します。デフォルトは 60 分です。
• review：プレゼンテーションを先に行い、事前資料を充実させ、フィードバックを明示的に記録する仕組みを設けます。デフォルトは 60 分です。
• decision-making：選択肢を先に提示し、判断基準を示して、求める決定を明確にします。提案書を含む事前資料が必要です。デフォルトは 45 分です。
• brainstorm：アジェンダは最小限にし、アイデアを生み出すためのプロンプトを用意します。決定を迫りません。デフォルトは 45 分です。
• stakeholder-review：TL;DR を先に示し、ビジネスへの影響を軸に説明して、求める対応を明示します。デフォルトは 45 分です。
• project-kickoff：スコープ、役割、成功基準、リスク、コミュニケーション計画を扱います。デフォルトは 60 分です。
• working-session：アジェンダは最小限にし、事前作業を必須とし、成果物を明示します。デフォルトは 60〜90 分です。
• exec-briefing：TL;DR を先に示し、その後に補足情報を提示します。デフォルトは 30 分です。
• other：一般的なトピック構成を使います。デフォルトは 30 分です。

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

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

• 読み込み： active_initiative と最近の decision アーティファクトを読み込み、すでに決着した事項を反映して、再検討のための時間を予定に入れないようにします。
• 書き込み： 何も書き込みません。アジェンダはこれから行う会議の計画であり、永続的に残すのは会議の振り返りです。
• 方針： 書き込む前にエントリーを提案し、確認を待ちます。ただし、memory_auto_append: true が設定されている場合は、追記して、書き込んだ内容を表示します。

これは、ファイル名に基づくファミリー内の連携を置き換えるのではなく、それを補完するものです。ファイル名は引き続き、ある会議の関連アーティファクトを特定するために使われ、プロジェクトメモリは会議をまたいで永続的なプロダクトのコンテキストを保持します。

品質チェックリスト

アジェンダを提出する前に、以下を確認します。

• 会議の必要性チェックを実施し、記録した
• 会議タイプを設定した（または、信頼度が低い旨を明示して other に設定した）
• 所要時間を設定した（指定がない場合のデフォルトは 30 分で、その旨を明記した）
• 期待する成果が具体的で、検証可能である（「X について話し合う」ではなく、「X をリリースするかどうかを決める」）
• すべてのトピックにタイプタグ、担当者、目標、時間を設定した
• トピックの時間の合計が会議時間と一致している
• 事前資料の準備時間を記載した（所要時間が明記されていない場合、参加者は準備を省略します）
• ロジスティクスのセクションに参加リンクと資料への参照がある
• 共有可能な要約が 5〜6 行で、Slack にそのまま貼り付けられる
• 出典と参照のセクションに、適用したデフォルトと行った推論を含む生成コンテキストが記載されている

関連項目

• Meeting Skills Family Contract。共有される動作要件と構造要件
• foundation-meeting-brief。ユーザー個人向けの事前準備（会議の必要性チェックを共有）
• foundation-meeting-recap。後続処理：このアジェンダのトピックリストから振り返りを自動入力
• foundation-stakeholder-update。後続処理：会議の成果を欠席者向けに翻訳