スプレッドシート地獄なしのキャパシティプランニング

多くのキャパシティプランは人数からスタートします。チームにエンジニアが6名いれば、6名分のリソースがSprint全体で使えると想定し、6名分の作業量をコミットします。

しかしSprint終了時に、計画した作業の40%が完了しないことがよくあります。「想定外のブロッカー」や「複雑さの見積もり不足」という言葉でその場を乗り越え、次のSprintも同じ6名で、同じく楽観的なコミットメントから始まります。

本質的な問題は、見積もりの精度でもチームのベロシティでもありません。キャパシティプランニングが時間ではなく人数を数えていることです。実際の稼働可能時間、会議や割り込みが入り込む現実の時間は、人数とは大きく異なります。

週に12時間を会議、2時間をStandup、3時間をレビュー、2時間を突発的な割り込みに使っているエンジニア6名のチームがあるとすれば、実際の作業時間は1人あたり週約20時間です。40時間でも30時間でもなく、20時間です。さらに、その20時間の100%を計画に使うと、現実の作業を予測困難にする変動要素を無視することになります。Atlassian「State of Teams」調査によると、ナレッジワーカーは平均週31時間を非生産的な会議に費やしており、多くのSprintプランが想定するdep workのキャパシティは実態よりはるかに少ないことが示されています。

解決策は、より高度なスプレッドシートではありません。実際に稼働可能な時間を正直に把握することです。会議の棚卸しで会議時間を実際に集計すると、実際の作業時間が常に想定より少ないという事実が浮かび上がります。

実際にキャパシティを奪う隠れた時間

キャパシティを正確に計画するには、まず時間が実際にどこへ消えているかを把握する必要があります。この確認をしたことがない多くのマネージャーは、結果に驚きます。

多くのキャパシティプランが見落としているカテゴリを以下に挙げます。

定例会議。 各チームメンバーのカレンダーにある、プロジェクト作業以外のすべての会議を数えてください。Standup、チーム同期、全社ミーティング、1:1、スキップレベル、パートナーチームの会議、計画会議、レビュー会議。ナレッジワーカーの多くにとって、これだけで週8〜15時間に達します。Sprint中にアドホックに入る会議はこれに含みません。

オンコールと割り込みローテーション。 オンコール担当があるチームでは、「オフコール」のSprintでも常時バックグラウンドの割り込み負荷があります。誰かが常にキューを確認し、インシデントのポストモーテムに引き込まれます。

レビューとフィードバックのサイクル。 コードレビュー、デザインレビュー、ドキュメントへのフィードバック。これらは実際の作業ですが、「オーバーヘッド」として処理され、明示的に追跡されないことが多いです。シニアエンジニアやリードにとって、レビュー負荷は週4〜6時間に達することがあります。

管理業務のオーバーヘッド。 チケットのグルーミング、プロジェクトの進捗更新、ツールのメンテナンス、コンプライアンスレビュー。地味な作業のため、過小評価されがちです。

マネージャーの時間。 プレイングマネージャーとして週40時間のプロジェクト作業ができると計画しているなら、慢性的なオーバーコミットが発生します。1:1、チームマネジメント業務、クロスファンクショナルな調整はプロジェクト作業ではありません。オーバーヘッドの計算に含める必要があります。

パートタイムや分割役割のメンバー。 誰かが時間の50%を別チームや別の役割に使っているなら、そのメンバーを100%のキャパシティで計画すると、2週間ごとに50%の未達が生まれます。

このチェックをチームで1回実施するだけで、計画の立て方が変わります。数字は想定よりほぼ必ず厳しい現実を示します。

20%バッファルール

既知のオーバーヘッドをすべて考慮した後でも、計画が立てにくい予測不可能な作業カテゴリがあります。

予測不可能なことはさまざまな形で現れます。他の作業を止める重大なバグ、2時間の分析につながるステークホルダーからの質問、重要な成果物を完成させる予定だったメンバーの急な欠席、想定と異なる形で解決される依存関係による手戻り。

これらのどれが特定のSprintで起きるかは予測できません。ただし、何かは起きると予測できます。年間を通じた複数のSprintで、計画外の作業は一貫してチームキャパシティの15〜25%を吸収します。

20%バッファは悲観論ではありません。経験則です。McKinseyのアジャイルデリバリーチームに関する調査によると、高パフォーマンスのチームは稼働可能キャパシティの75〜80%を計画しており、バッファを適用するチームはそうでないチームに比べてSprint完了率が35〜40%高いことが示されています。バッファを組み込まない場合も計画外の作業は発生しますが、その分は予定作業を置き換えることになります。Sprint完了率が下がり、チームのベロシティ問題として語られますが、真の原因はキャパシティを100%で計画したことです。

実際には、20%バッファの適用とは次のことを意味します。実際の稼働可能時間（会議とオーバーヘッドを差し引いた後）から、コミットする作業量を20%削減します。チームの稼働可能時間がオーバーヘッド後に120時間なら、96時間分の作業をコミットし、残りの24時間を計画外キャパシティとして残します。

