このユニットの結論
システム連携とは、あるシステムで生まれたデータを、それを必要とする別のシステムへ、決めた形・決めたタイミングで受け渡す仕組みです。
連携は、業務のつながりをシステムの間で再現したものです。連携を読むときは、「どの業務のために、どのデータが、どちらからどちらへ流れるか」から読みます。
1. 何の話か
このユニットは、STAGE 07「36本のシステム連携を管理する」の入口です。
会社の仕事は部署をまたいでつながっています。営業が契約を取るとプロジェクトが始まり、社員の作業時間が原価になり、請求と会計につながります。人の手なら、表を渡したり、同じ内容を別の画面に入力し直したりします。システム連携は、この受け渡しをシステムの間で行うものです。
2. なぜ必要か
連携がなければ、
- 同じデータを、人が複数のシステムに入力し直すことになる
- 入力のし直しで、写し間違い・入力漏れ・時間差が生まれる
- システムごとに少しずつ違う値が残り、どれが正しいか分からなくなる
ということが起きます。一方で、連携が増えるほど、1つのシステムの停止や誤りが、つながった先へ広がります。だから連携は、1本ずつ設計し、全部を管理する必要があります。
3. このユニットで分かること
- 連携を「業務のつながり」として読む方法
- 連携の種類（何のデータを運ぶか）
- 連携のタイミング（すぐ渡すか、まとめて渡すか）
- STAGE 07 の各ユニットで扱うこと
4. 連携を業務のつながりとして読む
連携を見るときは、技術の方式より先に、次の3つを確かめます。
- 何の業務のためか：受け取る側は、そのデータで何をするのか
- どちらが正本か：そのデータの正しい値を持っているのはどのシステムか（正本（せいほん）＝データのおおもと）
- どちらからどちらへ：正本から、使う側へ流れているか
正本がはっきりしていれば、値が食い違ったときにどちらを正しいとするかが決まります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の連携とデータの正本
- 約36本のシステム連携。そのうち正本で個別に定義されているのは IF-01〜IF-12
- IF-01 顧客マスター連携：営業管理 → 新基幹／IF-02 契約情報連携：営業管理 → 新基幹／IF-03 社員・組織マスター連携：人事 → 新基幹
- IF-04 工数連携：勤怠・工数SaaS → 連携基盤 → 新基幹
- IF-05 売上仕訳連携・IF-06（名称はシステム・連携を参照）・IF-07 原価仕訳連携：新基幹 → 連携基盤 → FIN-CORE
- IF-08 新基幹 → BI、IF-09 FIN-CORE → BI、IF-10 認証・ID → 新基幹、IF-11 新基幹 → 監視・ログ、IF-12 連携基盤 → 監視・ログ
- データの正本（抜粋）：顧客・契約は営業管理システム、社員・組織は人事マスター、工数は勤怠・工数管理SaaS、案件・案件原価・請求は新基幹、正式な会計仕訳は FIN-CORE、経営分析は BI
IF-01〜IF-12 以外の連携の名称・経路・内容と、各連携の方式・タイミングは、正本に記載がありません。未確定
5. 連携の種類 — 何を運ぶか
上の CASE FACT を、運ぶデータの種類で分けると、次のように読めます（分け方は教材上の整理です）。
| 種類 | 意味 | 正本の連携 |
|---|---|---|
| 基本情報（マスター） | 顧客・社員・組織など、何度も参照する基本のデータ | IF-01・IF-03 |
| 業務の記録 | 契約・工数・仕訳など、業務のたびに生まれるデータ | IF-02・IF-04・IF-05・IF-06・IF-07 |
| 分析 | 経営の判断のために集めるデータ | IF-08・IF-09 |
| 認証 | 誰が使ってよいかの情報 | IF-10 |
| 監視 | システムの状態の情報 | IF-11・IF-12 |
IF-01〜IF-04 は、それぞれのデータの正本のシステムから新基幹へ流れています。たとえば、顧客の情報は営業管理システムが正本なので、新基幹は受け取って使う側です。IF-05〜IF-07 は、新基幹から、正式な会計仕訳の正本である FIN-CORE へ向かう連携です。連携の向きは、いつも「正本から使う側へ」とは限りません。IF-08〜IF-12 で運ぶデータの正本は、正本に記載がありません。未確定
6. 連携のタイミング — すぐ渡すか、まとめて渡すか
| 渡し方 | 考え方 | 向いている場面（一般的な説明） |
|---|---|---|
| すぐ渡す | データが生まれたら、そのつど渡す | 画面で入力した結果を、すぐに相手でも使いたい |
| まとめて渡す | 決めた時刻に、たまったデータをまとめて渡す | 量が多く、少し遅れても業務に困らない |
すぐ渡す方法の代表が API（システムどうしの決まった窓口）です。まとめて渡す方法の代表が、夜間などの一括処理（バッチ）です。どちらにも向き・不向きがあります。API の限界は 07-02 APIは万能ではない、一括処理は 07-03 夜間処理が必要な場合 で学びます。
7. THINK — 新基幹でも顧客を登録できるようにする？
（教材上の例）新基幹システムの利用者から、次の要望が出ました。
「急ぎの案件のとき、営業管理システムに顧客が登録されるのを待てません。新基幹の画面でも顧客を登録できるようにしてください。」
問題
この要望をそのまま受け入れてよいでしょうか。上の CASE FACT のデータの正本を見て考えてください。
判断例を開く
判断
そのままでは受け入れません。
確認すること:
- 顧客の正本は営業管理システムと定められている。新基幹で登録した顧客は、どちらが正本になるのか
- 同じ顧客が両方で別々に登録され、二重になったとき、誰がどう直すのか
- 「待てない」の中身は何か。営業管理システムでの登録や連携の手順を早めることで解決できないか
正本を2つにすると、どちらの値が正しいか決められなくなります。要望の元にある業務の困りごとを確かめ、正本を変えずに解決する方法を先に探します。
8. STAGE 07 で扱うこと
- 07-02 APIは万能ではない：すぐ渡す方法の限界
- 07-03 夜間処理が必要な場合：まとめて渡す方法と、その注意点
- 07-04 相手システムが止まっていたらどうするか：相手が止まったときの判断
- 07-05 同じ処理が2回来ても大丈夫にする：二重に届いても困らない設計
- 07-06 36本を一覧で管理する：全部の連携を一覧で管理する
9. よくある失敗
- 技術の方式から話し始め、何の業務のための連携かを確かめない
- データの正本を決めず、両方のシステムで同じデータを登録できるようにする
10. 成果物との接続
- ARC-004 システム連携一覧：すべての連携を同じ項目で並べる
- ARC-005 システム連携処理図：連携1本ごとの処理の流れを図にする
- ARC-001 システム全体構成図：システムと連携の全体の位置関係を見る
11. AI WORKFLOW — 連携を業務の言葉で説明させる
指示例:
「次の連携一覧とデータの正本の一覧をもとに、連携ごとに『何の業務のために、どのデータを、どちらからどちらへ渡すか』を、業務の担当が読める言葉で1〜2文にしてください。一覧に書かれていない方式・時刻・目的は補わず、『記載なし』と書いてください。」
12. REVIEW — AIの説明を確認する
- AIが、一覧にない目的や方式を推測で書いていないか
- 正本と流れの向きが、元の一覧と合っているか
- 業務の担当が読んで、実際の業務と合っているか
人間が判断すること
- データごとの正本をどのシステムにするか
- 連携ごとに、すぐ渡すか、まとめて渡すか
- 新しい連携を追加するかどうかと、その承認
13. 判断演習
上の CASE FACT の IF-03 社員・組織マスター連携（人事 → 新基幹）について、次の3つを書いてください。
- 新基幹は、このデータを何の業務に使うと考えられるか（推測であることを明記する）
- このデータの正本はどのシステムか
- すぐ渡すか、まとめて渡すかを決めるために、業務の担当に確かめること
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
連携は、業務のつながりをシステムの間で再現したものです。
「何の業務のために、どのデータが、正本からどこへ流れるか」から読み、方式はそのあとで決めます。