gtm-operating-cadence
成長中の企業向けに、ミーティングのリズム設計、指標レポート体制、四半期計画、および意思決定スピードの改善を支援します。意思決定が遅い、計画プロセスが機能していない、会社は成長しているのに組織の連携が悪化している、またはリーダーシップ会議に時間を取られるばかりで意思決定が生まれないと感じる場面で活用してください。
description の原文を見る
Design meeting rhythms, metric reporting, quarterly planning, and decision-making velocity for scaling companies. Use when decisions are slow, planning is broken, the company is growing but alignment is worse, or leadership meetings consume all time without producing decisions.
SKILL.md 本文
オペレーティング・カデンス
30人で機能していた会議構造は100人で崩壊する。100人で機能していた構造は300人で崩壊する。失敗パターンは常に同じ:大勢の人々が大勢の会議に参加しながら、ほとんど意思決定を行わない。
使用時期
トリガー:
- 「我々の会議は意思決定を生み出していない」
- 「成長しているが、アラインメントが悪くなっている」
- 「どのくらいの頻度で会議すべきか?」
- 「部門間で何が起こっているか誰も知らない」
- 「意思決定に時間がかかる」
- 「経営陣は終日会議に出ている」
コンテクスト:
- 20人から300人以上に成長している企業
- PMF後からグロース段階
- 分散/リモートチーム
- 「これについて話す必要がある」がデフォルトになったあらゆる段階
コアフレームワーク
1. 5段階ミーティングアーキテクチャ
パターン:
異なる会議は異なる目的を果たす。それらを混同するか、非効率性(時間が多すぎる)または混乱(不明確な意思決定)を招く。会議を機能、頻度、意思決定権限で分離する。
Level 1: デイリースタンドアップ(15分、チームのみ)
- 昨日完了したこと、今日開始すること、ブロッカー
- 最大5-10人。全社スタンドアップはパフォーマンス
- アンチパターン: ステータス報告(会議ではなくSlack)
- アンチパターン: 戦略的議論(間違った時間、間違った場所)
- 成功基準: 15分で終了、1-2個のブロッカーを浮上させる
Level 2: 週次機能別レビュー(60分、機能リーダーシップ)
各機能独自の週次リズムを持つ:
- プロダクトチーム金曜16時: メトリクス、ユーザーフィードバック、ロードマップブロッカー
- GTMチーム火曜16時: パイプライン、カスタマー更新、ディール健全性
- エンジニアリング水曜16時: ベロシティ、バグバックログ、デプロイメント
形式: メトリクスサマリー(10分) → 成功/ブロッカー(15分) → 1つの深掘り(30分) → 来週の優先事項(5分)
アンチパターン: 会議内ですべての問題を解決しようとする。1-2個選択し、他はフォローアップに委譲する。
Level 3: 週次オールハンズ(60分、全社)
スケーリング企業における最もアラインメント重要な仕組み。
- CEO更新(15分): 北極星進捗、週のフォーカス、変更内容
- メトリクスダッシュボード(10分): 毎週同じ形式(一貫性がパターン認識を可能にする)
- 深掘り(20分): チームインプットが必要な1つの戦略トピック — プレゼンテーションではなく、ディスカッション
- Q&A(15分): 本当の質問、本当の回答
アンチパターン: 防御的なトーン。オールハンズは率直であるべきで、スピンではない。 アンチパターン: 一貫性のないメトリクス。ダッシュボードを変更すれば、チームは進捗を追跡できない。
Level 4: 隔週リーダーシップアラインメント(90分)
- 北極星進捗(5分)
- 機能別更新(30分、各5-7分)
- 解決が必要な主要な意思決定(30-40分): リソース競合、戦略的ピボット、カスタマー/プロダクト意思決定
- 次2週間の計画(15分)
ここで部門横断的なブロッカーが解決される。機能が独立して運用されている場合、この会議は機能していない。
Level 5: 四半期戦略計画(半日から終日)
- 前四半期の回顧(90分): 何がうまくいったか、何がうまくいかなかったか、異なることをどうするか
- 次四半期の計画(120分): 何を最適化するか? ロードマップは?
- 機能別ブレークアウト(90分): 各機能が四半期を計画
- シンテシス(60分): 機能が約束を共有し、競合を解決
アンチパターン: 「楽しい活動」が多すぎて、実質がない。 アンチパターン: 明確な決定が出ない。
スケーリング調整:
- <30人: Level 2-3のみ。デイリースタンドアップをスキップ(すべてが見える)。隔週リーダーシップをスキップ(あなたが経営陣)。
- 30-100人: 5つのレベルすべてを追加。月次レビューは毎日見えなくなったものをキャッチ。
- 100-300人: スキップレベルレビューを追加。実行から2層以上。
- 300人以上: 機能固有のサブカデンスを追加。CEOは50人時代よりより少ない会議に出席すべき — より多くではなく。
これを機能させるルール:
すべての会議は意思決定を生み出すか、キャンセルされる必要がある。ステータス更新は非同期。会議にいて誰も意思決定をしていなければ、立ち去る。
2. 週次メトリクスレポーティング(問題を早期に捉えるダッシュボード)
パターン:
月次レポートは30日遅れで問題をキャッチする。その時点で、悪い月は確定している。週次レポートは2週目に問題をキャッチし、その月をまだ救える。
形式(毎週同じ構造):
WEEK OF [DATE]
North Star: [Metric]
This Week: [Value] | Last Week: [Value] | Change: [+/-] [↑↓]
Context: [One sentence — why this trend matters]
Functional Metrics:
Product: 7-Day Retention: 34% | Last: 33% | +1% ↑
Feature Adoption: 18% | Last: 16% | +2% ↑
Context: Onboarding improvements showing impact
GTM: Pipeline: $8.2M | Last: $7.8M | +$400K ↑
New POCs: 3 | Last: 2
Context: Partner pipeline adding deals
Health: Team Morale: 7.2/10 (down from 7.5)
Context: Org restructure causing uncertainty
規律ルール:
- 毎週同じメトリクス。 一貫性がパターン認識を可能にする。メトリクスを追加してもいい、決して削除しない。
- メトリクスごとに1つのコンテクスト文。 数字だけでなく — なぜこれが重要か? 計画比? 前期比?
- すべてのメトリクスのトレンド方向。 上/下/フラット矢印。大幅に動いた場合: 一時的か構造的か?
- トラフィックライト色。 GREEN(予定通り)、YELLOW(注視)、RED(アクション必要)。すべてのREDアイテムは: オーナー、具体的なアクション、期限が必須。
エスカレーションルール:
メトリクスが同じアクション計画で2週連続REDの場合、エスカレート — アクション計画が機能していない。
メトリクスの数:
8-12個選択。メトリクスが動いてもあなたの行動を変えなければ、削除。40個のメトリクスを持つダッシュボードは装飾であり、意思決定ツールではない。
一般的な間違い:
良く見えるが事業成果を予測しない虚栄メトリクス。採用コンテクストなしの総ダウンロード。サポートメトリクスなしのCEO見出し。
3. 四半期計画(戦略的ドリフトを防ぐプロセス)
パターン:
四半期計画なしで、企業はドリフトする。各機能がローカルで最適化。セールスはICP外のディール追跡。プロダクトは1顧客向けに機能構築。マーケティングはパイプラインに接続しないキャンペーン実行。
3週間計画サイクル:
Week 1: 回顧 + データ収集
- 前四半期の結果対計画(リーダーシップが準備)
- 各機能が1ページの回顧を記述: 何がうまくいったか、何がうまくいかなかったか、異なることをどうするか
- ファイナンスが準備: 収益実績、支出実績、フォーキャスト
- 市場データ: 競争相手の動き、カスタマーフィードバックテーマ、win/loss分析
Week 2: 優先事項設定(リーダーシップ半日)
- 回顧をレビュー(30分 — 事前読み、プレゼンテーションしない)
- 3-5個の企業レベル優先事項で同意
- 各: オーナー、成功メトリクス、リソース要件
- あなたが行わないもの(行うことと同じくらい重要)を特定
- 部門横断的依存性を解決
- 北極星をタイブレーカーとして使用: 「これ目標達成を助けるか? 優先。ナイストゥハブ? 延期。」
Week 3: OKRカスケード + リソース配分
- 各機能が企業優先事項をチームOKRに翻訳
- リーダーシップがアラインメント確認
- リソース配分確定(ヘッドカウント、予算、ツール)
- 最終計画を全社で共有
四半期コミットメント形式:
Q2 2026 Roadmap
North Star: [What we're optimizing for]
Pillar 1: Product (25% team effort)
Initiative: [Name]
Problem: [What we're solving]
Success: [Specific metric]
Owner: [Name]
Timeline: [When]
Pillar 2: GTM (50% team effort)
Initiative: [Name]
...
Pillar 3: People (10% effort)
Initiative: [Name]
...
Pillar 4: Tech Debt (15% effort)
Initiative: [Name]
...
「行わない」リスト:
追加するすべての優先事項に対して、やめることを1つ特定。あなたが行わないもの名付けられなければ、優先事項が多すぎる。
一般的な間違い:
誰も読まない30ページのドキュメントを生成する四半期計画。出力は: 1ページに3-5個の優先事項、各オーナーとメトリクク付き。以上。
4. 意思決定ベロシティと権限
パターン:
20人では、CEOがすべての意思決定をリアルタイムで行う。速い。100人では、意思決定にはアラインメントが必要。遅い。300人では、意思決定にはアラインメント、承認、ドキュメンテーションが必要。遅々とした進行。
修正は会議を増やすことではない。明確な意思決定権である。
意思決定権限マトリックス:
| 意思決定 | 誰が決定 | タイムライン | エスカレーション |
|---|---|---|---|
| 企業戦略 | CEO | 1週間 | 戦略的であれば取締役会 |
| 機能優先事項 | プロダクトリード | 1週間 | >3エンジニアウィークであればCEO |
| カスタマーサポート問題 | CSM | 即座 | エスカレートされたらCS lead |
| マーケティングキャンペーン | マーケティングリード | 2週間 | >$10K予算であればCMO |
| 採用 | 機能リーダー | 2週間 | 承認されたロールでなければCEO |
| 新パートナーシップ | CEO | 2週間 | 戦略的であれば取締役会 |
| ベンダー選定 | 機能リーダー | 1週間 | >$50K/年であればCEO |
問題:
スケーリング企業は可逆的で低リスクな意思決定を不可逆的で高リスクなものとして扱い始める。すべてが承認を必要。すべてが会議が必要。すべてがコンセンサスを必要。
修正:
Type 1(不可逆的、高リスク): 価格設定モデル、市場進出、主要パートナーシップ → CEO/リーダーシップが議論で1回の会議で決定。タイムライン: 最大1-2週間。
Type 2(可逆的、低リスク): キャンペーンクリエイティブ、機能優先事項、1回の採用 → 機能オーナーが決定、通知、反復。タイムライン: 同日または翌日。
100%の情報ではなく70%の情報で意思決定。 スピードはあらゆる段階での競争優位。
一般的な間違い:
コラボレーションに見せかけるコンセンサス文化。「全員をアラインさせましょう」は「誰も決定したくない」を意味することが多い。意思決定者を名指し。彼らに決定させる。先に進む。
5. 非同期優先コミュニケーション
パターン:
同期的会議はスケールしない。デフォルトは非同期、同期にエスカレート。
非同期優先(会議不要):
- 意思決定ドキュメント(主要なもの — 提案を記述、コメント募集、フィードバック48-72時間、コンセンサスまたは実質的異議がなければ決定)
- 進捗更新(会議ではなく週次レポート)
- プロセス変更とSOP
- 既に決定されたもの(議論しない、通知)
同期が必要な場合:
- リアルタイムブレストが必要
- 解決すべき主要な異議
- ホワイトボードが必要な複雑なトピック
- チームビルディング/関係構築
ドキュメンテーション規律:
すべての意思決定がドキュメント: 何が決定された? なぜ? 誰が決定? いつ有効になる? 誰が知る必要か?
検索可能な形式(wiki、共有ドライブ)に保存。新入社員はより速くオンボード。過去の意思決定は再度検討されない。
一般的な間違い:
10時間/週に拡大する「クイック同期」会議。Slack(一時的、ノイズ)での過剰コミュニケーション、永続的形式(ドキュメント、メール)での過少コミュニケーション。重要なものは6ヶ月後に検索可能であるべき。
6. CEO週次アップデート
パターン:
スケーリング企業で最も高いレバレッジのコミュニケーション。書くのに5-10分。全員読む。それはコンテクスト設定、成功祝い、優先事項命名、共有理解を作成。
形式(日曜夜または月曜朝に送信):
1. 週フォーカス(1段落): この週の優先事項は? チームが何にフォーカスすべきか?
2. 北極星進捗(1-2個の箇条): 主要メトリクスでどこにいるか? トレンド上/下/フラット? なぜこれが重要か?
3. この週の成功(3-5個の�条): 何がシップ? カスタマー/パートナー成功? 大局的含意?
4. 解決するブロッカー(1-2個の箇条): この週何をアンブロックするか? 誰が知る必要か?
5. 要求(1個の箇条、オプション): チームはどんな助けが必要か? 紹介、フィードバック、カスタマー紹介?
ルール:
毎週同じ日。一貫性は運用規律を表す。週をスキップすれば、チームは気づく — あなたが何を言わないか疑い始める。
一般的な間違い:
長すぎ(チームは読まない)、詳細すぎ(機能会議のために取っておく)、良いニュースのみ(チームは信頼を失う)、一貫性がない(チームは読むのをやめる)。
7. ロール明確性 > タイトル
パターン:
スピード最強ツールは階層ではない — 明確なロール明確性。誰かが彼らが何を所有するかを正確に知ったとき、それを委譲できないと、意思決定がより速く起こる。
実行方法:
- すべてのイニシアティブは正確に1人のオーナーを得る(サポートするチームメートと共に)
- メトリクスそのオーナーに結びつく
- 成功はタスク完了ではなくKPI移動で測定
- 48時間以内に明確なオーナーシップなしでイニシアティブを排除
テスト:
このアウトカムを所有する単一の人を名付けられるか? 「チーム」ではなく — 人。そうでなければ、イニシアティブはドリフト。
一般的な間違い:
複数の人にプロジェクト割り当て(「全員が所有」=「誰も所有しない」)。アクティビティではなく影響を測定。イニシアティブごとにROI追跡なしでバーンレート上昇。
決定ツリー
どのミーティングレベルが必要か?
Company size <30?
├─ Yes → Levels 2-3 only (weekly functional + all-hands)
└─ No → Continue...
│
30-100 people?
├─ Yes → All 5 levels
└─ No → All 5 + skip-level reviews + function sub-cadences
この会議は継続する価値があるか?
Does it produce decisions?
├─ No → Can it be async?
│ ├─ Yes → Make it async, cancel the meeting
│ └─ No → Redesign with decision agenda
└─ Yes → Are the right people in the room?
├─ No → Fix attendee list (fewer > more)
└─ Yes → Keep it
一般的な間違い
1. 成長に応じて会議を追加 それらを置き換える。200人では、CEOは50人時代より少ない会議に出席すべき。
2. ステータス更新会議 メールでできれば、メールであるべき。会議は意思決定のもの。
3. 四半期ごとにメトリクス変更 一貫性はトレンド識別を可能にする。同じダッシュボード、毎回。
4. コンセンサス文化 意思決定者を名指し。彼らに決定させる。他のすべてに通知。
5. Slackのすべての情報 一時的、ノイズ、検索不可。重要な意思決定はドキュメント。
6. 30ページドキュメントを生成する四半期計画 1ページに3-5個の優先事項。以上。
クイックリファレンス
ミーティングアーキテクチャ: デイリースタンドアップ(15分) → 週次機能別(60分) → 週次オールハンズ(60分) → 隔週リーダーシップ(90分) → 四半期計画(半日)
週次メトリクスダッシュボード: 8-12個メトリクス、毎週同じ形式、トラフィックライト色、メトリクスごとに1つのコンテクスト文、すべてのREDについてオーナー+アクション+期限
四半期計画サイクル: Week 1: 回顧 + データ → Week 2: 優先事項設定(3-5最大) → Week 3: OKRカスケード + リソース
意思決定権限: Type 1(不可逆的): CEO/リーダーシップ、1-2週間 → Type 2(可逆的): 機能オーナー、同日
CEO週次アップデート: 週フォーカス → 北極星進捗 → 成功 → ブロッカー → 要求
情報フロー: デイリー: Slack成功/カスタマーボイス → 週次: CEOメール + 機能更新 → 月次: オールハンズ + スキップレベル → 四半期: 計画共有 + デモ
関連スキル
- enterprise-account-planning: ステークホルダー管理とディール カデンスパターン
- 0-to-1-launch: ローンチ固有の実行カデンス
- board-and-investor-communication: 取締役会会議構造と投資家アップデート
20人から1,000人以上に成長する企業での運用カデンスデザイン、3倍ヘッドカウント成長を生き延びた5段階会議アーキテクチャ、月次レビューより3週間早くパイプライン問題をキャッチした週次レポート形式、複数企業で洗練されたCEO週次アップデート形式に基づく。理論ではなく — ハイパーグロース通じて運用システムを構築し、次のチームに教えたパターン。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- github
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/github/awesome-copilot / ライセンス: MIT
関連スキル
nano-banana-2
inference.sh CLIを通じてGoogle Gemini 3.1 Flash Image Preview(Nano Banana 2)で画像を生成します。テキストから画像を生成する機能、画像編集、最大14枚の複数画像入力、Google Searchグラウンディング機能に対応しています。トリガーワード:「nano banana 2」「nanobanana 2」「gemini 3.1 flash image」「gemini 3 1 flash image preview」「google image generation」
octocode-slides
洗練されたマルチファイル形式のHTMLプレゼンテーションを生成します。6段階のフロー(概要 → リサーチ → アウトライン → デザイン → 実装 → レビュー)で構成されています。各スライドは独立したHTMLファイルとなり、iframeで読み込まれます。「スライドを作成してほしい」「プレゼンテーションを作ってほしい」「HTMLスライドを生成してほしい」「デックを構築してほしい」といった依頼や、ノート・ドキュメント・コードを洗練されたプレゼンテーションに変換する際に使用できます。
gpt-image2-ppt
OpenAIのgpt-image-2を使用して、視覚的に優れたPPTスライドを生成します。Spatial Glass、Tech Blue、Editorial Monoなど10種類のキュレーション済みスタイルに対応し、ユーザーが提供したPPTXファイルを模倣するテンプレートクローンモードも搭載しています。HTMLビューアと16:9形式のPPTXファイルを出力します。プレゼンテーション、スライド、ピッチデック、投資家向けPPT、雑誌風PPTの作成依頼などで活用してください。
nano-banana
Nano Banana PRO(Gemini 3 Pro Image)およびNano Banana(Gemini 2.5 Flash Image)を使用したAI画像生成機能です。以下の場合に活用できます:(1)テキストプロンプトからの画像生成、(2)既存画像の編集、(3)インフォグラフィックス、ロゴ、商品写真、ステッカーなどのプロフェッショナルなビジュアルアセット制作、(4)複数画像での人物キャラクターの一貫性保持、(5)正確なテキスト描画を含む画像生成、(6)AI生成ビジュアルが必要なあらゆるタスク。「画像を生成」「画像を作成」「写真を作る」「ロゴをデザイン」「インフォグラフィックスを作成」「AI画像」「nano banana」またはその他の画像生成リクエストをトリガーとして機能します。
oiloil-ui-ux-guide
モダンでクリーンなUI/UXガイダンス・レビュースキルです。新機能や既存システム(Webアプリ)に対して、実行可能なUI/UX改善提案、デザイン原則、デザインレビューチェックリストが必要な場合に活用できます。CRAP(コントラスト・反復・配置・近接)をベースに、タスクファーストなUX、情報設計、フィードバック・システムステータス、一貫性、affordances、エラー防止・復旧、認知負荷を重視します。モダンミニマルスタイル(クリーン・余白・タイポグラフィ主導)を強制し、不要なテキストを削減、アイコンとしての絵文字を禁止し、統一されたアイコンセットから直感的で洗練されたアイコンを推奨します。
axiom-hig-ref
Apple Human Interface Guidelines リファレンス — 色(セマンティックカラー、カスタムカラー、パターン)、背景(マテリアル階層、ダイナミック背景)、タイポグラフィ(標準スタイル、カスタムフォント、Dynamic Type)、SF Symbols(レンダリングモード、色、多言語対応)、ダークモード、アクセシビリティ、プラットフォーム固有の考慮事項を網羅したガイドラインです。