業務プロセス改革では、作業を速くする前に、その作業が必要かを問い直します。現状の可視化から始め、業務の流れを組み直すことが核心です。
例えば「同じ顧客情報をスプレッドシートとCRMに入力している」「承認を待つ間に次の担当者が動けない」「担当者が休むと案件の状況がわからない」——こうした状態では、個々の作業を効率化しても、業務全体の停滞は残ります。
業務プロセス改革とは、業務の目的と工程を見直し、部門や担当者をまたぐ仕事の流れを再設計する取り組みです。既存の流れを前提に改善するか、流れそのものを組み直すかを、課題の場所に応じて判断します。
このページは、経営管理完全ガイドの中の「業務プロセス改革」カテゴリのガイドページです。
この記事でわかること
手作業や属人化を見直したい担当者に向けて、改善対象の選び方から効果の確かめ方までを整理します。
- BPRと業務改善の使い分け — 今の業務を改善する場合と、業務の流れを再設計する場合の判断軸がわかります。
- ECRSを使った現状の見直し — 不要な工程を残したまま効率化しないための検討順序がわかります。
- 現場を巻き込む再設計の進め方 — 現状の可視化から新しい運用への移行までを確認できます。
- 投資判断と効果測定 — 改善前後で何を比べ、経営にどう報告するかを整理できます。
- 小さく始める実行方法 — 対象業務の選定と、途中で改革が止まったときの戻り先がわかります。
BPRと日常的な業務改善をどう使い分けるか
BPRと日常的な業務改善の違いは、次のとおりです。
| 区分 |
考え方 |
| BPR |
既存の業務プロセスを根本から再設計する |
| 日常的な業務改善 |
現在の流れを生かしながら負担や無駄を減らす |
改革の規模を先に決めるのではなく、問題が個別の工程にあるのか、工程同士のつながりにあるのかを調べるところから始めます。
個別の作業に問題があるなら、現在の流れから見直す
例えば、同じ情報の転記に時間がかかっていても、その情報を受け取る部門や判断の順序に問題がなければ、入力方法の見直しから始められます。まず、次を記録します。
入力元を整理するだけで業務を進められるなら、現在の流れを生かした改善を選びます。
ただし、転記を自動化しても、使われていない報告書を作り続けるなら負担は残ります。
作業方法を変える前に、その成果物を誰が何の判断に使うかを確かめてください。
利用する人と目的が見つからなければ、作業自体をなくせないか検討します。
部門間で仕事が止まるなら、流れ全体を設計する
担当者ごとの作業は整っていても、引き継ぎや承認のたびに情報を探し直す場合は、工程同士のつながりが課題です。この場合、ひとつの作業を速くしても、後続の工程に同じ待ち時間が残ります。
仕事の開始から完了までをつなげて描き、誰が、どの情報を受け取った時点で次に進めるのかを定義します。
既存の部門分担を前提にすると解決できない場合は、BPRとして役割や判断の順序を組み直します。現場で決められる範囲を超える変更は、経営側が目的と優先順位を示す必要があります。
進め方の全体像は、BPR(業務プロセス改革)の進め方|経営主導で業務を根本から再設計する7ステップでも整理しています。
改革の出発点は業務の流れを可視化すること
忙しさの原因は、作業している本人にも見えにくいものです。担当者が扱う一覧表だけでは、前後の工程で起きる手戻りや待ち時間を捉えきれません。
まずは、仕事が始まってから完了するまでを、担当者間の受け渡しも含めて記録します。
現状の工程と受け渡しを同じ図に書き出す
現状を表すAs-Isの業務フローには、次の内容を書きます。
- 各工程の担当者
- 受け取る情報
- 作る成果物
- 次の工程へ渡す条件
所要時間を把握できる業務では、その計測方法もそろえます。数値を取れない工程も空欄のまま放置せず、「承認待ち」「情報の確認待ち」など、止まる理由を現場に確認します。
スプレッドシートとCRMの両方で管理している場合は、次の点を追います。
- どちらが最初の入力先か
- 誰が更新するか
- どちらを見て次の判断をするか
情報が食い違うなら、担当者への入力徹底だけで解決しようとせず、二重に更新する仕組みを見直します。引き継ぎ時に必要な情報が揃っているかも、次の工程の担当者に確認してください。
改善する場所は、負担と影響を合わせて選ぶ
洗い出した問題をすべて同時に扱うと、改善後に何が効いたのか判断しにくくなります。候補ごとに、次の点を確認します。
- 「繰り返し発生するか」
- 「後続の工程を止めるか」
- 「変更に関わる担当者は誰か」
確認した結果に応じて、見直す場所を選びます。
- 頻繁な転記が中心なら ── 入力の流れから見直します
- 部門をまたぐ待ち時間が中心なら ── 受け渡し条件から見直します
ここで記録した現状は、改善後との比較にも使います。現状を測らないまま新しい仕組みを導入すると、作業時間が短くなったのか、負担が別の担当者へ移っただけなのかを見分けられません。
対象を決めたら、その業務の開始点と完了点を固定してから次の設計へ進みます。
ECRSと改善手法を課題に合わせて選ぶ
業務改善の手法には、それぞれ得意な課題があります。本記事では、次の順で整理します。
- 個別工程を見直すとき ── ECRS
- 改善を継続するとき ── PDCA
- 品質のばらつき ── シックスシグマ
- 流れ全体の制約 ── TOC
手法の名前から選ぶのではなく、可視化した問題の性質から選んでください。
| 手法 |
選ぶ前に確認する問題 |
最初に記録するものと次の判断 |
| ECRS |
工程や成果物そのものが必要か |
記録:工程ごとの目的、利用者、重複する入力 次の判断:排除できる工程を先に検討し、残す工程の結合・順序・簡素化へ進む |
| PDCA |
変更しても同じ問題が戻るか |
記録:変更前後で同じ範囲を測れる指標 次の判断:小規模に試し、結果を確かめて次の変更を決める |
| シックスシグマ |
誤りや品質のばらつきを定義・測定できるか |
記録:対象となる不良、発生機会、処理件数 次の判断:測定対象をそろえて原因を分析する |
| TOC |
特定工程に仕事が滞留して全体を止めるか |
記録:工程ごとの投入量、完了量、待ち 次の判断:制約工程を特定し、前後を含む流れを見直す |
この表は手法の優劣や導入順を一律に決めるものではありません。例えば同じ「承認待ち」でも、不要な承認を減らせるならECRS、承認担当へ仕事が集中しているならTOCの視点が合います。
先に工程の実態を記録し、問題に合う方法を選びます。
ECRSでは、作業を簡単にする前に必要性を問う
ECRSは、排除、結合、交換、簡素化の視点で業務を見直す方法です。最初に、その工程や成果物が使われているかを確かめます。
- 排除 ── 使われていない工程なら検討します
- 結合 ── 同じ情報を別々に扱う工程なら検討します
- 交換 ── 順序や担当が手戻りの原因なら考えます
- 簡素化 ── 残す必要がある作業について考えます
例えば、報告書の作成に時間がかかるとき、最初から入力欄を減らす案に飛びつく必要はありません。報告書を使う人が判断した内容を確認し、別の情報で代えられるなら作成自体を見直します。
報告書が必要なら、他の記録と重複する項目を整理し、最後に作成方法を簡素化します。現場への当てはめ方は、ECRSの原則で業務改善を実践する方法|排除・結合・交換・簡素化の適用ガイドで詳しく扱っています。
問題が残る場所に応じて次の手法へ進む
- 改善後も同じ問題が繰り返されるなら ── 変更を試して結果を確かめるPDCAの運用に移します
- 担当者や時期によって成果のばらつきが大きいなら ── ばらつきの原因を分析するシックスシグマが検討対象になります
- 特定の工程に仕事が滞留し、前後の工程まで影響しているなら ── TOCの視点で制約となる場所を調べます
ASQのシックスシグマ解説では、6σ水準の数値目標を「100万の不良発生機会当たり3.4件の不良」と説明しています。
これはシックスシグマの目標水準であり、この会社や一般的な事務作業の実績・合格基準ではありません。自社の業務へ当てはめる前に、次を定義します。
- 何を一つの「不良」とするか
- 各処理に何回の発生機会があるか
定義をそろえずに件数だけ比較すると、改善前後の差を誤って読み取ります。
ただし、高度な手法を選んでも、測る対象や工程の境界が曖昧なままでは議論が進みません。まず現状のフローと、問題が起きた場所を共有します。
そのうえで、次のように手法を選び、測定する指標を決めます。
- 工程単位の無駄なら ── ECRS
- 変更後の継続的な調整なら ── PDCA
- ばらつきや滞留が中心なら ── 対応する手法
各手法の比較は、業務改善フレームワーク比較|ECRS・PDCA・シックスシグマ・TOCの使い分けにまとめています。
現状から新しい業務プロセスへ移す
プロセス再設計では、現状の業務フローをそのまま新しいツールに置き換えるだけでは不十分です。現場の知見を使って、実際に必要な判断と受け渡しを残します。
経営側は、部門をまたぐ変更の目的と優先順位を示し、現場で解決できない判断を引き受けます。
To-Beは、次の担当者が動ける条件から設計する
新しい流れを表すTo-Beでは、各工程の終了条件を先に考えます。「入力したら次へ」ではなく、次の担当者が何を判断できれば仕事を受け取れるかを明確にします。
条件が曖昧なら、現場で発生している確認のやり取りを調べ、そのうち判断に必要な情報を業務フローへ戻します。
ここで項目を増やしすぎると、入力の負担が新たな問題になります。情報を使う場面を説明できない項目は、初期の運用に含める前に用途を確認します。
必要な情報だけを、必要な工程で記録する設計にすれば、担当者が替わっても次の行動を判断しやすくなります。
再設計の作業順は、業務プロセス再設計の実践ステップ|ゼロベースで業務を組み直す具体的手法でも確認できます。
移行計画には、旧業務の終了条件も書く
新しい流れを作っても、従来の表や報告書を残したままでは二重作業になります。移行計画には、新しい運用を始める条件に加え、旧来の記録をいつ、誰の判断で終了するかを書きます。
現場が新しい流れで仕事を完了できないなら、足りない情報や権限を特定し、To-Beの設計へ戻ります。
担当者に「新しいやり方に慣れてください」と伝えるだけでは、引き継げる仕組みになりません。工程ごとに、次の内容を残します。
- 入力する情報
- 次の担当者へ渡す条件
- 判断に迷ったときの確認先
これにより、特定の人の記憶に頼っていた作業を、共有できる業務の流れへ変えていけます。
CRMを使うなら業務全体の流れに位置づける
CRMは、顧客情報を保存する場所として使うだけでは、業務プロセスの改革につながりません。コンタクトへの対応から取引の管理、顧客になった後の対応や請求へ進む流れの中で、どの情報を誰が使うかを設計します。
HubSpotを活用する場合も、まず自社の業務フローを定義し、その流れに沿って記録と報告の役割を決めます。
入力先を整理してから、連携や自動化を考える
次の情報が並立しているなら、最初に各情報の用途と更新者を確認します。
- スプレッドシートの顧客一覧
- 担当者ごとのメモ
- CRMの取引情報
同じ情報を複数の場所に入力している場合は、どの記録を業務上の基準にするかを決めます。
基準が決まれば、次を検討できます。
- コンタクトで受け取った情報を取引時の判断にどう引き継ぐか
- 顧客対応や請求に必要な情報へどうつなぐか
ただし、自動化する対象を先に決めると、不要な通知や転記まで残すおそれがあります。ECRSで工程の必要性を確かめ、残す工程について担当者と次の行動を定義してから自動化を検討します。
担当者の判断が必要な場面は、その判断に使う情報が見える状態を先に整えます。
レポートは改善対象の工程に合わせて読む
取引の状況を可視化するなら、見栄えのよいダッシュボードを先に作るのではなく、どの工程を改善したいかを決めます。
例えば、取引の進み方を確認したい場合は、次の対象が揃っているかを確かめます。
- 現場が管理する取引の情報
- 経営に報告する集計の対象
対象が揃わない場合は、グラフの作り方を変える前に入力と集計の定義へ戻ります。
以下の画面は、HubSpotの商談分析レポートを表で示した例です。

