新しいアプリをERP、会計、既存データとつなぐ：バイブコーディングが最も役に立たない仕事

要点

会計システムや在庫システムとつながっていない新しいアプリを入れると、社員は同じデータを2か所に入力することになり、やがて両方の数字が合わなくなります。
連携する前に、データの種類ごとにどのシステムを正とするのか、送信に失敗したら何が起きるのかを決めておく必要があります。
連携の仕組みを作る前に、2つのシステムの数字を突き合わせるレポートを完成させておけば、問題は締め日を待たずにその日のうちにわかります。

問題の多くはシステムのつなぎ目で起きる

よくあるのは、営業担当が新しいアプリで注文を受け、そのあと経理担当が同じ伝票を会計ソフトにもう一度入力する光景です。こうして会社には、一致するはずなのに一致させる仕組みが何もない、2組の数字ができあがります。人が二重に入力するたびに、2組の数字は少しずつずれていくおそれがあります。

症状はたいてい遅れて表に出ます。忙しい日に注文が1件抜け落ちたり、誰かがERPの側だけで価格を直したためにアプリには先月の価格が残っていたり、アプリの在庫表示が実際の倉庫より半日遅れていたりします。月末になると、経理担当は差額がどの伝票から来ているのかを探すのに何日も費やします。

この部分は、バイブコーディングがあまり役に立たない仕事です。APIの説明書がしっかりしていれば、AIはAPIを呼び出すコードをとても速く書けます。しかし、システム連携に必要な知識の大半は、文書になったことがありません。たとえば、営業と倉庫で別々の商品コードを使っていたり、かつて3つの支店から請求書を出していたせいで同じ顧客に3つのコードがあったり、経理が10年前から備考欄に顧客の発注書番号を入れていたりします。こうした事情は、働く人の頭の中と古いデータの中にしかありません。誰かが直接聞いて回り、データを開いて確かめる必要があります。

連携の仕組みを作る前に答えておくべき4つの質問

システム連携は、2つの部署に同じ帳簿を使ってもらうのに似ています。始める前に、誰が書き込むのか、誰が読むだけなのか、いつ書き込むのか、書き間違えたら誰が直すのかを決めておかなければなりません。この4つの質問には事業部門が答える必要があり、技術チームが代わりに答えることはできません。

データの種類ごとに、どのシステムを正とするか

どのデータにも、本物とみなすシステムが1つだけあるべきです。そこにあるデータを、正となるデータ（Source of Truth）と呼びます。たとえば、販売価格はERP、在庫数は倉庫システム、顧客の連絡先はアプリを正とします。ほかのシステムは読んで使ってもよいものの、書き換えてはいけません。2か所で書き換えられるようにしてしまうと、どちらの数字が正しいのか誰にも答えられなくなります。

いつ、どの方向に送るか

ほぼリアルタイムで届く必要があるデータもあります。売れ行きの速い商品の在庫などです。会計に計上する売上のように、夜間にまとめて送れば足りるデータもあります。送る頻度を上げるほどシステムは複雑になり、費用もかさみます。送る間隔は、データが遅れたときの損失をもとに決めるべきです。

送信に失敗したら何が起きるか

通信が途中で切れるのはよくあることです。そのため送信元のシステムは再送できなければならず、しかも再送しても2枚目の伝票ができてはいけません。この性質を冪等性（Idempotency）と呼びます。何度送っても失敗する項目は人の目に入る場所にとどめ、担当者の名前をつけて対応してもらう必要があります。

誰が、いつ数字を確認するか

今日は正しく動いている連携の仕組みも、誰かが新しい種類の値引きを追加した日に間違い始めるかもしれません。2つのシステムの数字を毎日突き合わせて差を確かめる作業を、突合（Reconciliation）と呼びます。突合はシステムの一部であり、稼働初日から用意しておくべきです。

