はじめに

補助金の申請業務を例に、少し回り道な話をします。

申請を受け付けて、書類を形式チェックして、基準と突き合わせて、審査して、採否を決めて、通知して、入金する。BPOの現場では、こうした業務を手順書に落とし、役割を分けて回しています。

この標準化された業務を、システムに載せて効率化したい、という話はよく出ます。ただ、現場でその様子を眺めていると、システム化したあとに「過去が読めなくなる」場面に何度か出くわします。動いてはいるけれど、なぜその結果になったのかを誰も説明できない、という状態です。

おかしな話です。標準化は、本来その逆をやろうとしていたはずでした。この記事は、その引っ掛かりを設計思想の観点からほどき、最終的にAIを使った発展形まで一本の線でつないでいきます。

BPOの標準化は、もともとブラックボックスへの抵抗だった

BPOの現場では、属人化は基本的に悪として扱われます。担当者が異動・退職した瞬間に、その人の頭の中にあった業務が消えてしまうからです。

だからこそ手順書を書き、役割を分け、誰がやっても同じ結果になるようにします。BPOの標準化は、効率化のためというより、業務の意味を人の頭の外へ出すための工夫でした。一人の中に閉じていた判断やコツを、外から読める形に開いておく営みです。

[申請受付] → [形式チェック] → [突合] → [審査] → [決定] → [通知] → [入金]
   担当A       担当B        担当C    担当D   担当E   担当F   担当G

ところが、この標準化された業務をシステムに載せると、皮肉なことに、再びブラックボックスが生まれることがあります。人の属人化を解消したはずが、今度はシステムの中に業務の意味が埋もれていきます。

三段階で考える ― 人の手、RPA、システム化

人の手で回している業務を、いきなり本格的なシステムに載せ替えるのは飛躍が大きすぎます。間に一段挟むと、移行はずっと自然になります。

人の手(標準化。意味は手順書と人の頭の中にある)
   ↓
RPA(自動化しながら、設計思想の棲み分けを実地で確かめる)
   ↓
システム化(確かめた棲み分けが、そのまま本実装の設計思想になる)

第一段階は人の手です。標準化はされていても、業務の意味は手順書と担当者の頭の中にあります。

第二段階はRPAです。RPAは、人の作業をそのままの形で自動化できるため、本格的なシステムを作る前に小さく試せます。そしてここが肝心で、RPA化のときに「どの工程をデータの流れに乗せて自動化し、どの工程は人の判断として残すか」を実際に切り分けることになります。これは後で述べる設計思想の棲み分けを、低コストで予行演習している段階です。

第三段階がシステム化です。RPAで棲み分けと業務理解が固まった状態で、本格的な実装に移ります。第二段階で確かめた判断が、そのまま本実装の設計思想になるため、移行が滑らかになります。

二つの設計思想 ― データ駆動設計とDDD

棲み分けの軸になる設計思想を、二つ取り上げます。データ駆動設計と、DDD(ドメイン駆動設計)です。

なお、ここでのDDDは厳密な実装手法そのものではなく、「業務の意味と判断の根拠を設計に残す」という発想として援用しています。

データ駆動設計 は、データの構造と状態の流れで業務を動かします。「ステータスがチェック済になったら次へ」というように、データが処理を駆動します。速くて素直です。
DDD は、業務の意味と判断の責務を中心に据えます。「この工程は何を判断する行為で、その根拠は何か」を、設計に残します。手間はかかります。

この二つは、業務をシステムに委ねる担当者にとって、「覚悟」と「保険」 の違いだと捉えています。

工程ごとに、思想を使い分ける

補助金業務の工程を、この観点で整理します。

工程	性質	設計思想	理由
申請受付	定型・データ入力	データ駆動でよい	流れに乗せれば足りる
形式チェック	定型・ルール明確	データ駆動でよい	判定根拠が単純
基準との突合	半定型	境界線	ルールは明示管理する
審査	非定型・判断	DDD寄りで残す	判断の根拠が本体
決定	責任を伴う判断	DDD寄りで残す	説明責任・追跡の核
通知	定型・文書生成	データ駆動でよい	決定を差し込むだけ
入金	定型・データ処理	データ駆動でよい	二重チェックは残す

定型工程は、データの流れに委ねて構いません。ここはデータ駆動設計の「覚悟」、つまり中身が見えにくくなることを受け入れてでも速さを取る判断が合理的です。

問題は審査・決定です。ここをデータの流れに溶かすと、なぜその判断に至ったかが残りにくくなります。データ駆動設計は、データの形は表せても、判断の意味までは表しづらいからです。

実際にあった話 ― リプレースで、過去が読めなくなる

判断の根拠を残すことにこだわる理由は、観測者として見たある出来事にあります。クライアント側で、ベンダーがシステムを刷新する様子を眺めていたときの話です。

リプレースの際、旧システムからの移行で戻入(本来の還付とは逆向きの、過払い回収のような事象)が発覚しました。誰が見ても「おかしい」と分かりました。ところが、なぜそうなったのか、原因が特定できませんでした。

