運営責任者に任命され、開催日は仮決めされた。それなのに、ウェビナーのやり方を検索して出てくるのはZoomの操作画面の解説ばかりで、知りたいこと(何週間前から、誰が、何をやるのか)が書かれていない。そんな状態ではないでしょうか。兼務のメンバーから「で、私は何をすればいいんですか」と聞かれ、答えに詰まった方もいるはずです。
この記事は、Zoomの押し方を書きません。ボタンの操作は公式ヘルプがいちばん正確です。代わりに、専任のいない兼務チームがウェビナーを回すための「運営の段取り」だけを扱います。
具体的には、次の6つを、そのまま社内に持ち込める表の形で渡します。
- 開催日からの逆算スケジュール(何週間前に・誰が・何をやるか)
- 当日の役割分担と必要人数
- 当日のタイムテーブルと進行台本の項目
- リハーサルの確認項目と「本番に進んでよい」合格基準
- 配信が止まったときの切り替えと、判断者の決め方
- 終わった後の作業(録画・アーカイブ・実施レポート)
表を埋めた結果「うちの人数では足りない」と分かったときの選択肢は、記事の最後に用意しました。まずは、「やり方」という言葉の中身を置き直すところから始めます。
ウェビナーのやり方は「Zoomの操作」ではなく「運営の段取り」
ウェビナーのやり方として先に決めるべきは、ツールの操作ではなく、誰が・いつ・何をやるかという運営の設計です。
検索上位の「やり方」記事の多くは、配信ツールの設定画面の解説です。それ自体は間違いではありませんが、操作の解説なら開発元の公式ヘルプ(Zoomなら公式サポートサイト)が最も正確で、更新も早く反映されます。この記事では、操作の説明は行いません。
なお、ウェビナー(オンラインセミナーとも呼ばれます)とは、インターネット経由で開催するセミナー・講演会のことです。定義や、Web会議・対面セミナーとの違いは、別の記事で整理しています。【ウェビナーとは】
この記事で扱う範囲は、次の4区分です。開催までの準備は「時間軸」で(逆算スケジュール)、当日は「体制」で(役割分担・タイムテーブル・進行台本)、本番前の検証は「合格基準」で(リハーサル)、想定外と開催後は「判断と工程」で(トラブル時の切り替え・事後作業)押さえます。
以降の表は、すべて同じ条件で通します。職員40名の公益財団法人が、定期研究会(60分・参加50〜100名)を年6回オンライン開催し、運営は兼務3名(Aさん=運営責任者、Bさん、Cさん)、会員名簿は400件——という「モデルケースA」です。説明のための仮の設定であり実在の団体の実測値ではありませんので、数字はご自身の組織に読み替えてください。
ひとつだけ先回りしておくと、「当日は司会が1人いれば回るだろう」という見立ては、この記事がはっきり否定する唯一の誤解です。理由は当日の体制の章で説明します。
段取りの最初の道具は、開催日から逆算したスケジュール表です。
ウェビナー準備の逆算スケジュール — 開催日の8週間前から「いつ・誰が」動くか
準備の起点は、目安として開催日の8週間前です。この週数に公開された調査データは無く、私たちが支援の現場で見てきた目安として示します。組織の規模や形式によって前後しますが、開催日から逆算するという考え方は変わりません。
この表は準備計画であると同時に、理事会や上層部に「何週間前から人が動くのか」を示す説明資料を兼ねます。オンライン開催にも人と時間がかかることを、日付と担当という具体的な形で示せるからです。
最初に押さえる、リードタイムの長い3つの工程
最初に日付を打つのは、自分たちの努力では圧縮できない3つの工程です。登壇者への依頼、配信ツールのライセンス調達、機材の手配。いずれも相手の都合・契約・納期が絡むため、着手の遅れを後から取り戻せません。登壇者の予定が押さえられず、開催日そのものを動かすことになるケースも起こりえます。
ありがちな数え間違いは、準備期間を「告知の1ヶ月前」から数え始めることです。告知はすでに準備の中盤で、その前にこの3工程が動いていないと間に合いません。
なお、登壇者への依頼は、この記事では「8週間前に依頼する」という1行までにとどめます。依頼の内容やテーマ・企画書の作り方は、企画をテーマにした別の記事で扱います。
開催日からの逆算スケジュール表
開催日から逆算し、週ごとに「やること・担当・締切の根拠」を1枚にまとめます。
| 開催までの週数 | やること | 担当(モデルケースA) | 締切の根拠 |
|---|---|---|---|
| 8週間前 | 開催日と形式の確定/登壇者へ依頼/配信ツールのライセンス調達開始/機材の手配 | Aさん | 相手・契約・納期が絡み、遅れを圧縮できない |
| 6週間前 | 告知文と申込フォーム(事前登録)の準備、告知開始 | Cさん | 申込期間を1ヶ月程度確保するため |
| 4週間前 | 申込状況の確認/登壇資料の初稿回収/進行台本の作成開始 | Aさん・Bさん | 台本はリハーサル1回目までに形にする |
| 2週間前 | リハーサル1回目/リマインドメールの設定/役割分担の最終確認 | 全員 | 直しの時間を1週間残すため |
| 1週間前 | 通しリハーサル/進行台本の確定/アンケートの準備 | 全員 | これ以降は内容の変更を凍結する |
| 前日 | 接続テスト・最終リマインド | Bさん・Cさん | 当日の朝に初めて気づく不具合を防ぐ |
| 当日 | 開場60分前に集合(詳細は当日の章のタイムテーブル) | 全員 | ― |
| 翌日〜2週間後 | お礼メール/録画編集・アーカイブ公開/実施レポート | 分担(事後の章) | 記憶と関心が残っているうちに終える |

