ひとことで言うと#
チームの運営に必要な意思決定・情報共有・目標管理・振り返り・コミュニケーションのルールを一貫したシステムとして設計する手法。PCにOSが必要なように、チームにも「基本動作の仕組み」が必要であり、それを明示的に設計・運用する。
押さえておきたい用語#
- チームOS
- チームの日常運営を支える意思決定・会議・情報共有・評価・振り返りの一連の仕組みを体系化したもの。
- ケイデンス
- 定期的に繰り返すミーティングやイベントのリズム。日次・週次・月次・四半期のサイクルで構成される。
- ワーキングアグリーメント
- チーム内で合意した日常の行動ルール。コミュニケーション手段、レスポンス速度、会議のマナーなどを含む。
- 可視化ボード
- チームの目標・進捗・課題を一目で把握できるダッシュボード。物理的なホワイトボードまたはデジタルツールで管理する。
チームOSの全体像#
こんな悩みに効く#
- リーダーが不在のときにチームの動き方がわからなくなる
- 「うちのチームはどう運営されているか」を新メンバーに説明できない
- 会議・情報共有・意思決定がバラバラで一貫性がない
基本の使い方#
現在のチーム運営を5要素に沿って書き出し、足りている要素と足りていない要素を把握する。
| 要素 | 確認ポイント |
|---|---|
| 意思決定 | 誰が何を決めるか明確か。エスカレーション基準はあるか |
| ケイデンス | 定例会議のリズムは整っているか。目的は明確か |
| 目標管理 | チーム目標は設定されているか。進捗の測り方はあるか |
| 情報共有 | ツールは統一されているか。情報の非対称性はないか |
| 振り返り | 定期的にやり方を改善する場があるか |
5要素を1ページのドキュメントにまとめる。チーム全員がいつでも参照できる場所に置く。
- 意思決定マトリクス(RACI等)
- ケイデンス一覧(日次/週次/月次/四半期の定例)
- 目標と進捗の管理方法
- ツールの使い分けルール
- 振り返りの頻度とフォーマット
チームOSは一度作って終わりではない。月次のレトロスペクティブで「OSに不便な点はないか」を議題に入れる。
- 「この会議は不要」「このツールは使いにくい」はOSの改善提案として扱う
- メンバーの入れ替え・プロジェクトの変化に合わせてバージョンアップする
- 「v1.0 → v1.1」のようにバージョン管理すると変遷が見える
具体例#
状況: 8名の開発チーム。チームリーダーが休職した際、意思決定・会議運営・進捗管理のすべてが止まり、3週間 ほぼ機能しなかった。「リーダーの頭の中にしかルールがない」状態だった。
チームOSの設計
- 意思決定: 技術判断はテックリード、ビジネス判断はPM、日常運営はメンバーの合議
- ケイデンス: デイリー15分/週次レビュー45分/隔週レトロ60分/四半期OKRレビュー3時間
- 目標管理: OKRをNotionで管理。週次レビューで進捗率を更新
- 情報共有: Slack(即時)+ Notion(ストック)+ 週次レビュー(同期)
- 振り返り: 隔週KPTでプロセス改善
| 指標 | OS導入前 | OS導入6か月後 |
|---|---|---|
| リーダー不在時の生産性低下 | 80%低下 | 15%低下 |
| 新メンバーのオンボーディング | 平均4週間 | 平均2週間 |
| スプリント完了率 | 60% | 78% |
OSドキュメントを見れば「このチームがどう動いているか」がわかるため、新メンバーの立ち上がりも大幅に加速した。
状況: 経営コンサルティング会社の営業チーム(6名)。各自が独自のスプレッドシートで案件を管理しており、「全体のパイプラインが見えない」「フォロー漏れに気づくのが月末」という状態。マネージャーは毎週 3時間 かけて各自のシートを集計していた。
チームOSの構築
- 目標管理: 四半期の売上目標をチームOKRに設定。週次で進捗率を共有
- 情報共有: Salesforceに一元化。案件ステージ・金額・次アクションを全員が入力
- ケイデンス: 月曜朝30分のパイプラインレビュー。金曜15分のウィンレポート(成約報告)
- 意思決定: 500万円以下はメンバー裁量、500万円超はマネージャーと相談
- 振り返り: 月末に失注分析会(60分)
マネージャーの集計作業は週 3時間 → 0時間(ダッシュボードで自動可視化)。フォロー漏れは月 5件 → 0件 に。四半期の売上は前年同期比 118% を達成した。
状況: 子ども食堂を運営するNPO(常勤2名・ボランティア15名)。ボランティアの参加が不定期で、「今日誰が来るかわからない」「食材の準備量が読めない」「引き継ぎがなく毎回ゼロからスタート」。年間のボランティア離脱率が 50%。
チームOSの導入
- ケイデンス: 週1回のLINEグループで翌週のシフト確認。月1回の全体ミーティング(30分)
- 情報共有: Googleスプレッドシートに「作業マニュアル」「食材在庫」「当日の役割分担」を一元化
- 意思決定: メニューは常勤スタッフが決定。当日のオペレーション判断はその日のリーダー(持ち回り)
- 振り返り: 月1回の全体ミーティングで「良かったこと・改善したいこと」を共有
ボランティアの年間離脱率は 50% → 22% に改善。「来るたびにやることが明確で、安心して参加できるようになった」という声が複数のボランティアから上がっている。
やりがちな失敗パターン#
- OSを複雑に設計しすぎる — ルールが20個以上あると誰も覚えない。最初は5〜7個のルールに絞り、必要に応じて追加する
- ツールを決めただけで運用ルールを決めない — Slackを導入しても「何をどのチャンネルに投稿するか」が曖昧だと混乱する。ツール+運用ルールのセットが必要
- 振り返りでOSを改善しない — OSは最初から完璧にはならない。使ってみて不便な点を改善し続けることが、チームの成長そのもの
- リーダーだけがOSを理解している — OSの意味がなくなる。全メンバーがOSの内容を理解し、自分たちで運用できる状態を目指す
まとめ#
チームOSは「意思決定・ケイデンス・目標管理・情報共有・振り返り」の5要素で構成される、チーム運営の基盤になる。属人的な運営から仕組みによる運営に移行することで、リーダー不在でも動けるチームが作れる。最初はシンプルに始め、振り返りを通じてOSそのものをバージョンアップし続けることが持続的な効果を生む。