【漫画で分かるDX】第14回:営業の「受注済」と事務の「受注済」が違う日。Salesforceとkintoneの辞書づくり
『漫画で分かるDX』第14回。—
あとがき ― Salesforce×kintone連携の現実的ロードマップ
商談管理(例:Salesforce)と事務台帳(例:kintone)で、同じ日本語ラベルが別の業務意味を持っていると、API連携は**調停地獄**になります。 佐藤さんと田中くんによる、分かりやすいIT・AI解説シリーズ。
目次 クリックで開く
営業の「受注済」と事務の「受注済」が違う日。Salesforceとkintoneの辞書づくり
金曜の午後、営業フロアでは商談ステージが画面の上へ上へと進んでいる。一方で事務エリアのモニターには、別のアプリで「受注チェック」の欄が並んでいた。田中誠は、その二つの画面を見比べながら、毎週同じExcelに同じ行を貼り直している自分に気づく。
「受注確定」の瞬間だけ、両方の世界で別の言葉が使われていた。営業版の「受注済」は、まだ契約書の押印待ち。事務版の「受注済」は、請求の起票が済んだあと——どちらも正しいのに、連携の設計図には書けない。
週次の突合で、同じ顧客名なのに番号が違う行を見つけたとき、指先が冷たくなる。辞書を揃えないままAPIを繋ぐと、定義のズレがそのまま別システムに書き込まれ、月末の修正と説明が増える。
佐藤修は、ホワイトボードの前でマーカーを握りしめ、いつもより小さな声で言った。「今夜は顧客IDとステータス対応表だけを固める。残りの項目は、週次のレビューで足していけばいい」
登場人物紹介
【本話の登場】田中・佐藤・岸本・黒坂(水野は出ません/営業・事務の語彙衝突が主題)。
田中 誠(29):伴走コンサル。営業のSalesforceと事務のkintoneの間で週次突合を抱え、同じ顧客なのにIDが割れている行を見つけるたびに血の気が引く。
佐藤 修(39):シニアDXアーキテクト。語彙とIDを先に揃えてからAPIを繋ぐ順序を徹底する。
岸本 麻衣(41):経理主任・部門担当。一気移行で事務が潰れるパターンを何度も見ており、段階導入を強く主張する。
黒坂 剛(62):競合営業。白混ロング。「一気にやった方が早い」「現場が弱い」が口癖。
「『受注済』の意味が、営業版と事務版で違う……このままAPIで繋いだら、請求のタイミングがズレて炎上します」
田中の声に、近くの席の営業が一瞬顔を上げ、すぐに電話に戻った。誰の悪意でもない。ただ、画面のラベルが同じ言葉を共有していないだけだ。
佐藤が言う。「壊れるのは仕様じゃない。語彙のズレだ。Salesforce側のステージ定義と、kintone側のステータスを、表で突き合わせないまま連携すると、ログは綺麗でも現場は地獄になる」

岸本の声が硬い。「段階を踏まないと、事務側がまた拾う。拾うってことは、結局田中君のExcelに戻るってことよ」
黒坂が肩をすくめる。「一気が早い。現場が弱いんですよ」フロアの空気が一瞬ざわつき、岸本の眉が跳ね上がる。
佐藤がマーカーを置いた。「一気通貫を狙うと疲れる。まず顧客と案件のCanonical IDを一つにし、次に一方通行——逆方向は差し戻しに限定する。逆同期を全部開くと、どこで真実が割れたか分からなくなる」
「例外は隠さない。滞留が見えないと、連携は毎回誰かの善意になる。善意は、休暇と一緒に消える」
田中が言う。「要確認キューの件数と、事務リーダーとのSLA——期限までに誰が触るか、週次で数字を見せます」
佐藤が頷く。「キューは恥ずかしい数字じゃない。経営に見せるべき健康診断だ」
「同じ『受注確定』の定義で止まるようになりました。週次の突合、かなり削れそうです」
事務のリーダーが安堵の吐息をつく。営業側のマネージャーは「これで商談メモのコピペしなくていいのか」と聞き、田中は「まずはこの項目だけ」と笑って答えた。
佐藤が頷く。「削れた時間で、手続きの漏れを探そう。連携は手段で、現場の安心が本体だ」
四半期かけて辿り着いた。完璧な設計図ではなく、週次の例外レビューが続いたからだ。付箋の色が入れ替わるたびに、「まだ終わっていない」ではなく「ここまで来た」と言えるようになっていく。
営業と事務の間に、共通言語が一つ増えた。同じ画面を指して怒鳴り合う時間が、減った。
「連携は完成じゃない。観測の習慣が本体だ」佐藤が言う。田中は、その言葉を次の案件のキックオフ資料の冒頭に貼った。
ここから先は、本文のストーリーとは切り離した解説です。
あとがき ― 仕事に落とすと
あとがき ― Salesforce×kintone連携の現実的ロードマップ
商談管理(例:Salesforce)と事務台帳(例:kintone)で、同じ日本語ラベルが別の業務意味を持っていると、API連携は**調停地獄**になります。ログ上は成功でも、請求や出荷のタイミングがズレると、現場は「システムのせい」ではなく「誰の定義が正しいか」の争いに戻ります。
Aurant Technologiesが現場で繰り返し勧めるのは、次の三点です。
Canonical IDとステージ辞書を先に固定する: 顧客・案件の主キーを一本化し、ステータス対応表を「誰が読んでも同じ解釈」になるまで磨く。
逆方向は差し戻しに限定する: 双方向を最初から全面開放すると、真実の分裂と権限トラブルが増える。差し戻しと例外キューに役割を閉じ込める。
週次で滞留を見る: 例外件数と滞留日数を定例で見せ、SLAと担当を固定する。隠すと連携は毎回個人の善意頼みになる。
ID・権限・逆同期の落とし穴は、コードを書く前に設計で切り分けます。Aurant Technologiesは、その伴走をします。