旧システムは、データの流れで処理を回す作りでした。動いている間は問題ありません。ですが、どの工程のどの判断でその値になったのか、という意味が残っていませんでした。そのため、数年越しに異常が表面化しても、データから原因を遡れません。結局、人間が業務知識を総動員して、一から再チェックすることになりました。

戻入が発覚したとき、クライアントの担当者は頭を抱えていました。原因の分からないまま、ベンダーには強い調子で対応を求めていました。そしてそのプレッシャーは、皮肉なことに、刷新を担う後のベンダーへと向かっていきます。二度とこういうことが起きないように、と完璧な設定を求められ、その現場は日々ぴりぴりしていました。前のベンダーの残した「読めなさ」が、無関係な後のベンダーの重荷になっている。BPO事業者としてその様子を眺めていて、私は後のベンダーにいくらか同情していました。

ここで誤解のないように補足します。DDDで作れば自動的に追跡できる、という単純な話ではありません。追跡可能性を得るには、業務ルールの明示的な管理や、判断の履歴を残す仕組みなど、相応の設計が別途必要です。ただ、DDDそのものが追跡可能性を保証するわけではありません。それでも、業務ルールと判断根拠を設計の対象として扱う発想は、少なくとも過去を読み解くための土台にはなり得たはずだ、と感じています。

トレードオフ:覚悟か、保険か

二つの構えを、あらためて並べます。

データ駆動設計は「覚悟」です。 データの流れに業務を委ね、速さと効率を取ります。ただし、異常が出たときやリプレースのときには、中身を自分たちで解読する覚悟が必要になります。委ねた以上、見えにくくなることを引き受けます。

DDDは「保険」です。 業務の意味と判断の根拠を、人が読める形で残します。手間はかかります。ですが、担当者が抜けても、監査が来ても、いつかシステムを刷新するときも、過去を読み解く手がかりが残ります。

どちらが正しいという話ではありません。定型で、流れが単純で、間違えても痛手が小さい工程は、覚悟して委ねれば十分です。判断を伴い、後から根拠を問われ、いつか必ず刷新が来る工程は、保険をかけて意味を残します。

発展形 ― AIドリブンなBPOへ

ここまでで、審査・決定をDDDで残す意味を述べました。実は、この「意味を残す」という選択は、リプレースの保険になるだけではありません。その先のAI活用の土台にもなります。

システム化が済んだあと、DDDで残した審査・決定の領域は、人とロジックの判断領域として生き続けます。そこへ、次のような構成を重ねていくのが理想形だと考えています。

① 基幹システム(システム化済みの定型工程)
   申請受付 / 形式チェック / 突合 / 通知 / 入金
        │  申請データ・処理結果を出力
        ▼
② Power Automate(オーケストレーター/司令塔)
   各部品を呼び出し、流れを統括する
        │
        ├──▶ ③ LLM(Copilot等) ──┐
        │     申請内容を評価軸に照らす  │ 参照
        │                           ▼
        │     ④ RAG ─ Azure上の評価軸データを検索
        │       (DDDで残した判断基準が源泉)
        │
        │  最適化された「審査結果の案」
        ▼
⑤ 人による最終判断・決定(責任の所在)
   案を検証し、採否と根拠を確定して記録する

ここでRPAの役割が一段進化します。前半でRPAは定型工程を自動化する道具でした。この発展形では、RPA(Power Automate等)はシステム出力・AI・RAGといった部品を束ねるオーケストレーターになります。踏み台ではなく、全体を統括する司令塔です。

そして、ここでDDDの意味が回収されます。AIに審査を手伝わせるとき、RAGで読み込む「評価軸データ」とは、まさにDDDで残した業務の判断基準そのものです。判断の根拠を構造化して残しておいたからこそ、それをAIに評価軸として渡せます。 もしデータ駆動設計でブラックボックスに溶かしていたら、AIに渡すべき評価軸を取り出すことすらできません。意味を残す選択が、そのままAI活用の前提条件になっているわけです。

ひとつだけ、前半の主張と矛盾しないよう線を引いておきます。ここでAIが出すのは、あくまで最適化された審査結果の案です。最終的な判断と責任は人が持ちます。AIは判断を助け、人が決める。この一線を守る限り、AIドリブンへの発展と、説明責任の堅持は両立します。審査をブラックボックスに戻すためにAIを使うのではなく、人の判断を支えるためにAIを使う、という位置づけです。

おわりに

補助金のような業務では、判断の根拠を残すこと自体が成果物になります。効率の最大化よりも、後から追跡できることのほうが重い場面があります。

BPOはもともと、人の頭の中のブラックボックスを開くために標準化してきました。その標準化の段階で、あらかじめエンジニアの設計思想を業務の根本に組み込んでおくと、RPAでの自動化、本格的なシステム化、そしてAIドリブンな発展へと、各段階が地続きにつながっていきます。

意味を残しながら作られた業務は、リプレースもしやすく、担当者が代わっても引き継げ、いずれAIに評価軸を渡すこともできます。

振り返ると、BPOの標準化とは、人の頭の中に閉じた業務を外へ取り出すための営みでした。そしてDXやAIの時代になっても、その本質はあまり変わっていないように思います。

標準化とは、今も昔も、ブラックボックスへの抵抗なのかもしれません。