連携の方法	向いているケース	注意点
連携先システムのAPIを呼び出す	システムにAPIがあり、ベンダーもその利用をサポートしている	1日あたりの呼び出し回数の上限と、APIモジュールのライセンス料
ファイルを定期的にインポート・エクスポートする	古いシステムにAPIはないが、ファイルの取り込みはできる	データは送る間隔の分だけ遅れ、取り込みに失敗したファイルの扱い方も決めておく必要がある
既存システムのデータベースを直接読む	ほかに方法がなく、システムのベンダーも了承している	直接書き込むとデータを壊すおそれがあり、利用規約に違反する可能性もあるため、読み取りだけに限るべき
人の代わりにプログラムに画面を操作させる	ほかのどの方法も使えず、作業量が少ない	既存システムの画面が変わると動かなくなる

開発チーム向け · 技術的な詳細

伝票ごとに冪等キー（Idempotency Key）を付け、Outboxとメッセージキューを経由して送ります。リトライにはバックオフをかけ、人が処理するための画面を備えたデッドレターキューを用意します。商品コードと顧客コードの対応表は中間層に置き、受信データのスキーマを検証します。キューの遅延とエラー率を監視し、ベンダーのAPIにはコントラクトテストを用意して、仕様の変更を本番環境に届く前に検知します。

架空のケース

建材の卸売会社と、2回届いたセメント

ある建材の卸売会社が、取引先の販売店が自分で発注できるアプリを作りました。アプリはAPI経由で注文をERPに送ります。大雨の日、倉庫のインターネット回線が断続的に切れました。アプリは注文を送ったものの、応答を待つうちにタイムアウトとなり、設定どおりに注文を再送しました。ERPは同じ注文を2回受け取って出荷指示書を2枚発行し、セメントを積んだトラックが同じ店に2回向かうことになりました。会社が気づいたのは、店主から2便目の受け取りを断る電話がかかってきたときでした。

チームは2か所を直しました。1つ目は、再送のたびにアプリが元の参照番号を付け、受信側が伝票を作る前にその番号を確認するようにしたことです。2つ目は毎朝実行する突合レポートで、前日の注文件数と金額をアプリとERPの間で突き合わせます。このレポートは翌週、別の種類の問題も見つけました。アプリではキャンセルされたのにERPには残ったままの注文です。それまで、こうしたことが起きていると知っている人はいませんでした。

連携の前に数字を突き合わせる

システムをまたいで流れる伝票を1種類選びます。たとえば受注伝票です。
両方のシステムで毎日一致すべき数字を決めます。たとえば伝票の枚数、合計金額、商品コードごとの数量です。
2つのシステムから数字を取り出して並べるレポートを作り、先月の手入力データで試します。
レポートが見つけた差を1件ずつ読みます。その1件1件が、連携の仕組みが対応すべきルールになります。
連携の仕組みを稼働させたら、レポートを毎朝実行し、その日のうちに差を解消する担当者を名前で決めます。

記録として残すべきなのは、日ごとの差の件数と、1件ごとの解消にかかった時間です。この方法がうまくいかないのは、2つのシステムが同じ言葉を別の意味で使っている場合です。たとえば、一方の売上は税込みで、もう一方は税抜きといった具合です。その場合は、先に経理部門が定義を決めておく必要があります。

古いデータの移行は、最も甘く見積もられやすい

新しいシステムを既存システムの顧客データ、商品データ、残高から始める場合、データ移行には誰の予想よりも時間がかかります。古いデータには重複も空欄もあり、入力した人の時代によって形式も変わっているからです。

安全な進め方は4段階です。まず、データをきれいにします。重複をまとめ、必須の項目を埋める作業です。次に、既存システムのどの項目を新システムのどの項目に入れるかの対応表を作ります。これをデータマッピング（Data Mapping）と呼びます。3段階目では試験的に移行し、データの責任者にサンプルを確認してもらいます。最後に、しばらく2つのシステムを並行して動かしてから新システムに切り替えます。切り替え当日に問題が起きた場合に備えて、元に戻す計画も用意しておきます。

古いデータは、きれいにし、重複をまとめ、整理してから新しいシステムに移す必要がある

次のどれか1つでも当てはまるなら、システム連携への投資はまだ早い

伝票の量が少なく、週1回の手入力のほうが、連携の仕組みを作って保守する費用より安い
1年以内に連携先のシステムを入れ替える予定がある
2つのシステムの数字が食い違ったときに判断できるデータの責任者がまだいない
既存システムのベンダーが連携を許可していない、または対応していない

