システム連携とは？つなぐ前に決める4つ｜正本・共通ID・更新責任・止まったときの手順

販売管理、見積、会計、名刺、問い合わせフォーム。必要になった順にシステムを入れてきた会社は、いまそれぞれに顧客の情報が入っています。同じ会社の名前が4箇所にあり、住所は3箇所で違い、担当者は誰かの頭の中にだけ最新版がある。ここまで来ると「つなげばいい」という話になります。

このように、部門やシステムの中に情報が孤立し、どれが正しいか照合できない状態をサイロ化と呼びます。別管理との境目や、現場で見つける兆候はサイロ化とは何か、原因と解消の順番に分けて整理しました。

ただ、つなぐ作業そのものは、いまなら手段がいくつもあります。詰まるのはその手前です。どちらの住所を正しいものとして送るのか、両側の「株式会社◯◯」と「◯◯（株）」を同じ会社だと判定できるのか、連携が止まった日に受注処理を止めるのか。ここが決まっていないままつなぐと、間違いが今までより速く広がります。

この記事では、方式の比較ではなく、方式を選ぶ前に決める4つを書きます。読み終えたときに、自社が「つなぐ段階」なのか「まだ揃える段階」なのかを判断できる状態を目指します。

システム連携とは、同じ情報を2つ以上の場所で持つときの取り決め

システム連携という言葉は、データを自動で送る仕組みを指して使われることが多いのですが、業務側から見ると意味が少し違います。同じ情報が2つ以上のシステムに存在する状態を、破綻させずに運用するための取り決めです。自動化はその取り決めを実行する手段のひとつにすぎません。

だから、連携がうまくいっている会社を見ると、たいてい自動化の範囲は狭いです。全部を双方向でつないでいるのではなく、正しい値を持つ側を決めて、そこから一方向に流しています。逆に、どちらからでも更新できる双方向の連携は、片方の更新がもう片方を上書きし、上書きされたことに誰も気づかない事故を起こします。

前提として押さえておきたいのは、連携は業務の「開始」と「完了」の間にしか置けないということです。問い合わせが入ってから請求が終わるまでの流れのどこで、どのシステムが登場するか。これを書き出さずに連携ツールの比較を始めると、機能表は読めても自社に必要な機能が決まりません。

つなぐ前に決める4つ

次の4つは、どの方式を選んでも自社で決める必要があります。ベンダーが代わりに決められるものはひとつもありません。決めずに着手すると、連携の設定作業の途中で必ず質問として戻ってきて、そこから業務の議論が始まります。

1. 正本：その項目が「ここに書いたものが正しい」場所を1つに決める

顧客の住所、案件の受注金額、商品の単価。項目ごとに、正しい値が置いてある場所を1つに決めます。決めるのはシステム単位ではなく項目単位です。「顧客情報は販売管理が正本」ではなく、「請求先住所は会計、営業の訪問先住所は顧客管理」のように分かれることのほうが多いからです。

2箇所に書けるようにした時点で、どちらが新しいかを人の記憶で判断することになります。記憶は繁忙期に消えます。正本を決めたら、正本でない側は読み取り専用にするか、少なくとも「ここで直しても正本には返らない」と画面に書いておく。これだけで、後から数字を追いかける作業がかなり減ります。

正本を決めるときによく揉めるのが、どちらの部署が持つかです。ここは業務の順番で決められます。その項目を最初に確定させる人がいる場所が正本です。請求先は経理が確定させるので会計側、訪問先は営業が更新するので顧客管理側、というように、更新の頻度ではなく確定のタイミングで決めると、話が早く終わります。

2. 共通ID：システムをまたいで同じものと判定するキーを決める

顧客、取引先、案件、物件、商品。これらを両側で同じものだと判定するキーが要ります。会社名や氏名の文字列で突き合わせると、必ず壊れます。「株式会社」の位置、全角と半角、スペースの有無、支店名を入れるかどうか。人間には同じに見えるものが、システムには別物として残ります。

