【2026年8月版】
実装しない技術（第1回）― 依頼の歪みと、ECRSによる業務の整理
公開日: 2026/08/11
読了時間: 約 24分
デジタル庁が公開している窓口BPRアドバイザー派遣事業の概要資料には、「窓口DXの前提条件は、窓口の業務改革（Business Process Reengineering, 以下 BPR）」という見出しがあり、その下に「BPR無しでツールだけ導入しても意味がない」と書かれている。示されているBPRのプロセスも、フェーズ1が土台作り、フェーズ2がアナログから始めるBPR、フェーズ3がシステムを活用したBPRという順序で、システムの導入は最後に置かれている。
不要な業務を高速化しても、不要であることは変わらない。複雑な手続きをそのままデジタル化すれば、できあがるのは高速に動く複雑な手続きである。上流工程でまずやらなければならないのは、業務を徹底的に洗い出し、統廃合や縮小、単純化し、システム化するべきものだけに再構成し、それ以外を捨てる、見直す、という業務そのものの再エンジニアリングであり、実装しない技術である。
第1回では、依頼に混入している歪み、それを残したままデジタル化した結果、そして ECRS による業務整理の手順を扱う。
1. 依頼に含まれる三つの歪み
システム化の依頼は、それ自体が中立な情報ではない。次の三つの歪みが、要件定義に入る前の段階で混入している。
| # | 歪み | 内容 | 結果 |
|---|---|---|---|
| 1 | 解決策が先に決まっている | 問題ではなく手段の形で依頼が届く | 手段の妥当性が検証されない |
| 2 | 現状維持の要求が集まる | ヒアリングでは現在の業務を前提とした要求が出る | 不要な業務が新システムへ移植される |
| 3 | 目的と手段が混同される | 「承認機能」のような手段が要件として扱われる | 目的を満たす別の手段が検討されない |
1.1 解決策が先に決まっている
Excelで管理している台帳をWebシステムにしたい、メールで行っている申請をワークフロー化したい、紙のチェックリストをタブレットにしたい。システム開発の依頼はこうした形で届く。「システムを作る」という結論が先に置かれていて、受け取った開発者は画面、機能、データ、権限、通知、帳票、APIの要件を整理し始める。その台帳、申請、チェックが現在も必要なのかという問いは、この時点ですでに抜け落ちている。
「ExcelをWeb化する」は問題ではなく、すでに選ばれた解決策である。英国政府の Service Manual は、ディスカバリー段階でサービスの構築を始めてはならないとしたうえで、調査を始める前に提示された解決策を問い直し、解くべき問題として捉え直すよう求めている。挙げられているのは、「拠点の場所を示す対話的な地図を作る必要がある」という要望を、「最寄りの拠点を人が見つけやすくするにはどうすればよいか」という形へ書き直す例である。調査の結果として次のフェーズへ進まない判断も失敗にはあたらず、時間と費用を別の場所へ回せると書かれている。
1.2 現状維持の要求が集まる
この歪みはヒアリングで生じる。利用部門が話す内容の多くは、現在の業務を存続させるための要求になる。一覧で確認したい、CSVを出力したい、承認者を三段階設定したい、操作履歴を残したい。いずれも現在行っている仕事を前提にすれば合理的に見えるが、現在の業務が合理的である保証はない。業務は長い年月の中で、法改正、事故、監査指摘、組織変更、担当者交代、取引先からの要望を受けて継ぎ足される。追加された手続きにはそれぞれ理由があったとしても、その理由が現在まで存続しているとは限らない。それでも前任者から引き継いだ、昔トラブルがあった、監査で必要と言われた気がする、他部署へ提出している、規程に書いてある、システムに入力欄がある、といった形で業務は残り続ける。
1.3 目的と手段が混同される
承認を例に取る。「上司が申請を承認する」という業務の現在の手段は、申請者がフォームへ入力し、上司へ通知が飛び、承認ボタンを押し、次の承認者へ送られ、最終結果が保存される、という流れだとする。ワークフローシステムを設計する前に確かめるのは、この承認が何のために存在するかである。目的は一つとは限らず、目的ごとに代替手段が存在する。
| 承認の目的 | 代替手段 |
|---|---|
| 誤入力の発見 | 入力制約、マスタ参照 |
| 予算超過の抑止 | 予算残高との自動照合 |
| 管理職への情報共有 | 通知のみ |
| 不正の防止 | 職務分離、金額やリスクに応じた限定 |
| 責任者の明確化 | 操作記録による代替 |
| 法令や契約による要求 | 根拠条文の確認（第2回で扱う） |
承認者が実際に何を確認しているのか、形式的に押しているだけではないのかも、同じ場で確かめられる。「承認機能が必要」という要件は、どのリスクをどの程度まで誰がどの手段で抑えるかという定義に置き換えられる。その結果として承認機能そのものが消えることもある。
2. デジタル化しても業務が変わらない五類型
前節の歪みを残したままデジタル化すると、業務の構造は変わらないまま手段だけが置き換わる。
業務は、情報を記録する媒体、それを置く場所、担当者間で受け渡す経路、作業を行う主体、そして判断を下す主体から成る。デジタル化は、このいずれかの層を置き換える操作である。層ごとに整理すると次のようになる。
| # | 置き換わる層 | 典型的な施策 | 残るもの |
|---|---|---|---|
| 1 | 媒体 | 紙をPDFにする | 記入項目、添付資料、押印相当の確認、転記、保管、照合 |
| 2 | 保管場所 | ExcelをWeb画面にする | 同じ項目・担当者・タイミングでの入力、別Excelへの再出力 |
| 3 | 伝達経路 | メールをワークフローにする | 依頼、催促、承認、差し戻しの流れ。操作手順は増える |
| 4 | 実行主体 | 手作業をRPAにする | システム間で同じ情報を複製する構造 |
| 5 | 判断主体 | 複雑な対応にAIを入れる | 規程の複雑さ、情報の分散、例外 |
層1から3は情報の器を替える操作で、業務の手順そのものには触れていない。層4と5は手順を実行する側を替える操作だが、手順の内容は保たれる。類型4では、人間が複数システムへ転記していた処理をロボットが代行しても、複製の構造は残る。無駄が見えにくくなる分、発見は遅れる。類型5でも、規程が複雑で情報が分散し例外だらけの状態へAIを接続すると、AIは複雑性を解決するのではなく、複雑性を処理する新しい層として追加される。
実際の施策は複数の層にまたがることがある。対面窓口をオンライン申請へ移す場合、媒体と伝達経路の二つが同時に置き換わる。
この五層のいずれを置き換えても、記入項目の多さ、承認段階の深さ、例外の数といった業務の構造は残る。構造を変える操作は、第3節で扱う ECRS の側にある。
非効率なプロセスを再構成せずに自動化しても、期待した削減効果は得にくい。McKinsey は自動化プログラムを頓挫させる実行上の落とし穴として、価値が大きいがゆえに技術開発へ直行してしまう傾向を挙げ、その結果として非効率または陳腐化したプロセスをそのまま自動化することになると書いている。
五類型に共通するのは、技術が既存業務の問題を消すとは限らない点である。むしろ問題を高速化し、広範囲へ展開し、発見しにくくする。
3. ECRSによる業務の整理
業務の見直しには、生産管理の分野で改善の4原則と呼ばれる ECRS がある。日本能率協会コンサルティングの用語集は、Eliminate（排除）、Combine（結合と分離）、Rearrange（入替えと代替）、Simplify（簡素化）の順に適用すると、改善の効果が大きく、過剰や過小な改善も避けられ、不要なトラブルも最小になると説明している。
順序が効果を左右するのは、前段の判断が後段の対象を減らすためである。排除した業務には結合も簡素化も要らない。逆に簡素化から入れば、手を入れた手順を後から排除することになり、その作業は無駄になる。
| 段階 | 原則 | 主な問い | 適用後に残るもの |
|---|---|---|---|
| 1 | Eliminate（排除） | その業務をやめられないか | やめられない業務 |
| 2 | Combine（結合と分離） | 分散した同種の処理をまとめられないか | 統合後の手続き |
| 3 | Rearrange（入替えと代替） | 順序、場所、担当者を変えられないか | 再配置後の手続き |
| 4 | Simplify（簡素化） | 分岐、例外、承認段階を減らせないか | システム化の候補 |
3.1 Eliminate ― 排除
最初に置かれるのは排除の検討である。確認する対象は次のとおり。
- その作業の結果を誰が使っているか
- 使われなかった場合に何が起きるか
- 最後に意思決定へ使われたのはいつか
- 法令や契約で本当に必要か
- 情報を収集するコストに見合う価値があるか
- この仕事がなくなったことに誰か気づくか
作成した帳票を実際に読んでいる人がいるか、入力したデータがどこで使われているか、まったく参照されていない項目はないかまで数える。
検討の対象になりやすいのは、帳票、報告、台帳、定例会、承認である。作る側には明確な負担があるが、受け取る側が利用しているとは限らない。毎月提出していることと、毎月利用されていることは別である。
Lean の Value Stream Mapping は、製品を注文から納品まで届けるのに必要な物と情報の流れを図に起こす手法で、価値を生む活動と生まない活動の両方を含めて全体を並べ、無駄を特定して取り除くために使われる。価値が届くまでの流れ全体を一つの対象として扱う点に特徴があり、個々の作業を速くする話にはとどまらない。
3.2 Combine ― 結合と分離
同じ目的を持つ処理が、部署、製品、地域、チャネルごとに分散していることがある。部署ごとに別々の申請書を使い、同じ顧客情報を複数部門で入力している状態が典型になる。電話と窓口とWebで別々の処理手順があり、各担当者が独自の管理表を作り、類似する会議で同じ進捗を報告していることもある。このままシステム化すると、分断された業務ごとに画面、権限、データ、通知が作られる。
確認するのは、入力元を一つにできないか、判断基準を共通化できないか、同じ情報を再利用できないか、部門別の例外をなくせないか、顧客から見て一つの手続きにできないか、という五点で、答えが巨大な統合システムの構築になるとは限らない。GOV.UK の Service Standard も、14項目のうち2番目に「利用者にとっての問題全体を解決する」を、3番目に「すべてのチャネルをまたいで一貫した体験を提供する」を置いている。
分離が働く場合もある。正常な案件と例外案件の比率を数えると、例外のために全件を複雑にしている構造が判明することがある。例外だけを別の手順へ分ければ、正常系は単純なまま残せる。その例外が現在も発生しているのかも合わせて確かめる。
3.3 Rearrange ― 入替えと代替
結合と分離の次は、順序、場所、担当者の入替えを検討する。承認を作業の完了後ではなく着手前に置く、複数部署を経由していた処理を発生元の部署で完結させる、後工程で行っていた点検を前工程へ移す、といった変更が該当する。
代替も同じ枠に入る。顧客に情報を提出してもらう代わりに組織が保有する情報を再利用する、全件審査をルールによる自動許可と例外審査へ移す、といった置き換えである。処理の総量を変えずに、実行する場所と主体だけを動かす操作になる。
3.4 Simplify ― 簡素化
残った業務について、頻度、対象、精度、保存期間を削る。
| 削減の軸 | 簡素化前 | 簡素化後 |
|---|---|---|
| 対象 | 全件の確認 | 例外のみの確認 |
| 頻度 | 毎日 | 週次 |
| 項目 | 20項目の記入 | 5項目 |
| 承認範囲 | すべての案件 | 高リスク案件のみ |
| 保存期間 | 永久保存 | 必要期間のみ |
| 収集内容 | 詳細データ | 判断に必要な指標のみ |
どの程度の精度が必要か、いつ削除できるか、誤っていた場合にどのような損害が出るかまで決めておくと、収集の範囲は自然に狭まる。
システム化すると大量処理が容易になり、処理できるから収集するという逆転が起こりやすい。保存するデータが増えれば、入力、検証、権限制御、バックアップ、移行、監査、削除、漏えい対策の責任も増える。入力欄を一つ追加することは、画面項目を一つ増やすことではなく、そのデータを組織として管理し続ける契約を追加することになる。
分岐、例外、入力項目、承認段階、担当者間の受け渡し、ステータスも同じ対象になる。重複するマスタを統合し、判断基準を明文化する。
開発コストを押し上げるのは、正常系の画面数に加えて、例外、分岐、組織別ルール、経過措置、手動補正、特殊権限の組み合わせになる。簡素化の効果は画面数の削減にとどまらない。承認者を三段階から一段階にした場合、承認経路設定、代理承認、不在時の処理、差し戻し先が不要になり、通知、期限超過、権限変更、監査ログ、テストケース、操作説明も同時に消える。業務上の分岐を一つ消すことは、多数の機能、データ、テスト、運用をまとめて消すことになる。
4. 非システム施策との比較
ECRS を経てもなお残る課題について、システム化の前に非システム施策と比較する。システムを作らないという判断は、現状維持と同じではない。
| 変更する対象 | 内容 |
|---|---|
| 規程 | 承認権限、保存期間、報告頻度、対象範囲を変える |
| 責任分界 | 複数部署を経由していた処理を一つの部署で完結させる |
| サービス | 顧客に提出させる代わりに組織が保有する情報を再利用する |
| 判断基準 | 全件審査からルールによる自動許可と例外審査へ移す |
| 契約 | 取引先ごとに異なるフォーマットや納品方法を標準契約で統一する |
| 組織 | 情報を転送するだけの中継部署や会議を廃止する |
| 既存製品 | フォーム、共有ストレージ、カレンダー、既存SaaSの設定変更で済ませる |
| 時期 | 件数が少なく変化が多い業務は手作業を残し、標準化できる段階を待つ |
システムは業務改善の手段の一つであり、改善案が必ずソフトウェアへ到達する必要はない。
ECRS は業務の構造を減らす手順だが、適用するには対象の業務が正確に把握されている必要がある。第2回では、担当者ごとの作業一覧では見えない業務の全体像、廃止を阻む「法令で決まっている」という説明の検証方法、そして整理の結果をシステム化の判断へ繋ぐ手順を扱う。