スイムレーン図とは？フローチャートやシーケンス図との違いを調べてみた

はじめに#

ユーザーの操作からWeb画面、バックエンドの認証APIまでが絡むログイン機能の設計書を作っているときに、処理の流れを図にする必要があった。

そのとき、自分はシーケンス図を書こうとしていたのだが、チームの先輩から、

「この内容なら、スイムレーン図の方が合っているかもしれない」

と指摘を受けた。

スイムレーン図という名前自体は聞いたことがあったが、改めて考えてみると、正直よく分かっていなかった。

特に気になったのが、

• 普通のフローチャートと何が違うのか
• シーケンス図とは何が違うのか
• UMLの図なのか
• どんな場面で使うのか
• 人とシステムを同じ図に書いてよいのか
• APIやDBをレーンにしてもよいのか

という点。

そこで今回は、スイムレーン図について調べつつ、同じ「ログイン処理」を題材にして、

• フローチャート
• スイムレーン図
• シーケンス図

の3種類をMermaidで実際に作って比較してみる。

単に「スイムレーン図とは何か」を調べるだけではなく、

結局、どんなときにどの図を使えばいいのか？

まで整理することを今回のゴールにする。

まず結論#

今回調べてみた結果、自分としては次のように整理した。

つまり、

どの図が優れているかではなく、「何を伝えたいか」で使い分けが大事

というのが今回の結論。

例えばログイン処理なら、

「ログイン処理にどんな分岐があるのか」を確認したいならフローチャート。

「ユーザー、Web、認証APIなどが、それぞれ何を担当するのか」を確認したいならスイムレーン図。

「Webから認証API、認証APIからDBというように、誰が誰にどの順番で処理を要求するのか」を確認したいならシーケンス図。

という感じで使い分けられる。

スイムレーン図とは？#

┌──────────┬──────────┬──────────┐
│ ユーザー │ Web画面  │ 認証API   │
├──────────┼──────────┼──────────┤
│          │          │          │
│ 入力     │          │          │
│          │ 認証要求 │          │
│          │          │ 認証     │
│          │ 結果表示 │          │
└──────────┴──────────┴──────────┘

「スイムレーン」という名前の意味#

スイムレーンを英語にすると「泳ぐレーン」の意味になる。

プールのコースを複数のレーンに分けるように、処理を担当者やシステムなどの単位で区切る。

例えば、

ユーザー
────────────
Web
────────────
認証API
────────────
DB

という形で区切り、それぞれの場所に処理を配置していく。

見た目がそのまますぎるが、この形状から「Swimlane」という名前が使われている。

UMLとの関係#

ここは少し注意が必要だった。

最初は、

「スイムレーン図というUMLの独立した図がある」

くらいに考えていた。

しかし、UMLではActivity Partitionという要素が定義されている。

Activity Partitionを利用すると、アクティビティ図の中で処理を担当する要素などを区切って表現できる仕組みになっている。

そのため、

「スイムレーン図＝UMLの独立した図」

と単純に考えるより、

UMLのアクティビティ図では、Activity Partitionを利用してスイムレーン形式で表現できる

と理解した方が正確っぽい。

UMLの仕様については、OMGがUML 2.5.1を公開している。

OMG — UML Specification

フローチャートじゃだめなの？#

フローチャートは、基本的に処理や判断の流れを表現するための図。

例えばログイン処理なら、

flowchart TD
    Start([開始]) --> Input[ID・パスワードを入力]
    Input --> Auth[認証]
    Auth --> Check{認証成功？}
    Check -->|Yes| Success[ログイン成功]
    Check -->|No| Error[エラー表示]

この図からは、

「ログイン処理がどのように進み、どこで分岐するのか」

がはっきり分かる。

一方で、

「この処理は誰が担当しているのか」

までは、この図だけだと見えてこない。

そこで「誰がやるか」を可視化するためにスイムレーン図を使う形になる。

実際にスイムレーン図を作ってみる#

swimlane-beta LR
 subgraph User["ユーザー"]
        Input["ログイン情報を入力"]
        Complete["ログイン結果を確認"]
    end

    subgraph Web["Web画面"]
        Request["認証要求"]
        Result["認証結果を表示"]
    end

    subgraph Auth["認証API"]
        Authenticate["ユーザー認証"]
    end

    Input --> Request
    Request --> Authenticate
    Authenticate --> Result
    Result --> Complete

スイムレーン図で分かったこと#

実際に同じログイン処理をスイムレーンにしてみると、

処理の流れそのものが大きく変わったわけではない

ということが分かった。

変わったのは、処理に「担当」という視点が加わったこと。

例えば、

ユーザー → ログイン情報入力
Web      → 認証要求
認証API  → 認証処理
Web      → 結果表示

という関係が見えるようになる。

そのため、

「普通のフローチャートだとダメ」

ということではない。

確認したい情報が違うだけということが分かった。

レーンにAPIやDBを置くのはだめなの？#

ここも気になったので確認してみた。

結論としては、

人間（ユーザー）とシステム（Web画面・API・DB）を1つのスイムレーン図に混在させて書いても全く問題ない

し、レーンを人間で分けるかシステムで分けるのも自由だと分かった。

例えば、ユーザーとWeb画面、認証APIを並べれば、「人間の操作からシステムのどのコンポーネントへ処理が引き継がれるか」という境目が非常にクリアに見えるようになる。

また、システムの処理だけを細かく説明したいなら、

ユーザー
Web
認証API
DB

という区切り方が考えられるし、

一方、業務フローを説明するのであれば、

顧客
営業
経理

のような人間の組織単位での区切り方が考えられる。