告知・リマインド・アンケート・機材の行は、この記事では工程名の1行にとどめています。チャネルの選び方、文面、設問、機材の構成はそれぞれ独立した論点で、この表の役割は「いつ・誰が動くか」を確定させることだからです。
「遅れているか」の自己判定 — 圧縮できる工程とできない工程
表の使い方は単純です。今日が開催日の何週間前かを数え、その行より上が終わっているかを見ます。終わっていなければ遅れています。
ただし、遅れがそのまま失敗になるわけではありません。工程は2種類に分かれます。
- 圧縮できる工程: 進行台本・チェックリスト・告知文など、自分たちの作業時間の問題であるもの
- 圧縮できない工程: 登壇者への依頼・ライセンス調達・リハーサル日程の確保など、相手のあるもの
たとえば今日が4週間前で告知がまだでも、打つ手はあります。先に圧縮できない工程(特にリハーサル日程の確保)を今日動かし、告知は期間を短くして走らせる、という順番です。逆に、圧縮できない工程が動いていない場合は、開催日の後ろ倒しを早めに決断するほうが、結果として傷が浅く済みます。
「いつ」が決まったら、次は「誰が」です。
ウェビナー当日の運営体制 — 兼務3名の役割分担・タイムテーブル・進行台本
当日の運営は、司会が1人いれば回るものではありません。進行・配信オペレーション・チャットとQ&Aの対応・受付と問い合わせ窓口という4つの機能に分かれ、それを手元の人数に割り当てる作業が、当日のやり方の本体です。
前提として、人を増やすという選択肢は最初から外して設計します。中小企業庁の「2026年版 中小企業白書・小規模企業白書」も、人手不足への対応について、人を増やす発想から、省力化投資や業務プロセスの見直しによって人手に依存しない体制へ転換していく必要性を示しています。役割分担を設計することは、この「業務プロセスの見直し」を当日運営に適用することにほかなりません。

