シーケンス図と業務フローの違い｜使い分けと確認事項

はじめに

「業務フローは完成したのに、システムの仕様を決める会議で話がかみ合わない」。たとえば受注の流れを「注文を受ける→在庫を確認する→出荷を指示する」と整理しても、在庫が不足したときに画面が何を表示し、どのシステムに何を記録するかまでは分かりません。

そこで役立つのがシーケンス図です。業務フローは、仕事がどの順で進み、誰が判断するかを俯瞰します。シーケンス図は、その中の一場面を取り出し、利用者やシステムの間で何がどの順にやり取りされるかを示します。どちらか一方が優れているのではなく、答えたい問いが異なります。

この記事では、発注者や業務担当者が図の違いを理解し、開発担当者と何を確認すればよいかを、受注業務の例で整理します。

業務フローとシーケンス図の違い

業務フローにも順番はあります。シーケンス図にも人の判断を描けます。違いは、どの粒度で、何を確かめるために描くかです。全体を見たいときに細かい通信を並べれば読みにくくなり、連携の失敗を検討したいときに「在庫確認」の箱だけでは判断が足りません。

IBMのシーケンス図の解説では、相互作用に参加する対象と、その間で時間順に交換されるメッセージを示す図と説明しています。業務フローの形式は組織によって異なり、スイムレーン形式やBPMNなど複数の表し方があります。ここでは特定の記法ではなく、業務の流れを共有する図として扱います。

同じ受注業務を二つの図で考える

例えば、顧客から注文を受け、在庫があれば出荷を手配する仕事を考えます。業務フローなら、まず次のように並べます。

1. 営業担当が注文を受け付ける。
2. 受注担当が注文内容と在庫を確認する。
3. 在庫があれば出荷を指示し、なければ顧客へ納期を確認する。
4. 変更や取消しがあれば、担当者が記録して関係者へ伝える。

この図を見れば、誰が在庫不足を判断し、どの部署が顧客へ連絡するかを話し合えます。一方、在庫照会がどのシステムへ送られ、結果が返るまで何を待つかは、この粒度では決めきれません。

そこで「受注担当が在庫を確認する」場面を取り出します。シーケンス図では、参加者を受注担当、注文画面、注文管理システム、在庫管理システムのように並べ、次のやり取りを時系列で示します。

1. 受注担当が注文画面で在庫確認を依頼する。
2. 注文管理システムが、商品と数量を在庫管理システムへ送る。
3. 在庫管理システムが、在庫あり・不足・確認失敗のいずれかを返す。
4. 注文画面が結果を表示し、不足や失敗なら担当者が次の操作を選ぶ。

これは説明のための例であり、すべてのシステムがこの構成とは限りません。開発担当者と実際の構成を確認し、在庫が「ある」と返った後に引当てるのか、単に照会するだけなのかも区別します。照会結果だけで在庫が確保されたと決めつけると、別の注文と競合した際の仕様が抜けます。

どちらから作る？迷ったときの判断

1. 仕事の範囲が曖昧なら業務フローから

部門ごとに説明が違う、承認の要否が決まっていない、現行業務に例外が多い。こうした場合は、まず仕事の開始と終了、関係者、作業、分岐を並べます。図に載せるのは、システム操作だけではありません。電話での確認やExcelの転記など、実際に行っている仕事も対象です。

To-Be業務フローの整理では、改善後の目的、例外、責任をどう合意するかを扱っています。現状と改善後を混ぜず、どちらの図なのかを明記しておくと、開発範囲の認識違いを防げます。

2. 受け渡しや応答順が曖昧ならシーケンス図を追加

「確認する」という作業は決まっていても、確認先、渡す情報、返る結果が分からない場合は、対象の一場面をシーケンス図にします。特に外部システムが関わる場合、依頼と応答を分けることで、自社と連携先の責任を整理しやすくなります。