レポートで見えた差をそのまま改善成果と判断せず、対象期間や取引の扱い方が改善前後で同じかを確認します。
- 比較条件が揃っていれば ── 工程の変更によって何が変わったかを現場と確認できます
- 揃っていなければ ── レポートの数値を評価に使う前に集計条件を修正します
投資判断と改善効果を同じ指標でつなぐ
業務改善には、ツールの導入、外部への支払い、社内の作業時間などの投入が伴います。
投資判断では、期待する効果を挙げるだけでなく、その効果を改善後にどう測るかまで決めます。
稟議時の見込みと運用後の結果を同じ対象で比べられるようにしておきます。
ROI試算では、投入と効果の範囲をそろえる
ROIを考えるときは、対象業務にかかる費用と、そこで減らせる負担を対応させます。
従業員の負担感や顧客対応のしやすさも、施策を選ぶ材料です。ただし、金額に換算しにくい効果は、定量的な効果と分けて説明します。次のように判断します。
| 状況 |
対応 |
| 投入する費用に対して測定できる効果が見込める |
試行を検討する |
| 効果の根拠が不足している |
まず現状の計測から始める |
投資判断の整理は、業務改善の投資判断基準|稟議で問われるROI試算と意思決定のポイントで扱っています。
改善前後は、同じ業務と同じ条件で比べる
改善前に、次のような指標から対象業務に合うものを選びます。
- 処理件数
- 所要時間
- エラーの発生状況
- 対応にかかる費用
改善後は同じ開始点と完了点で測り、差が出た工程を確認します。ある担当者の作業時間だけが減り、別の担当者の確認時間が増えたなら、業務全体としての効果を見直します。
経営への報告では、次の内容をつなげて示します。
- 変えた工程
- 比較した条件
- 確認できた変化
- 残っている課題
効果が見えなければ、施策を広げる前に、実際の運用が設計どおりか、測る指標が課題に合っているかを調べます。
測定と報告の進め方は、業務プロセス改善のROI測定|改善効果を数値化して経営に報告する方法も参照してください。
小さく始め、改革が止まる原因を先に扱う
日常業務を続けながら改革を進める場合は、対象を絞って試す方法が現実的です。効果が見えやすく、関係者と変更範囲を把握できる業務から始めます。
その結果を確認してから、同じ問題を抱える別の工程へ広げるかを判断します。
最初の対象は、変更の影響を説明できる業務から選ぶ
次のような業務は、見直しの候補になります。
- 手作業の転記
- 紙の申請
- 担当者だけが把握している報告
ただし、目についた業務をすぐに選ぶのではなく、その作業がなくなると誰の判断に影響するかを調べます。関係者と受け渡し条件を把握でき、改善前の状態を確認できるなら、試行対象にしやすくなります。
試行では、次を記録します。
新しい流れで仕事を完了でき、後続の担当者にも必要な情報が渡るなら、対象を広げる判断材料になります。
仕事が止まるなら、運用を広げず、停止した工程と不足した情報を設計に戻します。優先順位の付け方は、中小企業の業務改善|スモールスタートで成果を出す優先順位の付け方で整理しています。
経営と現場の役割を分け、止まった場所から立て直す
改革が進まなくなる原因には、次のようなものがあります。
- 目的の曖昧さ
- 現場への丸投げ
- 変化への対応不足
- 成果を急ぐ進め方
立て直しでは、役割を次のように分けます。
- 経営側 ── 何を改善するかを決め、部門間で解決できない問題を判断します
- 現場 ── 実際の工程と新しい運用で起きた支障を伝えます
進捗の確認では、担当者の努力を問うよりも、仕事が止まる条件を取り除けているかを確認します。
現場が従来の手順に戻った場合は、変更への抵抗と決めつけず、次のような原因を調べます。
- 必要な情報が揃わないのか
- 承認が滞るのか
- 旧業務を終了できていないのか
原因が業務設計にあれば工程を直し、部門間の判断にあれば経営側へ戻します。失敗の原因と対策は、業務改革が失敗する5つの原因と対策|現場が動かない理由と経営者の関わり方で詳しく扱っています。
よくある質問
BPRと業務改善の違いは何ですか?
業務改善は、現在の仕事の流れを生かしながら、工程の負担や無駄を減らす取り組みです。BPRは、業務の目的から問い直し、工程や役割のつながりを再設計します。問題が個別作業に収まるなら業務改善から、部門間の受け渡しまで変える必要があるならBPRを検討します。
最初に使う改善手法はどれですか?
個別の作業に無駄があるなら、ECRSでその作業の必要性から調べると進めやすくなります。変更後も同じ問題が繰り返されるならPDCAで結果を確かめ、ばらつきや滞留が中心なら、その原因に合う手法を検討します。手法を選ぶ前に、対象業務の開始点と完了点を決めてください。
専任の改革チームがなくても進められますか?
対象を絞り、日常業務の中で確認できる範囲から試す方法があります。まず、関係者と変更の影響を把握できる業務を選び、改善前の状態を記録します。試行で仕事が滞るなら拡大せず、止まった工程を直してから再度確かめます。
改善の効果はどう報告すればよいですか?
改善前後で、同じ業務の同じ範囲を測ります。処理時間が減っても、別の担当者の確認作業が増えたなら、その負担も含めて説明します。変更した工程、比較条件、確認できた変化、残る課題を合わせて示すと、次の投資判断につなげやすくなります。
まとめ
業務プロセス改革では、作業の効率化に入る前に、仕事の目的と工程のつながりを確かめます。
- 個別の無駄 ── ECRSを使います
- 部門をまたぐ停滞 ── 業務全体の再設計を検討します
改善後は、現場が仕事を完了できるかを確認し、改善前と同じ条件で効果を測ります。
まずは、手作業や引き継ぎで負担が生じている業務をひとつ選ぶところから始めてください。
- 仕事の開始から完了までを書き出し、担当者間で渡す情報を確認します。
- 各工程をECRSで見直し、変更する場所と新しい受け渡し条件を決めます。
- 小さく試し、仕事が止まった場所と改善前後の変化を記録して、次の変更を判断します。
あわせて読みたい