3カラム形式

各メンバーの実際の稼働可能時間が明確になれば、キャパシティプランニングの形式自体は複雑にする必要はありません。Sprint規模の計画には、3カラムのビューで十分です。

稼働可能時間 = Sprint内の総労働時間 - 会議オーバーヘッド - バッファ（20%）

コミット作業 = このメンバーがSprintに持ち込む具体的な項目（個別の時間見積もり付き）。合計が稼働可能時間を超えないこと。

カラムの比較により、オーバーアロケーションが即座に可視化されます。コミット作業のカラムが合計40時間で、稼働可能時間のカラムが18時間を示している場合、Sprint開始前に対話すべきことがあります。Sprint終了後に原因を調べる謎にする必要はありません。

Sprint開始時のキャパシティ確認

キャパシティプランニングが最も頻繁に失敗する場所はタイミングです。チームは四半期計画でキャパシティを確認し、ロードマップにコミットしてから、各Sprintの開始時には稼働可能時間を再確認せずにチケットをアサインします。

しかし稼働可能時間は週ごとに変化します。PTO（有給休暇）が追加され、パートナーチームがインテグレーション作業の時間を要請し、オンコールローテーションで想定外のインシデントが増え、メンバーが休暇に入ることもあります。

Sprint開始時（四半期や月次ではなく、各Sprint開始時）に簡単なキャパシティ確認を行うことで、四半期コミットと実際にチームが2週間で達成できることのずれを防ぐことができます。

Sprint開始時のキャパシティ確認は15〜20分で完了します。

1. 3カラム形式を開き、既知の会議とPTOに基づいて稼働可能時間を事前に入力します。
2. 各メンバーが自分のカラムを確認し、今Sprint中の稼働可能時間に影響を与えるものをフラグします（大型コードレビュー、取得中の資格、午前中を使う通院など）。
3. 稼働可能時間を適宜調整します。
4. コミット作業と稼働可能時間を比較します。差がある場合は、Sprint開始前に再調整します。

これは完全な計画会議ではありません。素早い稼働可能時間のチェックポイントです。継続的に実施することで、「見積もりの問題」として語られるSprintミスの80%を防ぐことができます。実際には稼働可能時間の問題であるケースがほとんどです。

オーバーアロケーションを可視化する

健全なキャパシティプランニングプロセスの最も重要な要素の一つは、オーバーアロケーションが可視化されて明示されることです。隠れて暗黙的に吸収されるのではなく。

キャパシティテーブルで誰かが20時間の稼働可能時間に対して42時間のコミット作業を持っていることが見えると、議論の対象が生まれます。コミット作業を減らすか（優先順位の再調整が必要）、あるいは一部の作業が完了しないことを受け入れてSprint終了後ではなく今すぐステークホルダーに伝えるかを選択できます。

最悪の結果は、オーバーアロケーションが見えない状態です。そのメンバーは20時間のSprintで42時間分の作業を試みます。夜や週末に働き、作業のほとんどは完了しますが急ぎ足になり、一部は予告なく省かれます。Sprintが終わっても何が起きたのか、なぜそうなったのかが不明のままです。

可視化されたオーバーアロケーションは交渉を生み出します。隠されたオーバーアロケーションは失敗を生み出します。

Sprint稼働可能時間トラッカー

共有ドキュメントやスプレッドシートに収まる、Sprint キャパシティを追跡するための実用的なテンプレートを紹介します。

---

Sprint [番号], キャパシティ概要 Sprint期間: [開始日] → [終了日]

---

チーム稼働可能時間

---

コミット作業

---

オーバーアロケーション確認 [ ] すべてのコミット作業が稼働可能時間に収まっている [ ] オーバーアロケーションがある場合: フラグを立てステークホルダーと再調整済み

---

計画外バッファ チーム全体の稼働可能時間合計: [合計] コミット時間合計: [合計] 残りバッファ: [差分、約20%が目安]

---

オーバーアロケーション時のエスカレーションスクリプト

キャパシティプランニングでオーバーアロケーションが判明した場合、ステークホルダーに迅速かつ明確に状況を伝える方法が必要です。シンプルなスクリプトを紹介します。

「Sprint のキャパシティを確認したところ、[名前]さんは今Sprint で[X時間]の稼働が可能ですが、[Y時間]分のコミット作業があります。[Z時間]のオーバーアロケーションです。[具体的な項目]を次のSprintに移すか、追加のキャパシティを確保する必要があります。このまま進めた場合、[具体的な項目]は持ち越しになる可能性が高いです。優先度の判断をお願いできますか。」

このフレーミングには3つの効果があります。問題を具体化する（数字であいまいさがない）、問題ではなく選択肢を提示する、そして共感ではなく決断を求める。このフレーミングを受けたステークホルダーは、「今Sprintは少し遅れそうです」と言われた場合より建設的に対応します。

よくある落とし穴