図の中の縦の線は、参加者がやり取りに関わる時間の流れを示すものです。矢印は参加者間のメッセージを表し、通常は上から下に進みます。記号を暗記するより、「この矢印で何を頼み、何を受け取るのか」を確認することが大切です。PlantUMLの公式説明には参加者とメッセージ、条件分岐の表現例があります。具体的な描き方はシーケンス図の書き方も参考にしてください。

3. 両方をつなぐ単位を一つ決める

二つの図を別々に作り、対応が分からなくなることがあります。業務フローの「在庫を確認する」に番号を付け、シーケンス図にも同じ番号と開始・終了条件を記載します。業務フローで作業名や責任者を変えたら、対応する図と仕様も確認する運用にします。

図にすべての判断を書き込む必要はありません。例えば、在庫不足時の連絡期限や再試行回数は、別の仕様書に記載し、図から参照します。図と文書のどちらを正本にするか、変更時に誰が両方を見直すかも決めておきましょう。

開発担当者と確認したい5つのこと

1. 誰が開始し、何をもって完了するか

在庫照会は担当者のボタン操作で始まるのか、注文の登録後に自動で始まるのか。完了は在庫の回答を受け取った時点か、担当者に結果を表示した時点か。開始と終了の定義を明確にすると、図に入れる範囲を絞れます。

2. どの情報をどこへ渡すか

商品番号、数量、納品希望日など、必要な情報を列挙します。個人情報が含まれる場合は、連携先へ本当に必要かも確認します。画面に見えている情報が、そのまま相手システムへ送られるとは限りません。項目名と意味は、外部インターフェース一覧などの文書と対応させます。

3. 判断と承認の担当は誰か

在庫不足なら、担当者が顧客へ連絡するのか、システムが自動通知するのか。納期の変更を誰が承認するのか。図で自動処理と人の判断を分け、代理担当や営業時間外の扱いも未決事項として残します。

4. 応答がないとき、どこまで進めてよいか

連携先が応答しない場合、結果が届かないだけで、処理自体は完了している可能性があります。画面に「失敗」と表示するだけでは、担当者が再操作して二重の処理を起こすかもしれません。確認方法、再試行の条件、記録すべき情報、担当者へ戻すタイミングを開発側と決めます。待ち時間や回数は、その業務の要件と連携先の仕様を確認してから決めましょう。

5. どうなれば受け入れられるか

正常に在庫が返る場合だけでなく、不足、応答なし、注文取消しの場面も取り上げます。それぞれについて「画面に何が表示され、何が保存され、担当者が何をできるか」を、具体的な確認条件にします。図は会話の入口であり、図を描いたこと自体がテスト合格の証拠にはなりません。

よくある行き違いと防ぎ方

図を一枚に詰め込みすぎる。 業務全体の図へ、すべてのAPIや内部処理を載せると、現場の判断が見えにくくなります。業務全体と個別のやり取りを分け、番号やリンクで結びます。

正常系だけで合意する。 注文が届き、在庫があり、すぐに出荷できる例だけでは、欠品や連携停止の対応が残ります。件数が少なくても影響が大きい例外は、責任者と優先して確認します。

図を作成後に更新しない。 仕様変更で担当部署や連携先が変われば、両方の図の対応も見直します。更新日、責任者、関連する仕様へのリンクを残し、会議資料だけが古いまま残らないようにします。

記号の正しさだけをレビューする。 記法の統一は役立ちますが、事業側が「在庫不足時に顧客へいつ連絡するか」を判断できなければ合意には至りません。開発担当者に図を説明してもらい、業務上の結果と言葉で突き合わせましょう。

まずは一つの仕事で試す

業務フローは全体の流れと責任を共有し、シーケンス図はその一場面のやり取りを詳しく確認します。最初から全業務を描き直す必要はありません。関係者が迷いやすい作業を一つ選び、開始・終了、参加者、やり取り、例外、受け入れ条件を整理するところから始めてみてください。

会議メモや既存資料が散在している場合は、Kakusillを使って業務フローや論点のたたき台を整理し、関係者と不足を確認できます。図と仕様のつながりを作り、決まっていない点を残したまま開発へ進めないことが、認識のずれを減らす第一歩です。