kintoneと基幹システム・社内DBを連携するとき、データ同期方式をどう選ぶか
- 3 日前
- 読了時間: 10分
更新日：2 日前
kintoneを導入したものの、顧客情報や商品情報、受注情報は既存の基幹システムにも残っている。二重入力をなくすために連携したいが、リアルタイムにするべきか、定期的に同期すればよいのか迷うことがあります。
同期方式を決めるときは、「顧客情報は基幹システムが正」とレコード単位で考えるだけでは不十分です。どの項目をどちらが管理するのかまで整理し、そのうえで同期方向や反映タイミングを決めることが重要です。
はじめに：「kintoneと基幹をつなぐ」だけでは同期方式は決まらない
kintoneを業務で使い始めると、既存システムとのデータの重複が問題になることがあります。
たとえば、
顧客マスタは基幹システムにある
営業担当者はkintoneで案件を管理している
商品・価格情報は社内DBにある
kintoneにも顧客名や商品名を表示したい
kintoneで入力した情報を別システムでも利用したい
といった状態です。
このとき、
kintoneと基幹システムをAPIで連携したい。
だけでは、実際の連携方法は決まりません。
同じ「連携」でも、
1日1回データをコピーすればよい
15分ごとに更新したい
kintoneで変更した直後に反映したい
基幹→kintoneだけでよい
kintone→基幹にも戻したい
では、必要な仕組みが異なるからです。
kintoneと外部システムを連携するときの全体的な考え方については、「kintoneを活かした業務システム拡張。外部連携で実現できること」で解説しています。
この記事では、その先の判断として、データをどちらで管理し、どのような方式で同期するのかに絞って考えます。
結論：「どちらが正か」ではなく、項目単位で管理主体を決める
同期方式を考えるとき、
顧客情報は基幹システムを正にする。
という方針を決めることは重要です。
しかし、実際の業務ではそれだけでは足りないことがあります。
たとえば、同じ顧客レコードでも次のように管理主体が分かれる場合があります。
項目 | 主に管理するシステム |
顧客番号 | 基幹システム |
会社名 | 基幹システム |
請求先住所 | 基幹システム |
営業担当 | kintone |
最終訪問日 | kintone |
営業メモ | kintone |
この状態で、基幹システムの顧客情報をそのままkintoneへ上書きすると、kintone側で入力した営業担当や営業メモまで失われる可能性があります。
そのため、同期設計では、
「どのレコードを同期するか」だけではなく、「どの項目をどちらが更新するのか」まで決める
必要があります。
この項目単位の管理主体が決まった後で、
どちら向きに同期するのか
いつ同期するのか
変更されたデータだけ同期するのか
同時に変更された場合にどうするのか
を決めていきます。
同期方式は大きく4つのパターンで考える
kintoneと基幹システム・社内DBの連携は、大きく4つの形に整理できます。
方式 | 例 | 向いているケース |
定期的な一方向同期 | 基幹 → kintoneを1時間ごとに更新 | kintoneを閲覧・業務補助に使う |
変更時の一方向連携 | kintone変更 → 外部システム | kintoneでの操作をすぐ外部へ渡したい |
双方向同期 | 基幹 ⇄ kintone | 両方で同じデータを変更する必要がある |
必要時だけ取得 | 操作時に外部から取得 | データをkintoneへ複製したくない |
定期的な一方向同期
比較的シンプルなのが、
基幹システム → kintone
のように方向を一つに決め、一定間隔で同期する方法です。
たとえば商品マスタを1時間ごとにkintoneへ反映するようなケースです。
業務上、数十分程度の反映遅れが問題にならないのであれば、必ずしもリアルタイムにする必要はありません。
変更をきっかけに連携する
kintone上の変更をきっかけとして、外部システムへ処理する方法です。
たとえば、
kintone上で申請を「承認済み」にしたら、外部システムへ登録する。
という連携です。
変更が発生したタイミングで処理できるため、定期的に全件を確認する必要がありません。
双方向同期
基幹システムとkintoneの両方でデータを変更し、それぞれの変更を相手へ反映します。
便利に見えますが、最も慎重な設計が必要です。
たとえば、
10:00に基幹システムで住所を変更 10:01にkintoneでも同じ顧客の住所を変更
した場合、どちらを採用するのかを決めなければなりません。
単純にAPIを2方向へ用意するだけでは、双方向同期にはなりません。
必要なときだけ外部から取得する
すべてのデータをkintone側へ保存せず、必要なときだけ外部システムへ問い合わせる方法もあります。
大量のデータを二重管理したくない場合や、常に外部システムの最新値を表示したい場合には選択肢になります。
Webhookが使えるかどうかも、同期方式を左右する
「変更されたらすぐ連携する」という方式を考えるときには、変更を検知できる仕組みがあるかを確認する必要があります。
kintoneでは、レコードの追加・編集・削除、コメント、プロセス管理のステータス更新をきっかけとして、Webhookで外部システムへ通知できます。
そのため、
kintoneで申請を承認したら、外部システムへ登録する。
といった処理では、変更時の連携を設計しやすくなります。
一方、Webhookはkintoneで発生したすべての出来事を自由に通知できる仕組みではありません。
また、
基幹システム側で顧客情報が変更されたことをkintoneへ反映したい。
という逆方向の変更について、kintoneのWebhookで検知することもできません。
外部システム側に変更通知の仕組みがない場合には、
一定間隔で変更を確認する
更新日時を使って差分を取得する
夜間にまとめて同期する
といった別方式を検討します。
つまり、
「リアルタイムにしたい」という希望だけでは方式は決まらず、変更を検知できる仕組みが双方にあるか
も確認する必要があります。
Webhookが使えないから連携できないわけではありません。
その場合は、定期同期など別の方法へ切り替えて考えます。
全件同期より「変更されたデータだけ」を同期する方がよいことがある
基幹システムに大量の顧客データがある場合、同期するたびに全件を取得し直す必要があるとは限りません。
たとえば、
前回同期後に追加されたデータ
前回同期後に変更されたデータ
だけを対象とする差分同期があります。
たとえば、
前回同期した日時より後に更新された顧客だけを取得する。
という方法です。
対象件数を減らせるため、データ量が多い場合には有効です。
ただし、差分同期では「途中で失敗した場合」を考えておく必要があります。
たとえば、
100件中70件まで同期したところで処理が停止した。
とします。
このとき、
71件目から再開するのか
100件を最初から再実行するのか
処理済みの70件を再実行しても問題ないのか
を決めておかなければなりません。
特に注意したいのが、
送信側では失敗に見えていても、受信側では処理が完了している
ケースです。
通信が途中で切れると、送信側は「登録できなかった」と判断していても、kintoneや外部システムにはすでに登録されている場合があります。
その状態で同じ処理を再実行して、
顧客が2件登録される
注文が二重登録される
といったことは避ける必要があります。
同期処理では、正常時にデータを送れることだけではなく、同じ処理を再実行したときにもデータを壊さないことが重要です。
具体例：基幹システムを残し、kintoneを現場の窓口にする
たとえば、長年利用している基幹システムがあるとします。
顧客・商品・受注などの重要データは入っていますが、スマートフォンから利用しにくく、現場ではExcelや紙も併用している。
この場合、基幹システムをすべてkintoneへ置き換えなくても、
基幹システムを残したまま、現場で必要な情報だけをkintoneへ連携する
という構成が考えられます。
たとえば、
基幹システム → kintone
顧客番号
顧客名
商品情報
受注情報
は定期的に同期する。
一方、
kintoneだけで管理
営業メモ
訪問記録
現場写真
対応状況
とする。
さらに業務上必要であれば、
kintone → 基幹システム
へ、確定した一部の情報だけを戻します。
この構成で重要なのは、「顧客レコードを双方向同期する」と考えるのではなく、
項目ごとに管理主体と同期方向を分けていること
です。
プレイリーソリューションズ自身も、社内システムでkintoneと外部システムを組み合わせて利用しています。
実際に複数のシステムを組み合わせて使うと、単にデータを移すだけではなく、
どちらで入力するのか
どちらを表示用として使うのか
どの情報だけ相手へ渡すのか
連携が止まった場合に業務をどう継続するのか
を決めておく必要があります。
そのため、既存システムをすべて置き換えるより、それぞれのシステムが得意な役割を残して必要な部分だけ連携する方が適しているケースもあります。
双方向同期は「できるか」より「本当に必要か」を確認する
打ち合わせでは、
せっかくなら双方向でリアルタイムに同期したい。
という要望が出ることがあります。
技術的に実現できる場合でも、業務上本当に必要かは別に考えた方がよいでしょう。
双方向にすると、
同じ項目を両方で変更した場合にどちらを採用するか
同時更新をどう扱うか
削除をどう反映するか
通信障害後にどう復旧するか
kintone→基幹→kintoneと同じ変更が循環しないか
など、決めることが増えます。
たとえば、
商品価格は基幹システムでしか変更しない。
のであれば、商品価格は基幹→kintoneの一方向で十分です。
一方、
現場がkintoneで入力した検査結果は基幹システムにも残したい。
のであれば、その項目だけkintone→基幹へ連携します。
レコード全体を双方向にするのではなく、項目ごとに同期方向を変える
ことで、仕組みを単純にできる場合があります。
同期方式を決めるときに確認したい5つのこと
API連携を発注する前に何を整理するかという一般的な準備とは別に、kintoneとの同期方式を選ぶために特に確認したいのは5点です。
1. 各項目をどちらのシステムが管理するのか
「顧客情報」のようなレコード単位ではなく、顧客番号、住所、担当者、メモなど、必要に応じて項目まで分けます。
2. その項目をどちら向きに同期するのか
基幹→kintoneだけなのか、kintone→基幹なのか、両方から変更する必要があるのかを確認します。
3. どの程度の反映時間が許容されるのか
数秒以内が必要なのか、15分程度でよいのか、翌朝まででよいのかによって方式が変わります。
4. 両方で変更された場合に、どちらを優先するのか
双方向にする項目では、更新が競合したときのルールを決めます。
5. 同期に失敗した場合に、どう再実行するのか
自動で再試行するのか、担当者へ通知するのか、手動で再実行できるようにするのかを考えます。
この5点が整理できれば、定期同期、Webhookを利用した変更時連携、双方向同期などの方式を比較しやすくなります。
プレイリーソリューションズでは、kintoneの外側まで含めて同期方式を設計します
プレイリーソリューションズ合同会社では、kintone単体のアプリ設定だけではなく、基幹システム、社内のデータベース、外部API、AWSなどを含めたバックエンド連携を対応領域としています。
たとえば、
古い基幹システムを残したままkintoneを活用したい
社内のデータベースと直接連携したい
kintoneへの二重入力をなくしたい
データ量が多く、単純な全件同期では運用しづらい
双方向連携の整合性をどう設計すればよいか分からない
プラグインや既製の連携サービスでは対応しきれない
といった場合には、kintone側だけを見るのではなく、現在のシステム全体を確認したうえで連携方式を整理します。
同期方式が決まっていない段階でも、
現状確認 → 管理主体・同期方向の整理 → 同期方式の選定 → 設計・実装・試験
と段階を分けて進めることが可能です。
また、kintone構築会社などから、外部連携部分だけをご相談いただく形にも対応しています。詳しくは「kintone案件で外部連携が必要になったとき、バックエンド開発をどう外注するか」をご覧ください。
まとめ：同期方式は「項目ごとの役割」から決める
kintoneと基幹システム・社内DBを連携するとき、
「顧客情報は基幹システムが正」
と決めるだけでは不十分な場合があります。
同じ顧客情報でも、
顧客番号・請求先は基幹
営業担当・訪問記録はkintone
というように、項目ごとに管理主体が異なるからです。
まず、
どの項目を、どのシステムが管理するのか。
そのうえで、
どちら向きに同期するのか
いつ反映するのか
Webhookによる変更時連携が使えるのか
全件か差分か
競合時にどうするのか
失敗後にどう再実行するのか
を決めていきます。
リアルタイム・双方向だから優れているわけではありません。
業務上必要な情報だけを、必要な方向・頻度で安全に同期することが重要です。
「kintoneと基幹システムを連携したいが、同期方式をどう決めればよいか分からない」「双方向やリアルタイムまで必要なのか判断できない」という場合は、プレイリーソリューションズへご相談ください。
既存環境の確認から、項目ごとの管理主体・同期方式の整理、API・DB連携、AWS上の連携処理の設計・実装まで対応しています。
