現場ではkintoneのようなツールで日報や案件管理を回しているのに、同じ数字を基幹システムにもう一度入力している。営業からは「つながらないんですか」と言われ、開発会社に相談したら「どこまでつなぎますか」と聞き返された。基幹システム連携を調べる方は、この「どこまで」が分からずに止まっていることが多いと思います。

先に押さえておきたいのは、連携は本数が増えるほど費用も障害点も増えるという性質です。全部つなげば楽になるわけではなく、つないだ数だけ「動かなかったときに気づく仕組み」が必要になります。だから最初にやるのは、二重入力が実際に起きている場所を数えて優先順位を付けることです。この記事では、範囲の絞り方、CSVとAPIとデータ連携ツールの選び分け、費用の考え方、そして依頼前に固める4つの要件を整理します。

この記事のポイント

  1. 連携は本数が増えるほど費用と障害点が増えるので、二重入力の実害が大きい順に絞る
  2. 方式はCSV・API・データ連携ツールの3つで、反映のタイミングと手作業の残り方が違う
  3. つなぐ前に取引先や品目マスタの主管を決めないと、データの不一致が必ず起きる
  4. 見積もりが出るには対象データ・方向・頻度・エラー時の扱いの4点が必要になる
目次
  1. 基幹システム連携はどこまで必要か
  2. つなぐ前に二重入力が起きている場所を数える
  3. 連携の方式は3つから選ぶ
  4. 現場ツールとつなぐならマスタの主管を先に決める
  5. つながなくてよいケース
  6. 基幹システム連携の費用と依頼前の要件
  7. 費用は連携の本数と方式で決まる
  8. 依頼前に固める4つの要件
  9. 連携でよく起きるトラブルと取り決め
  10. 基幹システム連携についてよくある質問
  11. 総括:基幹システム連携で先に決める判断軸

基幹システム連携はどこまで必要か

机に並べた2枚の一覧表をペンで指しながら、どちらのデータを基準にするかを2人で確認している場面
つなぐ前に「どちらのデータが正か」を決めておくと、後の不一致を防げる

まず範囲の決め方です。「全部つなぎたい」から相談を始めると、開発会社は最大の範囲で見積もるしかなく、金額が跳ね上がります。実害のある場所から順に絞っていきます。

つなぐ前に二重入力が起きている場所を数える

最初の作業は棚卸しです。どの業務で、どのデータを、月に何件、二重に入力しているのかを書き出します。感覚で「あちこちで二度手間がある」と言うのではなく、件数と時間で並べると優先順位が自然に決まります。

業務 二重入力の内容 月の件数の目安
受注 現場ツールに入れた受注を基幹にも入力 数百件
在庫確認 基幹の在庫数を見て現場ツールに転記 数十〜数百件
取引先の追加 新規取引先を両方に登録 数件〜十数件
月次の集計 基幹から出力して表計算で加工 月1回

この表を埋めると、上位2〜3本に絞れることがほとんどです。連携は1本ずつ増やせるので、いちばん件数の多いものから作って様子を見る進め方が現実的です。最初から5本も6本もつなごうとすると、テストの手間だけで計画が崩れます。

もうひとつ、参照だけで足りるものは連携でなくても解決します。基幹の数字を見たいだけなら、閲覧用の権限を渡す、定期的にCSVを出力して共有フォルダに置く、といった手段で済むこともあります。

連携の方式は3つから選ぶ

つなぐ方法は大きく3つです。反映のタイミングと、手作業がどこまで残るかが違います。

方式 反映のタイミング 費用感 向くケース
CSVの受け渡し 1日1回など、まとめて 低い 件数が多く、即時でなくてよい業務
API連携 ほぼ即時 中〜高(基幹側の改修次第) 在庫や受注をすぐ反映したい業務
データ連携ツール 設定した間隔または即時 月額と初期設定費 つなぐ先が複数あり、今後も増える見込み