つまり、

「レーンには必ず人間だけ（あるいはシステムだけ）を書かないとダメ」

というルールはない。

重要なのは、

この図では、何を単位として処理を分けると理解しやすいのか？

という点。

シーケンス図じゃだめなの？#

次に、最初に作ろうとしていたシーケンス図と比較してみる。

シーケンス図では、登場する要素と、それらの間で発生するメッセージの順序を表現できる。

同じログイン処理をMermaidで表現すると、

sequenceDiagram
    actor User as ユーザー
    participant Web as Web画面
    participant Auth as 認証API
    participant DB as DB

    User->>Web: ログイン情報を入力
    Web->>Auth: 認証要求
    Auth->>DB: ユーザー情報を検索
    DB-->>Auth: ユーザー情報
    Auth-->>Web: 認証結果
    Web-->>User: ログイン結果

となる。

こちらでは、

ユーザー → Web → 認証API → DB

というやり取りの順番やリクエスト・レスポンスの往復が分かりやすくなっている。

同じログイン処理を3種類で比較してみる#

ここまでの結果を整理してみる。

この表からも分かるように、単純に「スイムレーン図がフローチャートより優れている」という話ではない。

それぞれ得意・不得意がある。

どの図を使えばいいのか問題#

今回の記事で一番整理したかった部分。

自分は次のように考えると選びやすいと思った。

処理A
 ↓
処理B
 ↓
判断
 ├→ 処理C
 └→ 処理D

ユーザー
Web
API
DB

A → B
B → C
C → B
B → A

誰が読む資料なのかも考える#

今回調べていて、もう一つ重要だと思ったことがある。

それは、

「誰が読む資料なのか？」

という点。

同じログイン処理でも、読む人によって必要な情報は変わる。

例えば業務担当者に対して、

「認証APIがDBへSQLを発行して……」

と説明しても、必要以上に細かいかもしれない。

逆に開発者に対して、

「ユーザーがログインすると認証されます」

だけでは情報不足になる。

そのため、

何を伝えたいのか

だけではなく、

誰に伝えるのか

も図を選ぶときの重要なポイントだと感じた。

要件定義では、どこまで細かく書くのか？#

今回、自分がシーケンス図を書こうとしたとき、

「まだ要件定義の段階なので、細かいものはいらない」

と言われた。

最初は、

「シーケンス図ではなくスイムレーン図の方が正しいのかな？」

と考えていた。

しかし今回調べてみると、必ずしもそういう意味ではなさそう。

重要なのは、

その段階で何を共有・確認する必要があるのか

という点。

例えば要件定義の初期段階なら、

ユーザー
 ↓
ログイン
 ↓
認証
 ↓
ログイン完了

程度の全体像で十分かもしれない。

一方、詳細設計では、

Web
 ↓
認証API
 ↓
DB
 ↓
認証API
 ↓
Web

という具体的な処理順序を確認する必要が出てくる場合がある。

この場合は、シーケンス図の方が適している。

つまり、

図の種類だけではなく、設計の段階に応じて必要な情報量も変わる

と考えた方が良さそう。

スイムレーン図のメリット・デメリット#

ユーザー
Web
SPA
API Gateway
認証API
認証サービス
DB
Cache
外部認証サービス

調べる前と調べた後#

注意点・今回分からなかったこと#

今回の比較では、同じログイン処理を3種類の図で表現した。

ただし、実際のプロジェクトでは、

• 「要件定義では必ずこの図」
• 「詳細設計では必ずこの図」

という共通ルールがあるとは限らない。

また、「スイムレーン図」という言葉も、UMLだけでなく業務プロセスやBPMNなど、複数の文脈で使用される。

そのため、

「スイムレーン図は必ずこの書き方」

と決めつけるのは避けた方が良さそう。

今回の検証も、あくまで同じログイン処理を異なる表現で描くことで、それぞれ何が見えやすくなるのかを比較したもの。

実際の設計では、プロジェクトで採用している記法やルール、資料の読者などを考えて判断する必要がある。

まとめ#

今回は、設計書を作っているときに、

「シーケンス図よりスイムレーン図の方が合っているかもしれない」

と言われたことをきっかけに、スイムレーン図について調べてみた。

最初は、

「フローチャートと何が違うの？」

という程度の理解だった。

そこで、同じログイン処理を、

• フローチャート
• スイムレーン図
• シーケンス図

の3種類で実際に作って比較してみた。

その結果、

• フローチャート → 処理や判断の流れを見る
• スイムレーン図 → 処理の流れと担当を見る
• シーケンス図 → 要素間のやり取りと順序を見る

という違いが見えてきた。

今回の最初の疑問だった、

「スイムレーン図とシーケンス図って、何が違うの？」

については、

スイムレーン図は「処理と担当の関係」を把握しやすくする表現で、シーケンス図は「要素間のやり取りと順序」を詳しく把握するための表現

と整理した。

また、どの図を使うか迷ったときは、

1. 何を伝えたいのか
2. 誰に伝えるのか
3. どの程度の詳細さが必要なのか

を考えると判断しやすそう。

今回調べたことで、次は「要件定義・基本設計・詳細設計で、図の粒度をどのように変えると分かりやすいのか」もスキルとして持っておいた方がよさそうだけど、どうも苦手なんだよなぁ。。。
どこかで、勉強してまとめます。。。

参考資料#

• OMG — Unified Modeling Language
• Mermaid — Swimlanes
• Mermaid — Sequence Diagram
• Mermaid — Flowchart
• Microsoft — 部門連係フローチャート
• ISO — ISO 5807:1985