company-os について
会社の運営システムを明確にし、改善するためのスキルです。創業者や経営チームが EOS、Scaling Up、OKR、Holacracy などを選び、役割、指標、会議、優先事項、課題解決の仕組みを整えます。
主な機能
- 01EOS、Scaling Up、OKR、Holacracyの比較
- 02責任分担表とスコアカードの設計
- 03会議とコミュニケーションの周期設定
- 04IDSによる課題解決の構成
- 0590日間の優先事項と導入計画
活用シーン
- 01会社に合う運営フレームワークの選定
- 02各機能の責任者の明確化
- 03週次指標レビューの作成
- 04四半期の優先事項と会議周期の設定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill company-osインストール後、Claude Code で/company-osを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
scripts/meeting_pulse_designer.pyrocks_tracker.pyscorecard_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.
フレームワーク比較表
| 特徴 | EOS | Scaling Up | OKR ネイティブ | Holacracy |
|---|---|---|---|---|
| 複雑さ | 低 | 中 | 中 | 高 |
| 導入期間 | 30-90 日 | 90-180 日 | 60-120 日 | 6-12 か月 |
| 最適な会社規模 | 10-250 | 50-500 | 20-500 | 50-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 個を超えると、何にも注意が向かなくなります |
| 各指標に担当者を設定する | オーナーシップがアカウンタビリティを促します |
| 各指標に週次目標を設定する | 範囲ではなく、具体的な数値を設定します |
| 赤/黄/緑のステータス | 段落ではなく、信号機のように表示します |
| 議論するのは赤の指標だけ | 緑なら、会議で議論する必要はありません |
スコアカードの例
| 指標 | 担当者 | 目標 | 週次 | ステータス |
|---|---|---|---|---|
| 新規MRR | CRO | $50K | $43K | [R] |
| ロゴチャーン | CS Lead | < 1% | 0.8% | [G] |
| アクティブユーザー | CPO | 2,000 | 2,150 | [G] |
| デプロイ | CTO | 3/week | 3 | [G] |
| 未解決の重大バグ | CTO | 0 | 2 | [R] |
| ランウェイ | CFO | > 18mo | 16mo | [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-advisor | CEO がビジョンを設定し、それが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 のフォローアップを調整します |