mcpField
C
company-os

company-os

github.com/borghei生産性1.0k99 回インストール1 週間前に更新
リポジトリ

company-os について

会社の運営システムを明確にし、改善するためのスキルです。創業者や経営チームが EOS、Scaling Up、OKR、Holacracy などを選び、役割、指標、会議、優先事項、課題解決の仕組みを整えます。

主な機能

  1. 01EOS、Scaling Up、OKR、Holacracyの比較
  2. 02責任分担表とスコアカードの設計
  3. 03会議とコミュニケーションの周期設定
  4. 04IDSによる課題解決の構成
  5. 0590日間の優先事項と導入計画

活用シーン

  1. 01会社に合う運営フレームワークの選定
  2. 02各機能の責任者の明確化
  3. 03週次指標レビューの作成
  4. 04四半期の優先事項と会議周期の設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill company-os

インストール後、Claude Code で/company-osを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

scripts/
meeting_pulse_designer.py
rocks_tracker.py
scorecard_builder.py

詳細

会社のオペレーティングシステム

オペレーティングシステムとは、会社の機能の仕方を決めるツール、リズム、合意事項の集合です。どの会社にも存在しますが、その大半は自社のものを把握していません。それを明確にすれば、改善できるようになります。

キーワード

オペレーティングシステム、EOS、Entrepreneurial Operating System、Scaling Up、Rockefeller Habits、OKR、Holacracy、L10 ミーティング、ロックス、スコアカード、アカウンタビリティチャート、課題リスト、IDS、ミーティングのリズム、四半期計画、週次スコアカード、マネジメントフレームワーク、会社のリズム、トラクション、年間計画、コミュニケーションの頻度


まず確認すること

生成する前に、以下の情報を確認してください。不明または曖昧なものがあれば、推測せずに質問してください。

  • 会社の規模と成長段階 — フレームワークの推奨(EOS/Scaling Up/OKR ネイティブ/Holacracy)と導入スケジュールは、主に従業員数によって決まります
  • 実際に機能していないこと(スコアカードがない、優先事項が一致していない、課題が繰り返し未解決のままになる、会議が多すぎるなど)— 6 つのコンポーネントのうち、どれから構築するかを決めます
  • 創業者の業務スタイル(業務重視かビジョン重視か)、および会社がエンジニアリング主導か営業主導か — 同じ規模区分内でのフレームワーク選定に影響します
  • すでに存在するリズムと指標 — 新しい OS によって会議が置き換えられるようにし、既存の会議に追加して会議疲れを招かないために確認します

中断ルール:出力に最も大きく影響する 2~3 項目だけを質問してください。ユーザーが「とにかく草案を作って」と言った場合は、そのまま進め、成果物の冒頭に前提を記載してください。


オペレーティングシステムの選定

判断ツリー
START: "Which operating system?"
  |
  v
[Company size?]
  |
  +-- 10-50 people
  |     |
  |     v
  |   [Is the founder operational or visionary?]
  |     |
  |     +-- Operational --> EOS / Traction (structured, simple)
  |     +-- Visionary --> Scaling Up (ambitious, strategy-heavy)
  |
  +-- 50-200 people
  |     |
  |     v
  |   [Engineering-led or sales-led?]
  |     |
  |     +-- Engineering-led --> OKR-native (hypothesis-driven)
  |     +-- Sales-led --> Scaling Up or EOS (execution-focused)
  |
  +-- 200+ people
  |     |
  |     v
  |   [High autonomy or high alignment needed?]
  |     |
  |     +-- High autonomy --> Holacracy (only if patient)
  |     +-- High alignment --> Custom hybrid (best of EOS + OKR)
  |
  +-- Not sure --> Start with EOS. It is the simplest to implement.
