meetings について
会議の目的を明確にし、集中時間を確保したいエンジニアリングマネージャー向けのスキルです。会議の要否、準備、進行、フォローアップ、振り返りの指針を提供します。
主な機能
- 01会議か非同期かの判断
- 02アジェンダと参加者の計画
- 03決定につなげる進行
- 04定例会議の削減
- 05会議結果の評価
活用シーン
- 01情報共有会を非同期更新に置き換え
- 02焦点の定まらない定例会議を再設計
- 03会議記録を振り返り改善点を特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ manager-dot-dev/ manager-skills --skill meetingsインストール後、Claude Code で/meetingsを入力して読み込まれたか確認します。
同梱ファイルreferences/sources.md
詳細
ミーティング
始める前に
まず EM のコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。
.agents/em-context.md が存在しない場合は、詳しいアドバイスをする前に、まず最小限のマネージャープロフィールを尋ねて保存してください。役職・肩書き、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。
特定の人物が会話の中心で、その人のための .agents/reports/[name].md が存在しない場合は、詳しいアドバイスをする前に、その人の最小限のプロフィールを尋ねて保存してください。役職・レベル、在籍期間、強み、現在の課題または成長分野を確認します。
その後の会話で長期的に役立つ新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。安定した事実や傾向を保存し、推測、一時的な不満、未解決の解釈は保存しないでください。
回答のスタイル
最初の回答は簡潔で役立つものにしてください。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。
基本方針:
- 可能性の高い診断または推奨事項を最初に述べる
- 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大2〜3個する
- 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える正確な文面も提示する
- 関連するフレームワークに簡単に触れる。ただし、すべての要素を説明しない
- 直接的な回答の後にのみ、より詳しい説明を提案する
このスキルの使い方
- ミーティングを開催すべきか迷っている → ミーティングにするべきか
- 特定のミーティングを運営する:招待する人、準備、進行方法 → 効果的なミーティングの進め方
- ミーティングが多すぎる、チームが集中できない、カレンダーが分断されている → ミーティングを減らす
- 誰も目的を説明できない定例ミーティングがある → 目的を終えたミーティングを廃止する
- ユーザーが議事録を共有する、またはミーティングの様子を説明する → ミーティングを振り返る
- エンジニアがいつも気を散らされ、集中状態に入れない → ミーティングのコストが高い理由(その後、ミーティングを減らす)
回答の基本構成
ミーティングについて支援する際は、決定事項と運用計画を提示してください。
- ミーティングの判断: 継続、廃止、短縮、非同期化、分割、または再設計。
- 目的: 意思決定、問題解決、認識合わせ、関係構築、または情報共有。
- アジェンダ/非同期の代替案: 具体的な構成または文書による代替手段。
- 参加者: 必ず出席すべき人と、後から情報共有すればよい人。
- フォローアップの仕組み: 担当者、決定事項、議事録、見直し日。
議事録や過去のミーティングについては、何がうまくいかなかったのかを診断し、改善案を提示してください。
ミーティングのコストが高い理由
エンジニアの仕事はメーカー型のスケジュールに合っています。有意義な作業には1時間単位の枠ではなく、半日単位の時間が必要です。午前11時のミーティングは、1時間のコストでは済みません。その前の時間枠では深い作業に取り組むには短すぎるため、午前中を丸ごと奪います。あなたにとってはいつもの予定でも、エンジニアにとっては大きなコストです。
60万件以上のプルリクエストを対象とした調査によると、エンジニアが本当に生産的なのは 午前9〜11時と午後2〜4時 の2つの時間帯です。短時間であっても、この時間帯にミーティングを入れると、生産的な時間枠が失われます。ミーティングは午前8時30分、午前11時30分、午後1時、または午後4時以降に設定してください。この差はわずかではありません。
これは会議ですか?
予定を入れる前に、会議の種類を見極めましょう。
- 問題解決 — グループで協力して問題に取り組む必要がある
- 意思決定 — 決定を下す必要があり、適切な人が参加していなければならない
- 賛同を得る — すでに決定しており、合意とコミットメントを得る必要がある
- 情報共有 — 何かを伝える
情報共有のために会議が必要になることは、ほとんどありません。Loom の録画を作成する、ドキュメントを送る、Slack に投稿するなどの方法を使いましょう。同時にやり取りする必要があることに、リアルタイムの時間を充ててください。
意思決定者は参加する必要がありますか? 参加できない場合は、日程を変更しましょう。決定を下すはずの会議に意思決定者がいなければ、何も決まりません。
意思決定の会議では、7 人を超える参加者はたいてい多すぎます。 人が増えるごとに、対人関係の複雑さが増し、議論が遅くなり、焦点がそれることもよくあります。状況を「把握しておく」必要がある人には、概要を共有できます。
良い会議の進め方
準備する。 すべての会議で、事前に書面のアジェンダを送る必要があります。「近況を話し合う」ではなく、取り上げる内容と期待する成果を具体的に列挙しましょう。複雑なテーマの場合は、24〜48 時間前に資料を送り、参加者には自分の見解を持って参加するよう依頼します。全員が会議中に資料を読むような会議は、準備が不十分です。
進行する。 必ず時間どおりに始めましょう。ファシリテーターと議事録担当者を決めます。話がそれたら、「それも大切ですね。いったん保留にして、後で戻りましょう」と伝えましょう。保留事項のリストを作れば、正当な懸念を退けることなく、会議を本題に沿って進められます。
議論ではなく、決定へと導きましょう。「これについては、もう少し考えるべきですね」で終わる会議は失敗です。決定を下す、次のステップを割り当てる、または必要な情報とその入手担当者を明確にする、のいずれかで締めくくりましょう。
60 分の会議で 20 分後に目標を達成できたら、そこで終了しましょう。
最後までやり遂げる。 24 時間以内に、決定事項、担当者と期限を含むアクション項目、未解決の質問を記載した議事要約を送ります。会議で明白に思えたことでも、人によって記憶は異なります。書面の記録が事実です。
会議を減らす
あなたのカレンダーは、チームのカレンダーの手本です。 一日中、会議が連続していると、それが普通だというメッセージを発信していることになります。
- 先を見越して取り組む時間を確保する。 週の勤務時間の少なくとも 30%を、中断のない時間枠に充てることを目指しましょう。20%を下回ると、受け身の対応に追われている状態です。
- 会議をまとめる。 午前中や特定の日など、決まった時間帯に集中させて、集中して作業できる時間を確保しましょう。
- 標準の時間を短くする。 30 分や 60 分ではなく、25 分や 50 分に設定しましょう。時間枠を短くすると効率が上がります。会議は予定された時間いっぱいまで延びるものです。
- 参加を委任する。 あなた自身が出席しなくてもよい会議もあります。代わりに報告担当者に出席してもらい、後で概要を報告してもらいましょう。
- 断ってもかまいません。 意思決定者でもなく、必須の情報提供者でもない場合は、出席を断り、概要で情報共有してもらいましょう。
目的を終えた会議をなくす
どのチームにも、誰も理由を説明できない定例会議があります。何の価値も生み出さない朝会。2 年もカレンダーに登録されたままの定例ミーティング。
定期的にこう問いかけましょう。「なぜまだこれを続けているのか?」 答えが「ずっとそうしてきたから」なら、それは慣性であり、理由ではありません。前任のマネージャー、異なるチーム規模、あるいは異なる段階から引き継いだプロセスは、役に立たなくなっても続いていることがよくあります。
簡単な習慣として、四半期に一度、チームの定例的な活動を書き出し、それぞれについて問いかけましょう。これはどのような問題を解決するのか? 誰も答えられなければ、1 か月間やめてみましょう。多くの人がほっとするはずです。
ミーティングを振り返る
ユーザーが議事録を共有したり、ミーティングの様子を説明したりしたら、次の5つの観点から評価します。
1. 目的 — ミーティングの開始前に目標は明確でしたか? 達成できましたか? 決定、コミットメント、明確な次のステップがないままミーティングが終わった場合、それは失敗です。
2. 参加者 — 適切な人が参加していましたか? 意思決定者は出席していましたか? 要約を聞くだけでよい人がその場にいませんでしたか?
3. 準備 — アジェンダはありましたか? 関連資料を読んで参加しましたか? それともミーティング中に読んでいましたか?
4. 進行 — 話し合いは本筋からそれずに進みましたか? 脱線した話題は明示され、後回しにされましたか? 1人が話を独占していませんでしたか? 発言の少ない人にも発言の機会がありましたか?
5. フォローアップ — 決定事項は記録されましたか? 担当者と期限を含むアクションアイテムが記録されましたか? それとも、曖昧な約束だけでミーティングが終わりましたか?
各観点について、何が起きたかと、次回に向けて変えるべき具体的なことを1つ挙げます。目標は満点を取ることではありません。次のミーティングを大きく改善するための、1つか2つの変更点を見つけることです。
さらに詳しく
ユーザーがフレームワークの出典を尋ねたり、元の記事を読みたいと言ったり、このスキルのトピックについてさらに詳しい情報を求めたりした場合は、references/sources.md を読んで、出典となる記事と書籍の全リスト(リンク付き)を確認してください。
関連スキル
managing-urgency— 緊急性を重視する文化は、不要なミーティングや慢性的な中断のよくある原因ですdelegation— 委任しない EM は、自らが中断のよくある原因になってしまいますteam-health— ミーティングの頻度と質は、チームの健全性やエンゲージメントにも表れます1on1s— 1:1 は、独自の形式を持つ特定の種類のミーティングです