capacity-planner

capacity-planner

キューに入った業務を扱うオペレーションチーム向けの規模算定ツールです。サポート、CX、カスタマーサクセス、BizOps、IT オペレーション、財務オペレーション向けです。Erlang-C の待ち行列理論、Little の法則、オペレーションリーダーシップの主要文献（Fournier、Larson、Cleveland、Reinertsen）に基づいています。決定論的で、標準ライブラリのみを使用し、LLM 呼び出しはありません。

目的

あなたは、15 人から 35 人へ規模を拡大したものの、ピーク負荷時に 35 人の組織が実際にどう動くのか見当もつかないオペレーションリーダーかもしれません。あるいは、稼働率が 88% に達し、SLA が守れなくなり始めている状況かもしれません。または、採用予算が承認され、既存チームを疲弊させずに 4 四半期にわたって採用をどう進めるか検討しているのかもしれません。このスキルは、感覚ではなく計算によって、こうした疑問に答えます。

次の 3 つの成果物を作成します。

1. キャパシティの規模算定。稼働率 70／80／90% について、需要の P50／P90／P99 に対する算定を行い、各時点での P（SLA 違反）と SAFE／WATCH／AT_RISK／CRITICAL のリスク区分を示します。
2. 稼働率の健全性。メンバーごとの信号機形式の評価と、チーム全体の判定（HEALTHY／SQUEEZED／OVERLOADED／UNBALANCED）を示します。
3. 12 か月間の四半期別採用計画。立ち上がり曲線、離職、前四半期比の需要成長率、管理スパンのマネージャー採用トリガーを考慮します。

使用するタイミング

• 年間のオペレーション・キャパシティ計画（翌会計年度に向けて 10～11 月に実施）。
• 四半期ごとの規模再算定。需要が 15% を超えて変化した場合、または離職が急増した場合に実施します。
• 予算申請前の根拠づくり。CFO に人員数の要望を正当化するための計算に使用します。
• 診断。オペレーションチームが SLA を達成できておらず、規模の問題なのか、プロセスの問題なのか、ボトルネックの問題なのかを特定する必要がある場合に使用します。
• M&A／新セグメント立ち上げのモデリング。新チームや統合組織の規模を算定します。

ワークフロー

1. 需要を把握します。業務システム（Zendesk、Intercom、JSM、ServiceNow、Salesforce）から、チケット／ケースの 1 日あたりの P50／P90／P99 件数を取得します。平均値しかない場合は、作業を止めて分布を取得してください。需要を一点で見積もることは、オペレーションにおいて最もコストの高いアンチパターンです。
2. スループットをモデル化します。需要、AHT、SLA 目標、現在の FTE、シュリンケージを指定して、capacity_modeler.py を実行します。担当機能（support / cx / bizops / finance-ops / it-ops）には --profile を使用します。80% 稼働率の行を確認してください。これが規模算定の基準点です。
3. 稼働率リスクにフラグを立てます。現在のチームの実際の稼働率データを使って、utilization_analyzer.py を実行します。85% を超える状態が継続するメンバーは、Reinertsen によればスループット崩壊のリスクがあります。チーム内の差が 30 パーセントポイントを超える場合は UNBALANCED です。採用する前に、これを解消してください。
4. 採用の順序を決めます。現在の FTE、年末の目標、立ち上がり期間、離職、成長率を指定して、hiring_sequencer.py を実行します。採用を前倒しし（Q1 は 35%、Q4 は 15%）、立ち上がり曲線を適用し、管理スパンがマネージャー 1 人あたり IC 7 人を超えるとマネージャー採用をトリガーします。
5. 「判断を迫る質問」ライブラリ（後述）を順に確認します。一度に 1 つの質問に取り組んでください。先に進まないでください。計画を確定する前に、回答を書き留める必要があります。

スクリプト

• scripts/capacity_modeler.py — Erlang-C による規模算定。シュリンケージ調整と、P50／P90／P99 での違反確率を含みます。業界のデフォルト設定には --profile を使用します。
• scripts/utilization_analyzer.py — メンバーごとの信号機形式の評価と、分散検出を含むチームレベルの健全性判定を行います。
• scripts/hiring_sequencer.py — 立ち上がり、離職、成長、四半期あたりの採用上限、マネージャー採用トリガーのロジックを含む、12 か月間の四半期別計画を作成します。

3 つのスクリプトはいずれも、--input <path>（JSON）、--output {markdown,json}、--sample（組み込みの例）、--help を受け付けます。標準ライブラリのみを使用します。

簡単な例

