kintoneと基幹システムのデータ連携——CSV手作業をやめる前に決めるべきこと

kintoneが社内に定着してくると、次に必ず出てくるのが既存システムとの連携です。「販売管理システムから顧客マスタを毎朝CSVで落として、kintoneに取り込んでいる」——珍しい話ではありません。この作業を自動化したいというご相談は多いのですが、いきなり仕組みを作り始めると、かえって事故につながります。連携は「つなぎ方」より「決めごと」が本体だからです。

「毎朝CSVを取り込む担当者」がいる会社は珍しくない

手作業の連携は、それ自体が悪いわけではありません。問題は、それが誰か一人の日課として固定化したときに表面化します。

担当者が休むと止まる——取り込み手順が本人の頭の中にしかなく、代わりが立てられない
取り込み漏れ・二重取り込みに気づけない——エラーが出ないため、数字が合わなくなって初めて発覚する
データが常に古い——朝の取り込み時点の情報しかなく、日中の変更が反映されない
加工が属人化する——「この列は削って、この値は変換して」という手順がExcelマクロなどに埋もれている

つまり自動化の目的は、作業時間の短縮だけではありません。止まらないことと間違いに気づけることのほうが、経営上の価値は大きいと考えています。

連携方式は3系統——どこまで自前で持つか

実現方法は数多くありますが、判断の観点では3つに整理できます。

①CSV連携の自動化——出力・加工・取り込みの手順をそのまま自動実行する方式。今の運用を大きく変えずに済み、費用も抑えられます。ただし、ファイルの受け渡しに依存する構造は残ります
②APIで直接つなぐ——kintoneのAPIと相手システムのAPIを、プログラムやクラウドの自動化サービスで結ぶ方式。リアルタイムに近づけられる一方、エラー処理や再実行の設計を自分たちで持つ必要があります
③連携製品（EAI/iPaaS等）を挟む——連携専用の製品に設定で任せる方式。実行ログや再実行の仕組みが最初から備わっているのが利点で、相手システムが複数ある場合ほど効いてきます。費用と製品依存は発生します

選ぶ基準は、つなぐ相手の数です。1対1なら①か②で十分なことが多く、3つ以上のシステムが絡み始めたら③を検討する——というのが実務上の目安です。

【判断基準】連携設計で最初に決める4項目

方式を選ぶ前に、次の4つを文書として決めておいてください。ここが曖昧な連携は、動き始めた後に必ず揉めます。

1. どちらが「正」のデータか——顧客マスタの正は基幹システムか、kintoneか。両方で編集できる状態にすると、どちらが正しいか誰も判断できなくなります
2. 更新の向きは一方通行か——基幹→kintoneだけなのか、逆も返すのか。双方向は難易度が跳ね上がるため、本当に必要かを疑ってかかるべきです
3. 何をキーに突き合わせるか——顧客コードなど、変わらない一意の値が必要です。会社名や電話番号をキーにすると、表記ゆれで必ず破綻します
4. 失敗したとき誰がどう気づくか——連携が止まったことを検知する仕組みと、通知先を決めます。ここを決めていない連携は「静かに止まる」のが最悪のパターンです

4項目のうち、後から変更が最も難しいのは3番目のキー設計です。運用開始後にキーを変えるのは、実質的に作り直しに近い作業になります。最初に時間をかける価値がある部分です。

連携が事故になる典型パターン

失敗事例には共通の型があります。着手前に自社が当てはまらないか確認してください。

安易な双方向同期——両側で更新できる設計にした結果、片方の修正がもう片方に上書きされる。「どちらの更新を優先するか」の規則がないまま作ると起こります
エラーの握りつぶし——取り込みに失敗しても処理を続ける作りにしてしまい、欠損に気づかないまま月次集計に使われる
全件洗い替えの副作用——毎回全データを入れ替える方式にすると、kintone側で追記した情報が消える。差分更新にするか、追記領域を分けるかの判断が必要です
テスト環境なしの本番投入——いきなり本番データで動かし、誤った値が全レコードに反映される
作った人しか分からない——スクリプトや設定に説明がなく、担当者の退職とともにブラックボックス化する

最後の一つは、連携に限らずkintone活用全般で最も多い詰まり方です。仕組みを作るときは、同時に「誰がどう引き継ぐか」まで設計に含めてください。