ECRSによる業務改善

01｜業務改善は『今の仕事を速くする』だけではない

忙しい組織で起こりやすい失敗は、作業の存在理由を検証しないままツールを導入することです。使われない報告書を10分で作れるようにしても、報告書そのものが不要なら効果は限定的です。システムを入れる前に、顧客価値・業務上の必要性・リスク管理を基準に、仕事の構造を見直します。

業務改善は人を急がせることではありません。仕事の流れを設計し直してムダな入力・移動・待ち・手戻りを減らし、品質と説明責任を保つことです。

02｜ECRS：4つの視点をひと目で理解する

ECRSはEliminate（排除）、Combine（結合）、Rearrange（入替え）、Simplify（簡素化）の頭文字です。原則としてなくせないか → まとめられないか → 並べ替えられないか → 簡単にできないかの順番で考えます。最初から自動化に飛びつくより、不要な作業を残さない判断がしやすくなります。

03｜E：Eliminate — なくしてよい仕事を見つける

例えば経費精算で「部長の承認」と「部長の補佐のCC確認」が重複し、後者が判断に使われていなければ、CC確認は排除の候補です。削る判断は、現場の印象だけでなく、承認権限、法令・契約、内部統制の必要性も確認して行います。

必要なコントロールまで取り去ると、不正や入力ミスを見逃します。「価値がない作業の排除」と「統制の省略」は別です。

04｜C：Combine — ばらばらの仕事をまとめる

営業部・開発部・サポート部が同じ会議の議事録を別々に作っている場合は、代表者が一つの議事録を作成して共同編集・共有する形に変えます。これは複数の類似作業を結合する改善です。

統合により入力を一元化できても、閲覧権限や記録の責任者が不明確になるなら逆効果です。共有データの定義、編集ルール、公開範囲、版管理を先に整えます。

05｜R：Rearrange — 順番・配置を変えて成果を出す

配送の順番を変えて走行距離を減らす例が典型です。業務そのものや訪問件数は変えず、並びを最適化することで移動・待ち・折り返しを減らすのが狙いです。

申請業務でも、完了しないと進められないと思われていた工程を並列にしたり、承認前に不足資料を検証したりすることで滞留を減らせます。ただし依存関係や必須の承認を無視して順番を入れ替えてはいけません。

06｜S：Simplify — 残る作業の負担を減らす

書式の統一、入力補助、選択肢の標準化、計算式の設定、API連携、RPAはSimplifyの候補です。例えば単価と数量を入力すれば合計額が自動計算される仕組みは、業務をなくすのではなく作業を簡単にします。

自動化で起こり得る新しい失敗もあります。誤った計算式が全件に適用される、マクロの作成者しか直せない、例外処理が属人化する、といったケースです。自動化の前にルールと例外を明文化します。

07｜E→C→R→Sの順で考える理由

排除できる作業を先に簡素化すると、価値のない仕事のためにシステム費用が発生します。統合できるデータを部門ごとに自動化すれば、複数の仕組みを保守する負担も残ります。

この順序は万能の強制ルールではありません。安全性や変更難易度などを考え、小さな簡素化から始めることもあります。それでも「なくすこと」を忘れないための思考順として有効です。

08｜まず現状の業務フローを描く

業務を可視化すると、担当者が何度も変わる箇所、転記、承認待ち、差し戻しが見えてきます。作業時間だけでなく、待ち時間、処理件数、例外処理の頻度を計測します。

この例では作業時間は49分ですが、受付から完了までの所要時間は承認待ちを含むためもっと長くなります。現状を測らずに「導入したから改善した」と判断することはできません。

09｜実例：自社SaaSの請求申請を再設計する

社員15人の架空の法人向けSaaS企業を想定します。営業担当が利用プランをスプレッドシートへ入力し、CS担当が契約条件をメールで確認し、経理が再入力して請求書を作成していました。月末に件数が集中すると、確認メールの行き違いで請求が遅れます。

Eで形だけのCC確認を見直し、Cで契約情報と請求情報の重複入力を統合し、Rで不備チェックを承認前に移し、Sで請求金額の計算を支援します。課題がどの原則に当たるかは一つに限定されず、複数の観点が重なることもあります。

10｜改善効果はどの指標で測るか

作業時間だけが減っても、顧客に届くまでの待ち時間が変わらなければ体験は改善しません。逆に、処理時間が短縮しても誤請求が増えたなら成功とは言えません。複数の指標を組み合わせて評価します。

11｜ボトルネック：全工程を速くしても成果が出ない理由

例えば受付が1時間に50件を処理できても、最終承認が1時間に10件しか対応できなければ、全体の処理能力は承認工程に制約されます。ボトルネックの手前には未処理の案件がたまります。

最も忙しく見える場所が常に原因とは限らないため、流入量、滞留件数、処理能力、例外件数を合わせて調べます。

12｜標準化・マニュアル化・自動化は何が違うか

標準化はやり方や判断基準を統一すること、マニュアル化はその基準を人が再現できるよう記述すること、自動化は定型的な処理をシステムに任せることです。標準化されていない作業を自動化すると例外が多くなり、保守コストが増えやすくなります。

標準化のし過ぎで顧客ごとの重要な例外対応をなくさないよう、例外を扱う権限とエスカレーション手順も残すことが必要です。

13｜小さな改善とBPRの違い

現行業務の枠組みで手順を減らす改善に対し、BPR（Business Process Re-engineering）は部門の境界も含め、業務を根本から再設計する発想です。ECRSは日常の改善だけでなく、BPRの検討でも役立ちます。

例えば申請書の入力欄を減らすのは小さな改善ですが、申請→回覧→台帳更新という仕組みを、統一データ基盤での自動処理に置き換えるのはより大きな再設計です。

14｜効率化と内部統制を両立させる

不要な承認を減らすときは、誰が責任を持つか、誰が変更を実行できるか、誰が後から確認できるかを区別します。一定額以上の支払いに必要な承認をなくした場合は、不正の発見が難しくなることがあります。

15｜現場で改善案を出す進め方

まず現場の担当者に「この工程を省略すると誰が困るか」「結果は何に利用されるか」と聞きます。次に顧客や次工程の利用者の視点から必要性を確認し、処理実績と業務フローを使って改善候補を分類します。

効果とリスクを見積もった上で、小さな範囲で試行し、作業時間・待ち時間・エラー率を比較します。改善前後の条件が異なると比較が歪むので、繁忙期、対象件数、担当者の経験にも注意します。

16｜業務改善でありがちな失敗

17｜操作ラボ：作業の削除・統合・入替えを比較

申請業務の工程を変更する演習、配送順序の入替え、現場の改善例からECRSを判別する演習を用意しました。時間や距離はモデル上の数値です。意思決定では必要な統制や制約も別途確認してください。

18｜まとめ：『何をしないか』から業務を設計する

ECRSは、排除・結合・入替え・簡素化という4つの視点で業務を見直す方法です。配送順を変更するのは入替え、不要な承認者を外すのは排除、重複した議事録を一つにするのは結合、計算を関数で支援するのは簡素化です。

ただ作業時間を減らすのではなく、顧客価値、正確性、統制、担当者の負担、リードタイムを総合的に見ることが重要です。ツールは改善の手段であり、不要な仕事を高速化することが目的ではありません。