当日に必要な4つの機能 — 司会のほかに3つの係がある
当日の仕事は、次の4つの機能に分かれます。
| 機能 | 当日の作業 | 何のための作業か(依頼するときの言葉) |
|---|---|---|
| 進行(司会) | 開会・進行・質疑の読み上げ・時間管理 | 参加者の60分を預かり、時間と場を握る役 |
| 配信オペレーション | 画面切り替え・音声監視・録画・回線の見張り | 配信が「届いている」ことを保証する役。対面の研究会には存在しなかった新しい係 |
| チャット・Q&A対応 | 質問の拾い上げ・選別・一次回答 | 参加者の声を拾い落とさないための役 |
| 受付・問い合わせ窓口 | 「入れない」への電話・メール対応 | 参加できなかった会員を作らないための窓口 |
このうち配信オペレーションは、対面イベントに対応する役割が無いため、体制を考えるときに最も抜けやすい係です。配信ツール上で「ホスト」の権限を持つのも、通常はこの係にあたります。しかし、開始5分前に「URLを開いても入れない」という電話が鳴り、同時に登壇者のマイクが入らない——という同時多発は、オンライン開催では珍しくありません。係が分かれていなければ、そのすべてを司会が1人で抱えることになります。
表の右端の列は、兼務メンバーに依頼するときの言葉に使えるように書きました。「手が空いていたら受付をお願い」の代わりに「参加できなかった会員を作らないための窓口をお願いしたい」と頼めれば、この作業が雑務ではなく、研究会の成果に直結する仕事であることが伝わります。
兼務3名での割り当て — 兼ねてよい役割・兼ねてはいけない役割
4つの機能は、組み合わせを選べば3名で持てます。モデルケースAでの割り当ては次のとおりです。工数は支援経験から置いた目安で、組織や形式によって変わります。
| 担当 | 受け持つ機能 | 主な作業(準備〜当日) | 目安工数(1回あたり) | 欠員時の代役 |
|---|---|---|---|---|
| Aさん(運営責任者) | 進行(司会) | 全体統括・進行台本の作成・登壇者との調整・当日の進行 | 準備 約10時間+当日 約2時間 | Bさん→Cさんの順 |
| Bさん | 配信オペレーション | 配信環境の設定・リハーサルの主導・当日の切り替えと監視 | 準備 約6時間+当日 約2時間 | Cさん(リハーサルに代役でも参加しておく) |
| Cさん | チャット・Q&A対応+受付・問い合わせ窓口 | 申込管理・案内送付・当日のチャットと電話対応 | 準備 約6時間+当日 約2時間 | 受付はAさんが引き取り、Q&Aは縮小して進行が兼ねる |
組み合わせには線引きがあります。
- 兼ねてはいけない: 進行×配信オペレーション。トラブルの瞬間に「話す人」と「直す人」が同一人物になり、進行と復旧の両方が止まります。配信オペレーション×受付も避けます。配信トラブルと「入れない」という問い合わせは、同時に起こるからです。
- 兼ねてよい: チャット・Q&A対応×受付(どちらも参加者との文字・電話のやり取りで、席を移らずに持てます)。進行×Q&Aの読み上げ(質問の選別を別の担当がやる前提なら成立します)。

規模が変わったときの目安も添えます。参加が200名を超える場合、双方向のワークを入れる場合、会場と配信を並行するハイブリッドの場合は、1〜2名の追加を見込んでください。逆に参加30名以下の視聴のみ形式なら、チャット対応を進行が兼ねて2名で回ることもあります。
この表を自組織の名前で埋めてみて、埋まらないと感じた場合の選択肢は、最後の章で扱います。
当日のタイムテーブル — 開場60分前から終了後まで
当日の動きは、開始時刻の60分前から始まります。14時開始・60分のモデルケースAでのタイムテーブルです。
| 時刻 | 内容 | 主に動く担当 |
|---|---|---|
| 13:00(60分前) | 機材の設営・配信環境の起動・接続確認 | Bさんを中心に全員 |
| 13:30(30分前) | 最終チェック・登壇者の入室・音声確認 | Bさん・Aさん |
| 13:45(15分前) | 開場(待機画面の表示)・受付対応の開始 | Bさん・Cさん |
| 14:00 | 開会アナウンス・注意事項の案内・録画開始 | Aさん(録画操作はBさん) |
| 14:05 | 講演本編。チャット監視と質問の選別 | 登壇者・Cさん |
| 14:45 | Q&A(選別済みの質問を読み上げ) | Aさん・Cさん |
| 14:58 | クロージング・アンケートの案内 | Aさん |
| 15:00 | 終了・録画停止の確認 | Bさん |
| 15:00〜15:30 | 登壇者との振り返り・撤収・録画保存の確認 | 全員 |
押さえたいのは、設営と開場のあいだに「最終チェック」の枠を明示的に確保することです。この枠が無いと、不具合に気づくタイミングが参加者の入室後にずれ込みます。
進行台本(キューシート)に書く項目
このタイムテーブルを当日動かすための指示書が進行台本です。進行台本は、司会が読み上げる原稿とは別物です。時刻・画面・話者・配信操作・担当を1行に並べた「操作と切り替えの指示書」にあたります。
列は次の6つで足ります。時刻/所要時間/画面(スライド番号・カメラ)/話者と要点/配信操作(録画・ミュート・共有切替)/担当。たとえば最初の1行は次のようになります。
14:00|5分|スライド1|Aさん:開会・注意事項|録画開始・登壇者のミュート解除|Bさん