フレームワーク比較表
特徴EOSScaling UpOKR ネイティブHolacracy
複雑さ低中中高
導入期間30-90 日90-180 日60-120 日6-12 か月
最適な会社規模10-25050-50020-50050-300
目標フレームワークロックス(二択)OKR + 優先事項OKR(評価あり)役割 + アカウンタビリティ
会議の頻度週次 L10毎日のハドル + 週次週次 + 四半期ガバナンス + 戦術
課題解決IDS継続/中止/統合振り返りガバナンスプロセス
アカウンタビリティアカウンタビリティチャート機能別アカウンタビリティOKR のオーナーシップ役割ベース
スコアカード週次の数値週次 KPI四半期 KR役割ごとの指標
強みシンプルで導入が速い厳格で、戦略を重視柔軟で、テクノロジーとの親和性が高い権限が分散されている
弱み硬直的に感じられることがある複雑で、規律が求められる構造がないと方向性がぶれることがある習得の難易度が高い

6 つの中核コンポーネント

効果的なオペレーティングシステムには、フレームワークにかかわらず、以下の 6 つが含まれます。

コンポーネント 1:アカウンタビリティチャート

組織図ではありません。アカウンタビリティチャートは、「この成果に責任を持つのは誰か?」に答えるものです。

設計原則
原則実施方法
単独オーナーシップ各機能の責任者は 1 人です。複数人がその機能に携わることはできます。
明示的な空白誰も担当していない機能を特定し、担当者を割り当てます。
重複なし2 人が自分の担当だと思っているなら、どちらの担当でもありません。すぐに解決してください。
成長段階に応じた設計初期段階では、1 人が複数の役割を担当できます。そのことを明確にしてください。
四半期ごとの見直し会社の成長に応じて担当が変わります。四半期ごとに見直してください。
アカウンタビリティチャートのテンプレート
CEO
  |
  +-- Revenue (CRO/VP Sales)
  |     +-- Inbound pipeline
  |     +-- Outbound pipeline
  |     +-- Customer success
  |
  +-- Product & Engineering (CTO/CPO)
  |     +-- Product roadmap
  |     +-- Engineering delivery
  |     +-- Technical operations
  |
  +-- Operations (COO)
  |     +-- Finance & legal
  |     +-- People operations
  |     +-- Business operations
  |
  +-- Marketing (CMO/VP Marketing)
        +-- Demand generation
        +-- Brand & content
        +-- Product marketing
ワークショップの進行手順(2 時間)
Step 1: List all functions the company performs (30 min)
Step 2: Assign ONE owner per function (30 min)
Step 3: Identify gaps (functions nobody owns) (15 min)
Step 4: Identify overlaps (2+ people claiming ownership) (15 min)
Step 5: Resolve gaps and overlaps (20 min)
Step 6: Publish and communicate (10 min)
コンポーネント 2:スコアカード

会社が順調に進んでいるかを示す週次指標です。月次でも四半期ごとでもありません。週次です。

スコアカードのルール
ルール理由
指標は最大 5~15 個15 個を超えると、何にも注意が向かなくなります
各指標に担当者を設定するオーナーシップがアカウンタビリティを促します
各指標に週次目標を設定する範囲ではなく、具体的な数値を設定します
赤/黄/緑のステータス段落ではなく、信号機のように表示します
議論するのは赤の指標だけ緑なら、会議で議論する必要はありません
スコアカードの例
指標担当者目標週次ステータス
新規MRRCRO$50K$43K[R]
ロゴチャーンCS Lead< 1%0.8%[G]
アクティブユーザーCPO2,0002,150[G]
デプロイCTO3/week3[G]
未解決の重大バグCTO02[R]
ランウェイCFO> 18mo16mo[Y]
オファー承諾率CHRO> 85%90%[G]
コンポーネント 3:ミーティングのリズム
ミーティング全体のリズム
ミーティング頻度所要時間参加者目的
デイリースタンドアップ毎日15 min各チームブロッカーのみ
L10/リーダーシップ同期会毎週90 minリーダーシップチームスコアカード+課題
部門レビュー毎月60 min部門+リーダーシップ部門指標の詳細分析
四半期計画四半期ごと1-2 daysリーダーシップ重点課題の設定、戦略の見直し
年次計画毎年2-3 daysリーダーシップ1年後+3年後のビジョン
L10ミーティングのアジェンダ(週次リーダーシップ)
セクション所要時間内容
良いニュース5 min個人およびビジネスの成果
スコアカードの確認5 min赤の項目のみを指摘
重点課題の確認5 min各重点課題の進捗状況
顧客/従業員のトピック5 min注目すべき出来事
課題リスト(IDS)60 min特定、議論、解決
ToDoの確認5 min先週の約束事項:完了したかどうか
締めくくり5 minミーティングを1~10で評価し、次回10点にするには何が必要か
コンポーネント 4:課題解決(IDS)