# Emits an Erlang-C capacity model (required headcount + P50/P90/P99 breach probabilities) for the built-in example
cd business-operations/skills/capacity-planner && python3 scripts/capacity_modeler.py --sample

参考資料

• references/queueing_theory_canon.md — Erlang、Little、Hopp & Spearman、Reinertsen、Kingman、Cleveland、ITIL、Armony et al.（8 件の資料）。数理面を扱います。
• references/ops_workforce_planning_canon.md — Fournier、Larson、Google SRE Workbook、Frei、Lawler、Bersin、Gartner、Grove（8 件の資料）。人に関する要素を扱います。
• references/capacity_anti_patterns.md — 出典付きの 11 個の名称付きアンチパターン、ツールによるガード、Lencioni + Goldratt + Christensen が求めるメタ規律を扱います。（8 件以上の名称付き資料。）

アセット

• assets/capacity_brief_template.md — 3 つすべてのツール用の JSON スケルトンと出力チェックリストを含む、20 分で記入できるテンプレート

前提条件

このスキルは、次のことを前提としています。

• 業務はプロジェクト形式ではなく、キューに入れられる形式です（チケット、ケース、作業項目など）。チームの業務がキューに入れられる形式でない場合、このスキルは適していません。
• 需要の分布は、四半期内で十分に定常的です（新製品の発売、M&A、規制の変更などによる急激な変化がある場合は、四半期の途中で再実行する必要があります）。
• P50／P90／P99 を算出するための、少なくとも 90 日分の過去の需要データがあります。ない場合は、まず売上またはユーザー基盤の予測から分布を生成してください。
• キュー内のサービスは単一クラスです。厳密な優先度階層（クラスごとに SLA が異なる P1／P2／P3）がある場合は、クラスごとに別のキューとしてモデル化し、最後に合算してください。
• チャネルは一貫性をもってモデル化されています。 複数チャネルを扱うチームでは、組み込みの縮小プレミアムを備えた適切な --profile を使用してください。

アンチパターン

出典を含む分類の全容については、references/capacity_anti_patterns.md を参照してください。主な 8 項目は次のとおりです。

1. 稼働率 100％を目標に計画する（Reinertsen の原則 12）
2. 立ち上がりを即時として扱う（Larson）
3. 12 か月計画で離職を考慮しない（Bersin）
4. マネージャー採用の契機を設定せずに、IC をいつまでも採用する（Fournier）
5. 需要の P50 だけを基準に規模を決める（Cleveland）
6. シュリンケージ調整を行わない（Cleveland、SRE Workbook）
7. 複数チャネルの業務を単一チャネルのモデルで扱う（Gartner、Kingman）
8. P99 の事象に対するサージ計画がない（Hopp & Spearman、Reinertsen）

他との違い

