「人が足りない」を乗り越える。業務とデータをつなぐシステム統合

01SaaSの数ではなく、分断の数を測る

現場の負荷は、契約しているツールの数だけでは分かりません。調べるのは、同じ顧客名を何回入力しているか、ステータスの定義が何種類あるか、月末に何件を手で照合しているか、の3点です。分断点ごとに、誰が、どの情報を、どの判断で次の工程へ渡しているかを記録します。

分断を測る前に、人が足りない現実のほうが先に来ます。帝国データバンクが2026年4月16日から30日に全国23,083社へ行い、10,538社から回答を得た調査（回答率45.7%）では、正社員が不足していると答えた企業は50.6%でした。4月として4年連続で半数を超えています。情報サービスや運輸、倉庫など7業種では6割以上に達しました。人を増やして分断を埋める前提は、もう置けません。

棚卸しで集めるのは、人がデータを運んでいる箇所の一覧です。1行に1つの受け渡しを書き、下の雛形の列を埋めていきます。業務全体を洗い出す手順は「業務棚卸のやり方」で扱っています。

「作業の種類」は転記、照合、確認から1つを選びます。1つの受け渡しに2つの作業があるときは行を分けます。「判断の基準」が空欄になる行は、担当者の経験で処理している箇所です。そこが、システムをつなぐ前に定義を決めるべき候補になります。

02記入例：受注から入金消込までの分断点

以下は架空の例です。BtoBで役務を販売する会社の経理部門を想定し、受注から請求、入金消込までの流れに雛形を当てはめました。件数は記入のしかたを示すための例であり、実在の会社の数値ではありません。

この例で目を引くのは、No.2の「判断の基準」が空欄になっている点です。請求先や支払期日の決め方が書かれておらず、前月の請求書を見て担当者が判断しています。また、顧客名は営業管理SaaS、販売管理システム、請求書発行サービス、会計ソフトの4か所に入力され、No.3では振込名義との照合にも使われています。顧客名の正本がどこかを決めないまま連携を作ると、表記の揺れがそのまま4つのシステムに広がります。

棚卸し表ができたら、件数の多い行から手を付ける必要はありません。先に見るのは、判断の基準が空欄の行と、同じデータが何度も現れる行です。前者は手順の定義が要る箇所で、後者は正本を決めるべき箇所です。

03データの正本と責任者を決める

顧客、案件、契約、請求などの主要データごとに、一つの正本と更新責任者を決めます。画面上で同じ情報が見えていても、更新権限と反映のタイミングが曖昧なら統合とは呼べません。

連携先には識別子、更新日時、更新元を渡し、競合したときの優先順位を定義します。人が例外を修正する窓口も一つに絞ります。下の表は、この3つを1行で決めるための雛形です。

1行目は、先の架空の例にあわせた記入例です。表を埋めるときは、「正本のシステム」と「更新責任者」を必ず1つずつに絞ります。2つ書きたくなる場合は、データの単位が大きすぎる可能性があります。例えば顧客を「取引先の基本情報」と「請求先」に分けると、それぞれの責任者を1人に決めやすくなります。

更新責任者を決める作業は、内部統制の職務分掌とも重なります。あとでAIに更新を任せる段階が来たときに、誰が承認するかをこの表から決められるようにしておきます。

04マスターは運用の中で崩れていく

データの不整合は、システムを入れた時点では見えません。運用を続けるうちにマスターが少しずつ崩れ、拠点ごとに項目の名前や粒度がずれていきます。サステナビリティ開示のデータ集計では、名前の違う同じ項目を本社で寄せ直す作業が、毎回の例外処理として残ります。

これを防ぐには、導入の時点でマスターの体系と統制のルールを決めておきます。業務側のルール（業務統制）とシステム側の制御（システム統制）を両方入れることで、ルールを上から担保できます。片方だけでは、運用の中でまた崩れます。