注意したいのは、古い基幹システムには外部から呼べるAPIが用意されていないことが多い点です。その場合はデータベースを直接参照する、中間のテーブルやファイルを介する、といった作り方になり、基幹側の改修費が発生します。方式を決める前に「うちの基幹は外部と何ができるのか」を保守会社に確認しておくと、実現できない前提で話が進むのを防げます。

CSVから始めて、必要になったらAPIに寄せる進め方も十分あります。即時性が本当に必要かどうかは、業務側に「30分後の反映では困りますか」と聞いてみると案外あっさり決まります。

現場ツールとつなぐならマスタの主管を先に決める

kintoneのようなツールをフロントにして、入力や集計は現場ツール、正しいデータは基幹に置く、という使い方はよくあります。このとき絶対に先に決めておくのが、取引先や品目といったマスタをどちらで登録するかです。

両方で登録できる状態のままつなぐと、表記の違う同じ取引先が2つできたり、片方にしかない品目が出たりします。そうなると連携が止まるだけでなく、集計の数字も合わなくなります。「マスタの登録は基幹だけ、現場ツールは基幹から受け取って表示するだけ」のように、主管を1つに決めてください。

更新の方向も同じです。片方向で始めるほうが、難易度も費用も抑えられます。双方向は「どちらの更新を優先するか」の取り決めが必要になり、テストの量も一気に増えます。私の感覚では、最初から双方向を要件に入れた案件がいちばん揉めます。まず片方向で動かし、本当に必要になってから広げてください。

つながなくてよいケース

連携しないほうが安く済むこともあります。月1回の集計だけ、件数が月に数十件、あるいは参照するだけで更新はしない、といった業務です。連携には初期費用のほかに毎年の保守費がかかるので、手作業の時間と比べて割に合わないなら、そのままにしておく判断も合理的です。

もうひとつ、そもそも現場ツール側を見直したほうが早い場合があります。部門ごとに別のツールが増えて連携先が5つも6つもある状態なら、ツールを統合するほうが結果的に安くなることもあります。現場向けのツールを買うか作るかの線引きは業務改善システムは買うか作るか?既製ツールと開発発注の選び方で整理しています。

判断の目安は、連携しないことで毎月どれだけの時間を失っているかです。転記に月10時間かかっているなら年120時間で、費用と比べられます。この数字を出さずに「不便だから」で発注すると、費用の妥当性を社内で説明できません。

基幹システム連携の費用と依頼前の要件

紙に連携する項目とデータの流れる方向を矢印で書き出して整理している手元
対象データと方向を書き出すと、そのまま見積もり依頼の材料になる

次は費用と、見積もりが出るために必要な情報です。連携の見積もりは「つなぎたい」だけでは出せないので、何を渡せばよいかを押さえておきます。

費用は連携の本数と方式で決まる

費用は、連携1本ごとの作業量の積み上げで決まります。1本あたりの作業量は、扱う項目数、データの変換ルールの複雑さ、そしてテストの量で変わります。同じ受注データの連携でも、項目が10個か50個か、コードの読み替えが必要かどうかで金額は変わります。

方式による差も大きいです。CSVの受け渡しは比較的安く収まりますが、基幹側にAPIを新しく作る必要がある場合は、その改修費が上乗せされます。データ連携ツールを使う場合は月額の利用料が続く代わりに、本数が増えたときの追加が楽になります。つなぐ先が今後も増える見込みなら、ツールのほうが総額で安くなる分岐点があります。

忘れやすいのが保守費です。連携は作って終わりではなく、項目が増えるたびに改修が必要で、基幹側やツール側の更新に合わせた確認も発生します。開発全体の費用感を先に押さえたい場合は、システム開発の費用相場と内訳|規模別・種類別の目安を参考にしてください。なお金額の水準はあくまで一般的な目安で、実際の判断は個別の見積もりで確認する必要があります。

依頼前に固める4つの要件

