データ連携は、別々のシステムにある同じ情報を、手で写さずにつなぎ、どのシステムでも同じ内容を使えるようにすることです。例えば、顧客の管理の仕組みで受注が決まったら、その情報が販売の仕組みに送られ、請求の後に会計の仕組みに反映される、という流れを、人の手を介さずに行う形です。連携が無いと、担当者が CSV のファイルを書き出し、表計算で形を整え、別の仕組みに取り込む、という作業を毎日や毎月繰り返すことになります。この作業は時間がかかるだけでなく、形を整える途中の誤りや、取り込みの忘れを生みます。連携を考えるときは、どのデータを、どちらからどちらへ、どのくらいの頻度で渡すかを先に決めることが大切です。
CSV の手作業の問題
CSV のファイルを手で書き出して取り込む方法は、どのシステムでも使える手軽な方法です。しかし、作業が日常になると、次のような問題が出てきます。
- 時間がかかる：書き出し、形の整え、取り込みの作業が、担当者の時間を毎回取る
- 誤りが入る：列の順番の違い、日付や金額の形式の違い、文字化けなどで、取り込みの際に誤りが入る
- 遅れる：作業が週に 1 回や月に 1 回だと、その間、システムの間で情報が食い違う
- 担当者に頼る：手順を知っている担当者が休むと、作業が止まる
連携の方法の種類
| 方法 | 中身 | 向いている場合 |
|---|---|---|
| ファイルの自動の受け渡し | システムが書き出したファイルを、決まった時間に別のシステムが自動で取り込む | API が無い古いシステムとつなぐ、1 日 1 回程度の受け渡しで足りる |
| API での連携 | システムの API を使い、データを直接受け渡す | すぐに反映したい、受け渡しの量が多い |
| iPaaS | 連携のサービスの上で、複数のサービスのつなぎ方を設定で組み立てる | クラウドのサービスが多い、プログラムを書ける人が社内にいない |
| システムに備わった連携の機能 | 提供元が用意している、特定のサービスとの連携の機能を使う | よく使われる組み合わせ（会計と銀行の明細など） |
まず確かめるのは、使っているシステムに、つなぎたい相手との連携の機能が最初から備わっていないかです。備わっていれば、設定だけで使えることがあります。備わっていない場合に、API、iPaaS、ファイルの自動の受け渡しの順に検討します。
よくある連携の例
中小企業でよく見られる連携の例を挙げます。
1 つめは、受注から請求、会計までの流れです。顧客の管理の仕組みで受注が決まると、販売の仕組みに受注の情報が送られ、出荷の後に請求書が作られ、請求の情報が会計の仕組みに売上として記録される、という流れです。手作業のままだと、同じ取引先名と金額を 3 回入力することになり、どこかで食い違いが起きます。
2 つめは、勤怠と給与の流れです。勤怠の仕組みで締めた労働時間を、給与の計算の仕組みに取り込む形です。毎月の締めのたびに、書き出したファイルを手で直して取り込んでいる場合は、項目の対応を一度決めて自動で取り込む形にすると、締めの作業が大きく減ります。
3 つめは、問い合わせから顧客の管理への流れです。ウェブサイトの問い合わせの入力欄から届いた内容を、顧客の管理の仕組みに自動で登録し、担当者に知らせる形です。メールで届いた問い合わせを担当者が手で写していると、写し忘れや対応の遅れが起きます。
どの例でも、最初に決めるのは、どのシステムの情報を正とするかと、どの時点で次のシステムに渡すかです。受注の例であれば、「受注が確定した時点」なのか「出荷した時点」なのかで、販売の仕組みに送る時期が変わります。業務の区切りに合わせて、渡す時点を決めます。
連携を決める手順
手順 1：今のデータの流れを書き出す
どのシステムからどのシステムへ、どのデータを、誰が、どのくらいの頻度で写しているかを書き出します。業務の流れの図に、システムとデータの受け渡しを書き込むと分かりやすくなります。業務の流れの図の書き方は、業務フロー図の書き方で扱っています。
手順 2：正とするシステムを決める
同じ情報が複数のシステムにある場合、どのシステムの情報を正とするかを決めます。取引先の情報は会計の仕組み、案件の情報は顧客の管理の仕組み、というように、情報の種類ごとに 1 つに決めます。連携は、正とするシステムから、ほかのシステムへ渡す向きで作ります。決め方は、マスタデータ管理とはで説明しています。
手順 3：優先順位を付ける
書き出したデータの流れのうち、手作業の時間が長いもの、誤りの影響が大きいもの、頻度が高いものから、連携の対象にします。すべてを一度に連携しようとすると、設定と確認の作業が膨らみます。
手順 4：誤りが起きたときの手順を決める
連携は、相手のシステムが止まっている、データの形式が合わない、などの理由で失敗することがあります。失敗したときに、誰に知らせが届き、誰が直すのかを決めておきます。失敗に気づかないまま日がたつと、システムの間の食い違いが大きくなります。
連携を増やす前に考えること
連携の対象が増えると、つなぎ方が複雑になり、どこで何が受け渡されているのかが分からなくなります。連携を増やす前に、使っているシステムの数そのものが多すぎないかを確かめます。同じ用途のサービスが部署ごとに入っている場合は、連携より、まとめることを先に考えます。サービスが増えすぎた状態の整理の判断基準は、SaaS乱立はなぜ起きるのかで扱っています。
作った連携は、一覧にして残します。一覧には、どのシステムからどのシステムへ、何を、どの頻度で渡しているか、担当者は誰か、を書きます。一覧が無いと、システムを入れ替えるときに、どの連携が止まるのかが分からなくなります。
実行時の落とし穴
連携を作った人しか分からない
連携の設定を 1 人の担当者だけが知っている状態では、その人がいなくなると直せなくなります。設定の中身と手順を文書にし、2 人以上が分かるようにします。
失敗の知らせが届かない
連携が止まっていることに、数週間気づかないことがあります。失敗の知らせが担当者に届くように設定し、定期的に件数を確かめます。
データを整えずにつなぐ
名前や分け方がそろっていないデータをつなぐと、食い違いがそのまま相手のシステムに広がります。つなぐ前に、正とするシステムのデータを整えます。