ただし統制を強くしすぎると、入力や更新の手間が増えて業務の効率が落ちます。効率を主に置き、制度が求める正確性、網羅性、妥当性の分だけ統制を足すという加減で設計してください。

05業務イベントを中心に接続する

「受注した」「承認された」「入金された」といった業務イベントを起点に、必要な処理をつなぎます。画面同士を直接結ぶより、イベントと状態遷移を共通化したほうが、システムを入れ替えるときの影響を小さくできます。

イベントごとに、確定の条件、次に動く処理、重複を防ぐ識別子、失敗したときの再実行を決めます。同じイベントで処理が2回走ると、請求書が二重に発行されます。そのため、再実行の列にはどの識別子で重複を防ぐかを必ず書きます。

AIはイベントの解釈や例外の分類を支援できます。例えば、振込名義が請求先と一致しない入金を「名義の表記違い」「別の請求との合算」「不明」に分ける作業です。ただし、状態を確定する条件と再実行のルールは業務側で表に書いておきます。AIの分類結果は提案として扱い、状態を確定するのは表の条件を満たしたときだけにします。

06段階移行と戻し方を設計する

一括で移行せず、読み取り、提案、承認付き更新、自動更新の順に権限を広げます。各段階で旧運用と結果を比較し、差異が出た場合に元の処理へ戻せる状態を保ちます。

次の段階へ進む基準は、稼働前に決めておきます。「どの期間、どの差異までなら進む」を数字で書き、関係者の合意を取ります。月次で回る業務なら、少なくとも1回の締めをまたいで結果を確かめてから次へ進みます。

連携が止まったときの手動手順、未処理データの再送方法、責任者への通知も、稼働前に確認します。旧運用の手順書は、そのまま使える状態で残しておきます。

07棚卸しの下書きをAIに作らせる

棚卸し表の最初の下書きは、生成AIに作らせると早く進みます。業務の流れを箇条書きで渡し、雛形の列に沿って整理させます。社内の業務手順にAIを組み込む考え方は「生成AIを組み込んだ社内ワークフロー」で扱っています。

出てきた表は下書きとして扱います。件数と判断の基準は、AIが推測で埋めやすい列です。プロンプトで「要確認」と書くよう指示し、担当者への確認で埋めることを前提にします。

あなたは業務プロセスを整理する担当者です。以下の業務の流れから、人がデータを運んでいる箇所（分断点）を洗い出してください。

# 出力の形式
次の列を持つMarkdownの表にしてください。
No | 業務 | 受け渡し元システム | 受け渡し先システム | 運んでいるデータ | 担当者 | 作業の種類（転記、照合、確認のどれか1つ） | 1か月の件数 | 判断の基準 | 不一致が起きたときの対応

# 守ること
- 1行に1つの受け渡しを書く。1つの受け渡しに2つの作業があるときは行を分ける
- 業務の流れに書かれていない情報は推測で埋めず、「要確認」と書く
- 表のあとに、同じデータが3回以上現れる箇所と、判断の基準が「要確認」の行を列挙する

# 業務の流れ
（ここに業務の流れを箇条書きで貼り付ける）

08統合後に見るべき指標

処理時間だけでなく、転記回数、データ不一致、承認待ち、例外の再作業を測ります。経営側には意思決定に必要な情報が揃うまでの時間を、現場側には一件を完了するための操作数を示します。

統合の前に、棚卸し表の「1か月の件数」を基準値として残しておきます。統合後に同じ表をもう一度埋めれば、どの分断点が消えたかを行単位で確かめられます。経営側と現場側の両方の指標が改善して初めて、統合が事業の処理能力につながったと判断できます。

• 転記回数：同じデータを人が入力し直した回数
• データ不一致：正本と他のシステムの値が食い違った件数
• 承認待ち：承認者の手元で止まっている件数と日数
• 例外の再作業：自動処理から外れて人がやり直した件数
• 判断までの時間：経営側が必要な情報を揃えるまでにかかった日数