本記事には一部広告が含まれます

業務改善のフレームワークは、いま困っていることに合わせて選びます。仕事の流れが分からないなら業務フロー、原因が分からないならなぜなぜ分析、見直し案が出ないならECRS、試した案を定着させたいならPDCAが出発点です。すべてを一度に使う必要はありません。

この記事では、4つの手法の役割と使い分けを比較し、事務部門で起きる申請の差し戻しを例に、どんな資料を作り、どこで次の手法へ進むかを説明します。手法の一覧を覚えるより、次に判断したいことを1つ決めるのが先です。

業務改善フレームワークを選ぶ早見表

ここでいうフレームワークは、改善のための考える順番や整理の枠組みです。業務フローは可視化する道具、なぜなぜ分析は原因を調べる方法、ECRSは改善案を考える視点、PDCAは試して見直す進め方であり、同じ目的の道具ではありません。

いまの困りごと選ぶ手法最初に作るもの次へ進む判断
担当者や処理の順番が分からない業務フロー現状の手順・担当・分岐の図関係者が実態と一致すると確認した
ミスや遅れが繰り返されるなぜなぜ分析事象と原因候補、裏付けの記録原因候補を事実で確かめられた
作業をどう変えるか決まらないECRS排除・結合・交換・簡素化の案実施条件と影響を確認できた
改善案を試したが続かないPDCA実施担当・確認指標・見直し日の計画試行結果を基に継続・修正を決めた

例えば、原因が不明な段階で入力作業を自動化しても、誤ったルールまで速く処理してしまうかもしれません。まず現状と原因を確認し、見直す対象が分かってから改善案を検討します。以下の使い分けと実践例は、各手法の基本を事務業務へ当てはめた編集上の整理です。

4つの手法の使い方と限界

業務フローで現状の手順と受け渡しをそろえる

最初に、どこからどこまでを対象にするかを決めます。申請業務なら「申請を受け付けた時点」から「承認結果を通知する時点」までなど、開始と終了をそろえます。そのうえで、誰が確認し、どの条件で差し戻し、どこで待つかを現状のまま描きます。

図をきれいに整えるだけでは原因は確定しません。規程にある理想の手順と、現場で実際に行う手順も区別します。ASQはフローチャートの手順として、対象範囲を定め、作業を順に並べ、関係者と正確さを確認する流れを示しています。ASQのフローチャート解説を参考に、図と実際の処理履歴を照合しましょう。

具体的な作図方法は、As-Is業務フローの作り方で確認できます。本記事では手法の選択を扱い、詳細な記号や作図操作はそちらへ分けています。

なぜなぜ分析で原因候補と証拠を分ける

なぜなぜ分析は、起きた問題について理由を掘り下げ、原因の理解を深める方法です。「担当者の注意が足りない」で終わらせず、入力項目、説明、確認方法、役割分担など、業務の仕組みを調べます。回答が仮説なら、処理履歴や画面、担当者への確認で裏付けを取ります。

ASQは、原因へ到達するまでの問いが5回より少ない場合も、多い場合もあると説明しています。ASQのFive Whys解説も参照し、5回埋めることを目的にしないようにします。原因が複数あるときは枝を分け、証拠のない1本の筋書きへ無理にまとめません。

ECRSで作業の残し方と変え方を検討する

ECRSは、Eの排除、Cの結合、Rの交換・変更、Sの簡素化という順に、作業を見直す視点です。日本IE協会は、工程・作業・動作の改善に用いる着眼点として説明しています。日本IE協会のECRS解説を基に、事務では次のように考えられます。

  • 排除 … 誰も使っていない転記や重複した報告をやめられないか。
  • 結合 … 同じ情報を別々に確認する作業をまとめられないか。
  • 交換・変更 … 確認の順番、担当や実施場所を変えられないか。
  • 簡素化 … 必要な作業を残したうえで、入力方法や説明を分かりやすくできないか。

順番に検討しても、すべての案を採用する必要はありません。承認や確認には、誤りの防止などの目的がある場合があります。その目的と影響を担当部門に確認し、必要な統制まで消さないようにします。「自動化できるか」だけでなく「その作業を残す必要があるか」から考えます。

PDCAで小さく試して継続か修正かを決める

PDCAは、計画、実行、確認、見直しを繰り返す進め方です。ASQの説明では、変更を計画し、小さく試し、その結果から学んで次の対応を決めます。ASQのPDCA解説を踏まえ、試す前に担当者、対象範囲、確認する数字、見直す日を決めましょう。

実施したことだけを確認しても、有効だったかは判断できません。作業時間が減ってもミスが増えれば、そのまま展開するとは限りません。件数や業務の難しさが変わった影響も記録し、続ける、修正する、元に戻すのどれにするかを決めます。

