スイムレーン図の例: すべての引き継ぎが見える部門横断フローチャート

顧客が月曜日に 40 USD の返金を依頼します。サポートは 1 時間以内に承認し、木曜日にまとめて返金を実行する経理へ回します。その後、銀行が入金を表示するまでに 5〜10 営業日かかることがあります。依頼から 10 日後、明細に何も載っていない顧客は、請求に異議を申し立てます。

どのチームも期限どおりに仕事を終えていました。遅れはチームの間にありました。依頼が次の担当者を待つキューの中です。このプロセスを普通のフローチャートで描くと、問題なさそうに見えます。スイムレーン図は、各ステップを実行する人のレーンに置くので、問題はレーンをまたぐ矢印として現れます。

この記事では、スイムレーン図とは何か、フローチャートや BPMN の代わりにいつ使うかを説明し、そのうえで返金の例を見ていきます。記号、引き継ぎ、改善、描き方のコツを扱います。

スイムレーン図とは

スイムレーン図は、アクターごとに 1 本ずつ、平行なレーンに分けたフローチャートです。アクターは人、役割、チーム、システムのいずれかです。各ステップは、それを実行する人のレーンに置きます。矢印は引き続き順序を示し、レーンが担当を加えます。部門横断フローチャート、スイムレーン図、スイムレーンプロセスマップは、どれも同じものの別名です。

レーン内の矢印は、チームの中で作業が動くことを表します。レーンの境界をまたぐ矢印は引き継ぎです。作業の担当が変わり、たいていは誰かが手を付ける前にキューで待ちます。

1990 年に初版が出た Improving Performance で、Geary Rummler と Alan Brache は「パフォーマンス改善の最大の機会は、多くの場合、機能間のインターフェースにある」と論じました。そこは作業が部門の間を渡る場所で、副題の言葉を借りれば組織図の余白です。スイムレーン図は、その余白を描きます。

スイムレーン図、フローチャート、BPMN の違い

答えたい問いで選びます。「次に何が起きるか」なら、フローチャートで足ります。オンコールのエンジニア 1 人がたどるインシデント対応フローチャートがその例です。「今それを誰が持っていて、どれだけ待っているか」なら、レーンが必要です。プロセスエンジンがモデルを実行する場合や、組織間のイベントとメッセージフローを正確にしたい場合は、BPMN を選びます。BPMN 2.0.2 仕様は、プールとレーンをスイムレーンと呼び、レーンの意味づけはモデラーに任せています。この表記法は BPMN 図の例で扱っています。

例: 返金依頼をステップごとに見る

オンラインストアは、返金を 4 者で処理します。顧客、サポート、経理、決済システム (決済プロバイダーと請求) です。この例のポリシーでは、30 日以内の返金を受け付け、100 USD 未満はサポートが承認でき、それより大きいものは経理に回します。

1. 顧客が返金を依頼します。
2. サポートが、注文を返金ポリシーと照らして確認します。
3. 依頼がポリシーの範囲外なら、サポートが理由を添えて却下を送ります。
4. 100 USD 未満なら、サポートが承認し、その日のうちに返金を実行します。
5. 100 USD 以上なら、経理が審査します。経理が却下の理由を見つけたら、サポートが顧客に判断を説明します。
6. 決済システムが元の支払い方法に返金し、確認メールを送ります。
7. 銀行が入金を表示するのは約 5〜10 営業日後です。これは Stripe の返金ドキュメントによります。

スイムレーン図の記号

記号を増やすのは控えましょう。記号が 1 つ増えるたびに、経理の担当者があなたの図を確認する前に覚えることが 1 つ増えます。

レーンから見えること

引き継ぎ

レーンの境界をまたぐ矢印を数えます。100 USD 未満の返金は 3 回またぎます。顧客からサポート、サポートから決済システム、決済システムから顧客へ戻る、の 3 回です。100 USD 以上の返金は 4 回またぎ、経理が却下する依頼も同じく 4 回です。しきい値がなかったころは、すべての返金が 4 回の引き継ぎを通っていました。引き継ぎのたびにキューができます。冒頭の話では、作業は数分で終わり、待ちに数日かかりました。

待ちと手戻りのループ

待ちは引き継ぎに隠れているので、矢印に書き込みます。ステップごと、ステップ間ごとの時間を詳しく測るなら、バリューストリームマップを描きます。

手戻りのループとは、作業がすでに通ったレーンに戻る矢印です。経理の却下がサポートに戻るのは意図的です。顧客とのやり取りはサポートの担当だからです。フォームで必須にできたはずの注文番号をサポートが顧客に尋ねるのは、純粋なムダです。

担当不在

どのレーンにも置けないステップは、担当の抜けです。失敗した返金を確認しましょう。Stripe によると、返金は失敗することがあり、たとえば顧客の銀行口座が閉鎖されている場合です。資金が残高に戻るまで最長 30 日かかることがあり、顧客や社内に知らせる仕組みは自分で作る必要があります。このステップをどのレーンも持っていなければ、誰もやりません。

図からプロセスを改善する

