「as-is凝視の罠」― 現状を睨むと再設計にならない
業務改革の議論は、たいてい現状のフロー図を広げるところから始まります。ところが、この「現状を睨みながら考える」という一見まっとうな進め方こそが、再設計を失敗させる最大の落とし穴です。現状のフローを見ながら発想すると、思考はどうしても既存の枠組みに縛られます。「この転記をRPAで」「この確認をAIチェックで」といった、各タスクを少しずつ速くする自動化案しか出てこないのです。
その結果、「承認は3段階」「この帳票は必ず作る」といった、そもそも必要かどうかを問い直すべき前提が温存されたまま残ります。これは改善であって、再設計ではありません。to-beを描くとは、現状を効率化することではなく、「もし今この業務をゼロから作るなら、どう作るか」を問い直すことです。そのためには、まず現状のフロー図を一度、目の前から片付ける必要があります。
現状フロー図を眺めながらの発想は「as-isの添削会」にしかならない。再設計と改善は別物であり、両者を分ける最初の一手が「現状を一度伏せること」です。
ゼロベースでto-beを描く4手順
白紙からto-beを描くといっても、思いつきで理想を並べるわけではありません。順序を守ることが本質です。目的の再確認 → ゼロベース設計 → 制約の織り込み → as-isとの差分確認という4手順で進めることで、理由のない承認・転記・帳票が最初から生まれない設計になります。
- 目的の再確認。その業務が達成すべきことを一文で書きます。ここで大事なのは、申請書・承認・締め処理といった「手段」を目的に混ぜないこと。たとえば経費精算なら「正当な経費が、規程に沿って、月内に精算されること」といった具合です。
- ゼロベース設計。as-isを伏せたまま、「AIと人とデータ基盤がそろっている前提で、目的を達する最小のプロセス」を白紙に描きます。今あるステップを前提にせず、目的から逆算します。
- 制約の織り込み。法規制・監査要件・システム制約・組織の現実を、一つずつ理由付きで加えます。「なんとなく必要」は加えません。この順序なら「承認3段」は最初から存在せず、「監査要件上◯◯円以上は上長承認が必要」という理由のある1段だけが残ります。
- as-isとの差分確認。最後に現状と比較し、移行の距離を測ります。この差分が、実際に何をどう変えるかという移行計画の入力になります。
ポイントは、制約を「最後に、理由とともに」加えることです。最初から制約を前提にすると、結局as-isの清書に戻ってしまいます。廃止候補がゼロのto-beは、再設計に失敗している兆候だと考えてよいでしょう。
設計ワークショップの進め方
この4手順は、担当者が一人で机上で回すよりも、関係者を集めたワークショップ形式で進めるのが標準です。参加者は5〜8名程度 ― 業務オーナー、現場担当2〜3名、DX推進、システム担当。全3回×各2時間ほどを目安に、回ごとにゴールを区切ります。
- 第1回:目的とゼロベース。目的の一文に合意し、白紙にto-beの骨格を描き、廃止候補を洗い出します。この回ではas-is資料を配りません。配った瞬間、ワークショップは「現状の添削会」に変わってしまうからです。
- 第2回:制約と分担。制約を理由付きで織り込み、タスクごとに後述の役割分担の型と、人を残す基準を割り当てて分担表を完成させます。
- 第3回:例外と責任。例外処理の設計、責任の再定義、規程改定、as-isとの差分確認まで行います。承認や規程に踏み込むこの回には、監査・法務の担当も招くと後戻りが減ります。
進行の作法は3つ。as-isは途中まで伏せる、「できない理由」はいったん制約リストに退避して先へ進む、決定はその場で書き留める。この3つを守るだけで、議論が現状追認に流れるのを防げます。
人とAIの役割分担 ― 5つの型
to-beの骨格ができたら、タスク一つひとつについて「どこをAIに任せ、どこに人を残すか」を決めます。これは感覚ではなく、型で判断します。実務で使いやすいのは、次の5つの型です。タスク単位で➀〜➄のいずれかを割り当てていくと、AIの役割と人の役割が自然と言葉になります。
| 型 | 流れ | 向く業務 | 向かない業務（誤適用のサイン） |
|---|---|---|---|
| ➀ AI完結 | AIが実行 → 事後サンプル監査 | 誤りが軽微で、後からの抜き取り監査で発見・修正できる定型・低リスク作業 | 対外送信・支払など不可逆な操作を含む業務。誤りの発見が翌月以降になる業務 |
| ➁ AI下書き → 人確定 | AIが成果物案 → 人がレビュー・確定 | 顧客向け文書・提案書など、良し悪しを人が短時間で判定できる作成業務 | レビューが全件・大量になり形骸化する業務。人が品質を判定できない専門外領域 |
| ➂ 人判断 → AI実行 | 人が決定 → AIが後続処理を実行 | 判断は重いが、その後に定型の後続処理（起票・通知・登録）が多数連なる業務 | 実行の途中でさらに判断が繰り返し必要になる業務（➁か➄で設計し直す） |
| ➃ AIチェック → 人判断 | AIが規程照合・異常検知 → 人が例外だけ判断 | 基準が明文化された大量の定型判断で、例外率がおおむね2割以下の業務 | 基準が暗黙知のまま。例外率が3割を超える業務（定義を分割する） |
| ➄ AI情報支援 → 人主担当 | AIが情報収集・分析 → 人が判断・遂行 | 非定型で重く、頻度の低い判断（経営判断・人事評価・交渉） | 実は基準を明文化できる大量判断（➃に落とせれば効果は桁違い） |
迷ったときの原則はシンプルです。➀と➁で迷えば➁を選ぶ。人の関与が厚い側から始め、運用実績を根拠に一段ずつ自律側へ動かすほうが、最初の事故で全面停止するより結局は速く進みます。
再設計の効果が最も大きいのは➃の型です。「全件を人が見る」が「例外だけ人が見る」に変わると、判断者の負荷は件数比で激減し、絞られた案件に時間をかけられる分、判断の質はむしろ上がります。ただしその効果は、人が判断できる量まで絞るHITL設計とセットで初めて成立します。
HITL ― 人の判断を残す4つの基準
「AIは補助、確定は人」という原則を、業務設計の言葉に翻訳したものがHITL（Human-in-the-Loop、人の関与点）です。ここで重要なのは、「心配だから全部人が見る」をやめることです。全件レビューは自動化バイアス（AIの出力を無批判に承認してしまう傾向）で形骸化し、かえって本当に見るべき例外を見逃します。人を残す箇所は、次の4基準に照らして決めます。
- 不可逆性。支払実行・対外送信・契約・削除など、取り返しのつかない操作の直前には人を残します。
- 影響の大きさ（高額）。金額・法的・安全・レピュテーションの閾値を超えるもの。閾値は「高額なら」ではなく「50万円以上なら」と明文化します。
- 責任の所在（対外・組織判断）。組織として「誰かが決めた」という事実が要るもの ― 承認・採否・懲戒などは人が確定します。
- 例外・低確信。AIの確信度が低い、または定義済みパターンから外れたケースは人に回します。
この4基準に該当しない箇所の人手チェックは、外す候補です。そして関与点は「置いて終わり」ではありません。差し戻し率がほぼ0%のまま続く、1件あたりの承認が数秒しかない、「AIが通したなら大丈夫」という言い方が定着している ― こうした形骸化の兆候を四半期ごとに点検し、2つ以上該当したらその関与点を再設計します。
例外処理と責任の再定義
正常系だけの美しい設計は、現場で必ず崩壊します。現場の業務時間の相当部分は例外対応に費やされており、to-beが正常系しか定義していないと、例外が起きるたびに「じゃあ旧プロセスでやろう」が発生し、結局は旧プロセスが生き残ってしまうからです。例外は3段階で設計します。月に何度も起きる頻出例外は正常系のフローに分岐として昇格させ、希少な例外はAIを通さず人が処理する「人間ルート」を正式な経路として定義し、どこからをAIに任せるかのエスカレーション基準を明文化する。人間ルートは恥ずかしい例外扱いではなく、担当・記録方法・後日のフロー改善への還流まで決めた正規の経路として設計します。
そして再設計で最も曖昧になりやすいのが責任です。ここは原則をシンプルに保ちます。組織として、「AIが勝手にやった」とは言わない。AIの下書きやチェック結果を採用して確定した人が、従来どおりの責任を負います。「AIが言ったから」は理由になりません。ただし責任だけを課すのは公平ではないので、責任を負える条件 ― 根拠の提示・判断できる件数・差し戻す権限 ― を業務設計側が保証します。AI完結（➀型）の範囲については、個別案件ではなく「この範囲はAI完結でよい」と決めた業務オーナーが設計責任を負い、サンプル監査と異常検知で範囲の妥当性を継続確認します。最後に、変更後の承認段数・金額閾値・AI関与を職務権限規程や稟議規程に反映すること。規程を直さない再設計は、監査で「規程と実態の乖離」と指摘され、旧運用に引き戻されます。
実施例で見る ― 見積回答と経費精算
ここまでの考え方を、2つの架空のモデルケースで具体化します（いずれも説明のための例です）。
例➀:営業の見積回答業務
「有効な見積が、正しい価格で、依頼当日に顧客へ届くこと」を目的の一文とした再設計です。依頼メールの読解・案件登録はAIが完結（➀）し週次でサンプル監査。型番特定や見積書のドラフト作成はAIが案を出し人が確定（➁、対外送信は不可逆なので人を残す）。ボリュームの大きかった「基準内価格の全件上長承認」は廃止し、粗利率基準を下回る特価だけを人が例外判断する➃型に切り替えます。この設計では、最大の効果はAI化そのものより「基準内は全件承認しない」という設計判断から出ています。
例➁:経費精算業務
「正当な経費が、規程に沿って、月内に精算されること」を目的とした再設計です。領収書の読み取り・起票はAIが完結（➀）、規程との整合チェックはAIが全件照合して逸脱・低確信だけを経理担当に回す➃型。1段目の上長承認は、基準内（例:5万円未満かつ規程適合）を自動承認とし、閾値超・例外のみを人へ。経理部門の全件再チェックは月次サンプル監査へ縮小します。支払実行だけは不可逆操作の直前として人の確定を残します（4基準の「不可逆性」）。例外設計として、慣行的に口頭で回っていた経路を正式な人間ルートとして定義しておくのがポイントです。
どちらの例でも共通するのは、効果の源泉がAIの導入そのものではなく、「どこをやめ、どこに人を残すか」という設計判断にあるという点です。ゼロベースで目的から描き、役割を型で分け、人を残す基準を明文化し、例外と責任まで設計する ― この順序を踏むことで、AIは「入れたけれど楽にならない」から「業務が本当に変わる」に届きます。