フレームワーク活用ガイドひとことで言うと#
チームメンバーの稼働可能時間と各プロジェクトへの配分を一覧表にまとめ、誰がどれだけ空いているか、誰が過負荷かを一目で把握するリソース管理ツール。
押さえておきたい用語#
- キャパシティ（Capacity）
- メンバーが業務に使える総稼働時間。一般的には月の営業日数 × 1日の稼働時間から算出する。
- アロケーション（Allocation）
- メンバーのキャパシティを各プロジェクトにどの割合で配分するかを示す数値。100%配分＝そのPJ専任。
- 稼働率（Utilization Rate）
- キャパシティに対するアロケーション済み時間の割合。80%前後 が健全とされ、100%超は過負荷のサイン。
- バッファ（Buffer）
- 突発対応や管理業務に充てる未配分の余白時間を指す。通常はキャパシティの15〜20%を確保する。
リソースキャパシティ・マトリクスの全体像#
こんな悩みに効く#
- 誰が暇で誰が忙しいのか、マネージャーも把握できていない
- 新しいプロジェクトが始まるとき、誰をアサインすべきか判断できない
- 特定のメンバーに業務が集中し、燃え尽きが発生している
基本の使い方#
具体例#
従業員50名のBtoB SaaS企業。開発チーム8名が3つのプロジェクトを掛け持ちしていたが、「誰が何にどれだけ使っているか」が見えず、スプリントの計画精度が低かった。
スプレッドシートでリソースキャパシティ・マトリクスを作成した結果、8名中 3名 が稼働率 110〜130% に達していることが判明。一方で 2名 は 50% 未満だった。
| 調整内容 | 効果 |
|---|---|
| 過負荷の3名から2タスクを余裕のある2名に移管 | 稼働率が全員 75〜95% の範囲に |
| スプリント計画で実効キャパシティを使用 | 計画達成率が 62%→88% に改善 |
| 週次レビューを15分で実施 | 過負荷の早期発見が可能に |
3か月後にはチーム全体のベロシティが 22%向上 した。
従業員200名のコンサルファーム。15の同時進行プロジェクトに対してコンサルタント80名を配分しているが、PMOが全体の稼働状況を把握できていなかった。
ExcelベースのマトリクスからAsanaのリソース管理機能に移行。全80名×15PJの配分を可視化した。
問題が見つかったのは以下の3点。
- シニアコンサルタント5名が 120%以上 の配分になっていた
- ジュニア層12名が 40%以下 で「待ち」状態だった
- 2つのPJが同じメンバー4名に依存しており、片方が遅延するともう片方も止まる構造だった
PMOが四半期ごとのリソースレビューを月次に変更し、シニアのタスクをジュニアに段階的に移管。1年後にはプロジェクト利益率が 4ポイント改善 し、コンサルタントの離職率も 18%→11% に低下した。
職員350名の地方自治体。企画課の職員12名が通常業務に加えて横断プロジェクト（DX推進・地方創生・防災計画見直し）を兼務していたが、「忙しい人は常に忙しく、手が空いている人は暇」という状態が続いていた。
課長がホワイトボードにリソースキャパシティ・マトリクスを手書きで作成。全12名×4業務（通常+PJ3本）の配分を % で可視化。
すると、DX推進の主担当2名が稼働率 140% であることが判明。通常業務の 30% を他のメンバーに再配分し、DX推進のサブ担当を1名追加した。結果、DX推進のマイルストーン遅延が 月2回→0回 に改善されている。
やりがちな失敗パターン#
| パターン | 何が起きるか | 対策 |
|---|---|---|
| 100%配分を前提にする | 会議や突発対応の余白がなく、常にオーバーフローする | 実効キャパシティを80%で計算し、20%をバッファにする |
| 作って終わりで更新しない | 実態とマトリクスが乖離し、誰も信用しなくなる | 週次15分のレビューをカレンダーに固定する |
| 自己申告だけに頼る | 忙しい人ほど「大丈夫です」と言い、実態が見えない | タイムトラッキングの実績データと突合する |
| アロケーションの粒度が粗い | 「50%配分」だが実際は週によって0%〜100%で振れる | 月単位ではなく週単位でアロケーションを管理する |
まとめ#
リソースキャパシティ・マトリクスは、メンバーの稼働可能時間とプロジェクトへの配分を一覧にまとめ、過負荷と余裕を可視化するツール。作成自体は簡単で、スプレッドシート1枚から始められる。最も重要なのは週次レビューで更新し続けること。見える化するだけで、リソース問題の大半は解決の糸口が見つかる。