現実的なやり方は、片方のシステムのIDを共通IDとして採用し、もう片方にそのIDを入れる欄を作ることです。新しく採番し直すより早く、対応表を別に持つより壊れにくい。すでに両側にデータがある場合は、最初の1回だけ人が対応付けをして、以降は新規登録の時点でIDを入れる運用にします。

名寄せは一度やって終わりではなく、新しい表記ゆれが入るたびに発生します。だから、名寄せの精度を上げる努力より、IDを入れないと保存できないようにする工夫のほうが効きます。通話履歴のように後から突き合わせる情報でも同じで、どのキーで結ぶかを先に決める考え方はCTIとCRMのデータ連携設計（通話ID・要件・次回行動をつなぐ項目表）に具体例があります。

3. 更新責任：作る人、変えられる人、重複を寄せる人

正本の場所を決めても、そこに誰が書くかが決まっていないと運用は始まりません。決めるのは3つです。新しく作れるのは誰か、既存の値を変えられるのは誰か、重複が見つかったときにどちらへ寄せるか。3つ目が抜けている会社が多く、重複は見つかった時点で誰の仕事でもなくなり、そのまま残ります。

役職ではなく人の役割で決めます。「営業部が管理」ではなく「新規の取引先を作れるのは受注処理の担当2名、住所の変更は経理が承認」のように、実際にその画面を開く人まで落とします。項目群ごとに担当を分ける方法は取引先マスタの責任者設計（作成・変更・重複解消・廃止を分担する）に責任分担表の形でまとめています。

連携を入れると、この責任が曖昧になりやすい点にも触れておきます。自動で流れてくる値は「システムが入れたもの」に見えるので、間違っていても誰も直しません。流れてきた値であっても、元をたどれば必ず人が入れています。連携先の画面に「この値の出どころ」を表示しておくと、直す先を探す時間がなくなります。

4. 止まったときの手順：落ちた日に何が止まり、どう追いつくか

連携は止まります。相手側のメンテナンス、認証の期限切れ、仕様変更、こちら側の設定ミス。止まること自体は避けられないので、止まった日の手順を先に決めます。決めるのは、どの業務が止まるか、止まっている間は手作業でどう回すか、復旧したときに手作業ぶんをどう反映するかの3つです。

3つ目が一番忘れられます。止まっている間に手で入れた分が、復旧後の自動連携で上書きされる、あるいは二重に入る。これが起きると、止まったこと自体より後片付けのほうが重くなります。手作業で回した記録を1箇所に残しておく、復旧後は流し込む前に差分を確認する、という手順を紙で持っておくだけで違います。

あわせて決めたいのが、止まったことに気づく方法です。エラーが管理者のメールにだけ届く設定だと、その人が休んでいる日には誰も気づきません。連携が止まった状態がどの画面に見えるかを決めて、業務を回している人が気づける場所に出します。止まる原因の具体例と直し方はkintone連携が止まる原因と保守設計で扱っています。

方式の選択は、4つを決めた後の話

4つが決まると、方式の選択はかなり単純になります。ここでは代表的な4つを、向く場面・決めておくこと・止まったときの影響で並べます。上のほうが安く、下へ行くほど速く正確になり、その代わり止まったときに人手で代替しにくくなります。

中小企業で最初に検討する価値があるのは、上から2つ目までです。手作業を全部なくそうとせず、間違えると業務が止まる項目だけを自動にして、残りは人が見て入れる。この形が、止まったときに一番戻しやすくなります。

まだつながなくてよい会社と、つないだほうがよい会社

連携は入れた後の保守が続きます。だから、いま入れるべきかどうかを先に判定します。左が2つ以上当てはまるなら、いまは方式を比べるより、正本と共通IDを決めるほうが効きます。

いまの自社がどちらに寄っているか、業務ごとに分けて見たい場合は3分の事業基盤診断が使えます。8問に答えると、最初に整える業務と、いまは触らない業務が分かれます。分けるところまでで、連携の可否そのものを判定するものではありません。

つなぐ前に止めたほうがいい場合

