%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
各部門が作業を速めても、顧客に届くまでの時間が変わらないことがあります。改善の起点は、全体の流れを制限する工程を見つけることです。
各部門が作業を速めても、顧客に届くまでの時間が変わらないことがあります。改善の起点は、全体の流れを制限する工程を見つけることです。
「見積の依頼は出したのに、返答待ちで商談が進まない」「担当部門ごとの処理件数は増えたのに、完了する案件は増えない」「どこから改善すべきか判断できない」——こうした停滞は、工程ごとの忙しさだけを見ても原因をつかみにくいものです。
業務プロセスのボトルネック分析とは、仕事が始まってから完了するまでの流れを調べ、全体の処理を制限している工程を特定することです。処理そのものに時間がかかっているのか、着手前の待ち時間が長いのかを分けて確認すると、取るべき対策を選びやすくなります。
本記事では、制約理論（TOC）を中心に、業務プロセスのボトルネック分析手法と解消法を解説します。 この領域の全体像はプロセスマッピング実践ガイドで体系的に整理しています。
この記事でわかること
各部門で改善に取り組んでいても、業務全体の成果が伸びないと感じている方に向けて、測定から改善後の見直しまでの進め方を整理します。制約理論を、営業やバックオフィスの仕事にどう当てはめるかがわかります。
こんな方におすすめ: 組織全体のスループットを向上させたい経営者の方、部門間の連携不全やリードタイムの長期化に悩んでいる業務改善推進者の方
- ボトルネックと全体最適の関係 — 一部の工程を速めても、完了する仕事が増えない理由を説明します。
- ボトルネックの特定方法 — プロセスマップ、待ち時間の記録、CRMのデータ、現場へのヒアリングをどう組み合わせるかを整理します。
- 制約理論に沿った改善の順序 — 制約の特定から活用、他工程の調整、能力の強化、再測定までを追います。
- 営業・バックオフィスへの当てはめ方 — 承認待ち、転記、特定の担当者への依存を、仕組みの問題として見直します。
ボトルネック分析は業務全体の流れから始める
ボトルネックは、単に忙しい担当者や時間のかかる作業を指す言葉ではありません。仕事が完了するまでの流れを見たときに、全体の処理を制限している工程を指します。最初に仕事の開始点と完了点を決め、その間で何が滞っているかを調べます。
処理時間と待ち時間を分けて考える
「営業→見積→受注→製造→出荷」という流れで、見積作成に3日、ほかの工程にそれぞれ1日かかるという設定は、考え方を示す仮定例であり、実測値ではありません。この情報だけでは、見積作成の作業そのものが長いのか、依頼が届いてから着手するまでに待っているのかはわかりません。また、工程ごとの所要時間だけで、全体の処理能力を制限する工程を断定することもできません。
そこで、各工程について「依頼を受けた時刻」「処理を始めた時刻」「次の工程へ渡した時刻」を記録します。
- 見積の着手前に案件が溜まる場合 ── まず依頼の流し方や担当の割り当てを調べます
- 着手後の作業が長い場合 ── 見積に必要な情報や作成手順を調べます
対策を試した後は同じ項目を測り直し、顧客に届くまでの時間と完了した件数がどう変わったかを確認します。
部門の効率と全体の成果を区別する
制約理論（TOC）は、個々の工程だけを最適化するのではなく、システム全体の流れに注目する考え方です。エリヤフ・ゴールドラットの著書『ザ・ゴール』でも、制約の前に仕事が滞留する問題が描かれています。
例えば、営業部門が次々に案件を見積工程へ渡しても、見積工程が処理できる量を超えれば、依頼の列が長くなります。この場合は営業部門の処理件数よりも、見積依頼から次工程へ渡るまでの時間と、プロセス全体で完了した件数を合わせて見ます。
依頼を増やしても完了件数が増えず、待ち時間だけが延びるなら、投入量の調整と見積工程の改善を優先します。
プロセスマップで滞留する場所を絞り込む
仕事の流れが担当者の頭の中や別々のスプレッドシートに分かれていると、どこで待ち時間が生まれるかを比較しにくくなります。まずは仕事の開始から完了までを一枚の流れとして描き、工程間の受け渡しも含めて記録します。図の書き方は業務プロセスマップの書き方で解説しています。
開始点・完了点と工程をそろえる
営業プロセスなら、例えば「問い合わせを受ける」ことを開始点、「受注の可否が決まる」ことを完了点として描きます。対象を決めたら、担当部門だけでなく、見積依頼、承認依頼、差し戻しなど、仕事が手渡される場面を書き込みます。途中で別のシステムやスプレッドシートへ転記している場合も、その作業を工程として残します。
図を描いた時点で、誰が次の作業を始めるのか決まっていない場所があれば、先に受け渡しのルールを記録します。担当が明確なのに案件が溜まる場所では、次に処理時間と待ち時間を測ります。業務の境界をそろえずに部門ごとの平均時間だけを比べると、受け渡しの滞留を見落とします。
同じ指標で工程を測る
各工程で記録する項目は、次の表を基準にそろえます。処理能力だけでなく、着手を待つ仕事の量も並べることで、遅れがどこに蓄積しているかを調べられます。
| 指標 | 意味 | 計測方法 |
|---|---|---|
| サイクルタイム | 1件の処理にかかる時間 | タイムスタディ |
| 待ち時間 | 処理開始までの待機時間 | キュー計測 |
| 処理能力（キャパシティ） | 単位時間あたりの処理件数 | 実績データ |
| WIP（仕掛品） | 各ステップの滞留件数 | スナップショット計測 |
WIPが多い場所の直前は、ボトルネックの候補です。ただし、件数だけで原因を決めず、案件が到着するペース、処理を終えるペース、差し戻しの有無も確認します。待ち時間が増え続け、次工程への引き渡しが追いつかないなら、その工程を優先して詳しく調べます。改善後も同じ方法で記録し、滞留が別の工程へ移っていないかを見ます。
分析手法は調べたい原因に合わせて選ぶ
調べる方法には、次のものがあります。
- プロセスマッピング
- バリューストリームマッピング
- データ分析
- 待ち行列分析
- 担当者へのヒアリング
ひとつの手法で結論を急ぐより、流れの可視化で候補を探し、記録と現場の説明を照らし合わせると判断しやすくなります。調べたいのが作業の長さなのか、工程間の待ちなのかによって使い分けます。
価値を生む作業と待機を分ける
バリューストリームマッピング（VSM）は、顧客への価値提供までにある活動を、価値を生む作業と、それ以外の作業や待機に分けて流れを捉える方法です。顧客の要求を確認し、物と情報の流れを描き、各工程の作業時間、段取り、待ち時間を記入します。そのうえで、どの活動が顧客に届く成果へつながり、どこで時間を使っているかを見ます。
承認待ちが長ければ、承認という判断そのものに時間がかかるのか、承認者へ依頼が届いてから着手されるまでに時間がかかるのかを分けます。
- 判断そのものに時間がかかる場合 ── 判断に必要な情報や承認基準を見直します
- 依頼が届いてから着手されるまでに時間がかかる場合 ── 依頼の経路や担当の割り当てを見直します
変更後は、承認の作業時間だけでなく、依頼から完了までの時間も測り直します。
記録がある工程はデータで確かめる
CRMのパイプラインには商談が各ステージへ進んだ記録を、メールや承認の仕組みには依頼と応答の記録を残せる場合があります。パイプライン分析、メール応答時間分析、承認所要時間分析は、それぞれ「どの段階で」「どれくらい待っているか」を調べるために使います。
例えば商談の滞留が見つかったら、同じステージでも見積待ちなのか、顧客の判断待ちなのかを分けます。
- 社内の見積待ちが中心の場合 ── 社内工程を改善します
- 顧客の判断待ちが中心の場合 ── 情報提供や次回連絡の設計を見直します
ステージ名だけでは理由を区別できない場合は、滞留理由を記録する項目を最小限に決めてから、再び集計します。
記録が足りない工程は到着量と現場の声を照合する
待ち行列分析では、仕事が届く量と処理できる量の関係を見ます。依頼が届くペースに処理が追いつかず、未処理の仕事が増え続けるなら、その工程は構造的な制約の候補です。一方、特定の種類の依頼だけが滞るなら、全体の人数を増やす前に、その依頼に必要な情報や判断手順を調べます。
データに現れない事情を知るため、担当者には「何を待つことが多いか」「どんな依頼が差し戻されるか」を聞きます。ヒアリングで見つかった候補は、依頼時刻、着手時刻、完了時刻などの記録と照合します。説明と記録が一致すればその原因への対策を試し、一致しなければ工程の分け方や記録の取り方に戻ります。
制約理論の手順で改善の優先順位を決める
制約理論には、制約を特定し、活用し、他工程を従属させ、制約を強化し、制約が変われば見直すという集中改善の手順があります。（出典：TOCICO「Introduction to the Theory of Constraints」）本記事では、この順序を業務プロセスの測定結果に当てはめます。投資や自動化を考える前に、いまの手順で流れを改善できるかを確かめます。
次の図は、制約を特定し、活用し、他工程を従属させ、制約を強化し、制約が変われば見直す手順を示します。
制約を特定し、いまの処理能力を活用する
最初に、プロセスマップと測定結果から、全体の完了を制限している工程を選びます。複数の工程が忙しく見える場合は、各工程の未処理件数だけでなく、そこから先へ仕事が流れるペースを比べます。制約の候補が定まったら、担当者が何に時間を使っているか、差し戻しや付帯業務が処理を妨げていないかを調べます。
見積工程が制約なら、前工程から必要な情報がそろって届いているかを確認します。不足による差し戻しが多ければ、依頼時に記録する項目を整えます。差し戻しが少なくても付帯業務で処理が止まるなら、役割の分担を見直します。変更後は、見積の処理時間と着手前の待ち時間を分けて再測定します。
他工程を制約のペースに合わせる
制約の工程が処理できる量を超えて仕事を投入すると、未処理の依頼が積み上がります。そこで前工程では、依頼の優先順位と渡す条件を決め、制約の工程が着手できる状態の仕事を渡します。逆に、前工程から必要な情報が届かず制約の工程が手待ちになるなら、受け渡しの仕組みを先に整えます。
判断に使うのは、未処理件数の増減と、制約の工程が仕事を待っている時間です。未処理件数が増え続けるなら投入の順序や量を調整し、手待ちが生じるなら前工程の準備を見直します。その後、前工程の処理件数ではなく、プロセス全体の完了件数とリードタイムを測り直します。
能力を強化し、制約の移動を確認する
既存の手順を整え、他工程の流し方を調整しても制約の工程に滞留が残るなら、増員、システムによる自動化、外部への委託、工程の再設計を検討します。選択肢を比べる際は、滞留の原因が作業量なのか、判断待ちなのか、情報不足なのかを先に確かめます。判断待ちが原因なら、入力作業だけを自動化しても流れは改善しにくいからです。
能力を強化した後は、同じ工程だけを見続けず、開始点から完了点まで再測定します。見積工程の滞留が減っても、次の承認工程に仕事が溜まるなら、改善の対象を移します。このように、制約が変わるたびに特定からやり直します。
典型的な滞留は人ではなく仕組みから見直す
業務の停滞は、担当者個人の努力不足として片づけると再発しやすくなります。承認の渋滞、システム間の転記、専門人材への依存は、仕事の渡し方や判断基準が共有されているかという観点で調べられます。どのパターンでも、変更前後で同じ項目を測ることが大切です。
承認依頼が一か所に集まる場合
承認待ちの件数が増えているなら、まず依頼から着手までの時間と、着手から判断までの時間を分けます。
- 依頼から着手までが長い場合 ── 依頼の通知先や順番を調べます
- 着手から判断までが長い場合 ── 判断に必要な資料や基準を調べます
- 差し戻しが多い場合 ── 申請時に必要な情報を先に定義します
権限の委譲や並列承認を検討する際も、何を誰が判断するかを明確にしてから対象を選びます。手順を変えた後は、承認者の作業時間だけでなく、依頼から次工程へ渡るまでの時間を再測定します。
システム間の転記が滞る場合
スプレッドシートから別のシステムへ同じ情報を手で入力しているなら、転記にかかる時間、修正の回数、転記待ちの件数を記録します。同じ情報を繰り返し写している場合は、まずどの情報を元データとするかを決めます。入力元が定まってから、システム間の連携や転記の自動化を検討します。
元データの項目や更新の責任が曖昧なまま自動化すると、誤った情報もそのまま流れます。項目の対応関係を確かめ、例外時に誰が修正するかを決めてから、小さな範囲で流れを試します。その結果、転記待ちと修正作業がどう変わったかを確認して対象を広げます。
特定の担当者だけが処理できる場合
専門知識が必要な仕事では、どの判断で担当者の確認を待っているかを書き出します。繰り返し生じる判断なら、判断材料と引き継ぎ先を文書に残します。案件ごとの個別判断が必要なら、定型作業だけをほかの担当者へ分け、専門担当者が判断に集中できるようにします。
AIツールで情報の整理や下書きを支援する場合も、判断基準と最終的な確認者は人が決めます。担当者が不在でも次の人が仕事を進められる状態を目指し、変更後はその人を待つ件数と、仕事が完了するまでの時間を測り直します。
CRMの記録を全体の流れに結びつける
営業のボトルネックを調べるとき、CRMを単なる入力先として扱うと、ステージごとの件数だけが残り、停滞の理由がわからなくなります。問い合わせから取引、顧客、請求へと仕事が進む中で、どの時点の情報を次の担当へ渡すかを設計します。HubSpotを使う場合も、まず自社の業務の流れと判断に必要な記録を決めることをおすすめします。
ステージの滞留理由を次の行動につなげる
取引のステージで案件が滞留しているなら、見積作成待ち、社内承認待ち、顧客の回答待ちを同じ「進捗なし」として扱わないようにします。最初は担当者が滞留理由と次の行動を記録し、どの理由が繰り返されるかを確認します。入力項目を増やしすぎず、改善の判断に使う項目から始めます。
- 社内の受け渡しで止まっている案件が多い場合 ── 担当の割り当てと依頼時の情報を見直します
- 顧客の回答待ちが中心の場合 ── 次の連絡時期や提供する情報を検討します
対応後は、同じステージの滞留件数と次工程へ進んだ件数を見比べます。
自動化は確認済みのルールから始める
繰り返し発生する受け渡しには、担当者への通知や情報更新の自動化を検討できます。ただし、誰に何を渡すべきかが決まっていない段階では、まず手作業の記録からルールを整理します。条件と例外を言葉にできるようになった仕事から仕組みに移すと、担当者が替わっても同じ基準で進めやすくなります。
自動化の対象を選ぶ際は、入力情報がそろっているか、例外を誰が確認するかを確かめます。情報がそろわない案件は人の確認へ回し、条件が明確な案件から試します。その後、通知や更新が行われた件数だけでなく、次工程への引き渡しまでの待ち時間を確認します。
全体最適のための指標を持ち続ける
改善後に制約が別の工程へ移れば、以前の部門指標だけでは新たな滞留を見逃します。そのため、次の指標を見ます。
- 各部門の処理件数
- 開始から完了までのリードタイム
- 完了した仕事の量
- 工程ごとの未処理件数
指標を増やす前に、どの判断へ使うかを決めておきます。
部門ごとの達成と仕事の完了を見比べる
ある部門の処理件数が増えても、後工程の未処理件数が増え、全体の完了件数が変わらなければ、改善の優先順位を見直します。前工程の成果を否定するのではなく、後工程が受け取れる形と量になっているかを調べます。スループットやリードタイムをどう定義するかは、業務プロセスKPIの設計方法も参考になります。
指標を確認するときは、次の順で読みます。
- どの工程に仕事が増えたか
- 次へ渡るペースは変わったか
- 完了までの時間はどうなったか
滞留の場所が変わったら、新しい工程の処理時間と待ち時間を測ります。部門の数値だけが改善した場合は、全体の流れに戻って対策を選び直します。
測定を続けられる形にする
毎回、担当者が別々の表を手で集計していると、測定そのものが負担になります。まずは開始、着手、完了を記録する場所をそろえ、同じ定義で推移を見られるようにします。ダッシュボードを使う場合も、表示する数値がどの工程の判断に結びつくかを明確にします。
未処理件数が増えたら担当を確認し、待ち時間が延びたら受け渡しを調べるなど、数値を見た後の行動まで決めます。仕事の種類や流れが変われば、以前のボトルネックを前提にせず、プロセスマップから見直します。
HubSpotで滞留している工程を見つける設定例
ボトルネックを見つけるには、案件がどの工程で、どれだけ止まっているかを記録から確かめる必要があります。ここでは、見積から受注までの営業プロセスを例に、HubSpotで工程ごとの滞留を測る設定例を示します。ステージ名や項目名は例なので、自社の業務に合わせて変えてください。
工程ごとの滞留を記録する手順
- 工程をステージに置き換える ── プロセスマップで描いた工程のうち、部門の受け渡しが起きる箇所をステージとして設定します。設定（歯車アイコン）の「データ管理」＞「オブジェクト」で取引を選び、「パイプライン」タブで編集します（出典：オブジェクトのパイプラインの設定と管理）。
- 工程に入った日を記録する ── 「見積依頼日」「見積回答日」などの日付プロパティを作り、ステージが移ったときにワークフローで日付を入れます（出典：プロパティの作成と編集、ワークフローの作成）。
- 工程ごとの日数を計算する ── 計算プロパティで2つの日付の差を求め、工程ごとの所要日数を取引に持たせます（出典：計算プロパティの作成）。
- 止まっている案件を一覧にする ── 「見積回答日が空欄で、見積依頼日から7日以上」のような条件で取引の一覧を保存し、週次の会議で開きます（出典：保存済みビューの作成と管理）。
| 記録から分かること | ボトルネックの見立て | 次に確かめること |
|---|---|---|
| 特定の工程の所要日数だけが長い | その工程が全体の流れを制限している可能性が高い | 担当者の負荷か、前工程からの情報不足か |
| 所要日数のばらつきが大きい | 案件の種類によって処理の手順が違う | 長い案件に共通する条件（金額・商品・取引先） |
| 日数は短いが差し戻しが多い | 前工程で必要な情報がそろっていない | 差し戻しの理由を選択式で記録して集計する |
| 全工程が少しずつ長い | 受け渡しの待ち時間が積み重なっている | 通知や担当の割り当てを自動化できるか |
よくある失敗と回避策
- ステージを細かく分けすぎる ── 入力の手間が増え、記録が止まります。部門の受け渡しが起きる箇所に絞ります。
- 平均日数だけで判断する ── 一部の例外的な案件に引きずられます。件数と、日数の長い案件の内訳も確認します。
- ボトルネック以外の工程を先に速める ── 制約の手前に案件が積み上がるだけになります。制約の工程を特定してから改善します。
自社の状況に合わせた進め方
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わってきました。業務プロセスのボトルネックを解消する取り組みでは、次の順で小さく始めて広げる進め方を提案しています。詳しくはHubSpot導入・構築支援で紹介しています。
- 現状の整理・要件定義 ── プロセスマップを描き、受け渡しが起きる工程と、滞留が疑われる工程を特定します。
- 設計・構築 ── ステージ、日付のプロパティ、記録のワークフロー、計算プロパティと保存済みビューを設計します。
- データ移行 ── 進行中の案件を取り込み、工程に入った日を分かる範囲で記録します。
- テスト・検証 ── 1か月分の記録で工程ごとの日数を比べ、ボトルネックの見立てが現場の実感と合うかを確かめます。
- 定着・運用改善 ── 準委任で伴走しながら制約の工程を改善し、AI（Breeze・Claude等）による見積作成の補助や通知の自動化へ進みます。
| 自社の状況 | 最初の一手 | 次へ進む条件 |
|---|---|---|
| どこで止まっているか分からない | 受け渡しの工程をステージにし、工程に入った日を記録する | 工程ごとの所要日数を1か月分比べられた |
| 止まっている工程は分かっている | その工程の差し戻し理由と担当者の負荷を記録する | 止まる原因を1つに絞れた |
| 原因は分かっているが改善が続かない | 止まっている案件の一覧を週次の会議で確認する | 滞留の日数が下がり、それが続いている |
処理時間の測り方は業務効率化の生産性指標と測定方法、見積から請求までの自動化は営業事務 自動化の進め方で解説しています。
よくある質問
ボトルネックとは何ですか？
業務プロセス全体の流れを制限している工程です。忙しい工程がそのままボトルネックとは限りません。開始から完了までを見て、どの工程の前に仕事が溜まり、次へ渡るペースが制限されているかを確かめます。
未処理件数が多い工程を改善すればよいですか？
未処理件数が多い場所は有力な候補ですが、それだけでは原因を決められません。仕事が届く量、処理を終える量、着手前の待ち時間を合わせて見ます。差し戻しが原因なら依頼時の情報を整え、処理能力が追いつかないなら仕事の流し方や能力の強化を検討します。
データがそろっていない場合、何から始めればよいですか？
- 対象とする仕事の開始点と完了点を決め、工程と担当を図にします。
- 依頼、着手、完了の時刻と、待っている仕事の件数を記録します。
- 担当者へのヒアリングで候補を挙げ、その記録と照らし合わせてから対策を選びます。
自動化はどの段階で検討しますか？
滞留の原因と、仕事を次へ渡す条件が明確になってから検討します。転記が原因なら元データと項目の対応を、承認待ちが原因なら判断基準と担当を先に決めます。小さな範囲で試し、作業時間と待ち時間の両方を測り直します。
まとめ
ボトルネック分析では、工程ごとの忙しさよりも、仕事が開始から完了までどう流れるかを見ます。プロセスマップで滞留の候補を見つけ、処理時間と待ち時間を分けて測り、全体の流れを制限する工程から対策を選びます。改善後は、制約が別の工程へ移っていないかを確かめます。
まずは、ひとつの業務について仕事の開始点と完了点を決めることから始めてください。
- 工程と受け渡しを描き、依頼、着手、完了の時刻を記録します。
- 未処理の仕事が溜まる場所を探し、処理時間と待ち時間のどちらが原因かを調べます。
- 対策をひとつ選んで試し、同じ指標で再測定します。
あわせて読みたい
- 業務フロー可視化の目的と効果 — プロセスマッピングで組織の課題を見える化
- 業務プロセスマップの書き方 — ボトルネックを可視化するための記法と手順
- As-Is/To-Be分析で業務改善を実現する方法 — 現状と理想のギャップを埋める設計手順
- 業務改善フレームワーク比較 — ECRS・PDCA・シックスシグマ・TOCの使い分け
- 業務プロセス再設計の実践ステップ — ゼロベースで業務を組み直す手法
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
