L28：繁忙期ボトルネック分析（工程・人員・ピーク）→改善提案書（90日計画）演習（TRAINING ONLY／流用禁止）

【重要：本レッスンは訓練専用】

• このレッスンで作る内容（ボトルネック分析シート、需要ピーク表、工数見積、改善提案書、90日計画、KPI、品質ゲート等）は訓練専用です。通常業務でそのまま使用することは禁止します。
• 就業中に本番用を作る場合は、訓練中の作成物をコピペして使わず、必要情報を取り直し、別途の検収（レビュー/承認）を経て作成してください。
• 本レッスンでは実データ（実受注数、実注文番号、実返品、実在庫、実SKU、実要員配置、実シフト、実作業時間）は扱いません（ダミーのみ）。
• 本レッスンは繁忙期の実務運用ではありません。受注処理・顧客対応・出荷対応・発注・交渉等の実務は行いません（分析と計画設計の練習のみ）。

本レッスンでは「繁忙期がしんどい」を気合いで乗り切るのではなく、需要（ピーク）×工程（作業）×人員（能力）の計算問題として扱い、どこが詰まるか（制約）を見える化します。
ダミーの需要推移と工程表を使い、ボトルネック→対策案→KPI→90日計画までを、改善提案書（訓練用）としてまとめます。

このページの使い方

1レッスン＝1LP（1ページ）です。上から順に当日の時間割に沿って進めてください。
各項目の冒頭に EC事業部／文房具カフェ事業部・準備室 の実施時間を併記しています。
※本レッスンはダミーのみで行います（通常業務の繁忙期対応・受注処理・顧客対応は実施しない）。

このレッスンの狙い（到達状態）

• 繁忙期の負荷を「忙しい」で終わらせず、工程・ピーク・能力に分解して説明できる
• ボトルネック（制約工程）を、感想ではなく計算（工数/能力/差分）で特定できる
• 対策を「思いつき」でなく、仮説→KPI→検証計画→90日計画で提案できる
• 副作用（誤出荷・在庫差異・品質低下・安全・CS炎上）を先にリスクとして書き、停止条件を置ける
• 就業中に本番用を新規に作り直すためのHandoff Memo（不足情報・検収観点）を書ける

受講ルール（共通）

• 実データ禁止：実在の受注数/注文番号/顧客情報/シフト/作業時間/在庫/取引先の具体値は入力しない
• 通常業務をしない：訓練日は講義・演習・レビュー・理解度確認に専念する
• 成果物の流用禁止：訓練中に作成した計画・提案書・表・テンプレは通常業務でそのまま使用しない
• 命令系統の具体化をしない：役割は「CS担当」「出荷担当」「レビュー担当」など抽象ロールで表現する
• 相互レビュー2件以上：前日までの他者成果物に2件以上コメント（本ページのレビュー観点を使用）

今日の目標（できる範囲でOK）

受講者の理解度・進捗にはばらつきがある前提で、以下は「推奨の目標」です。
全部を完成させる必要はありません。今日いちばん伸ばしたいところを選んで進めてください。

• 目標A（基礎）：TRN-EC08 Spec（v0.1以上）＋需要ピーク表（ダミー）＋工程分解（5〜10工程）
• 目標B（標準）：工数見積（工程×分/件×件数）＋能力（人×分/日）を置き、制約工程を特定する
• 目標C（発展）：改善案を3案以上出し、KPI（最大3）＋検証計画＋90日計画（Phase分割）まで作る
• 目標D（運用接続）：Handoff Memo（本番で新規作成するための不足情報・検収観点）を作る

基本：繁忙期は「ピーク×工程×能力」のギャップで詰まる

用語（訓練内の最小定義）

• 需要（Demand）：1日あたりの処理すべき件数（受注/問い合わせ/出荷など：ダミー）
• 負荷（Load）：需要×1件あたり工数（分/件）で算出する総作業分（分/日）
• 能力（Capacity）：人員×稼働可能時間（分/日）×スキル係数（任意）
• ギャップ：負荷−能力（プラスなら詰まり/待ち/残業/翌日持越しの発生源）
• 制約（ボトルネック）：ギャップが最大、または後工程に待ち行列を作る工程

よくある失敗（訓練で潰す）