100%キャパシティで計画する。 キャパシティプランニングにおける最大の誤りです。人間はSprint全体を通じて100%の効率で働けません。常に割り込み、コンテキストスイッチング、変動があります。現実的な計画の出発点は80%であり、多くのチームでは70〜75%がより実態に合っていると気づきます。

マネージャーの時間を計上しない。 マネージャートラックの作業（採用、1:1、パフォーマンス面談、クロスチーム調整、管理業務）は「オーバーヘッド」ではありません。実際の時間を要する本物の作業です。これをキャパシティ計画に含めないマネージャーは、プロジェクト作業を慢性的にオーバーコミットし、不足分を取り返そうと奔走します。

パートタイムや分割役割のメンバーを無視する。 誰かが時間の40%を別チームで使っているなら、あなたのSprintでの実効キャパシティは労働時間の60%からオーバーヘッドを差し引いた値です。それに応じて計画してください。当然に思えますが、一貫して見落とされがちです。

キャパシティプランを作っても参照しない。 Sprint開始時に適切にキャパシティプランニングを行うチームの最も一般的な失敗は、Retrospectiveまで誰もそれを見ないことです。Sprint途中でキャパシティプランを確認してください。誰かが稼働可能時間を超えて進行している場合、金曜日ではなく火曜日に知りたいはずです。

キャパシティプランニングをパフォーマンス指標として使う。 キャパシティプランニングは計画ツールであり、責任追及ツールではありません。稼働可能時間が少ないと示すことがパフォーマンス面談につながると学習したメンバーは、入力を操作し始め、正直な状況把握という本来の目的が失われます。Deloitteのパフォーマンス管理における心理的安全性に関する調査もこのパターンを確認しています。正直な報告がペナルティにつながると感じるチームは問題を系統的に過小報告し、キャパシティプランニングが防ごうとしている組織の盲点をそのまま作り出します。

キャパシティプランニングと優先順位付けの連携

キャパシティプランニングと優先順位付けは、Sprintコミットの決定における表裏一体の関係です。「このチームはこのSprintで実際に何を達成できるか」という問いに答えるには、両方が必要です。

優先順位付けフレームワークは、どの項目が最も重要かを示します。キャパシティプランニングは、チームがそのうちいくつを実行できるかを示します。この2つの交点がSprintコミットです。

キャパシティが通常より低い場合（メンバーの不在、大型コードレビュー週、パートナーチームへのサポートなど）、優先順位付けの重要性はむしろ高まります。キャパシティが逼迫しているSprintこそ、「上位3項目だけに集中し、それ以外はしない」という規律が最も重要になります。

プロジェクトキックオフを実施する際は、キックオフの前にキャパシティ確認を行うべきです。関連するSprintでチームのキャパシティがどれだけあるかを把握せずに、タイムラインとスコープについて合意することは非常に困難です。先にキャパシティの全体像を把握してから、スコープの議論を行ってください。

週次ステータス更新は、キャパシティの想定外の変化をリアルタイムで発信する場です。計画外の割り込みにより、Sprint のコミット作業にリスクが生じた場合、ステータス更新がその伝達手段です。Sprint終了後ではなく、早めかつ明確に伝えてください。

正直なキャパシティプランとは

正直なキャパシティプランは、すべての関係者を喜ばせるわけではありません。チームがSprintごとに10項目を出荷できると聞かされていたステークホルダーにとって、正直な数字が6項目だと知ることは驚きを伴います。

しかし、正直な数字は現実の数字でもあります。継続的に共有されるリアルな数字は、楽観的な数字を提示し続けたうえで一貫して未達が続く場合には決して生まれない信頼を築きます。

目標はコミット量を最小化することではありません。チームが品質を保ち、燃え尽きずに、制約が可視化された状態で実際に守れるコミットメントを行うことです。チームが一貫してコミットしたことを届けると、ステークホルダーはより多くの項目をSprintに追加しようとするゲームを止めます。Gartnerのエンジニアリングチームパフォーマンスに関する調査によると、デリバリーの予測可能性（コミットしたことを一貫して届けること）は、エンジニアリングチームとビジネスステークホルダーの間で最も信頼を高める行動であり、単純な生産量よりもはるかに重要です。交渉は政治的なものではなく、合理的なものになります。

正直なキャパシティプランニングは、形式が整えば1Sprint あたり約20分で完了します。実施しない場合のコスト（Sprintの未達、燃え尽き、信頼の喪失、手戻りのバックログ）は、桁違いに大きくなります。分散チームにとっては、タイムゾーンのオーバーヘッドがさらなるレイヤーを加えます。オーバーラップウィンドウの時間と非同期ハンドオフの時間も、キャパシティの計算に含める必要があります。

時間を数える。バッファを適用する。Sprint開始時に確認する。オーバーアロケーションを公にフラグを立てる。それだけです。

詳細を確認する: 予測可能な出荷とクリアなコミュニケーションを実現するチームの運営についての詳細は、チーム生産性プレイブックをご覧ください。関連記事: チームレベルのfocus block、チームの規範に関する避けてきた会話、CFOのためのAI活用ROI分析。