スイムレーン図とは:部門横断プロセスの可視化方法

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
スイムレーン図は、プロセスフローチャートを水平または垂直のレーンに整理し、各レーンが1つの役割、チーム、または部門を表す図です。プロセスで何が起きるかだけでなく、誰が各ステップを担当し、どこで作業が機能の境界を越えるかを示します。
その最後の部分こそが、この図の本質です。ほとんどのプロセス図は、すべての関係者を1つの直線的な流れに押し込めてしまいます。スイムレーン図は関係者を分離したまま保つため、引き継ぎが図の上に文字どおり描かれます。あるタスクが1つのチームを離れて別のチームに渡る場所が一目で分かり、その可視性こそが、遅延、責任の抜け漏れ、説明責任のギャップを見つける上で有用な理由です。
スイムレーン図とは何か
スイムレーン図(部門横断フローチャートやプール・アンド・レーン図とも呼ばれる)は、図の空間を並行したレーンに分割するプロセスマップであり、各レーンは1人の関係者(職務上の役割、部門、システム、または外部組織)に割り当てられます。各ステップは、それを担当するレーンの中に配置されます。あるレーンから別のレーンへ交差する矢印は、引き継ぎ、つまり責任がある関係者から次の関係者へ移る瞬間を表します。
このフォーマットは、ギアリー・ラムラーとアラン・ブラッシュが1990年の著書『Improving Performance』の中で広めたもので、彼らはこれを「デプロイメントフローチャート」または「部門横断プロセスマップ」と呼びました。「スイムレーン」という呼び名が定着したのは、レーンが水泳プールのコースのように見えるからです。
重要なファクト
- マッキンゼーの調査によると、知的作業プロセスにおける遅延と欠陥の約80%は部門横断の連携不全に起因しています。スイムレーン図はそうした連携ポイントを可視化するため、あらゆる部門横断プロセス改善プロジェクトにおける標準的な最初のステップとなっています(McKinsey Quarterly、2020年)。
- MITスローン・マネジメント・レビュー誌に掲載された研究によると、再設計に着手する前の段階でプロセスを可視化するだけでも、チームが作業の滞留箇所を認識して自ら修正するようになるため、サイクルタイムを15〜25%削減できることが分かりました(MIT SMR、2019年)。
- ビジネスプロセスモデル表記法(BPMN)標準を管理するオブジェクトマネジメントグループ(OMG)は、実運用されているBPMN図の70%以上がスイムレーンのプールを主要な整理構造として使用していると推定しています(OMG BPMN 2.0利用調査、2021年)。 「ほとんどのプロセス問題は、人が自分の機能の中で失敗することによって起きるのではありません。機能と機能の間の空間を誰も所有していないことによって起きるのです。」(ギアリー・ラムラー、『Improving Performance』、1990年)
スイムレーン図の記号と表記法
スイムレーン図は標準的なフローチャートの記号セットを借用していますが、レーンそのものという1つの構造要素を追加しています。
| 記号 | 形状 | 意味 |
|---|---|---|
| 開始・終了 | 楕円または円 | プロセスを起動する、またはその完了を示すイベント |
| プロセスステップ | 長方形 | そのレーンの関係者が実行するタスクや活動 |
| 判断 | ひし形 | 次のステップを分岐させるYES/NOの分岐点 |
| 文書 | 底辺が波線の長方形 | 作成または使用されるフォーム、レポート、メール、その他の文書 |
| 引き継ぎ矢印 | レーンの境界を越える矢印 | 責任があるひとりの関係者から別の関係者へ移る |
| レーン | 水平または垂直の帯 | その中のステップを所有する関係者(役割、部門、システム) |
| プール | すべてのレーンを囲む外枠 | マッピング対象となる全体プロセスまたはエンドツーエンドのワークフロー |
水平レーンと垂直レーン。 どちらの向きも有効です。水平レーン(各行が関係者で、フローが左から右へ流れる)は、英語圏のチームにとって自然に読めるため、ビジネスの現場でより一般的です。垂直レーン(各列が関係者で、フローが上から下へ流れる)は、ソフトウェアや技術文書で一般的です。選択は純粋に実務的なものです。ページや画面が窮屈にならないほうを選びましょう。
レーンの数。 効果的なスイムレーン図のほとんどは3〜6レーンです。3未満であれば、そもそもレーンは不要かもしれません。標準的なフローチャートで十分でしょう。6を超えると図は読みにくくなります。プロセスを2つの図に分割するか、頻度の低い関係者を共有レーンにまとめることを検討しましょう。
スイムレーン図とフローチャートとBPMNの違い
この3つのフォーマットは関連していますが、それぞれ異なる目的を持ちます。
| フォーマット | 整理の軸 | 引き継ぎを示すか | 最適な用途 |
|---|---|---|---|
| フローチャート | ステップの順序 | 手作業で注釈をつけた場合のみ | 単一の関係者、またはシンプルな複数ステップのプロセスの文書化 |
| スイムレーン図 | 関係者(役割・部門) | はい、構造的に | 所有権が重要になる部門横断プロセス |
| BPMN | 完全なイベント・ゲートウェイ表記を伴うプールとレーン | はい、正式な意味論を伴って | 技術的なプロセスモデリング、自動化、システム統合仕様 |
フローチャートは何が起きるかを示します。スイムレーン図は何が起き、誰がそのステップを担当するかを示します。BPMNはさらに一歩進み、イベント、メッセージフロー、サブプロセス用のより豊富な記号語彙を持つ、機械可読で標準化された表記法を提供します。
プロセス文書化や、最初のビジネスプロセスマッピングの演習に取り組むほとんどのビジネスチームにとって、スイムレーン図はちょうどよい詳細度です。ワークショップに使えるほど視覚的で、説明責任のギャップを明らかにできるほど精密で、プロセスモデリングの背景を持たない関係者でも数秒で読めるほどシンプルです。
スイムレーン図のメリット
引き継ぎを無視できなくなる。 標準的なフローチャートでは、営業が有望なリードを財務に引き渡すステップは、一連の流れの中の単なる1つの箱にすぎません。スイムレーン図では、それは文字どおり境界を越える矢印になります。部屋にいる全員がそれを見ることができます。この視覚的表現により、引き継ぎの数を数えたり、どれが本当に必要かを問い直したり、遅延がどこに蓄積するかを特定したりすることが容易になります。
説明責任が構造に組み込まれる。 各レーンに名前のついた担当者がいるため、あるステップの責任者が誰かについて曖昧さがありません。これはプロセス標準化の作業において重要です。チームは現状のフローに合意した後、標準作業手順書を作成する必要があるからです。
根本原因分析がしやすくなる。 プロセスが破綻すると、チームは誰の責任かを議論することに何時間も費やしがちです。スイムレーン図は、その会話を非難から構造へとシフトさせます。誰が壊したかではなく、どこで引き継ぎが壊れたかを図を見て問うようになります。これによりビジネスプロセスマネジメントの議論が政治的ではなく生産的になります。
ワークショップから文書化まで拡張できる。 スイムレーン図は、発見ワークショップを行うためにホワイトボードに30分でスケッチすることもできます。また、プロセスマニュアル、コンプライアンス監査、あるいは本格的なビジネスプロセスリエンジニアリングの取り組みのために、洗練されたバージョンを作成することもできます。
他のツールと自然に組み合わせられる。 スイムレーン図は、SIPOC図(描く前にスコープと関係者を定義するもの)やバリューストリームマッピング(フロー図の上に時間とムダのデータを追加するもの)とうまく組み合わせられます。
よくある誤り
レーンが多すぎる。 関わるすべての人にレーンを割り当てると、誰も追いきれないグリッドになってしまいます。区別が本当に重要でない限り、個々の担当者は役割カテゴリー(例えば個人名ではなく「アカウントマネージャー」)にまとめましょう。
詳細度のレベルが混在している。 スイムレーン図は、一貫した抽象度でステップを表現すべきです。あるレーンが「請求書を確認する」を示し、別のレーンが「メールを開き、添付ファイルを確認し、経理担当者に転送し、システムにログインし、明細を入力し、保存をクリックする」を示している場合、これらは同じレベルではありません。粒度を決めて、全体に一貫して適用しましょう。
理想のプロセスを、実際のプロセスの代わりに描いてしまう。 これは現状と将来状態のマッピングの演習において最もよくある誤りです。チームは自然と、実際に起きていることではなく、あるべき姿を説明しがちです。まずは現状(as-is)のプロセスから始めましょう。正直にマッピングしていないものを改善することはできません。
引き継ぎを暗黙のままにしておく。 「送る」というラベルだけでは不十分です。実際に何が引き渡されるのか、具体的なフォーム、システム通知、口頭での承認などを記しましょう。曖昧な引き継ぎは曖昧な説明責任を生みます。
検証ステップがない。 1人または1つのチームが描いた図には、ほぼ必ず誤りが含まれます。ステップが抜けている。順序が間違っている。レーンが足りない。図を権威あるものとして扱う前に、必ず実際にその業務を行っている人々と一緒に図を確認しましょう。
スイムレーン図の作り方
ステップ1:スコープを定義する
プロセスの名前と開始・終了ポイントを定めます。「受注処理」は範囲が広すぎます。「顧客の購入確認から出荷ラベル印刷までの受注処理」がスコープです。図の一番上に、1つの箱を描く前に、これを書きましょう。明確なスコープがなければ、図は際限なく広がってしまいます。
ステップ2:関係者を特定し、レーンを作る
そのプロセスに関わるすべての役割、部門、またはシステムを列挙します。それぞれに独自のレーンを与えます。6を超える場合は、グループ化できる関係者や、小さなステップのために1回だけ登場する役割を探しましょう(それらはフルレーンを与えるのではなく、注釈で済ませることが多い)。
向きを決めます。水平レーンは通常、ビジネスプロセスのワークショップに向いており、垂直レーンはフローが自然に上から下に流れる技術図に向いています。
ステップ3:すべてのプロセスステップを列挙する
図に何かを配置する前に、すべてのステップをフラットなリストとして書き出しましょう。これにより、順序が視覚的に意味をなさない状況に自分を追い込むことを防げます。各ステップについて、どの関係者が担当するかを記録します。
ステップ4:ステップを正しいレーンに配置する
各ステップを順序どおりにそれぞれのレーンにマッピングします。標準的な記号を使いましょう。タスクには長方形、判断にはひし形、開始・終了イベントには楕円です。ラベルは短く、1つの箱につき2〜5語にとどめます。ラベルが長い場合、そのステップをさらに分解する必要がある、あるいは詳細度のレベルが混在しているサインです。
ステップ5:引き継ぎを描く
ステップ間に矢印を追加します。レーン内にとどまる矢印は内部の順序を示します。レーンの境界を越える矢印は引き継ぎを示します。引き継ぎに視覚的に注目を集めましょう。一部のチームは、レーンをまたぐ矢印に異なる色や太い線を使って目立たせます。
この段階で、見逃していたステップを発見したり、シンプルだと思っていた引き継ぎが実は3回の往復を伴っていたことに気づいたりすることがよくあります。それは図が意図どおりに機能している証拠です。
ステップ6:検証して洗練する
完成した図を、日々その業務を行っている少なくとも1人と一緒に確認しましょう。2つの質問をします。「これは実際に起きていることと一致していますか?」「何か抜けているものはありますか?」修正が入ることを想定しておきましょう。スイムレーン図が改善作業に使えるほど現実を反映するまでには、通常2〜3回の反復が必要です。
検証後、プロセスが必要とするなら追加のデータを重ねましょう。ステップごとの平均所要時間、欠陥率、滞留件数などです。これがバリューストリームマッピングやカイゼンイベントへの橋渡しになります。
スイムレーン図の例
以下の3つの例は、部門横断の引き継ぎが最も摩擦を生む一般的なビジネスプロセスをカバーしています。
| プロセス | レーン(関係者) | 主な引き継ぎ |
|---|---|---|
| 従業員オンボーディング | 人事、IT、採用マネージャー、財務、新入社員 | 人事が候補者にオファーレターを渡す;ITが人事から機器手配リクエストを受け取る;採用マネージャーがITとシステムアクセスをトリガーする;財務が人事から給与設定を受け取る |
| 受注処理 | 顧客、営業、倉庫、出荷、財務 | 顧客が営業に注文を提出する;営業が確認して倉庫にリリースする;倉庫が梱包完了時に出荷に通知する;出荷が財務で請求書をトリガーする |
| 請求書承認 | ベンダー、買掛金部門、部門マネージャー、財務ディレクター、経理 | ベンダーが買掛金部門に請求書を提出する;買掛金部門がコード化して部門マネージャーに回付する;マネージャーが承認して買掛金部門に戻す;買掛金部門がしきい値を超える金額を財務ディレクターにエスカレーションする;ディレクターが承認し、買掛金部門が経理に支払いのためリリースする |
請求書承認の例は、単純な支払いがなぜ3週間もかかることがあるのかを明らかにするのに特に有用です。引き継ぎを描いてみると、一定額を超える請求書が支払われるまでに4人もの人を経由し、それぞれのやり取りで平均的な待ち時間が発生していることが分かります。それが見えてしまえば、改善の議論は簡単になります。
ベストプラクティス(すべきこと・すべきでないこと)
| すべきこと | すべきでないこと |
|---|---|
| 各ステップのラベルを2〜5語にとどめる | 図の箱の中に完全な文章を書く |
| 読みやすさのために3〜6レーンを使う | 個人ごとにレーンを作る |
| 実際に業務を行う人々と検証する | 最初の草案を最終版として扱う |
| まず実際のプロセスをマッピングし、その後に理想形を考える | 現状を文書化する前に将来状態から始める |
| 一貫した記号の形を全体で使う | 同じ種類の記号に円、楕円、角丸長方形を混在させる |
| レーンをまたぐ矢印を視覚的に強調する | すべての矢印を同じ見た目のままにしておく |
| 各引き継ぎで何が移動するかを記す | 「送る」「通知する」だけでラベル付けする |
よくある質問
スイムレーン図と部門横断フローチャートの違いは何ですか?
これらは同じものです。「部門横断フローチャート」は、このフォーマットをより説明的に表した名前です。「スイムレーン図」は、レーンの見た目に基づいた通称です。どちらの用語も、関係者ごとに整理され、引き継ぎがレーンの境界を越える矢印として示されるプロセスマップを指します。ツールによっては「プール・アンド・レーン図」という別の呼び方をする場合もあります。
通常のフローチャートの代わりにスイムレーン図を使うべきなのはいつですか?
プロセスに複数の役割や部門が関わっており、各ステップの所有権が重要な場合はいつでもスイムレーン図を使いましょう。1人またはひとつのチームが最初から最後までプロセス全体を実行するのであれば、標準的なフローチャートのほうがシンプルで、同じくらい有用です。スイムレーン形式が特に価値を発揮するのは、誰が何をし、どこで作業が関係者間を移動するかを示す必要があるときです。
レーンはいくつまでなら多すぎませんか?
6を超えるレーンは、標準的なページや画面ではほとんどの図が読みにくくなります。プロセスが本当に6を超える明確な関係者を含む場合は、一部をグループ化できないか、あるいはサブプロセスをカバーする2つの別々の図に分割すべきかを検討しましょう。
スイムレーン図を描くために一般的に使われるツールは何ですか?
Lucidchart、Miro、Microsoft Visio、Draw.io(Diagrams.net)はいずれもスイムレーン図をネイティブにサポートしています。手早いワークショップのスケッチには、付箋を使ったホワイトボードもよく機能します。関係者ごとに1色、ステップごとに1枚の付箋を用意し、それぞれのレーンの中に貼っていきます。
スイムレーン図はBPMNとどう関係していますか?
BPMN(ビジネスプロセスモデル表記法)は、スイムレーンのフォーマットを標準化された機械可読の記号セットで拡張したものです。スイムレーン図は非公式で柔軟です。BPMNはオブジェクトマネジメントグループが管理する正式な仕様です。プロセス文書化や自動化のためのプロセス設計を行うチームは、通常まずスイムレーン図から始め、後にそれをBPMNとして正式化します。
部門横断の作業こそ、ほとんどのプロセス問題が潜む場所です。全員が同じメンタルモデルを共有していると思い込むのではなく、引き継ぎを明示的に描くことが、それらを解決するための第一歩です。スイムレーン図は、プロセス改善プロジェクトでチームが使う最後のツールになることはめったにありませんが、真の問題を初めて可視化するツールになることはよくあります。
関連記事
- ビジネスプロセスマッピング:改善に取り組む前にプロセスを最初から最後まで文書化する方法
- BPMN:プロセスモデルの正式な表記標準
- バリューストリームマッピング:部門横断フロー図の上に時間とムダのデータを追加する
- RACIマトリクスとは:あらゆるプロセスで役割に責任を割り当てるための補完的なツール
