連携の設計で最初に決めること — 手段を選ぶ前の 5 つ
「A と B をつなぎたい」の次に来るのは、たいてい「API で」か「iPaaS で」です。手段の前に決めることが 5 つあり、それが埋まると手段はほぼ自動で決まります。
5 つは何か
| 決めること | 問い | 決まると何が変わるか |
|---|---|---|
| ① 向きと主 | どちらのシステムが正で、片方向か双方向か | 双方向は対応表と競合の解決が要り、費用が段違いになる |
| ② 頻度と量 | 1 日 1 回で足りるか、人が触らずに何度も流すか | 1 日 1 回・少量・人が確認してよいなら CSV で足りることが多い |
| ③ 項目の対応 | 名前とコードの対応表を誰が作り、誰が保守するか。対応先が無い値はどうするか | つなぎ役の仕事は通信ではなく変換。ここが決まらないと本番で止まる |
| ④ 止まったとき | 回数の上限・仕様変更・障害に、誰が気づき、誰が直すか | 作った後に毎年かかる保守費の正体 |
| ⑤ どこで動くか | 提供元のクラウドか、手元のパソコンか | RPA はパソコン 1 台と電源、iPaaS はデータが提供元のクラウドを通る |
③ と ④ は「誰が」で決まる
③ 項目の対応は自動では作れません。「得意先名／取引先名称」「A001／000123」を結ぶ表を誰かが作り、対応先が無い値が来たときに止めるか飛ばすかを誰かが決めます。④ 止まったときも同じで、回数の壁・仕様変更・障害は必ず起き、気づく人と直す人が要ります（連携を作った後に起きること）。
| 「誰が」の答え | 向いている手段 |
|---|---|
| 自社に情シスがいて、対応表と監視を持てる | API 連携（自作）か iPaaS |
| 対応表は作れるが、監視は持てない | iPaaS（提供元が動かす）か純正連携 |
| どちらも持てない | 純正連携か CSV（人が運ぶ）。RPA は壊れ方の既定を決めてから |
こう決める — 手順
| 順 | 手順 | こう判定する |
|---|---|---|
| 1 | ① 向きと主を書く | 双方向が本当に要るかを疑う。片方向で済むなら片方向にする |
| 2 | ② 頻度と量を書く | 1 日 1 回・少量・人が確認してよい → まず CSV。人が触らず 1 日に何度も → API 系 |
| 3 | ③ 項目の対応を、対応表の担当と「対応先が無いとき」の扱いまで書く | 担当が書けなければ、双方向をやめるか純正連携に寄せる |
| 4 | ④ 止まったときの担当を書く | 気づく人が書けなければ、提供元が動かす手段（純正・iPaaS）に寄せる |
| 5 | ⑤ どこで動くかを書き、相手のシステムの調査記録（API の有無・純正連携・動作環境）と突き合わせる | 5 つが埋まって初めて手段を選ぶ。埋まらない項目は問い合わせの項目にする |
5 つが埋まったあとの手段の選び方は 連携の手段の選び方、費用の 3 層は 連携の費用の 3 層 に置きました。