• 「忙しい」のまま対策を出し、どこが詰まるかが不明
• 対策が「人を増やす」だけで、工程の工数が下がらない
• KPIがなく、効いたか判定できない
• 副作用（誤出荷/CS炎上/安全）が後出しで、改善が止まる

標準テンプレ（TRAINING ONLY）

A) TRN-EC08 Spec（v1.0）

【TRN-EC08 Spec（v1.0）：繁忙期ボトルネック分析→改善提案（90日計画）（訓練専用／流用禁止）】

Spec-ID：TRN-EC08
版：v1.0
状態：DRAFT / REVIEW / FINAL（訓練内の状態。業務利用の状態ではない）

目的：

* 繁忙期の詰まり（ボトルネック）を、工程・人員・ピークの観点で定量化し、
  改善提案書（90日計画、KPI、役割分担）としてまとめる訓練を行う。

範囲（やる/やらない）：

* やる：ダミー需要/ダミー工程で、負荷と能力を計算し、制約工程を特定し、対策を計画化する
* やらない：実受注処理、実顧客対応、実出荷、実発注、実シフト変更、実運用変更

前提（安全）：

* 実データ禁止（件数/時間/シフト/顧客/注文/在庫/取引先の具体値は入力しない）
* 不明は推測しない（要確認として残す）
* 訓練成果物は通常業務に流用しない（コピペ禁止）

役割（抽象ロール）：

* CS担当（問い合わせ/一次返信：ダミー）：
* 受注担当（受注確認：ダミー）：
* 出荷担当（ピッキング/梱包/出荷：ダミー）：
* レビュー担当：
* 承認担当：

入力（Input：ダミー）：

* 需要ピーク表（件数/日：ダミー）
* 工程分解（ステップ一覧）
* 1件あたり工数（分/件：ダミー推定）
* 人員・稼働可能時間（分/日：ダミー）

出力（Output：訓練用）：

* ボトルネック分析シート（負荷/能力/ギャップ）
* 制約工程（TOP1〜3）と根本要因（仮説）
* 改善案（最低3案）＋副作用（ガードレール）
* KPI（最大3）＋検証計画
* 繁忙期改善提案書（90日計画、KPI、役割分担）
* 品質ゲート（OK/差戻し/要相談）
* 記録テンプレ（ログ項目定義）
* Handoff Memo（本番で新規に作り直すための不足情報）

ダミー素材（このページだけで完結）

B) 需要ピーク表（ダミー：14日）

※「繁忙期の波」を作るための架空データです。実件数は入れません。

C) 工程分解（例：受注〜出荷＋CSの最小セット）

※実工程とは無関係なダミー工程です。粒度は訓練用に簡略化しています。

D) 人員・稼働可能時間（ダミー）

※「能力（Capacity）」計算の練習用です。

ボトルネック分析シート（負荷→能力→ギャップ）

E) 負荷・能力・ギャップ表（テンプレ：v1.0）

F) 制約工程（TOP3）抽出テンプレ

【TRN-EC08 制約工程 抽出（v1.0）】
対象日（ピーク日：D?）：
制約TOP1（工程ID）：
- 根拠（負荷/能力/ギャップ）：
- 影響（どこに滞留？）：
- 根本要因（仮説：断定しない）：

制約TOP2（工程ID）：
...

制約TOP3（工程ID）：
...

改善案：3案以上＋ガードレール（副作用）

改善案の方向性（ダミー例）

• 工数を下げる：テンプレ化、チェック固定、入力の前処理、バッチ化
• 能力を上げる：教育/応援者投入（ただし品質ゲート必須）、作業分担の再設計
• 需要の波をならす：締切ルール、優先度ルール、対応SLAの層分け（要相談は停止）
• 例外を減らす：例外の入口（欠損/誤り/問い合わせ）を事前に潰す

G) 改善案比較表（テンプレ：v1.0）

KPI（最大3つ）＋検証計画

H) KPIテンプレ（v1.0）

【TRN-EC08 KPI（最大3つ：v1.0）】
KPI1：滞留量（Backlog：ダミー）
- 定義：当日処理できず翌日に残った件数（受注/問い合わせ/出荷のいずれか）
- 測り方：日次で「発生−処理」を記録（訓練はダミー集計）
- 注意：滞留ゼロを目指し過ぎて品質が落ちたら失敗

