業務ワークフローとデータ連携の設計手順
要件は固まった。次は、その要件を実際に動く業務ワークフローとデータ連携の設計図に落とす番です。ここでつまずくと、せっかくの要件が「絵に描いた餅」になります。私たち日本FDE協会は、FDE（Forward Deployed Engineer＝顧客の現場に入り込んで課題を技術で解くエンジニア）の実践者が集まる中立の立場から、この設計フェーズに向き合ってきました。この記事を読めば、業務ワークフローを工程単位で分解し、システム間のデータ連携を「どこを自動化し、どこに人の判断を残すか」まで含めて設計図に落とせるようになります。連携方式の選び方と、壊れやすい箇所の洗い出しまで、次の作業でそのまま使える形で整理します。
業務フローを工程単位に分解する
設計の出発点は、ヒアリングで得た現場のフローを「工程」に切り分けることです。現場の説明は「注文が来たら処理して出荷する」のように塊で語られます。これを、入力・判断・変換・記録・出力といった単位まで割ることで、初めて自動化の可否が見えてきます。
「誰が」「何を入力に」「何を出すか」で書く
各工程は、担当者・入力データ・出力データ・判断の有無、という4点で記述します。この形にすると、工程間で受け渡されるデータの正体がはっきりします。ある製造業のクライアントの入出荷管理では、現場が一つの作業と思っていた工程が、実際には在庫照合・伝票発行・出荷指示の3工程に分かれていました。分解して初めて、自動化できるのは伝票発行だけで、在庫照合には人の判断が残ると判明したのです。
自動化と人の判断を最初に色分けする
工程を並べたら、自動化する工程と人が判断を残す工程を色分けします。例外が多い、責任が伴う、金額や与信が絡む——こうした工程は無理に自動化せず、人の判断を残す設計にします。FDEの現場では、初回に「それ、本当に全部自動化する必要がありますか」と問い直すことがよくあります。全自動より、人の確認を一箇所挟むほうが現場が安心して回る、というケースは少なくありません。
データ連携の方式を選ぶ基準
工程間でデータが動くところが「連携」です。ここで方式を誤ると、動いても保守できない仕組みになります。連携方式は大きく、リアルタイムに繋ぐAPI連携、決まった時刻にまとめて処理するバッチ連携、そして人手の転記を仕組みで置き換える手動転記の自動化、に分かれます。
即時性・頻度・データ量で見極める
選定は性能値の暗記ではなく、業務の性質で考えます。即時の反映が要る、頻度が高いならAPI連携が向きます。夜間にまとめて処理でよい、大量データを一括で扱うならバッチが堅実です。判断の目安を整理します。
連携方式 | 向いている業務 | 注意点 |
|---|---|---|
API連携（即時） | 在庫や予約など即時反映が必要 | 相手側の仕様変更・障害の影響を受けやすい |
バッチ連携（定期） | 日次集計・大量データの一括処理 | 反映まで時間差が出る／失敗時の再実行設計が要る |
手動転記の置換 | 今まさに人が転記している作業 | 元の入力ミスをそのまま自動で運ぶ危険 |
SaaS企業の現場で見た「繋ぎすぎ」の罠
あるSaaS企業では、営業データを複数ツール間ですべてAPIでリアルタイム連携していました。一見スマートですが、一つのツールが仕様変更するたびに連携が次々に壊れ、保守に追われていました。即時性が要らない部分を日次バッチに戻したところ、壊れる箇所が激減しました。繋げること自体が目的化しないよう、その連携に本当に即時性が要るのかを工程ごとに問うのが設計者の役割です。
壊れにくく、後から辿れる連携にする
連携設計で一般的な解説が触れないのが、統制の視点です。誰がどのデータをいつ触ったかを後から辿れること。これを最初から織り込むかどうかで、本番展開後の安心感がまるで変わります。
連携経路に権限とログを最初から通す
データが工程間を移動する経路には、アクセス権限と処理ログを設計段階で通しておきます。この連携を実行できるのは誰か、いつ何件を処理し成功したか、失敗したデータはどこに退避するか。これらを後付けしようとすると、動いている仕組みを作り直す羽目になります。金融機関のプロジェクトでは、連携ごとに処理件数と実行者、失敗レコードの記録を最初から残す設計にしたことで、監査部門との合意が驚くほど早く進みました（ここでのFDEは職種を指し、ディスク暗号化のFull Disk Encryptionとは別物です）。
壊れやすい箇所を先に洗い出す
連携が壊れるのは、たいてい決まった場所です。外部システムの仕様が変わる接続点、データ形式が揃わない変換点、相手側が落ちたときの待ち受け——ここを設計図の上で先に印を付け、失敗時にどう検知し、どう再実行するかを決めておきます。「正常に動く経路」だけでなく「失敗したときの経路」まで描いて、初めて設計図は完成します。要件を固める段階のコツはFDE要件定義で失敗しない実践テクニックを、改善全体の進め方はAI業務改善の進め方もあわせてご覧ください。
よくあるご質問
Q. 業務ワークフローの分解はどこまで細かくすべきですか。
自動化と人の判断の境目が見える粒度まで、が目安です。細かくしすぎると設計が重くなり、粗すぎると連携の受け渡しデータが曖昧になります。工程を「担当者・入力・出力・判断の有無」で書けるかを一つの基準にすると、適切な粒度に落ち着きやすくなります。
Q. すべての連携をAPIでリアルタイムにすべきですか。
いいえ。即時性が本当に必要な工程だけをリアルタイムにし、それ以外はバッチで十分なことが多いです。繋ぎすぎると保守負荷が上がり、壊れる箇所も増えます。その連携に即時性が要るかを工程ごとに問うのが現実的です。
Q. 統制やログの設計は後から追加できませんか。
技術的には可能ですが、動いている連携を作り直すコストが大きくなります。誰がいつ何を処理したかを辿れる記録は、設計段階で経路に織り込むほうが結果的に早く、安全です。法人での導入設計や研修は、ご相談いただければ現場に合わせて整理します。
業務ワークフローとデータ連携の設計・法人研修のご相談はお気軽に
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。