全社コード体系の変更を各業務システムへ確実に反映し集計ミスと誤請求を防ぐ方法

企業が成長するにつれ、商品コード・勘定科目コード・取引先コードなどの全社コード体系を見直す場面は避けられません。しかし、コード体系の変更を決定しても、販売管理・会計・在庫管理といった各業務システムへの反映タイミングがバラバラになり、新旧コードが混在する期間が生まれます。この混在期間に集計ミスや取引先への誤請求が発生し、最悪の場合は決算数値の修正や取引先からの信用失墜につながります。

本記事は、従業員50〜500名規模の企業で、情報システム部門や経営管理部門としてコードマスタの管理・展開を担当している方を想定しています。読み終えると、コード変更の決定から各システムへの展開・新旧コード変換・移行完了確認までを一気通貫で管理するワークフローを自社に導入できるようになります。なお、数千人規模のエンタープライズ向けの大規模MDM専用製品の導入計画や、個別業務システムの内部設定手順は扱いません。

本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、コード変更の起案から全システム反映完了までを管理するワークフローの設計図と、各ステップで使うツールの選定基準が手に入ります。

Workflow at a glance: 全社コード体系の変更を各業務システムへ確実に反映し集計ミスと誤請求を防ぐ方法

• Step 1: コード変更を起案し承認を得る (ジョブカンワークフロー) (ワークフローシステム)
• Step 2: マスタデータの正本を更新し変換テーブルを登録する (マネーフォワード クラウドERP) (ERP)
• Step 3: ERP外の業務システムへ変更を自動配信し反映状況を確認する (Zapier) (ノーコード・ローコード開発)

なぜコード体系の変更は各システムに正しく反映されないのか

変更の決定と展開が分離している

コード体系の変更は、経営管理部門や経理部門が主導して決定することが多い一方、実際にシステムへ反映する作業は情報システム部門や各部門の担当者が個別に行います。この決定と展開の間に正式な引き継ぎプロセスがないと、変更内容の伝達漏れや解釈のズレが起こります。たとえば、勘定科目コードの統合を経理部門が決定しても、販売管理システム側では旧コードのまま伝票が起票され続けるといった事態が典型です。

新旧コードの変換ルールが属人化している

移行期間中は、旧コードで入力されたデータを新コードに読み替える変換ルールが必要です。しかし、この変換ルールがExcelの対応表として個人のPCに保存されていたり、担当者の頭の中だけにあったりすると、他の担当者が正しく変換できません。結果として、同じ取引先に対して旧コードと新コードの両方で請求書が発行される、部門別の売上集計で二重計上や計上漏れが起きるといった実害が出ます。

反映完了の確認手段がない

各システムへの反映が完了したかどうかを確認する仕組みがないと、一部のシステムだけが旧コードのまま取り残されます。特に、部門独自で導入したSaaSや、長年使い続けているAccessデータベースなどは見落とされがちです。全システムの反映状況を一覧で把握できなければ、移行完了宣言を出すこともできず、新旧混在の期間がずるずると延びていきます。

重要な考え方：コードマスタを一箇所で管理し変更を各システムへ自動配信する

コード体系の変更を確実に反映するために最も大切な原則は、コードマスタの正本を一箇所に集約し、そこから各業務システムへ変更内容を自動的に配信する仕組みを作ることです。この原則を守れば、変更の伝達漏れや反映タイミングのズレを構造的に防げます。

正本は1つだけにする

コードマスタの正本が複数存在すると、どれが最新かわからなくなります。ERPのマスタテーブルを正本とし、他のシステムはすべてそこから同期を受ける側にするのが基本です。ERPを導入していない場合でも、1つのデータベースやスプレッドシートを正本と定め、他のシステムへの反映はすべてそこを起点にします。

変更プロセスを承認フローに乗せる

コード変更は影響範囲が広いため、担当者が単独で実行するのではなく、必ず承認フローを通す必要があります。起案・影響範囲の確認・承認・展開指示という流れをワークフローシステムで管理すれば、誰がいつ何を承認したかの記録が残り、変更の抜け漏れを防げます。

変換ルールと移行期間を明示的に管理する

新旧コードの変換ルールは、正本のマスタデータに変換テーブルとして組み込みます。移行開始日と移行完了予定日を明示し、移行期間中は自動変換を適用することで、手作業による変換ミスを排除します。

コード変更を全システムへ確実に届ける実践ワークフロー

ステップ 1：コード変更を起案し承認を得る（ジョブカンワークフロー）

コード体系の変更が必要になったら、まずジョブカンワークフローで変更申請を起票します。申請フォームには、変更対象のコード種別（商品コード・勘定科目コード・取引先コードなど）、変更内容（統合・分割・新設・廃止）、影響を受けるシステムの一覧、移行期間の希望日程を記載します。

申請は、経営管理部門の責任者と情報システム部門の責任者の両方が承認する二段階承認とします。承認が完了すると、情報システム部門の展開担当者に自動通知が届きます。この承認記録が、後から変更の経緯を追跡する際の証跡になります。

実務上のポイントとして、影響を受けるシステムの一覧は、事前にシステム台帳を整備しておくことで漏れなく記載できます。システム台帳がない場合は、まず主要な業務システムを洗い出すところから始めてください。

ステップ 2：マスタデータの正本を更新し変換テーブルを登録する（マネーフォワード クラウドERP）

承認が完了したら、マネーフォワード クラウドERPのマスタデータを更新します。具体的には、新コードの登録、旧コードの廃止予定日の設定、新旧コードの対応関係を示す変換テーブルの登録を行います。