1. 引き継ぎを 1 つ減らします。 少額の返金はサポートが直接実行できるようにし、しきい値未満のすべての返金から経理のキューを外します。決済プロバイダーは、フルアクセスなしでこれを許可します。Stripe の Refund Analyst ロールは、支払いの閲覧と返金ができますが、支払いの作成や残高の閲覧はできません (執筆時点、2026 年 11 月)。
2. 承認のしきい値を設けます。 データから選びます。前四半期の返金を金額順に並べ、各候補の下に何件の依頼とどれだけの金額が入るかを確認します。調べなくて済むように、その数字を判断の中に書き込みます。上限を信頼ではなく強制したいなら、返金ツールが決済 API を呼ぶ前にチェックします。
3. すべての引き継ぎに目標を置き、 矢印に書きます。サポートは 1 営業日以内に返信し、経理は 2 営業日以内に判断します。すると、少額の返金は 1 営業日以内、大きい返金は 3 営業日以内に実行されます。銀行の 5〜10 営業日はこちらでは制御できないので、確認メールにそう書きます。

横レーンか縦レーンか

BPMN では、レーンはどちらの向きでも使えます。違いは実用面にあります。

関連する図のセットでは向きを 1 つに決め、読み手が向きを切り替えなくて済むようにします。

返金依頼のスイムレーン図

図の読み方は次のとおりです。

• 4 つのレーンが上から順に、顧客、サポート、経理、決済システムです。
• Yes は常に右へ、No は下へ出ます。 どの問いも、Yes が「何か対応が必要」を意味する形で書いています。ポリシーの範囲外、100 USD 以上、却下の理由があるかどうかです。
• 緑は返金の経路です。 100 USD 未満の依頼は、サポートから決済システムへ直接下り、経理のレーンには入りません。
• 赤は却下の経路です。 2 つの却下はどちらも、サポートが顧客に理由を送って終わります。
• 引き継ぎのラベルが目標を示します。 破線の矢印は銀行の 5〜10 営業日です。
• Markdown ブロックには、ポリシー、目標、経路ごとの引き継ぎを載せています。

スイムレーン図をわかりやすく描くには

• レーンごとに担当は 1 つ。 レーンには人名ではなく、役割、チーム、システムの名前を付けます。Dana というレーンは、次の組織変更の後には間違いになります。
• すべてのボックスを動詞で始めます。 「Order check」ではなく「Check order and refund policy」とします。
• 判断の出口にはすべてラベルを付け、 どのひし形でも同じ答えを同じ側に置きます。
• やり取りの多い順にレーンを並べ、 引き継ぎの多くが境界 1 つをまたぐだけで済むようにします。レーンを飛ばすのは意図的な場合だけです。ここでは少額の返金がそうしています。
• 待ちは引き継ぎに書きます。 待ち時間は、誰かが書き出すまで見えないままです。
• システム内部は省きます。 API 呼び出しや Webhook は、決済ゲートウェイ連携図のようなアーキテクチャビューに属します。
• 現状のプロセスと提案は別々に描き、 計画を今日の姿と取り違えないようにします。
• すべての経路を端子で終わらせ、 レーンが 6〜7 本を超えるなら図を分けます。

Archboard で作る

1. Google または GitHub でサインインして図を作成するか、すでにレーンがある部門横断フローチャートのテンプレートを開きます。
2. BPMN パックから プール を追加し、名前を Refund request process にして、Customer、Support、Finance、Payment system の 4 つのレーンを作ります。
3. フローチャート パックから、Customer レーンに 開始 / 終了 ノードを 3 つ追加します。Request refund、Request closed、Refund received です。
4. Support には、注文を確認する 処理、2 つの 判断 ノード (Outside refund policy?、$100 or more?)、却下を送る 処理 を追加します。
5. Finance には 処理 (Review refund) と 判断 (Reason to decline?) を追加します。Payment system には、返金のための 処理 と、確認メールのための 書類 を追加します。
6. 各 Yes を右、各 No を下にして、ステップをつなぎます。引き継ぎに目標のラベルを付け、返金の経路を緑、却下の経路を赤にし、銀行の待ちは破線にします。
7. 基本 パックから、ポリシーと目標を書いた Markdown ブロックと、2 つの テキスト ノートを追加します。

プロセスがすでに Mermaid のフローチャートとしてあるなら、Mermaid から図への変換ツールで、編集できる最初の下書きにできます。Free の図に置けるダイアグラムノードは 15 個なので、長いプロセスには Pro か 2 つ目の図が必要です。この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。

よくある質問

スイムレーン図とは何ですか? 人、チーム、システムごとに 1 本ずつレーンに分けたフローチャートで、各ステップをそれを実行する人のレーンに置きます。レーンの境界をまたぐ矢印が引き継ぎです。

スイムレーン図とフローチャートの違いは何ですか? フローチャートはステップと判断の順序を示します。スイムレーン図は担当を加えるので、引き継ぎ、待ち、担当のないステップが見えるようになります。

部門横断フローチャートはスイムレーン図と同じですか? はい、呼び名は入れ替えて使えます。スイムレーンプロセスマップも同様です。BPMN もレーンを使いますが、プールの中で、より厳格な表記法で使います。

スイムレーンは横と縦のどちらにすべきですか? どちらでも使えます。横レーンはワイド画面の長いプロセスに、縦レーンは下へスクロールするドキュメントやスマートフォンに向いています。図のセットごとに 1 つ決めてください。

システムに専用のレーンを持たせられますか? はい。自分で作業する決済プロバイダーやスケジューラーには、レーンを持たせる価値があります。BPMN 仕様も、レーンの典型的な用途にシステムを挙げています。

無料で始める — 1 シート、クレジットカード不要。