• c-level-advisor/vpe-advisor は、DORA の 4 指標、ストーリーポイント、デプロイ頻度、サイクルタイムのボトルネックを通じて、エンジニアリングのスループットを測定します。コードをリリースするエンジニアリングチーム向けです。このスキルは、チケットやケースを処理するオペレーションチーム向けです。作業単位も、計算方法（Erlang-C と DORA）も、ボトルネック（キューを考慮しない人員配置と WIP＋リードタイム）も異なります。
• c-level-advisor/chro-advisor は、戦略的な人員計画（1～5 年のケイパビリティポートフォリオ、人材供給、リーダーシップの後継者計画）を行います。このスキルは、需要に基づく運用上の 0～12 か月のキャパシティ規模を決定します。Lawler によれば、この 2 つを混同すると、採用先を間違えることになります。
• project-management/* は、プロジェクトのデリバリースループット（Jira のベロシティ、スプリントのキャパシティ）を追跡します。このスキルは、定常状態でキューに入る業務を基準に規模を決定します。
• 同じ系統の process-mapper は、ボトルネックを特定します。このスキルは、既知のボトルネックに合わせてチームの規模を決定します。実行順序は、まず process-mapper を実行し、その後 capacity-planner を実行します。誤った制約に合わせて採用すると、採用した人材が無駄になります。
• business-growth/cs-coverage（存在する場合）は、ARR／CSM 比率とセグメントに基づいてカスタマーサクセスのカバレッジを決定します。このスキルは、キューに入る業務量（チケット、ケース、エスカレーション）に基づいて規模を決定します。顧客との関係構築業務とチケットキューの両方を扱う CS チームでは、両方を実行してください。

問い詰めの質問集（Matt Pocock の問い詰めの作法）

進め方：各質問を一度に 1 つずつ確認します。先に進みすぎないでください。回答は書き留めてください。答えられない質問があれば、それが次に調査すべきことです。

Q1 — 「ボトルネックは何で、それを実証データで確認しましたか？」

推奨される回答：作業がどこで滞留しているかを示すキュー時間データを伴った、ワークフロー上の名前が明確な測定済みのステージです。感覚で答えてはいけません。「エスカレーションの対応に時間がかかる」だけでは不十分です。実際に測定されたキューを示してください。

最初の質問である理由：Goldratt（The Goal、1984 年）によれば、どのシステムにも、一度に必ず 1 つの支配的な制約があります。誤った制約に合わせて規模を決定すると、採用した人材がまったく無駄になります。ボトルネックが分からない場合は、このスキルを使う前に process-mapper を実行してください。

参考文献：Eli Goldratt、The Goal（1984 年）；Reinertsen、Principles of Product Development Flow（2009 年）。

Q2 — 「どのサービス上のトレードオフを受け入れますか？」

推奨される回答：明確に文章化された選択です。迅速さか共感か、幅広さか深さか、低コストか高品質か。Frances Frei は明言しています。4つすべてで優れることはできません。すべてを狙うチームは、何ひとつ得られません。

重要な理由：AHT、SLA、シュリンケージの各入力値は、このトレードオフを運用面で表したものです。これらの整合性が取れていない場合（たとえば、「共感」を重視したAHTを設定しながら、「迅速さ」を重視したSLAを設定するなど）、計画に内部矛盾が生じます。

原典：Frances Frei と Anne Morriss、Uncommon Service（HBR Press、2012）。

Q3 — 「需要のP90はいくつで、P99との差はどれくらいですか？」

推奨される回答：直近90日間のデータから得た具体的な2つの数値と、それぞれの日付の状況です（例：「通常の火曜日のP90は1日あたり480件、11月のリリース翌日のP99は720件でした」）。P50に合わせて人員を配置すると、半分の時間でSLAを達成できません。P99に合わせると、30～50％の過剰配置になります。Cleveland によれば、運用上適切な人員配置の基準点はP90です。

原典：Brad Cleveland、Call Center Management on Fast Forward（第4版、2019）；A.K. Erlang、The Theory of Probabilities and Telephone Conversations（1909）。

Q4 — 「計画している稼働率の場合、P90時とP99時のSLA違反確率はいくつですか？」

推奨される回答：Erlang-C を使い、具体的なN、AHT、SLA目標値から計算した（推測ではない）2つの確率です。P90時の違反確率が10％を超えるなら、基準点で人員が不足しています。P99時の違反確率が50％を超えるなら、急増需要への対応計画がなく、次のピーク時にはCEOにも問題が明らかになります。

原典：Erlang（1909）；Hopp & Spearman、Factory Physics（第3版、2008）、VUT方程式。

Q5 — 「今年発生する離職に備えて、補充採用の予算を確保していますか？」

推奨される回答：はい。具体的な人数も決まっています。年間離職率が30％（Bersin のBPO中央値）の場合、20人のFTEチームでは今年約6人が離職します。「純増5人」の計画が実際には「11人採用」の計画なら、採用人数は大きく変わります。アンチパターン #3 です。

原典：Bersin/Deloitte の人材ベンチマーク（2015～2023）；Edward Lawler、Strategic Workforce Planning（USC CEO、2008）。

Q6 — 「管理範囲がどの時点でマネージャーの採用を必要とし、候補者は誰ですか？」

推奨される回答：具体的な四半期（hiring_sequencer.py から算出）と、特定済みの候補者を少なくとも1人挙げてください（社内のリード、または社外からの採用候補者）。マネージャー1人あたりのICが7人を超えると、1対1の面談の質が低下し、フィードバックのサイクルが滞り、離職が増加します。10人を超えると、カバー体制に危機が生じます。10人を超えてからではなく、超える前にマネージャーを採用してください。

原典：Camille Fournier、The Manager's Path（O'Reilly、2017）、第5章；Andy Grove、High Output Management（1983）。

Q7 — 「P99の日に向けた急増需要への対応計画は何ですか？」

推奨される回答：明示され、文書化された計画です。オーバーフロー対応の段階、BPO の契約済み対応能力、オンコール体制、エスカレーション先の役員一覧、または「P99の日はSLAをX分に延長し、お客様に事前に通知します」と明記したサービス低下に関する合意書のいずれかです。「そのとき考えます」という回答では、P99の日に発生する問題が取締役会にも見える火災になります。

原典：Hopp & Spearman、Factory Physics（2008）；容量マージンの管理規律に関する Reinertsen（2009）。

---

この7つの質問を順番に、1つずつ確認してください。回答を書き留めてください。提出する計画の妥当性は、この7つの質問への回答によって決まります。