KPI2：処理リードタイム（ダミー）

* 定義：発生→完了までの時間（分/時間はダミー）
* 測り方：開始/終了のログ（訓練は仮置き）
* 注意：短縮が誤出荷/誤案内を増やすならNG（ガードレールで監視）

KPI3：手戻り率（ダミー）

* 定義：差戻し/やり直しが発生した割合
* 測り方：差戻し件数/総件数（ダミー）
* 注意：報告が消えるのは改善ではない（観測のために記録する）

I) 検証計画（テンプレ：v1.0）

【TRN-EC08 検証計画（v1.0：訓練用）】
対象（ピーク日想定）：D?（ダミー）
対象工程（制約）：S?（TOP1〜2）

試す改善案（BN-xx）：
観測KPI（主要/ガードレール）：

* 主要：
* ガードレール（品質/安全/誤出荷/炎上）：

検証方法：

* 何を比較する？（現状 vs 改善案）：
* サンプル数（ダミー）：
* 記録（ログ項目）：

判定基準（効いた/効かない）：

* 効いた：
* 効かない：
* 保留：

停止条件（要相談条件）：

* 

繁忙期改善提案書（90日計画：テンプレ）

J) 提案書テンプレ（v1.0：TRAINING ONLY）

【TRN-EC08 繁忙期改善提案書（90日計画：v1.0：訓練専用）】
提案ID：
版：v1.0
状態：DRAFT / REVIEW / FINAL
対象（ダミー）：繁忙期（受注/CS/出荷）の詰まり
作成者（抽象）：
日付：

1. 問題（1行）
   -（例）ピーク日にCS一次返信と出荷が詰まり、滞留が増える（ダミー）

2. 現状（事実のみ：感想禁止）

* 需要ピーク（D?：件数）：
* 制約工程TOP1〜3（根拠：負荷/能力/ギャップ）：
* 影響（どこに滞留？）：
* 不明（要確認）：

3. 目標（KPIで定義：最大3）

* 主要KPI：
* 目標値（ダミー）：
* ガードレール（悪化させない指標）：

4. 原因仮説（最大3：断定しない）

* 仮説1：
* 仮説2：
* 仮説3：

5. 改善案（最低3案：比較）

* BN-01：
* BN-02：
* BN-03：

6. 90日計画（Phaseで分ける：役割分担も書く）
   Phase 1（0〜2週）：現状ログ整備＋制約工程の固定＋最小実験

* 目的：
* やること：
* 担当（抽象）：
* 成功条件：

Phase 2（3〜6週）：改善案の拡張（適用範囲を広げる）＋品質ゲート整備

* 目的：
* やること：
* 担当（抽象）：
* 成功条件：

Phase 3（7〜10週）：標準化（SOP/チェック/テンプレ）＋教育（応援者想定）

* 目的：
* やること：
* 担当（抽象）：
* 成功条件：

Phase 4（11〜13週）：定着（週次レビューで監視）＋次の制約へ移行

* 目的：
* やること：
* 担当（抽象）：
* 成功条件：

7. リスク（先に出す）＋停止条件

* リスク1（例：誤案内/誤出荷/安全/炎上/在庫差異）：

  * 兆候：
  * 一次対応：
  * 停止条件：
* リスク2：
  ...

8. 付録（訓練用）

* 需要ピーク表：
* 負荷/能力/ギャップ表：
* 記録テンプレ：
* 改善ログ（何を・なぜ・どう直したか）：

品質ゲート（差戻し基準）

記録テンプレ（項目定義のみでOK）

【TRN-EC08 記録テンプレ（v1.0：訓練専用）】
ログID：
日付：
Spec-ID・版：
対象日（D?：ダミー）：
実施者（抽象）：

制約工程（TOP1〜3）：
主要KPI（Before/After：ダミー）：

* KPI1：
* KPI2：
* KPI3：

採用した改善案（BN-xx）：
検証結果（効いた/効かない/保留）：
ガードレールの変化（悪化があれば記録）：

事実（確認できたこと）：
不明（要確認）：
次アクション（訓練用）：

