これは何か
容量計画書は、システムが扱う量（利用者数、データ量、処理の件数）が今どれだけで、これからどう増え、それに対してどの部品（計算機、記憶領域、通信、データベース）をどれだけ用意し、いつ増やすかを、数字と根拠つきで書いた成果物です。
「何人まで利用できればよいのか」（06-02 何人まで利用できればよいのか）で決めた要件を、実際の部品の大きさと費用に翻訳するのがこの文書です。足りなければ遅くなり、止まります。多すぎれば費用が無駄になります。その間を、根拠のある数字で決めます。
なぜ作るか
- 要件の数字（同時利用者数、処理件数）を、部品の大きさ（台数、記憶の容量、通信の太さ）に落とす
- 増える速さを見積もり、「いつ足りなくなるか」を事前に知る
- 増やすのに時間がかかる部品（調達、契約の変更）を、間に合うように手配する
- 性能試験（10-04 性能をどう確認するのか）で確かめる条件を、この計画書の数字から決める
誰が使うか・いつ作るか
- 作る人：システムアーキテクトと、基盤を担当する会社。業務部門が「量の見込み」を提供する
- 使う人：基盤の担当、性能試験の担当、運用の担当、費用を承認する人
- 一般的には、全体設計で部品の構成が決まったあとに最初の版を作り、性能試験の結果と稼働後の実測で更新します
- アステリア案件の容量の見積もり、部品の大きさ、増やす計画は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
量に関係する記載
- アステリア株式会社は従業員 約4,000名、売上高 約5,000億円
- 約120人規模のプロジェクト、約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- システムに SYS-01 新基幹システム、SYS-02 財務会計システム FIN-CORE、SYS-06 システム連携基盤、SYS-07 BI基盤 がある
- Vendor B クラウドブリッジの担当範囲に クラウド基盤、ネットワーク が含まれる
- P-008 黒田 健 — システムアーキテクト
同時に使う人数、1 日の処理件数、データの総量、増える速さ、用意した部品の大きさは、正本に記載がありません。未確定 「従業員 約4,000名」は会社の規模であり、新基幹の同時利用者数ではありません。
主な項目
一般的には、次の項目で構成します。
- 量の前提：利用者数（登録・同時）、業務の処理の件数（1 日・ピークの時間帯）、データの総量と 1 年の増加、保管する期間
- ピークの形：日の中の山、月の中の山、年の中の山。ピークが通常の何倍かと、その根拠（業務のカレンダー）
- 部品ごとの必要量：計算機の台数と大きさ、記憶領域、データベースの容量と処理能力、通信の太さ。前提の量からどう計算したか
- 余裕率：必要量に対してどれだけ余裕を持つか（たとえば通常時の使用率を 6 割以下に保つ）。余裕率の根拠
- 増やす計画：使用率がどこまで来たら、何を、どれだけ、どの手順で増やすか。増やすのにかかる日数
- 費用：部品ごとの費用と、増やしたときの費用の変わり方
- 確かめ方：性能試験で再現する量、稼働後に測る指標と見直しの周期
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 量の前提から必要量への計算
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、計画書の書き方を学ぶための例です。数値はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 項目（教材上の例） | 現在 | 1 年後 | 3 年後 | 根拠 |
|---|---|---|---|---|
| 登録利用者 | 3,500 人 | 3,700 人 | 4,100 人 | 人事の採用計画 |
| 同時利用者（通常時） | 400 人 | 430 人 | 480 人 | 登録の約 12%（現行システムの実測） |
| 同時利用者（ピーク） | 1,100 人 | 1,200 人 | 1,350 人 | 通常の約 2.8 倍（締めの日の実測） |
| 案件データ | 180 万件 | 205 万件 | 260 万件 | 年 25 万件の増加 |
| 夜間処理の対象 | 1 日 40 万件 | 46 万件 | 58 万件 | 案件データの増加に比例 |
| 部品（教材上の例） | 計算の仕方 | 現在の必要量 | 用意する量（余裕率） | 増やす目安 | 増やすのにかかる日数 |
|---|---|---|---|---|---|
| 画面を処理する計算機 | 同時利用者 ÷ 1 台あたり 300 人 | ピーク時 4 台 | 6 台（使用率 6 割） | ピーク時の使用率が 7 割を超えた月が 2 回続いたら 2 台追加 | 3 営業日 |
| データベースの記憶領域 | データ件数 × 1 件あたりの大きさ × 索引の係数 1.6 | 2.4 TB | 4 TB（1 年後の量の 1.5 倍） | 使用率 7 割で拡張 | 10 営業日 |
| 夜間処理の計算機 | 処理件数 ÷ 1 時間あたりの処理能力 | 4 時間 | 6 時間の枠に対して 4 時間（余裕 2 時間） | 処理時間が 5 時間を超えたら並列数を増やす | 5 営業日 |
読み方
- 量の前提に根拠（実測、計画、比例の関係）が書かれているか
- ピークが通常の何倍かと、その根拠があるか。通常時だけで計算していないか
- 部品ごとに「計算の仕方」が書かれ、前提の量から追えるか
- 余裕率と、増やす目安（どの指標がいくつになったら）が書かれているか
- 増やすのにかかる日数が、使用率の伸びに間に合うか
書き方
- 業務部門から量の見込みを、根拠つきで集める（現行の実測が最も信頼できる）
- ピークの形を、業務のカレンダーから描く
- 部品ごとに計算の仕方を決め、前提から必要量を計算する
- 余裕率と増やす目安を決め、費用と並べて承認を得る
- 性能試験の条件をこの計画書から決め、試験の結果で計画書を直す
何を書いてはいけないか
- 根拠のない量（「十分に大きく」「余裕を見て」）
- 通常時の量だけでの計算（ピークで止まる）
- 増やす目安のない余裕率（いつ増やすかが決まらず、足りなくなってから慌てる）
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 量の前提の根拠
- ピークの倍率と根拠
- 部品ごとの計算の仕方
- 余裕率と増やす目安
- 増やすのにかかる日数
赤信号
- 量の前提が「業務部門の感覚」だけで、実測がない
- ピークが計算に入っておらず、締めの日に遅くなる
- 増やす目安が決まっておらず、使用率が 9 割を超えてから初めて議論が始まる
- 性能試験の量が計画書の前提と違う（少ない量で合格にしている）
よくある失敗
- 登録利用者数をそのまま同時利用者数にして、部品を過大に用意する（費用の無駄）。または逆に、通常時の同時利用者だけで計算して、ピークで止まる
- データの増える速さを見込まず、稼働の 1 年後に記憶領域が足りなくなる
- 増やすのに契約の変更が必要な部品を、必要になってから手配し、間に合わない
関係するUnit・成果物・危機演習
- Unit：06-06 どれだけの容量を用意するのか、06-02 何人まで利用できればよいのか、10-04 性能をどう確認するのか、14-02 正常に動いているか何を見るのか
- 成果物：REQ-003 非機能要件一覧、ARC-007 環境・配置構成図、TST-005 性能試験結果報告書、OPS-002 監視・アラート一覧
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、計画書の計算（前提の量 × 計算の仕方 ＝ 必要量）が合っているかを検算する下書きに役立ちます。
「次の容量計画書の表について、各部品の『計算の仕方』に『量の前提』の値を当てはめて計算し直し、書かれている必要量と一致するかを表にしてください。一致しない行は、計算し直した値と差を示してください。前提の値や計算の仕方の妥当性は判断しないでください。」
REVIEW
- AIの検算が、計画書の計算の仕方を正しく読み取っているか（単位や係数の見落としがないか）
- 差が出た行について、計画書の誤りか、AIの読み違いかを人が確かめたか
- 計画書を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
人間が判断すること
- 余裕率をどこに置くか（費用との釣り合い）
- 増やす目安と、増やす判断をする人
- 前提の量が外れたとき、計画書をいつ直すか
設計承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 06｜壊れることを前提に設計する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この計画書を読んだ基盤の担当は、「来年の繁忙期に、どの部品が、どれだけの余裕を残して動くか。足りなくなる前に、いつ、何を増やすか」を数字で説明できますか？