ひとことで言うと#
チームが抱える課題に応じて適切なワークショップ(「プレイ」と呼ぶ)を選び、ファシリテーションガイドに沿って実行することで、チームの健全性を継続的に改善するフレームワーク。Atlassian(Jira/Confluenceの開発元)が自社の実践をもとに体系化し、無料で公開している。
押さえておきたい用語#
- Play(プレイ)
- 特定のチーム課題に対応した構造化されたワークショップのこと。Team Playbookには20以上のプレイが用意されている。
- Health Monitor(ヘルスモニター)
- チームの健全性を8つの属性で定期的に診断するツール。信号機(緑/黄/赤)で状態を可視化し、改善すべき領域を特定する。
- DACI
- **Driver(推進者)・Approver(承認者)・Contributor(貢献者)・Informed(報告先)**の頭文字。意思決定の役割を明確にするプレイの一つ。
- チームポスター
- チームの目的・メンバーの役割・働き方のルールを1枚にまとめたドキュメント。チーム結成時に作成する。
Team Playbookの全体像#
こんな悩みに効く#
- チームに問題があるのはわかっているが、何から手をつけていいかわからない
- レトロスペクティブがマンネリ化して、改善が進まない
- チームの状態を客観的に把握する方法がない
基本の使い方#
8つの属性(方向性、価値とメトリクス、役割の明確さ、意思決定、依存関係の管理、速度、心理的安全性、チームの一体感)をチーム全員で評価する。
- 各属性を緑(良好)/ 黄(改善の余地あり)/ 赤(深刻な問題)で判定
- 全員が投票し、結果を共有する。リーダーだけの判断にしない
- 赤と黄の属性から、優先的に取り組む課題を1〜2つ選ぶ
Playbookから課題に対応するプレイを選び、ファシリテーションガイドに沿って実施する。
- 方向性が不明確 → チームポスター / エレベーターピッチ
- 意思決定が遅い → DACI / トレードオフスライダー
- 信頼関係が弱い → ロール&責任 / ユーザーマニュアル(自分の取扱説明書)
- 1回のプレイは 30分〜2時間。月1〜2回のペースで継続する
プレイの実施後、変化があったかどうかを次のHealth Monitorで確認する。
- 2〜4週間後に同じ属性を再評価し、色が改善したか確認
- 改善しなかった場合は、別のプレイを試すか、アプローチを変える
- 四半期に1回 のHealth Monitorを習慣化する
具体例#
Atlassianは従業員 12,000名超 の組織で、Team Playbookを全チームに推奨している。社内の 1,000以上のチーム がHealth Monitorを定期実施し、プレイの実行記録を社内Wikiに蓄積している。
特に効果が高いとされたプレイ:
| プレイ | 所要時間 | 効果 |
|---|---|---|
| Health Monitor | 60分 | チーム状態の可視化。92%のチームが「有用」と回答 |
| DACI | 45分 | 意思決定速度が平均 40% 向上 |
| チームポスター | 90分 | 新チーム立ち上げ時の方向性共有が 2週間 短縮 |
| レトロスペクティブ | 60分 | スプリントの改善サイクルが定着 |
Atlassianの調査では、Health Monitorを四半期ごとに実施しているチームは、そうでないチームに比べてプロジェクトの成功率が27%高いという結果が出ている。
このPlaybookは2016年に無料公開され、世界中で数万のチームが利用している。
横浜のSaaS企業(従業員70名)の開発チーム(12名)は、機能のリリース判断に毎回 5日以上 かかっていた。Health Monitorを実施したところ、「意思決定」の属性が全員一致で赤判定。
DACIプレイを実施し、各種判断の役割を明確化した。
| 判断事項 | Driver | Approver | Contributor | Informed |
|---|---|---|---|---|
| 機能リリース | PM | テックリード | QA, デザイナー | 営業, CS |
| 技術選定 | テックリード | CTO | エンジニア全員 | PM |
| デザイン変更 | デザイナー | PM | エンジニア | 営業 |
DACI導入後、リリース判断にかかる時間は 5日 → 1.5日 に短縮。「誰に聞けばいいか」が明確になったことで、「念のため全員に確認する」という無駄な合意形成がなくなった。
3ヶ月後のHealth Monitorでは、「意思決定」が赤から 緑 に改善。
東京・福岡・バンコクの3拠点にまたがるリモートチーム(9名)は、表面上はうまく回っていた。プロジェクトは納期通りに進み、大きなトラブルもない。しかしマネージャーは「何か引っかかる」と感じていた。
Health Monitorを初めて実施したところ、意外な結果が出た。
| 属性 | 結果 | 具体的な声 |
|---|---|---|
| 方向性 | 緑 | 目標は明確 |
| 速度 | 緑 | 納期は守れている |
| 心理的安全性 | 赤 | 「バンコクメンバーが質問しにくいと感じている」 |
| チームの一体感 | 赤 | 「拠点間の雑談がゼロ。仕事の話しかしない」 |
この結果を受けて2つのプレイを実施:
- ユーザーマニュアル: 各メンバーが「自分の働き方の取扱説明書」を作成し共有。バンコクメンバーの「朝は集中したいので午後にミーティングを入れてほしい」という要望が初めて共有された
- スパークラー: 15分間の非業務雑談タイムを週2回導入
2ヶ月後のHealth Monitorで、心理的安全性は赤から 黄、チームの一体感は赤から 黄 に改善。バンコクメンバーからの質問・提案が月 3件 → 14件 に増えた。
やりがちな失敗パターン#
- Health Monitorをやって終わる — 診断だけして改善プレイを実行しないパターン。診断は「入口」であって「出口」ではない
- プレイを形だけ実行する — ガイドの手順を追うだけで、チームの本音が出てこない。ファシリテーターが「なぜそう思うか」を丁寧に掘り下げる必要がある
- リーダーだけが診断する — Health Monitorは全員参加が前提。リーダーが「うちは緑」と思っていても、メンバーは「赤」と感じていることは多い
- 毎週プレイをやりすぎる — プレイの効果が出るには時間が必要。月1〜2回のペースで、前回のプレイの効果を確認してから次に進む
- Playbookに載っていないことはやらない — Playbookはテンプレートであり、チームに合わせてカスタマイズしてよい。自チームならではのプレイを開発するのも有効
まとめ#
Atlassian Team Playbookは、Health Monitorでチームの課題を特定し、対応するプレイ(ワークショップ)を実行して継続的に改善するフレームワーク。Atlassianが1,000以上の自社チームで磨き上げた実践知が詰まっており、無料で公開されている。最大の価値は「チームの問題を見える化し、具体的なアクションに落とし込む」ところまでガイドしてくれる点にある。