司会のセリフは要点だけで構いません。全文を書くと読み上げることに集中してしまい、画面と時間から目が離れます。また、台本には「トラブル時」の欄をひとつ空けておいてください。切り替えの判断者と時間基準が決まったら、この欄に書き込みます。
なお、会場と配信を並行するハイブリッド開催では、この台本に会場側の動き(会場マイク・会場音声の扱い)が加わります。進め方は別の記事で扱います。【ハイブリッド開催とは】
この章の役割分担表と工数の列は、社内向けの説明資料としても使えます。兼務メンバーの上長には「誰の時間をどれだけ借りるか」を、上層部には「オンラインでも人と時間がかかる」ことを、数字の入った表で示せるからです。
担当が決まったら、台本どおりに動けるかを本番前に確かめます。
ウェビナーのリハーサルのやり方 — 確認項目と「本番に進んでよい」合格基準
リハーサルの本体は、通し稽古ではなく、機材・回線・切り替えの確認です。チェック項目がすべて確認でき、かつ切り替え操作を当日の担当者本人が実施できたこと。これが「本番に進んでよい」の合格基準です。
実施時期の目安は、2週間前に1回目(役割ごとの動きの確認)、1週間前に通し、前日に接続テストです。逆算スケジュール表の行と対応しています。
リハーサルは「通し稽古」ではない
対面イベントの「読み合わせ」の延長で捉えると、確認すべきものが漏れます。内容の練習は登壇者の仕事、機材・回線・切り替えの検証は運営の仕事。リハーサルというひとつの言葉に、性質の違う2つの作業が入っているため、運営側は後者(テクニカルリハーサル)を主目的に据えます。
確認の主な対象は、音・映像・画面切り替え・録画・参加者からの見え方の5つです。登壇内容の練習を省けという意味ではありません。運営が担う検証を、練習とは別の作業として扱うということです。
リハーサルのチェック項目と合格基準
確認項目は9つです。
| # | 確認項目 | 確認の仕方 |
|---|---|---|
| 1 | 登壇者の音声・マイク | 実際に話してもらい、聞き取りづらさが無いか確かめる |
| 2 | 映像・カメラ | 明るさ・画角・背景を本番の環境で確かめる |
| 3 | 画面共有とスライド切り替え | 当日の資料を最初から最後まで実際に送る |
| 4 | 出席者視点での見え方 | 別端末で参加者として入り、映像・音声・資料を確認する |
| 5 | 録画設定と保存先 | 録画を回し、保存されたファイルを開いて再生する |
| 6 | 回線 | 配信端末は有線接続か。予備回線(テザリング等)は用意したか |
| 7 | 待機画面と開始前アナウンス | 開場から開始までに参加者が見るものを確認する |
| 8 | 案内済みの参加URLと本番URLの一致 | 案内メールに記載したURLから実際に入室する |
| 9 | トラブル時のバックアップ手段 | 予備マイク・予備回線・登壇者との電話連絡手段 |

