チームOS

英語名 Team Operating System
読み方 チーム オペレーティング システム
難易度
所要時間 設計2〜4時間
提唱者 チーム運営・アジャイルのベストプラクティス
目次

ひとことで言うと
#

チームの運営に必要な意思決定・情報共有・目標管理・振り返り・コミュニケーションのルールを一貫したシステムとして設計する手法。PCにOSが必要なように、チームにも「基本動作の仕組み」が必要であり、それを明示的に設計・運用する。

押さえておきたい用語
#

押さえておきたい用語
チームOS
チームの日常運営を支える意思決定・会議・情報共有・評価・振り返りの一連の仕組みを体系化したもの。
ケイデンス
定期的に繰り返すミーティングやイベントのリズム。日次・週次・月次・四半期のサイクルで構成される。
ワーキングアグリーメント
チーム内で合意した日常の行動ルール。コミュニケーション手段、レスポンス速度、会議のマナーなどを含む。
可視化ボード
チームの目標・進捗・課題を一目で把握できるダッシュボード。物理的なホワイトボードまたはデジタルツールで管理する。

チームOSの全体像
#

チームOSの5つの構成要素
チームOS意思決定ルール誰が・どう決めるかケイデンス日次〜四半期のリズム情報共有・可視化ダッシュボード・ツール振り返り・改善レトロ・KPTで進化する目標管理OKR・KPI・チーム目標5つの要素が連動して、チームの基本動作を支える
チームOS設計フロー
1
現状棚卸し
現在の運営ルールを5要素で洗い出す
2
設計
不足している要素を補い、一貫性のあるOSを設計する
3
運用開始
チーム全員で合意し、2〜4週間試行する
OS自体を改善
振り返りでOSそのものをアップデートし続ける

こんな悩みに効く
#

  • リーダーが不在のときにチームの動き方がわからなくなる
  • 「うちのチームはどう運営されているか」を新メンバーに説明できない
  • 会議・情報共有・意思決定がバラバラで一貫性がない

基本の使い方
#

5つの構成要素を棚卸しする

現在のチーム運営を5要素に沿って書き出し、足りている要素と足りていない要素を把握する。

要素確認ポイント
意思決定誰が何を決めるか明確か。エスカレーション基準はあるか
ケイデンス定例会議のリズムは整っているか。目的は明確か
目標管理チーム目標は設定されているか。進捗の測り方はあるか
情報共有ツールは統一されているか。情報の非対称性はないか
振り返り定期的にやり方を改善する場があるか
チームOSを一枚にまとめる

5要素を1ページのドキュメントにまとめる。チーム全員がいつでも参照できる場所に置く。

  • 意思決定マトリクス(RACI等)
  • ケイデンス一覧(日次/週次/月次/四半期の定例)
  • 目標と進捗の管理方法
  • ツールの使い分けルール
  • 振り返りの頻度とフォーマット
振り返りでOSそのものを進化させる

チームOSは一度作って終わりではない。月次のレトロスペクティブで「OSに不便な点はないか」を議題に入れる。

  • 「この会議は不要」「このツールは使いにくい」はOSの改善提案として扱う
  • メンバーの入れ替え・プロジェクトの変化に合わせてバージョンアップする
  • 「v1.0 → v1.1」のようにバージョン管理すると変遷が見える

具体例
#

例1:SaaS開発チームがチームOSで属人運営から脱却する

状況: 8名の開発チーム。チームリーダーが休職した際、意思決定・会議運営・進捗管理のすべてが止まり、3週間 ほぼ機能しなかった。「リーダーの頭の中にしかルールがない」状態だった。

チームOSの設計

  • 意思決定: 技術判断はテックリード、ビジネス判断はPM、日常運営はメンバーの合議
  • ケイデンス: デイリー15分/週次レビュー45分/隔週レトロ60分/四半期OKRレビュー3時間
  • 目標管理: OKRをNotionで管理。週次レビューで進捗率を更新
  • 情報共有: Slack(即時)+ Notion(ストック)+ 週次レビュー(同期)
  • 振り返り: 隔週KPTでプロセス改善
指標OS導入前OS導入6か月後
リーダー不在時の生産性低下80%低下15%低下
新メンバーのオンボーディング平均4週間平均2週間
スプリント完了率60%78%

OSドキュメントを見れば「このチームがどう動いているか」がわかるため、新メンバーの立ち上がりも大幅に加速した。

例2:コンサル会社の営業チームが案件管理のOSを統一する

状況: 経営コンサルティング会社の営業チーム(6名)。各自が独自のスプレッドシートで案件を管理しており、「全体のパイプラインが見えない」「フォロー漏れに気づくのが月末」という状態。マネージャーは毎週 3時間 かけて各自のシートを集計していた。

チームOSの構築

  • 目標管理: 四半期の売上目標をチームOKRに設定。週次で進捗率を共有
  • 情報共有: Salesforceに一元化。案件ステージ・金額・次アクションを全員が入力
  • ケイデンス: 月曜朝30分のパイプラインレビュー。金曜15分のウィンレポート(成約報告)
  • 意思決定: 500万円以下はメンバー裁量、500万円超はマネージャーと相談
  • 振り返り: 月末に失注分析会(60分)

マネージャーの集計作業は週 3時間 → 0時間(ダッシュボードで自動可視化)。フォロー漏れは月 5件 → 0件 に。四半期の売上は前年同期比 118% を達成した。

例3:NPOが少人数チームの運営を仕組み化してボランティアの離脱を防ぐ

状況: 子ども食堂を運営するNPO(常勤2名・ボランティア15名)。ボランティアの参加が不定期で、「今日誰が来るかわからない」「食材の準備量が読めない」「引き継ぎがなく毎回ゼロからスタート」。年間のボランティア離脱率が 50%

チームOSの導入

  • ケイデンス: 週1回のLINEグループで翌週のシフト確認。月1回の全体ミーティング(30分)
  • 情報共有: Googleスプレッドシートに「作業マニュアル」「食材在庫」「当日の役割分担」を一元化
  • 意思決定: メニューは常勤スタッフが決定。当日のオペレーション判断はその日のリーダー(持ち回り)
  • 振り返り: 月1回の全体ミーティングで「良かったこと・改善したいこと」を共有

ボランティアの年間離脱率は 50% → 22% に改善。「来るたびにやることが明確で、安心して参加できるようになった」という声が複数のボランティアから上がっている。

やりがちな失敗パターン
#

  1. OSを複雑に設計しすぎる — ルールが20個以上あると誰も覚えない。最初は5〜7個のルールに絞り、必要に応じて追加する
  2. ツールを決めただけで運用ルールを決めない — Slackを導入しても「何をどのチャンネルに投稿するか」が曖昧だと混乱する。ツール+運用ルールのセットが必要
  3. 振り返りでOSを改善しない — OSは最初から完璧にはならない。使ってみて不便な点を改善し続けることが、チームの成長そのもの
  4. リーダーだけがOSを理解している — OSの意味がなくなる。全メンバーがOSの内容を理解し、自分たちで運用できる状態を目指す

まとめ
#

チームOSは「意思決定・ケイデンス・目標管理・情報共有・振り返り」の5要素で構成される、チーム運営の基盤になる。属人的な運営から仕組みによる運営に移行することで、リーダー不在でも動けるチームが作れる。最初はシンプルに始め、振り返りを通じてOSそのものをバージョンアップし続けることが持続的な効果を生む。