変換テーブルには、旧コード・新コード・変換開始日・変換終了日の4項目を必ず含めます。たとえば、取引先コードT001をT100に統合する場合、旧コードT001、新コードT100、変換開始日4月1日、変換終了日6月30日と登録します。移行期間中にT001で入力されたデータは、集計時に自動的にT100として扱われます。

マネーフォワード クラウドERPを正本とすることで、会計・請求・経費精算といった同シリーズの機能には即座に変更が反映されます。問題は、ERPの外にある業務システムへの展開です。これを次のステップで解決します。

ステップ 3：ERP外の業務システムへ変更を自動配信し反映状況を確認する（Zapier）

マネーフォワード クラウドERPで更新したマスタデータを、ERP外の業務システムへ自動的に配信するためにZapierを使います。Zapierは、あるサービスでの操作をきっかけに別のサービスへデータを送る自動連携ツールです。

具体的には、以下のような連携を設定します。マネーフォワード クラウドERPのマスタデータが更新されたことをトリガーとして、販売管理SaaS（例：board、freee販売など）のマスタテーブルへ新コードを登録し、旧コードに廃止フラグを立てます。同時に、変更内容をGoogle スプレッドシートの展開管理台帳に自動記録します。

展開管理台帳には、対象システム名・反映ステータス（未着手・反映中・反映完了）・反映完了日・担当者の列を設けます。Zapierで自動反映できるシステムは反映完了が自動記録されますが、API連携ができないレガシーシステムについては、担当者が手動で反映した後にステータスを更新します。

毎週月曜日に展開管理台帳を確認し、未反映のシステムがあれば担当者にリマインドを送ります。このリマインドもZapierで自動化できます。全システムの反映が完了し、移行期間の終了日を過ぎたら、旧コードでの入力を完全に停止し、変換テーブルの変換終了日をもって移行完了とします。

この組み合わせが機能する理由

ジョブカンワークフロー：変更プロセスの証跡と統制を確保する

ジョブカンワークフローは、日本企業の承認文化に合った柔軟な承認ルート設定が可能です。二段階承認や条件分岐（コード種別によって承認者を変える等）を設定でき、コード変更のような影響範囲の広い変更に対して適切な統制をかけられます。承認履歴がすべて記録されるため、監査対応や変更経緯の追跡にも役立ちます。

一方で、ジョブカンワークフロー自体にはマスタデータの管理機能はありません。あくまで変更プロセスの管理と承認に特化したツールとして使い、マスタデータの実体はERPに持たせるという役割分担が重要です。

マネーフォワード クラウドERP：マスタデータの正本としての信頼性

マネーフォワード クラウドERPは、会計・請求・経費精算・給与といった複数の業務機能が統合されており、1つのマスタデータを複数の業務で共有できます。コードマスタの正本をここに置くことで、ERP内の業務については変更が即座に反映されます。

注意点として、マネーフォワード クラウドERPのAPI公開範囲には制限があります。すべてのマスタデータをAPIで取得・更新できるわけではないため、Zapierとの連携で自動化できる範囲は事前に確認が必要です。API連携ができない項目については、CSVエクスポート・インポートによる半自動運用を組み合わせることになります。

Zapier：異なるシステム間の橋渡しを低コストで実現する

Zapierの最大の強みは、プログラミング不要で異なるSaaS間のデータ連携を構築できる点です。情報システム部門に開発リソースが少ない中小企業でも、マスタデータの配信を自動化できます。

ただし、Zapierには明確な制約があります。まず、連携先のシステムがZapier対応のAPIを公開している必要があります。オンプレミスの基幹システムやAPI非公開のパッケージソフトには直接連携できません。また、無料プランではタスク数（実行回数）に上限があり、大量のマスタデータを頻繁に更新する場合は有料プランが必要です。さらに、Zapierはリアルタイム同期ではなく、数分程度の遅延が発生します。秒単位の同期が必要な業務には向きませんが、コードマスタの更新頻度を考えれば実用上は問題ありません。

API連携ができないシステムについては、Zapierから担当者へメール通知を送り、手動反映を促すという運用でカバーします。完全自動化にこだわるよりも、手動反映が必要な箇所を明示し、確実にフォローする仕組みを作ることが現実的です。

Recommended tool list

結論：コードマスタの正本を1つに定め変更を承認フローと自動配信で届ける

コード体系の変更が各システムに反映されない問題の根本原因は、正本の不在と展開プロセスの未整備です。ジョブカンワークフローで変更の承認プロセスを統制し、マネーフォワード クラウドERPにマスタデータの正本を置き、Zapierで各システムへの配信と反映状況の追跡を自動化する。この3つの組み合わせで、新旧コードの混在期間を最小化し、集計ミスや誤請求を防げます。

最初の一歩として、まず自社で管理しているコードの種類と、それを使用しているシステムの一覧を作成してください。この棚卸しができれば、どのコードから優先的に正本管理を始めるべきかが見えてきます。

Mentioned apps: マネーフォワード クラウドERP, ジョブカンワークフロー, Zapier

Related categories: ERP, ノーコード・ローコード開発, ワークフローシステム

Related stack guides: 輸出管理教育の受講完了と実務権限を自動連動させ未受講者による誤申請を防ぐ方法, 該非判定の根拠資料が散逸して再現できない問題を解消し監査対応を万全にする方法, 補助金の変更申請と実績報告の整合性を保ち事後監査での指摘と返還リスクを防ぐ方法, パートナーへの変更依頼が社内承認後に正しく伝わらない問題を解消し手戻りとプロジェクト遅延を防ぐ方法, 付議基準の属人判断による上程漏れをなくし取締役会のガバナンスと議論の質を守る方法