Handoff Memo（本番で“新規に作り直す”ための移行メモ）

【TRN-EC08 Handoff Memo（v1.0：訓練専用）】
目的：
- 就業中に本番用の繁忙期改善提案（90日計画、KPI、役割分担）を“新規に”作成するための論点整理（訓練成果物の流用は禁止）。

本番で追加収集が必要な情報（不足リスト）：

* 実需要（ピーク日の受注/問い合わせ/出荷の件数推移）：
* 実工程（実際の手順、例外、品質ゲート）：
* 実工数（工程別の分/件、作業のばらつき）：
* 実能力（人員、シフト、応援者の可用性、スキル差）：
* 実SLA/優先度（何を先にやるか、締切ルール）：
* 実リスク（CS炎上、誤出荷、安全、在庫差異）と相談ルート：

検収観点（レビューで見る点）：

* 制約工程が「計算」で特定されている（根拠がある）
* KPI定義がブレない（含む/含まないが明確）
* 改善案が3案以上あり、比較と副作用（ガードレール）がある
* 検証計画がある（最小実験→判定→停止条件）
* 90日計画がPhase分割され、役割分担と成功条件がある
* 訓練と本番の峻別ができている（コピペ流用なし）

次アクション（就業中にやること：抽象で）：

* 

ChatGPTに投げるプロンプト（コピペ用：TRAINING ONLY）

1) 工程分解（Step）と必要な前提質問を作る

【L28 プロンプト①：工程分解＋前提質問（訓練用）】

前提（安全）：

* 教育訓練用ダミー。実データ禁止。
* 不明は推測しない。要確認として残す。
* 生成物は訓練専用（流用禁止）。

入力：

* ダミー需要ピーク表
* ダミー工程（例：S1〜S6）

目的：

* 繁忙期の処理フローを工程（Step）として整理し、足りない前提情報（質問）を列挙する。

出力形式（必須）：

1. 工程一覧（Step/入力/出力/チェックの見出し）
2. 工程ごとの「不明（要確認）」質問（最大10）
3. 例外カテゴリ（3〜6）

2) 負荷・能力・ギャップを計算し、制約工程TOP3を出す

【L28 プロンプト②：負荷/能力/ギャップ→制約TOP3（訓練用）】

前提：

* 計算は「分/日」で統一する（ダミー）。
* 不明は推測せず、空欄か要確認にする。

入力：

* 需要ピーク表（D1〜D14）
* 工程表（工数：分/件）
* 人員・稼働可能時間（分/日）

出力形式（必須）：

1. ピーク日（D?）の負荷/能力/ギャップ表（工程ごと）
2. 制約工程TOP3（根拠付き）
3. 制約の根本要因仮説（最大3：断定しない）

3) 改善案を3案以上出し、比較表（副作用/停止条件込み）にする

【L28 プロンプト③：改善案3案＋比較（訓練用）】

前提：

* 改善案は「どの制約工程に効くか」を必ず書く。
* 副作用（ガードレール）と停止条件を必ず書く。

入力：

* 制約工程TOP3
* ギャップの根拠（負荷/能力）

出力形式（必須）：

* 改善案（BN-01〜03以上）
* 改善案比較表（期待効果/副作用/必要条件/最小検証/停止条件）

4) KPI（最大3）＋検証計画＋90日計画（Phase）に落とす

【L28 プロンプト④：KPI＋検証計画＋90日計画（訓練用）】

前提：

* KPIは定義と測り方をセットにする（曖昧禁止）。
* 90日計画はPhase分割し、成功条件（Done）を置く。

入力：

* 改善案比較表

出力形式（必須）：

1. KPI（最大3：定義/測り方/注意）
2. 検証計画（最小実験→判定→停止条件）
3. 90日計画（Phase 1〜4：目的/やること/担当/成功条件）
4. リスク（先出し）とガードレール

5) 提案書として整形＋自己評価（差戻し観点）

【L28 プロンプト⑤：提案書整形＋自己評価（訓練用）】

入力：

* ボトルネック分析結果（表）
* 改善案比較表
* KPI/検証計画/90日計画

出力形式：