事務の申請差し戻しを4つの手法で改善する例

ここからは説明用の架空例で、実在企業の実績ではありません。総務の申請受付で、対象期間の申請200件のうち、必要項目の不足で20件を差し戻しているとします。差し戻し率は20件÷200件で10%です。件数は重複しない申請単位で数え、1件を何度戻しても、この例では差し戻しあり1件として扱います。

まず差し戻しが発生する位置を業務フローに記録する

「申請者が入力→総務が確認→不足なら差し戻し→申請者が修正→総務が再確認→承認者へ送付」と並べます。総務が実際に確認していた時間と、申請者の修正を待った時間は別に記録します。この図に改善案を混ぜず、まず申請者と総務が現状と一致すると確認します。

原因をなぜなぜ分析で確かめる

差し戻した20件を調べると、同じ項目の記入漏れが多かったとします。「入力者が不注意だから」と決めず、必須項目だと分かる表示があるか、説明と入力欄が離れていないか、条件付きで必要になる添付資料が伝わっているかを調べます。

例えば「申請者が添付の条件を知らない」「入力画面に条件の説明がない」という仮説なら、実際の画面と案内文、該当申請の内容を照合します。案内があっても読まれていない場合は、原因を同じものと扱わず、表示位置や利用状況を追加確認します。

ECRSで変更案を比較する

視点この例での検討案採用前に確認すること
排除利用先のない二重入力欄を削除する後続処理で本当に使われていないか
結合別の案内にある添付条件を申請画面へ集める申請種別ごとの条件が混ざらないか
交換・変更総務確認後ではなく申請時に不足を知らせるシステム対応の可否と誤判定時の対応
簡素化必須項目の表示と記入例を分かりやすくする初めての申請者が迷わず記入できるか

この架空例では、まず改修費用の小さい案内表示と記入例の修正を試すとします。検討順は排除から始めても、必要な確認欄を削除できないなら、残す理由を記録して別案へ進みます。特定のシステムで入力チェックを実装できると保証する例ではありません。

PDCAで試行の評価条件を先に決める

対象を同じ種類の申請に絞り、担当者と確認期間を決めます。差し戻し率だけでなく、1件の確認時間、問い合わせ件数、確認漏れも記録します。仮に次の200件で差し戻しを10件以下にする目標なら、目標値は5%以下です。これは計画上の数字であり、改善済みの成果ではありません。

期間が終わったら、変更前後で申請の種類や繁忙度が違わないかも確認します。率が下がっただけで施策の効果と断定せず、入力内容と問い合わせの変化も見ます。続けると決めた場合は、案内文の管理担当と更新方法を決めて、試行用の説明が放置されるのを防ぎます。

そのまま記入できる検討メモ

会議では次の項目を1つの改善対象ごとに埋めてください。分からない箇所を推測でつなぐより、確認する人と資料を決めておく方が次の行動につながります。

  • 対象業務 … 開始と終了、担当部門、対象となる案件。
  • 起きている問題 … 事象、対象期間、件数と数え方。
  • 次に判断したいこと … 流れ、原因、変更案、試行結果のどれか。
  • 使う手法 … 選んだ理由と、作る資料。
  • 確認できた事実 … 履歴、画面、帳票、関係者の確認結果。
  • まだ仮説のこと … 原因候補と、確かめる担当者。
  • 試す変更 … 対象範囲、担当、期限、戻す条件。
  • 評価 … 指標、比較する条件、見直す日。

業務改善フレームワークでよくある疑問

4つの手法を必ず順番に使いますか?

必須ではありません。現状の流れと原因が確認済みなら、ECRSで変更案を考えるところから始められます。逆に、改善案を試しても結果が悪ければ、原因の調査や現状の確認へ戻ります。この記事の順番は、現状が十分に分かっていない場合の進め方の例です。

どのフレームワークが最も効果的ですか?

課題や確認できる情報によって変わります。原因を調べたいのに改善案の数を増やしても、判断は進みません。「次に何を確かめるか」と「その資料で判断できるか」を基準に選びます。手法を使ったこと自体を成果にしないようにしましょう。

作業を減らすときに注意することはありますか?

作業の利用先と、確認や承認を置いている目的を先に確かめます。削除すると別部門の作業が増えたり、必要な確認が抜けたりする場合があります。関係者と実施条件を決め、小さく試して、問題があったときに戻せるようにします。

まず1つの問題と判断したいことを決める

業務改善フレームワークを選ぶ出発点は、手法の名前ではなく困っている事実です。流れをそろえる、原因を確かめる、変更案を比べる、試して見直すという役割を分け、次の判断に必要な手法を使いましょう。全体の進め方を整理したい場合は、DX・業務改革の進め方も併せて確認してください。