課題1件あたり最大15分です。これが問題解決の中核となるループです。

IDENTIFY: What is the actual issue? (One sentence, root cause, not symptom)
  |
DISCUSS: Relevant facts + perspectives. Time-boxed.
  |       When discussion starts repeating, STOP.
  |
SOLVE: One owner. One action. One due date. Written down.
IDSのアンチパターン
アンチパターンうまくいかない理由対策
「この件は別途話しましょう」別途話すことにした件は、ほとんど解決されません今解決するか、来週のリストに追加します
決定せずに議論する議論が充実していても、アクション項目がなければ時間の無駄ですすべての議論は決定で締めくくる必要があります
決定済みの課題を再検討するシステムを損ないます解決したらリストから外します。新しいデータがある場合のみ再度取り上げます
3回以上のミーティングにわたってリストに残る課題実際の課題ではないか、取り組むのが怖すぎるかのどちらかです今週対処するか、リストから外すかを決めます
複数の課題を一緒くたにするまとめられた問題は解決できません1つの項目には課題を1つだけ記載します。必要に応じて分けます
コンポーネント 5:重点課題(90日間の優先事項)
重点課題のルール
ルール理由
1人あたり最大3~7件7件を超えると、どれも完了しません
会社全体で3~7件の重点課題リーダーシップが共有する優先事項
ステータスは完了または未完了の二択「60%完了」はありません
四半期計画で設定毎週進捗を確認します
ToDoリストではない重点課題には90日間にわたる継続的な取り組みが必要です
良い重点課題と悪い重点課題
悪い重点課題理由良い重点課題
「営業プロセスを改善する」測定可能でも具体的でもありません「3月31日までに、パイプラインのステージとレポート機能を備えたCRMを導入する」
「エンジニアをもっと採用する」目標も期限もありません「4月15日までに、シニアエンジニア3人を採用し、オファー承諾を得る」
「チャーンを減らす」目標がありません「第2四半期末までに、月次ロゴチャーンを3%から1.5%に減らす」
「コミュニケーションを改善する」観察できません「12週間、毎週金曜日に全社向けの週次アップデートを配信する」
コンポーネント 6:コミュニケーションの頻度
対象内容時期形式
全従業員会社のアップデート毎月文書+質疑応答
全従業員四半期の成果+優先事項四半期ごと全社ミーティング
リーダーシップチームスコアカード毎週ダッシュボード
取締役会会社の業績毎月または四半期ごと取締役会向けメモ/資料
投資家主要指標+説明毎月または四半期ごと投資家向けアップデート
顧客製品アップデートリリースごとリリースノート

デフォルトのルール:社内で共有するかどうか迷ったら、共有します。情報共有が不足することで生じる損失は、共有しすぎることで生じる損失を常に上回ります。


導入ロードマップ

30日間のクイックスタート
週アクティビティ所要時間
1アカウンタビリティチャートを作成する2時間のワークショップ
2週次スコアカードの指標を5〜10個定義する1時間のすり合わせセッション
3週次L10ミーティングを開始する週90分(継続)
4最初の90日間のロックスを設定する半日の計画セッション

この4つだけでも、ほとんどの企業が1年かけて達成する以上に連携が向上します。

90日間の完全導入
月焦点成果物
1基盤アカウンタビリティチャート、スコアカード、L10ミーティング
2深化ロックスの定義、課題リストの運用開始、毎日のスタンドアップ
3リズム完全なミーティングリズム、コミュニケーションの頻度、初回の四半期レビュー

よくある失敗パターン