1. 繁忙期改善提案書（90日計画：v1.0）
2. 差戻しになりやすい点トップ5（どこが曖昧？）
3. 推測で埋めている箇所トップ3（要確認に直す）
4. v0.2で直す変更点（何を/なぜ/どう）

相互レビュー観点（L28専用）

• 訓練専用の担保：TRAINING ONLY／流用禁止が明記され、実在情報が混入していないか
• 制約の根拠：負荷/能力/ギャップで制約工程が説明できているか（感想でないか）
• 改善案の比較：3案以上あり、期待効果（KPI）と副作用（ガードレール）があるか
• 検証計画：最小実験・判定基準・停止条件があるか
• 90日計画：Phase分割、役割分担、成功条件（Done）があるか

レビューコメントテンプレ（コピペ用）

【L28 相互レビューコメント】
対象（分析表/改善案/検証計画/90日計画/提案書）：
版：

1. 良い点（1つ）：

*

2. 制約工程は根拠（負荷/能力/ギャップ）で説明できている？

* OK / 要改善
  不足している根拠（1つ）：
*

3. 改善案は比較できている？

* OK / 要改善
  副作用/停止条件が弱い案（1つ）：
*

4. 検証計画は回る？

* OK / 要改善
  曖昧な判定基準（1つ）：
*

5. 90日計画は実行可能に見える？

* OK / 要改善
  成功条件が曖昧なPhase（1つ）：
*

6. 次の一手（v+0.1で直すなら）：

* 

本日の流れ（タイムライン）

目次（クリックで移動）

1. 出席・当日選択カリキュラムの内容確認
2. 時間差相互評価（2件以上コメント）
3. 休憩
4. 自分への受領レビュー確認・改善方針メモ
5. L28 レクチャー本編（講師説明・質疑込み）
6. 昼休憩
7. 個人演習①：ピーク日選定→負荷/能力/ギャップ→制約TOP3
8. 休憩
9. 個人演習②：改善案→KPI→検証計画→90日計画→提案書（できた範囲で）＋移行メモ
10. 休憩
11. 復習：共有できる形に整形（できた範囲でOK）
12. 質問・コメント・感想の提出（指定スレッド）

1) 出席・当日選択カリキュラムの内容確認

【実施時間】

この時間にやること

1. 本日の目標（A/B/C/D）を選ぶ
2. ピーク日（D5またはD11など）を1つ選ぶ（ダミー）
3. 自分の注意点を1行で書く（例：推測で埋めない／計算で制約を出す／副作用を先に書く 等）

セルフ棚卸し（コピペ用）

【L28 セルフ棚卸し】
1) 今日の目標（A/B/C/D）：
-

2. 選んだピーク日（D?）：

*

3. 自分が弱い点（1つ）：

* （例：計算／KPI定義／副作用想定／90日計画の成功条件）

4. 今日の目標（1行）：

* 

2) 時間差相互評価（前日までの他者成果物に2件以上コメント）

【実施時間】

この時間にやること

• 前日までの他者成果物を2件選び、L28レビュー観点でコメントする
• 「提案の迫力」より、根拠（負荷/能力/ギャップ）→KPI→検証→90日計画の接続を見る

3) 休憩

【実施時間】

休憩：学習作業なし

4) 自分への受領レビュー確認・改善方針メモ（講師レビュー含む）

【実施時間】

改善方針メモ（コピペ用）

【L28 改善方針メモ】
受領した指摘の要点（最大3つ）：
1)
2)
3)

## 直す理由（根拠不足／計算不一致／KPI曖昧／副作用不足／90日計画が抽象的 等）：

直し方（どこを改善する？）：

* 需要ピーク表：
* 工程分解/工数：
* 負荷/能力/ギャップ：
* 改善案比較：
* KPI/検証計画：
* 90日計画：
* 移行メモ：

今日の最優先ルール（1行）：

* 

5) 当日選択カリキュラム実施：L28レクチャー本編（講師説明・質疑込み）

【実施時間】

ここからが「読む／聞く」パート

講師の口頭説明・質疑応答を挟みながら進めます。
午後は、ダミー需要・ダミー工程を使って「制約工程の特定→改善案→KPI→90日計画」を作成します。
※訓練成果物は流用禁止。本番は就業中に別途作成・検収します。

5-1. 今日の結論

