「SFAと請求システムで、顧客の住所が違うんです。どっちが正しいんですか？」

郵便で手紙が確実に届くには、宛先が正しく、同じ手紙を2回送っても困らず、届かなかったら差出人に戻ってくる必要があります。システム連携も同じです。

正の所在

そのデータの「正しい値」は、どのシステムにあるか（この記事）

同じ結果

何度実行しても、同じ結果になるか（信頼性編）

気づける失敗

失敗したとき、誰がいつ気づき、どう直すか（信頼性編・運用編）

家族で1冊のカレンダーを共有していれば予定は食い違いませんが、父のスマホ、母の手帳、冷蔵庫のカレンダーにそれぞれ書き込むと、どれが正しいのかわからなくなります。システムも同じで、同じ項目を複数のシステムで書き換えられると、どれが正しいかわからなくなります。

商談・ステージ・担当

正はSFA。ほかのシステムは読むだけ

請求先・入金状況

正は請求システム。SFAは読むだけ

Webの行動・メールの開封

正はMA。SFAは読むだけ

ヘルススコア

正は分析基盤。SFAに書き戻すが、SFAでは読み取り専用にする

項目ごとの正の所在を表にし、連携の全体図（システム・方向・タイミング・持ち主）を1枚描きます。連携が2〜3本までならシステム同士を直接つないでもよいですが、それ以上に増えたら、1つの中継（iPaaSや分析基盤）を通すハブ型を検討します。直結のままだと、本数が爆発します。

リアルタイム

その場で相手に問い合わせる。与信の照会など、待てないもの向け。相手が止まると、こちらも止まる

バッチ

決まった時間にまとめて送る。夜間の請求データの取り込みなど。鮮度は1日遅れ

イベント

何かが起きたら通知する。受注したらSlackに通知など。取りこぼしと重複が起きうる前提で作る

ここで先に反論しておきます。「全部リアルタイムで同期すれば、いつでも最新で安心だ」と思うかもしれません。ですが、リアルタイムはコストと複雑さが跳ね上がり、相手の障害でこちらまで止まります。まず「どれくらい遅れたら業務で困るか」を確かめ、1時間遅れで困らないものは、バッチで十分です。

方向は一方向が基本です。双方向にすると、両側で書き換えた値がぶつかり、最後に書いたほうが勝ちます。冒頭の「直した値が消えた」は、これが原因です。双方向がどうしても必要なら、項目ごとに正の所在を分け、衝突したときのルールを決めておきます。

手紙は名前ではなく住所で届きます。同姓同名の人はいるし、名前の書き方も揺れるからです。システム連携でも、「株式会社ABC」と「(株)ABC」のような表記ゆれのある名前ではなく、変わらないIDでつなぎます。

外部ID

相手システムのIDを、SFAの項目として持つ。一意の設定をつけ、あれば更新・なければ作成（upsert）に使う。連携の基本

法人番号

システムをまたいで同じ会社を指せる、公的なID

名前・メールアドレス

表記ゆれ・変更・重複があり、キーとしては弱い

見落としやすいのが、SFAで取引先を統合したときです。統合で外部IDが消えると、相手システムとつながらなくなります。統合や削除の手順に、外部IDの引き継ぎを入れておきます。

顧客の住所や担当者は、どのシステムの値が正しいことになっていますか？

決まっていなければ、食い違ったときに直せない

連携の全体図はありますか？

なければ、1つ止めたときに何が壊れるかわからない

双方向の連携で、両側から同じ項目を書き換えていませんか？

書き換えていれば、正しい値が消えうる

連携のキーは、名前ですか、IDですか？

名前なら、表記ゆれで重複や誤った上書きが起きる

複数のSaaSをつなぐとき、全体の設計はどう考えればよいですか

正の所在の表と全体図を先につくり、ハブ型にするかを決めます。複数SaaSの連携の考え方は複数SaaS連携の設計でも扱っています

社内で一番よく食い違う項目を1つ思い浮かべてください。その項目の「正しい値」は、どのシステムにあることになっているでしょうか。答えが「どちらも」なら、食い違いは連携の不具合ではなく、設計どおりに起きています。