8番は見落とされがちですが、案内したURLと本番のURLが別物になっていて、開始時刻になっても誰も入室してこない、という事故は実際に起きます。案内メールのリンクから入り直すだけで防げる項目です。
合格基準は2つです。全項目が確認できていること。そして、切り替え操作を当日の担当者本人が実施できたこと。ほかの人が代わりに確認した項目は、未確認と数えてください。本番の保証になるのは、当日その操作をする人が自分の手で動かせたという事実です。なお、機材のバックアップ構成の詳しい組み方は、機材をテーマにした記事の領域なのでここでは踏み込みません。
確認しきれない項目が残ったまま本番を迎えざるを得ない場合こそ、切り替えの基準を先に決めておく必要があります。そして、リハーサルで全項目を確認しても、本番では想定外が起きます。最後に決めるのは、起きたときに誰がどうするかです。
本番で配信が止まったら — トラブル時の切り替え手順と「誰が判断するか」
トラブル対応で決めておくべきことは、対処の方法だけではありません。「誰が判断するか」です。目標に置くのは、トラブルをゼロにすることよりも、誰も何も言えない数分間を作らないことです。
よくあるトラブルと切り替えの対応表
症状ごとに「何分待って、何に切り替えるか」を事前に決めておけば、当日は表を読んで動くだけにできます。表中の時間(2分・5分)は例示の目安であり、事前に自組織の基準を決めておくことがこの表の本体です。
| 症状 | 一次対応(目安時間) | 切り替え先 | 参加者へのアナウンス例 |
|---|---|---|---|
| 音声が出ない・聞こえない | ミュート状態と音声デバイスの確認(2分) | 予備マイクに交換。復旧しなければ電話音声で中継 | 「音声に不具合が生じております。復旧まで今しばらくお待ちください」 |
| 配信そのものが落ちた | 再接続(5分) | 予備回線で再開し、再入室の案内をメールで送る | (復旧後)「回線の不具合により中断いたしました。ここから再開いたします」 |
| 登壇者が接続できない | 電話で状況を確認 | プログラム順の入れ替え。資料は運営側の端末から代理共有し、電話音声でつなぐ | 「進行の順番を入れ替えてお届けいたします」 |
| 資料が映らない | 共有のやり直し | 配信オペレーション担当の端末から資料を共有 | 「資料の表示を切り替えております。少々お待ちください」 |
| (共通)基準時間で復旧しない | ― | 中断を宣言し、後日アーカイブ配信と資料送付に切り替える | 「本日はここで中断し、後日録画にてご案内いたします。お詫び申し上げます」 |
アナウンス例を付けたのは、止まった瞬間に文章を考えるのは無理があるからです。読み上げられる一文が台本にあれば、その場で言葉を探さずに済みます。
中止・切り替えを「誰が言うか」を決めておく
切り替えの判断者を事前に1人決め、進行台本のトラブル欄に書いておきます。決めていない場合に起こるのは、全員が顔を見合わせたまま数分が過ぎることです。
ここには構造的な穴があります。責任者が司会や登壇を兼ねていると、トラブルの瞬間、いちばん状況が見えていない人が判断者になってしまうのです。話している本人には、画面が止まったことも、チャットに「聞こえません」が並び始めたことも見えません。
だから判断者は、画面と回線の状態が見えている人、つまり配信オペレーション担当に置きます。モデルケースAなら判断者はBさんで、司会のAさんは判断しない、と先に決めておく形です。責任者ほど「自分が決めるべきだ」と考えてためらいますが、権限を委ねるのは責任の放棄ではなく、判断できる位置に判断を置くという設計です。
決めるのは2つで足ります。誰が言うか(判断者)と、いつ言うか(何分で復旧しなければ切り替えるかの時間基準)。どちらも進行台本のトラブル欄に書き戻し、リハーサルで一度声に出して確認しておきます。切り替えは失敗扱いにせず、用意しておいた選択肢のひとつとして扱います。判断者がためらわずに済む位置づけまで含めて、事前に決めておいてください。