• 繁忙期の詰まりは、ピーク×工程×能力のギャップで発生する
• 最初にやることは「全部改善」ではなく、制約工程（TOP1）を固定して潰す
• 改善はKPI定義＋検証計画＋90日計画が揃って初めて提案になる

6) 昼休憩

【実施時間】

昼休憩：学習作業なし

7) 個人演習①：ピーク日選定→負荷/能力/ギャップ→制約TOP3

【実施時間】

演習①のやり方（推奨）

1. ピーク日（D5またはD11）を1つ選ぶ
2. 工程（S1〜S6）について、負荷（分/日）を計算する
3. 能力（分/日）を置き、ギャップを出す
4. 制約工程TOP3を根拠付きで確定する（推測で埋めない）

提出用フォーマット（演習①：コピペ用／できた範囲でOK）

【L28 演習① 提出（できた範囲でOK）】
選んだピーク日（D?）：

## (1) 負荷/能力/ギャップ表（ピーク日）：

(2) 制約工程TOP3（根拠：ギャップ）：

* TOP1：
* TOP2：
* TOP3：

(3) 根本要因仮説（最大3：断定しない）：

* 

8) 休憩

【実施時間】

休憩：学習作業なし

9) 個人演習②：改善案→KPI→検証計画→90日計画→提案書（できた範囲で）＋移行メモ

【実施時間】

演習②のやり方（推奨）

1. 改善案を3案以上出し、比較表（副作用/停止条件込み）を作る
2. KPI（最大3）と検証計画（最小実験→判定→停止条件）を作る
3. 90日計画をPhase分割し、成功条件（Done）を置く
4. 提案書（v1.0）として整形（完成しなくてもOK）
5. 最後にHandoff Memo（本番で新規作成するための不足情報）を書く

提出用フォーマット（演習②：コピペ用／できた範囲でOK）

【L28 演習② 提出（できた範囲でOK）】
(1) 改善案比較表（BN-01〜03以上）：
-

## (2) KPI（最大3）：

## (3) 検証計画（最小実験→判定→停止条件）：

## (4) 90日計画（Phase 1〜4）：

## (5) 繁忙期改善提案書（v1.0：任意）：

(6) Handoff Memo（v1.0）：

* 

10) 休憩

【実施時間】

休憩：学習作業なし

11) 復習：共有できる形に整形（できた範囲でOK）

【実施時間】

最終チェック（コピペ用）

【L28 最終チェック（できた範囲でOK）】
- TRAINING ONLY／流用禁止が明記されている
- 実データ（件数/時間/シフト/顧客/注文/在庫）が混入していない（ダミーのみ）
- 制約工程が負荷/能力/ギャップで特定されている（感想でない）
- 改善案が3案以上あり、比較（効果/副作用/停止条件）がある
- KPIが最大3つで、定義と測り方がある
- 検証計画（最小実験）があり、判定基準と停止条件がある
- 90日計画がPhase分割され、役割分担と成功条件がある
- Handoff Memoがある（本番で新規作成するための不足情報・検収観点）

12) 講師への質問・コメント・感想の提出（指定スレッド）

【実施時間】

提出先（参考）

EC事業部・文房具カフェ事業部：ChatWork の指定スレッド／準備室：Slack の指定スレッド

提出テンプレ（コピペ用）

【L28 提出（本人レポート）】

1. 今日の学習内容（要約：3行）

*
*
*

2. 今日進めたこと（TRAINING ONLY：流用禁止）

* 今日選んだ目標（A/B/C/D）：
* 選んだピーク日（D?）：
* 制約工程TOP3（根拠：ギャップ）：
* 改善案（BN-xx）：作成/更新（比較で詰めた点）：
* KPI：作成/更新（定義を固めた点）：
* 検証計画：作成/更新（判定/停止条件）：
* 90日計画：作成/更新（成功条件を具体化した点）：
* 提案書：作成/更新（任意）：
* Handoff Memo：作成/更新：

3. 一番工夫した点（1つ）
   -（例：制約を計算で特定した／副作用と停止条件を先に書いた／90日計画のDoneを具体化した 等）
   理由：

*

4. 次に改善したい点（1つ）

*

## 理由：

5. 質問（最低1つ）

* 

ページ先頭へ戻る