失敗症状対策
部分的な導入「OKRは実施していますが、定期的な確認を省いています」OSの半分だけでは、何もしないより悪い状態です。システム全体に取り組みましょう。
ミーティング疲れ既存のミーティングに加えて新たなリズムを追加しているミーティングを追加するのではなく、置き換えましょう
指標の過多「どれも重要だから」とKPIが30個あるまずは5個から始めましょう。リズムが定着してからのみ追加します。
ロックスの膨張1人あたり12個のロックス厳格な上限は、1人あたり7個、会社全体で7個です。
リーダーの不履行リーダーシップがL10を欠席したり、IDSを無視したりするOSはリーダーシップの姿勢を映し出します。リーダーが率先しましょう。
四半期レビューがない年間目標を年末に確認するレビューサイクルは最低でも四半期ごとにする必要があります。
目標値のないスコアカードしきい値を設けずに数値を追跡するすべての指標に、実行可能な目標値が必要です。

危険信号

  • 「会社の最優先事項を3つ挙げると何ですか?」と聞くと、5人のチームリーダーから異なる回答が返ってくる――連携不足
  • 同じ課題が4週間以上、課題リストに残っている――回避、または構造的な問題
  • 週次スコアカードがない――状況を把握できていない
  • ロックスを設定しても週次で見直さない――アカウンタビリティのない目標
  • アカウンタビリティチャートが6か月以上更新されていない――現実とのずれが生じている
  • ミーティングが決定事項のないまま終わることが常態化している――ミーティング設計の問題
  • コミュニケーションが常にトップダウンで、ボトムアップがない――フィードバックループが機能していない

経営幹部との連携

役割OSとの連携
CEO(ceo-advisor)1年計画とロックスにつながるビジョンを設定する
COO(coo-advisor)ミーティングの進行サイクルと課題解決のリズムを担当する
CFO(cfo-advisor)スコアカードの財務指標を担当する
CTO(cto-advisor)エンジニアリングのロックスと技術スコアカードの指標を担当する
CHRO(chro-advisor)人材指標(離職率、採用スピード)を担当する
Culture Architect(culture-architect)企業文化の慣習をミーティングの進行サイクルに組み込む
Strategic Alignment(strategic-alignment)チームのロックスが会社のロックスから展開されていることを検証する
Change Management(change-management)新しいOSの展開にADKARモデルを適用する

出力成果物

リクエスト成果物
「当社のオペレーティングシステムを整備してください」フレームワークの推奨 + 30日間の導入計画
「ミーティングのリズムを設計してください」アジェンダと担当者を含む完全なミーティングリズム
「スコアカードを作成してください」担当者、目標値、しきい値を含む5〜15個の指標
「四半期計画を支援してください」計画セッションのアジェンダ + ロックス設定のフレームワーク
「アカウンタビリティを改善してください」アカウンタビリティチャートのワークショップ + ギャップ/重複分析
「同じ課題について何度も話し合っています」IDSトレーニング + 課題リストの監査

ツールリファレンス

scorecard_builder.py

RAGステータス、トレンド分析、L10ミーティング向けのIDS対応課題リストを備えた、週次の会社スコアカードを作成・追跡します。

# Run with demo data
python scripts/scorecard_builder.py

# From JSON with metrics and rocks
python scripts/scorecard_builder.py --input scorecard.json

# JSON output
python scripts/scorecard_builder.py --json
rocks_tracker.py

二値のステータス、ブロッカーの特定、担当者のアカウンタビリティを用いて、会社および個人の90日間のロックスを追跡します。

# Run with demo data
python scripts/rocks_tracker.py

# Specify quarter
python scripts/rocks_tracker.py --quarter Q2

# From JSON
python scripts/rocks_tracker.py --input rocks.json

# JSON output
python scripts/rocks_tracker.py --json
meeting_pulse_designer.py

会社のミーティングリズムを設計し、ミーティングの負荷を検証し、重複や不足を特定して、L10アジェンダのテンプレートを生成します。

# Run with demo meetings
python scripts/meeting_pulse_designer.py