効果を測るときは、経理部門と業務部門が実感できる数字を見てください。なくなった二重入力の時間、1日あたりの差の件数、差の解消にかかる時間、月末の締めにかかる日数です。2週間並行稼働しても差が減らなければ、切り替え日を先に延ばし、どのルールにまだ対応できていないのかを見直します。

DNA MAKER · SYSTEM INTEGRATION

新しいアプリと既存システムが同じ数字を出すようにする

勘定科目と仕訳のルールを管理しているのは、自社の経理部門です。商品コードと在庫の数え方は倉庫部門が管理していて、ERPベンダーは自社システムの制約を知っています。DNA Makerはこの3者と一緒に1枚の伝票を最初から最後まで追いかけ、つなぎ目の図に書き起こします。どの項目がどの項目に入るのか、データの種類ごとにどのシステムを正とするのか、1回に何件ずつ送るのか、送信に失敗したら誰が何をするのか、を示した図です。

その図をもとに、私たちはキュー、伝票を重複させない再送、コードの対応表、日次の突合レポートを備えた連携レイヤーを作り、経理部門が処理待ちの項目を確認できるダッシュボードも用意します。作業は1種類の伝票から始めます。差がゼロの状態が続くまで手入力と並行して動かし、それから新しいシステムに切り替えて、次の種類の伝票に広げます。社内で最も二重入力の多い伝票があれば、その伝票のサンプル10枚を両方のシステムから出して、ご相談ください。

SOFTWARE ENGINEERING GLOSSARY

ソフトウェア開発用語集

システム連携を計画するときに、開発チームや既存システムのベンダーとの話に出てくる用語です。右の列の質問を使うと、各工程の責任者が誰なのかがわかります。

用語	意味	わかりやすい例	開発チームへの質問
Reconciliation	2つのシステムの数字が一致しているかを突き合わせ、合わない項目の原因を突き止めること	毎朝レポートが、前日の注文件数と金額をアプリとERPの間で突き合わせる	差を解消するのは誰で、何時間以内に解消しなければなりませんか？
Data Migration	既存システムから新しいシステムへデータを移すこと。移行前のデータの整理と、移行後の確認も含む	重複をまとめたうえで、顧客8,000件分のリストを新しいシステムに移す	移行後、データがすべてそろい、残高が既存システムと一致していることを、どう確かめますか？
Data Mapping	あるシステムのどの項目が、別のシステムのどの項目に対応するかを示す表	営業の商品コードと倉庫の商品コードを1件ずつ対応させる	この表の責任者は誰ですか？新しい商品ができたとき、誰が追加しますか？
Middleware	あるシステムからデータを受け取り、形式を変換して別のシステムに渡す中継ソフト	中継ソフトがアプリから注文を受け取り、商品コードを変換してERPに送る	中継ソフトが止まったら、処理待ちの項目はどこにたまり、誰に通知が届きますか？
Message Queue	2つのシステムの間でデータを一時的に預かる場所。項目は送信待ちの列に並び、受信側が一時的に止まっても消えない	ERPがメンテナンスで1時間止まっている間、注文はキューで待ち、システムが戻ると順に取り込まれる	業務に支障が出るまでに、キューはどのくらい長くなってもよいですか？それは何を見ればわかりますか？
Parallel Run	既存システムと新しいシステムをしばらく同時に使い、結果を比べてから既存システムをやめること	連携の仕組みが動いている間も、経理部門がさらに2週間手入力を続け、毎日数字を突き合わせる	並行稼働をやめてよいと判断する基準は何ですか？誰が判断しますか？
Cutover	既存システムから新しいシステムへ実際に切り替える時間帯	土曜の夜に2時間だけ受注を止めて残高を移し、日曜の朝に新しいシステムを公開する	切り替えの夜に問題が起きたら、何時まで元に戻せますか？誰が指示を出しますか？

明日試せること：営業部門と経理部門に、それぞれのシステムから昨日の受注伝票の枚数を数えてもらい、数字を比べてください。合わなければ、抜けている伝票を1枚、原因がわかるまで追いかけます。その原因が、連携の仕組みが対応すべき最初のルールです。