本番を乗り切ったら終わり、ではありません。準備計画の最終行は、開催日の後にあります。
ウェビナーが終わった後にやること — 録画・アーカイブ公開・実施レポート
事後作業を工程に入れ損ねると、録画も名簿も実施レポートも残りません。残らなければ、次回の改善材料と、上層部への報告材料の両方を失います。終わった後にやることを、担当と期限つきの工程として、最初から準備計画に入れておきます。
録画の整理とアーカイブ公開
録画でまず確認するのは「撮れているか」で、これは当日中に行います。撮れていなかったという事故だけは、後から取り返せません。
編集は最低限で構いません。冒頭の待機部分のカットと音量の調整ができれば十分です。あわせて公開範囲(全員公開・会員限定・申込者限定)を決め、公開までの期限を目安2週間以内に置きます。アーカイブは欠席者のフォローと次回開催の材料になります。
名簿の突き合わせと実施レポート
録画と並ぶもうひとつの資産が名簿です。申込名簿と当日の参加ログを突き合わせ、誰が申し込み、誰が参加し、誰が参加しなかったかが分かる形で保存します。次回の告知や内容を見直す際の出発点になるからです。
お礼メールの送付とアンケートの集計も、この時期の工程です。それぞれの文面や設問の作り方は独立した論点なので、ここでは工程名にとどめます。実施レポートは「作る作業がある」ことを工程として置き、担当と期限を決めます。レポートに載せる数字の選び方はKPIの決め方の話になるため、この記事では扱いません。
モデルケースAでの事後作業は次のとおりです。
| 作業 | 担当 | 期限 |
|---|---|---|
| 録画の保存確認 | Bさん | 当日中 |
| 録画の最低限の編集・アーカイブ公開 | Bさん | 2週間以内 |
| 申込名簿と参加ログの突き合わせ | Cさん | 1週間以内 |
| お礼メールの送付 | Cさん | 翌営業日 |
| アンケートの集計 | Cさん | 1週間以内 |
| 実施レポートの作成・上層部への報告 | Aさん | 2週間以内 |
ここまでの表は、すべてモデルケースAの3名で埋めてきました。最後に確かめるのは、この表が自組織の人数で埋まるかどうかです。
自前で回すか、外に出すか — 役割分担表を埋めて人数が足りないとき
役割分担表が自組織の名前で埋まるなら、自前で回せます。先に「足りる」側の条件を書いておくと、視聴のみの形式で、参加が50〜100名規模、兼務3名が確保でき、リハーサル日程を全員で押さえられるなら、外部の手を借りずに回している組織は珍しくありません。私たちが支援で関わってきた範囲でも、この条件がそろった組織は自前で定着しています。
埋まらない場合も、選択肢は「全部自前」か「全部委託」の二択ではありません。ウェビナーの運営は工程の単位で切り出せるため、自前で回すならこの記事の体制表が設計図になり、外に出すなら企画〜集客〜当日〜事後のどの工程を任せるかを選ぶ形になります。
中間の選択肢として現実的なのは、当日の配信オペレーションだけを外に出す形です。「兼ねてはいけない組み合わせ」を守れる人数がどうしても確保できない場合、たとえば兼務2名で進行と配信を分けられない場合に、いちばん事故に直結する係だけを外部に持ってもらう考え方です。企画も進行も名簿も自組織に残るため、丸投げにはなりません。
大事なのは、「人数が足りない」という結論は失敗ではない、ということです。役割分担表を埋めてみたからこそ、根拠を持って足りないと言えるようになりました。その表は、上層部に増員や委託を相談するときの説得材料になります。
兼務のメンバー何人で回せるか、30分で見立てませんか
ビズブーストは、BtoBマーケティングの戦略設計とウェビナーの運営を「参謀」として支援しています。「うちの人数と形式で、当日は何人必要か」「どこを自分たちに残し、どこを外に出すか」といった体制の見立てを、30分の無料オンライン相談で一緒に整理します。見積もりや契約の場ではありませんので、役割分担表を埋めてみた結果を持ち込む壁打ちとしてご利用ください。
まとめ — ウェビナーのやり方とは、いつ・誰が・何をやるかを決めること
この記事で渡した定規は4つです。逆算スケジュール表(いつ)、役割分担表とタイムテーブル・進行台本(誰が・何を)、リハーサルのチェック項目と合格基準(準備完了の判定)、トラブル時の切り替え表と判断権限(例外への備え)。
ウェビナーのやり方の本体は、Zoomの操作ではなく、誰が・いつ・何をやるかを決める運営設計です。 そしてこの設計は、新しい予算を必要とせず、運営責任者の裁量で今日から動かせます。
今日やることは4つです。
- 逆算スケジュール表に、自組織の開催日を入れる
- 役割分担表を埋め、兼務メンバーに「何のための作業か」とセットで依頼する
- リハーサルの日程を、メンバー全員分いま押さえる
- 中止・切り替えの判断者と時間基準を決め、進行台本に書く
4つを終えたとき、「準備は間に合うのか」「当日は回るのか」という漠然とした不安は、「どの行がまだ埋まっていないか」という具体的な確認事項に変わっているはずです。
役割分担表で名前が入らない行を、どうするか決める
逆算スケジュールと役割分担表を埋めると、担当者の名前が入らない行が出てくることがあります。そこが、人手の足りない工程です。この資料では、ウェビナー運営を8つの工程に分けて工数を数え、その工程を自組織で抱えるか外に出すかを判定します。外に出した場合に自組織に残る作業と、委託先とのつなぎ目で発生する作業も整理できます。
<この資料でできること>
- 8工程ごとの工数を数え、人手の足りない工程を特定できる
- 外に出しやすい工程から、優先度を付けられる
- 委託した工程を、逆算スケジュールに「委託先との接点」として組み込める
関連記事