連携の見積もりを取るには、次の4点が決まっている必要があります。ここが空白のまま相談すると、開発会社は最大の想定で見積もるか、そもそも金額を出せません。

連携の依頼前に決めること

  • 対象データ(どの伝票・どのマスタの、どの項目までをつなぐか)
  • 方向(基幹から現場ツールへ/現場ツールから基幹へ/双方向)
  • 頻度とタイミング(即時/1日1回/締め処理の後など)
  • エラー時の扱い(誰に通知するか、自動で再試行するか、手で直すのは誰か)

4つ目のエラー時の扱いは、いちばん抜けやすく、いちばん後で困る項目です。連携は必ずどこかで失敗します。ネットワークが切れた、想定外の文字が入っていた、基幹側がメンテナンス中だった。そのときに誰も気づかない設計になっていると、数日分のデータが欠けたまま業務が進みます。

この4点を書き出すときは、項目の抜けがないかを点検しておくと差し戻しが減ります。要件定義書レビューシート(8カテゴリ60項目)を使うと、非機能要件やエラー処理まわりの抜けを見つけやすくなります。

連携でよく起きるトラブルと取り決め

実際に起きるトラブルは、だいたい次の4つに集約されます。どれも設計前の取り決めで防げるものです。

ひとつ目はマスタの不一致で、これは前半で触れた主管を決めていない場合に起きます。ふたつ目は重複登録です。同じ受注が2回連携されてしまう問題で、何をもって同じデータと判定するかというキーの決め方で防ぎます。この判定ルールは業務側でしか決められません。

みっつ目はタイミングのずれです。月次の締め処理が動いている最中に連携が走ると、数字が中途半端な状態で渡ります。締めの時間帯は連携を止める、といった取り決めを先にしておいてください。よっつ目は、失敗に気づかないことです。通知の宛先とログの保存期間を要件に含め、月に1回は連携の実行結果を確認する運用にしておくと安心できます。どこまでを基幹システムの対象範囲として扱うかという線引きそのものは、基幹システムとは?種類とERPとの違い・発注前の判断軸で整理しています。

これらを防ぐうえで効くのが、テストの段階で本番相当のデータを使うことです。きれいに整えたサンプルデータだけで確認すると、実際の取引先名に含まれる記号や、桁あふれ、空欄の扱いといった問題が本番で初めて出ます。過去1か月分の実データを使ったテストを条件に入れておくと、稼働直後のトラブルがかなり減ります。

基幹システム連携についてよくある質問

Q. CSVの受け渡しでは不十分でしょうか?
A. 業務によっては十分です。判断の基準は即時性です。在庫の残数を見てその場で受注を確定するような業務では、1日1回の反映では足りません。一方で、日報の集計や月次の請求データのように締めのタイミングで揃えばよいものは、CSVで問題なく回ります。まずCSVで始めて、必要になった業務だけAPIに寄せる進め方も現実的です。
Q. 既存の基幹システムにAPIがない場合はどうなりますか?
A. データベースを直接参照する、中間のテーブルやファイルを経由する、基幹側にAPIを新しく作る、のいずれかになります。どれが可能かは基幹システムの作りと保守契約の内容で変わるため、まず保守会社に外部連携でできることを確認してください。ここが分からないまま連携ツールを選ぶと、導入後に実現できないと分かる展開になります。
Q. 連携は自社で作れますか?
A. データ連携ツールを使えば、設定作業だけで動かせる範囲は広がっています。ただし止まると業務に影響する連携は、作れることと運用し続けられることが別問題です。作った人しか直せない状態になりやすいので、設定内容を文書に残し、担当が変わっても引き継げる形にしておいてください。
Q. 稼働後の保守は誰が見るのですか?
A. 基幹システムの保守会社、連携部分を作った会社、現場ツールのベンダーの3者に分かれることが多く、ここを決めずに始めると障害時にたらい回しになります。連携が止まったときの一次窓口をどこにするかを契約時に決め、切り分けの手順まで合意しておくのが安全です。