いちばん止めたほうがいいのは、同じ数字の入力先が2箇所あるままつなごうとしている場合です。連携は間違いを速く運びます。どちらが正しいか決まっていない状態で流すと、間違った値が短時間で全システムに広がり、しかも「自動で入った値」なので疑われません。人が転記していたときのほうが、途中で気づく機会がありました。

次に止めたいのが、片方のデータがまだ揃っていない場合です。項目が空のまま、あるいは自由記述で入っている状態で流し込むと、受け取り側で必須項目が埋まらず、その都度エラーになります。移す前に何を揃えるかの考え方はERPデータ移行の棚卸し（マスタ・未完了取引・履歴・切替を分ける移行表）にまとめました。いま持っているデータの構造そのものが怪しい場合は、ツール移行の前にやるデータ構造の棚卸しが近い話です。

3つ目は、その業務のやり方をこれから変える予定がある場合です。連携は現在の業務の形をそのまま固定します。半年後に受注のフローを変える予定があるなら、いまつないだ設定はその時点で作り直しになります。順番としては、業務の形を決めてからつなぐほうが安く済みます。

つないだ後に一番よく壊れるのは、相手側の変更

連携は作って終わりではありません。壊れる原因で多いのは自社のミスではなく、相手側の変更です。SaaSのバージョン更新、項目名の変更、APIの提供終了、認証方式の切り替え。通知は届いていることが多いのですが、受け取ったメールが管理者の受信箱で埋もれます。

対策として現実的なのは、いまどの連携がどのシステムのどのバージョンに依存しているかを1枚に持っておくことです。廃止の通知が来たときに、影響する業務と直す人がすぐ分かる状態にしておく。台帳の作り方はAPI廃止時の影響棚卸し（接続元・バージョン・代替・移行責任を追う）に書いています。

外部の会社に連携の構築を頼む場合は、この保守の範囲を最初に書面へ入れておきます。作るところまでの契約になっていると、半年後に相手側の仕様が変わったときに、直す人がいない状態から探すことになります。何をどこまで頼むかを言葉にする段階では、要件定義書のテンプレート（発注側が埋める欄と、埋まらない欄が意味すること）が使えます。

効果は転記の件数と、止まった時間で測る

連携の効果を売上や工数削減で測ろうとすると、他の要因と混ざって判定できません。次の4項目を、着手する前に1回測っておきます。数えるのに1時間もかかりませんが、これがないと3ヶ月後に「なんとなく楽になった」以上のことが言えなくなります。

• 同じ情報を人が2箇所へ転記している件数（週あたり）
• 2つのシステムの数字を突き合わせている作業の回数（月あたり）
• 連携が止まった回数と、気づくまで・復旧するまでの時間
• 表記ゆれで名寄せをやり直した件数

3つ目を「止まった回数」だけでなく「気づくまでの時間」も測るのは、止まること自体より気づかないことのほうが被害が大きいからです。1件目と4件目が減っていて、3件目が悪化していないなら、その連携は効いています。

来週の一歩：業務の開始と完了をA4に1枚書く

方式の比較やツールの資料請求より先に、A4を1枚使って次を書き出します。ひとつの業務、たとえば「問い合わせが入ってから請求書を送るまで」を選び、その開始と完了を左右に置きます。間に、触るシステムを登場する順に並べます。そして、同じ情報が入っている場所に同じ印を付けます。

この1枚を書くと、たいてい同じ情報が3〜4箇所に入っている項目が2つか3つ見つかります。見つかった項目について、正本をどこにするか、共通IDに何を使うか、更新できる人は誰かを埋めます。ここまで埋まってから方式の表に戻ると、選択肢は1つか2つに減っています。

書いてみて正本の置き場所で判断が割れる場合や、そもそもどの業務から手を付けるかで迷う場合は、オンライン相談でその1枚を持ち寄って整理することもできます。製品の選定を代行するものではなく、決める順番を一緒に決める場です。

導入方式を具体化する関連記事

• システム導入を選定前から定着まで進める7段階
• ローコードを選ぶ6つの判断軸
• ノーコードツール一覧を用途別に比べる方法

よくある質問