システム連携処理図

これは何か

システム連携処理図は、1本のシステム連携について、データが送る側から受ける側に届くまでの処理の流れを、図と表で示す成果物です。

たとえば、夜のうちに届くはずのデータが朝になっても届いていないとき、担当者は「どこで止まったのか」「送り直してよいのか」をすぐに知りたくなります。連携の一覧では、そこまでは分かりません。

ARC-004 システム連携一覧 との違いは、見る範囲です。

• 連携一覧：すべての連携（アステリア案件では約36本）を同じ項目で並べた台帳。「どんな連携が何本あるか」を見る
• 連携処理図：その中の1本を取り出し、「その連携の中で何がどの順に起きるか」を見る

なぜ作るか

• 止まったとき、どの段階まで進んだかを確かめる場所が分かる（07-04）
• 送り直しをどこから始めれば安全か、二重に届いたときにどうなるかを、事前に決めておける（07-05）
• 送る側・連携基盤・受ける側で担当が分かれていても、境目の処理を誰が持つかが見える

誰が使うか・いつ作るか

• 作る人：連携の設計の担当。送る側・受ける側・連携基盤の担当がそれぞれ確かめる
• 使う人：開発・テスト・運用の担当、障害を調べる人
• 一般的には、連携一覧で連携が決まった後、1本ずつの設計の段階で作ります。止まったときの業務への影響が大きい連携から描くことが多いです
• アステリア案件で、どの連携について処理図を作ったか、誰が作ったかは、正本に記載がありません。未確定

どの連携も、起動のきっかけ・方法・時刻・失敗時の扱い・送り直しの方法・二重に届いたときの扱いは、正本に記載がありません。未確定 下の教材用サンプルは、経路の形（送る側 → 連携基盤 → 受ける側）だけを借りた架空の例で、IF-04〜IF-07 の設計ではありません。

主な項目

1本の連携について、一般的には次を描きます。

1. 登場するもの：送る側・連携基盤・受ける側と、監視の仕組み
2. 起動のきっかけ：決まった時刻か、データができたときか、人の操作か
3. 正常の流れ：取り出し → 受け渡し → 取り込み → 終わりの知らせ
4. 失敗したとき：どの段階の失敗を、誰が、どうやって知るか
5. 送り直し：自動か人の判断か、どこから送り直すか
6. 二重に届いたとき：受ける側で、すでに処理したものをどう見分けるか
7. 終わりの確かめ方：件数などで、全部届いたことをどう確かめるか

読み方

1. 正常の流れをたどり、登場するものと順番をつかむ
2. 表の「失敗」の行で、どの段階で止まると誰が気づくかを見る
3. 送り直しと二重の行で、どこから・誰の判断で送り直し、受ける側でどう見分けるかを見る

書き方

1. 連携一覧から1本を選び、送る側・連携基盤・受ける側・監視を並べる
2. 正常の流れを、段階ごとに短い言葉で描く
3. 段階ごとに「ここで止まったら」を書き、知らせる先を決める
4. 送り直しと二重の扱いを、受ける側の担当と一緒に決める
5. 描いた流れを、テストの場面（TST-002）に写す

何を書いてはいけないか

• 正常の流れだけを描いた図（失敗・送り直しがない）
• 「エラー時は再送」のように、どこから・誰の判断で送り直すかが分からない書き方
• 決まっていない扱いを、決まったもののように描くこと（決まっていなければ「未決」と書く）

よくある失敗

• 送る側と受ける側が別々に図を作り、境目の処理が食い違う
• 障害の後に初めて、送り直しの起点を話し合う

関係するUnit・成果物・危機演習

• Unit：05-04 システム同士をどうつなぐのか、07-04 相手システムが止まっていたらどうするか、07-05 同じ処理が2回来ても大丈夫にする、07-06 36本を一覧で管理する
• 成果物：ARC-004 システム連携一覧、ARC-003 システム責任分担表、TST-002 テスト計画・対象一覧、OPS-002 監視・アラート一覧
• 危機演習：この成果物を直接の題材にする危機演習はありません

いつ使うか

この教材では STAGE 07｜36本のシステム連携を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。