# Specify team size
python scripts/meeting_pulse_designer.py --team-size 50

# From JSON with current meetings
python scripts/meeting_pulse_designer.py --input meetings.json

# JSON output
python scripts/meeting_pulse_designer.py --json

トラブルシューティング

問題考えられる原因解決策
5人のチームリーダーが、最優先事項のトップ3についてそれぞれ異なる回答をする目標の連携に失敗しています。rocks が展開されていない、または毎週レビューされていません四半期計画をやり直します。L10 で rocks を毎週レビューし、会社の優先事項を見える形で周知します
課題リストに同じ課題が4週間以上残っている回避している、または対処が怖い構造的な問題です強制的に対処します。今週対処するか、恒久的に削除します。必要に応じてエスカレーションします
スコアカードに KPI が30個以上ある指標が過剰で、何にも注意が向きません指標を5~10個に絞ります。会社が計画どおりに進んでいるかを把握できるものだけにします
rocks を設定したものの、一度もレビューされない説明責任のない目標です。L10 ミーティングが実施されていません毎週の L10 は必須です。毎週、rocks のレビューに5分を割きます
リーダーシップチームが L10 を欠席する、または IDS を無視するリーダーが従わないと、OS が機能しなくなりますCEO が徹底させる必要があります。まずリーダーが率先します。CEO が欠席すれば、OS は機能しなくなります
既存のミーティングに加えて、さらにミーティングが追加されるミーティングの積み重ねによる疲労ですミーティングは追加せず、置き換えます。ミーティングの一覧を確認し、重複をなくします

成功基準

  • 毎週 L10 ミーティングを実施し、リーダーシップチームの出席率が90%以上である(12週以上連続して例外なし)
  • スコアカードを毎週レビューし、赤色の指標を IDS 形式で話し合う(無視される赤色の指標がゼロ)
  • 四半期の rocks の70%以上を、四半期末までに完了/未完了の二択で完了する
  • 課題リスト:課題が平均2回のミーティング以内に解決される(4週間以上残る課題がない)
  • すべてのチームリーダーが、会社の最優先事項のトップ3を同じ内容で説明できる(四半期ごとに確認)
  • 1人あたりの週のミーティング時間が10時間未満である(meeting_pulse_designer.py で測定)
  • 説明責任チャートを四半期ごとにレビュー・更新し、担当者のいない機能がゼロである

対象範囲と制限事項

対象範囲:オペレーティングシステムの選定(EOS、Scaling Up、OKR、Holacracy)、説明責任チャート、週次スコアカード、ミーティングパルスの設計、IDS による課題解決、90日間の rocks、コミュニケーションの頻度、導入ロードマップ。

対象範囲外:OKR ソフトウェアの設定、プロジェクト管理ツールのセットアップ、アジャイル/スクラム手法、スプリント計画、製品バックログ管理、人事ポリシーの策定。

制限事項:スコアカードビルダーは、提供されたデータから RAG を算出しますが、業務システムからリアルタイムの指標を取得することはできません。rocks トラッカーではステータスを手動で更新する必要があり、完了を自動的に検知することはできません。ミーティングパルスデザイナーは、チームの規模とミーティング一覧に基づいて推奨事項を提示しますが、会社固有の文化的規範は考慮できません。フレームワークの比較は方向性を示すものであり、実際の導入の成否はリーダーシップの取り組みによって決まります。


連携ポイント

スキル連携内容
ceo-advisorCEO がビジョンを設定し、それが1年計画と rocks に反映されます
coo-advisorミーティングパルスと課題解決の頻度を担当します
cfo-advisor週次スコアカードに財務指標を含めます
cto-advisorエンジニアリングの rocks と技術スコアカードの指標を担当します
chro-advisorスコアカードに人事指標(離職率、採用のスピード)を含めます
culture-architect文化的な儀式をミーティングパルスに組み込みます
strategic-alignmentチームの rocks が会社の rocks から展開されていることを確認します
change-management新しい OS の導入では、定着に向けて ADKAR モデルに従います
chief-of-staff四半期計画セッションと L10 のフォローアップを調整します

コメント