プロセスモデリング：どの手法を何に使うか——そして各図がどこで終わるか

プロセスモデルは素早く描けますが、ほぼ同じ速さで役に立たなくなります。間違っているからではありません—ボックスはたいてい合っています。問題は、本来そのモデルで答えたかった問いに答えないことです。描くのは、どこに手を付けるべきかを知るためです。出来上がるのは、どのステップも同じ重要度に見える構造です。

この記事は二本立てです。第一に技術：どの手法が何に向くか、実際に必要な記号は何か、どの範囲で切るか、どんな順序で進めるか。第二に限界：どの表記にも書かれておらず、それがないとどのステップが処理を止めているかが分からない四つの指標。

プロセスモデリングとは何か

プロセスモデリングは、標準化された記号で単一の業務プロセスを図示することです。四つの質問に答えます：何がその流れを起動するのか？どの作業がどの順序で続くのか？どこで分岐し誰が判断するのか？何で終わるのか？

用語は日常で混同されますが、意味するものは異なります：

プロセスランドカートは街の地図、プロセスモデルはある通りの道案内です。両方を一つの図に無理に詰め込むと、発表の後に誰も開かない200個のボックスができあがります。上位のレベルの作り方はプロセスランドカートの作成ガイドにあります。

モデルが使える場面：

• 研修：新しい従業員が口頭説明ではなく図で流れを把握できる
• 監査と認証：ISO 9001はこの構造を求めることがある
• システム移行：ソフトが実装する前に何を表現すべきかを示す
• 引き継ぎ：いつ担当が変わるかを示す箇所
• 例外処理：取扱いが各人で異なるケース

モデルが向かない場面：

• 優先順位付け。すべてのボックスが同じ大きさに見える。
• 工数見積り。あるステップが10分か4日かは分からない。
• キャパシティ計画。プロセスの実行頻度は図に書かれない。

As-is と To-be：まず現状を描く

プロセスモデリングには二つのモデルタイプがあります。As-isモデルは現状を示します：今日実際にどのように流れているか。迂回、手直し、公式には存在しないExcelファイルも含みます。To-beモデルは変更後の望ましい状態を示します。

順序は譲れません：まずAs-is、次にTo-be。To-beから始めると、実態を知らずに最適化してしまいます。

ただし多くの指南書が省く第三のステップが間に入ります：測定すること。As-isから直接作ったTo-beは願望リストです。ワークショップで声が大きかったステップが改良されがちで、それはたいてい処理を止めているステップではありません。声が大きいのは不快な手間であり、費用がかかるのは静かに滞留が起きている箇所です。

実務ルール：To-beモデルはちょうど一つのステップについて作る。測定が指し示すステップだけです。他は当面そのままにします。

プロセスモデリング：手法の概観

Flussdiagramm

最も単純な形：開始、タスク、判断のダイアモンド、終了。誰でも導入なしで理解できる点が価値です。ただし複数の役割が関与すると限界が現れます—その場合、担当はボックス内のテキストにしかならず、時間が失われる引き継ぎ箇所が見えなくなります。

Swimlane-Diagramm

同じ流れを各役割にレーンとして割り当てます。利点は見栄えでなく厳密な情報です：あるレーンを出るすべての矢印は引き継ぎです。 引き継ぎは誰も担当していない、まだ誰も着手していないために処理が滞る場所です。複数部署にまたがる流れにはSwimlaneが標準的な選択です。

BPMN 2.0

Object Management Groupの国際標準で約150の記号があり機械可読です。強みは明確さ：BPMNモデルはエクスポート、検証、Process Engineでの実行が可能です。弱みは習得曲線で、現場の人は自発的に読まないことが多いです。

モデルを実行したり外部検証や長期の保守が必要ならBPMNを使ってください。見栄のために選ぶべきではありません。部署が目を通すきれいなSwimlane図は、誰も開かない正しいBPMNモデルより有益です。

EPK と eEPK

イベントと機能が交互に並ぶereignisgesteuerte Prozessketteで、イベント（「Anfrage ist eingegangen」）と機能（「Anfrage erfassen」）がAND/OR/XORのコネクタでつながります。ドイツ語圏ではARISを通じて普及しています。拡張EPKは各機能に組織単位と情報オブジェクト、つまり誰がそのステップを実行し何を使うかを補足します。

交互の強制は長所であり短所でもあります：トリガーを明確にさせる一方でモデルをほぼ倍にします。既にEPKの資産がある企業には有益です。新規モデルを白紙から作る場合はめったに理由がありません。

SIPOC

5列：Suppliers, Inputs, Process, Outputs, Customers。これはフロー図ではなく、その前段階の切り分けです。1時間で埋められ、ほとんどのモデリングが失敗する問いを明確にします：プロセスはどこで始まりどこで終わるか？プロセス部分は粗く保ちます—5〜7ブロック。

Wertstromanalyse

リーン管理由来。資材と情報の流れを描き、各ステップに数値を入れます：処理時間、待ち時間、在庫、欠陥率。このため定量的な古典手法の中で唯一自動的に数値化されます。主な適用先は製造です；事務プロセスでは「在庫」は受信箱の待ち行列で、扱いがやや面倒になりますが不可能ではありません。

Wertschöpfungskette と Detailmodell

同じスケールの両端です。Wertschöpfungsketteは内部を示さない5〜9のブロックで経営層や外部向けの版、Detailmodellは各ステップに部分プロセス、例外、システムまで含むITへの引き渡し版です。どちらも正当です。ただし両者の詳細度を一つの図に混在させると使えなくなります：営業を3ボックス、承認手続きに14ボックスというような図です。

どの手法を選ぶか？三つの質問

1. 複数の役割や部署が関与しますか？ はい → Swimlane。いいえ → Flussdiagramm。
2. モデルを後で実行、エクスポート、外部検証する必要がありますか？ はい → BPMN 2.0。
3. 材料、在庫、滞留時間が問題ですか？ はい → Wertstromanalyse。

切り分け自体が不明な場合は先にSIPOCを行います。他は好みの問題です—しかし表記の好みは悪い助言です。モデルはその表記を共有しない人たちに読まれます。

プロセスモデリングの記号

一般的な記号はフローチャートの伝統から来ており、ツール間で共通です：

• 楕円（ターミネータ）： プロセスの開始と終了
• 長方形： タスクまたは活動
• ひし形： 判断、出口にラベルを付ける
• 矢印： フローの方向
• 両側が二重線の長方形： 別場所でモデル化されたサブプロセス
• 平行四辺形： 入出力としてのデータ
• 下辺が波形の長方形： 文書
• D字形： 遅延、つまり滞留時間
• 上辺が斜めの長方形： 手入力—実務ではメディア・ブレイクの最も確実な手がかり

BPMNでは重要な五つは：開始イベント（細い円）、タスク（角丸長方形）、排他的ゲートウェイ（Xのあるひし形）、シーケンスフロー（実線の矢印）、終了イベント（太い円）です。これでほとんどの流れを表現できます。

二つの規則が記号リストより重要です：すべてのひし形は出口にラベルがあること—「はい」/「いいえ」や条件。すべての経路は終端があること。 空白に向かう枝は図の美観上の欠点であり、現実には決して完了しない処理です。

プロセスをモデリングする：六つのステップ

ステップ1：境界の設定

何か描く前に書面で二文：プロセスは何で始まるか（トリガー）と何で終わるか（結果）。これがないと作業中にモデルが膨張します—会話の前後に何かが付け加えられるからです。これが、二日で終わるはずのモデリングが三週間かかる最も一般的な理由です。

ステップ2：実行者のもとでステップを集める

責任者ではなく実行者のところで。責任者は望ましい手順を知っており、Istとの差がまさに探すべきものです。手順を引き出す確実な五つの質問：

• この作業は何が起点で、どう見分けていますか？
• 着手するために何が必要で、それはどこから来ますか？
• 何を最も頻繁に待っていますか？
• 何かが欠けているかシステムが動かないときはどうしますか？
• 手順書と違ってここでどうして違うことをしているのですか—その理由は？

ステップ3：粒度を決める

切り分けを決めるルール：一つのステップは、ある役割が一息でシステム内で完了する仕事の塊である。 役割が変わる、システムが変わる、または作業が中断されるなら新しいステップです。

通常の業務プロセスではこのルールで8〜15ステップになります。50ステップになればキー入力をモデル化しています。4ステップなら部署をモデル化しています。

ステップ4：描く

上の三つの質問で方法を決め、まず例外なしの第一巡目を描きます：通常ケースを左から右へ。分岐はその後で—しかも全部ではありません。典型的にプロセスは約3分の1が例外です；図にするのは頻度が高い2〜3件だけです。残りは横にテキストで記します。

ステップ5：読み直してもらう

完成図はステップ2で集めた同じ人たちに戻し、ただ一つの質問を投げます：「どこが違いますか？」「これでいいですか？」ではない—後者には誰もが「はい」と答えます。経験上、2〜4箇所が訂正され、そのうち少なくとも一つは重要な修正です。

ステップ6：数値を付ける

多くの指南書に欠けているステップで、ここを抜かすとモデルは装飾に終わります。各ステップに四つの値を、必要なら推定で付けます：

• 所要時間の幅： 楽観、典型、悲観—平均値ではありません
• 前の待ち時間： 誰かが始めるまでどれくらい溜まっているか
• 頻度： 月あたりそのステップが何回動くか、例外の割合も含む
• 役割とシステム、およびメディアブレイクの有無

なぜ平均でなく幅か：平均値を用いると、フローにゲート、ループ、共有処理者がある場合に体系的に楽観的になってしまいます。詳しくはあなたのExcelは正しく計算するがそれでも間違っているを参照してください。

例：見積プロセスのモデル化

以下のモデルは当社のサンプル分析 AN-2026-01 に基づきます。顧客から取った実測ではなく構成したモデルです—構造は典型的な中堅企業の流れに基づき、数値は500回のシミュレーションに由来します。ここで重要なのは図と測定の違いが手法の性質であり営業秘密ではないという点です。

Swimlaneで、6ステップ、4役割：

                 ┌────────────┐                              ┌──────────────┐
Innendienst   ●──│ 01 Anfrage │                              │ 05 Angebot   │──▶ ● 
                 │  erfassen  │                              │   schreiben  │
                 └─────┬──────┘                              └──────▲───────┘
                       │                                            │
                 ┌─────▼──────┐                                     │
Konstruktion     │ 02 Techn.  │                                     │
                 │  Klärung   │                                     │
                 └─────┬──────┘                                     │
                       │                                            │
                 ┌─────▼──────┐   ┌───────────┐   nein     ┌────────┴────┐
Kalkulation      │ 03 Kalku-  │──▶│ 04 Frei-  │───────────▶│ Rückfrage   │
                 │   lation   │   │   gabe?   │            │ (Ausnahme)  │
                 └────────────┘   └─────┬─────┘            └─────────────┘
                                        │ ja
                                        ▼
Vertrieb                          06 Versand & Nachfassen ──▶ ●

図は正しい。誰がどの順で何をするかを示し、三つのメディアブレイク（E-Mail、Excel、Word）も示しています。図が答えないのは：どの六つのステップのうちどれが処理を止めているか、です。

描画上は六つとも同じ大きさです。しかし計算上は違います：

{
  "caption": "Auslastung je Rolle im Ist-Zustand. Musteranalyse AN-2026-01, konstruiert, 500 simulierte Durchläufe",
  "unit": "%",
  "data": [
    { "label": "Konstruktion", "value": 118, "tone": "critical" },
    { "label": "Kalkulation", "value": 86 },
    { "label": "Vertriebsinnendienst", "value": 74 },
    { "label": "Vertriebsleitung", "value": 41 }
  ]
}

ある役割の負荷が100%を超えています—処理できる以上の仕事が入り、そのステップの前に待ち行列が成長します。モデルはこの役割を四つのレーンの一つとして示すだけで、Vertriebsleitungは41%の負荷です。

それに従ってリードタイムも変わります。リードタイムは単一の数値ではなく幅です：

[
  { "label": "Durchlaufzeit P10", "value": "1,8", "unit": "Tage", "note": "der schnelle Fall" },
  { "label": "Durchlaufzeit P50", "value": "4,6", "unit": "Tage", "note": "der typische Fall" },
  { "label": "Durchlaufzeit P90", "value": "11,2", "unit": "Tage", "tone": "critical", "note": "was zusagbar wäre" },
  { "label": "Läufe über Kapazität", "value": "34", "unit": "%", "tone": "critical" }
]

典型ケースと約束可能なケースの間に2倍の差があります。どの表記でも図には現れません。完全なサンプル分析とビフォー・アフターは構成で滞留する見積プロセスにあります。

どの表記にも書かれていない四つの値

なぜモデルはボトルネックを示さないのか、理由は明快です：表記は構造を記述し、負荷を記述しないからです。計算に必要な四つの量が表記には含まれていません：

1. 到着率—プロセスがどれだけの頻度で起こるか、どれだけ不均一か。週40件と、そのうち30件が月曜に来る40件は別物です。
2. 所要時間のばらつき—「2時間」ではなく「1〜4時間で通常は2時間」のように。ばらつきがないなら待ち行列は生じず、計算は楽観的になります。
3. 容量—実際にそのステップを処理できる人数と彼らの稼働割合。図の一つのレーンが一人か八人かは全く違います。
4. カレンダー—勤務時間、休暇、承認が火曜日のみなど。理論上3時間で終わる流れでも夜を跨げば一日かかります。

これら四つは、上のステップ6でモデル化時に収集するのが最良です。図から計算への橋渡しであり、モデルが施策になるか壁の飾りに終わるかを決める点です。

よくある誤り

1. 細かすぎる。 200個のボックス。対処法：ステップ3のルール—役割、システム、一息。

2. Sollを描きIstを描かない。 モデルに手直しがないなら要注意。実際の流れには必ず手直しがあります。

3. 管理職だけに聞く。 正式な手順は出てきますが、実際との違いがこの演習の成果です。

4. 権威づけのために表記を選ぶ。 BPMNを専門的に見せるために選び誰もレビューしないと、検証のないモデルは単なる主張になります。

5. 例外を無視する。 正常系だけ描き30%の処理が別経路になる。頻度の高い2〜3の例外は図に入れ、残りは隣にテキストで記載。

6. 数値がない。 モデルは完成しても「まず何をするか」が感覚的な議論に留まる。

7. 所有者と更新のきっかけがない。 責任者と定期更新のトリガー（システム移行、組織変更、年次レビュー）がないモデルは12ヶ月で実態と乖離します。

何でモデリングするか

最初の版は紙、ホワイトボード、付箋で十分です。付箋は移動でき、整った図は反論を招きにくいです。清書には一般的な図表ツールで十分—単一プロセスならツールは些細な問題です。長年管理・実行するモデルにはリポジトリやバージョン管理、承認を備えたBPMスイートが必要になり、十分な数のプロセスがあるときにのみ投資に見合います。

会議で入力して描かない場合

ワークショップで誰もボックスを引かないケースは中止の最も一般的な理由なので触れておきます。横で描く人は追いつけず、書き起こす人は後で転記するかしないかになります。当社のデスクトップアプリケーションFlowVisualには入力行があり、各行が一つのステップになりEnterで次へ、チェーンは自動配線されます。

Anfrage kommt rein
Angebot rechnen @Vertrieb 20-40min
Freigabe @Chef 5min ?über 10k
Nacharbeit @Vertrieb !fehlende Angaben

四つのマーカーだけで、他の文法はありません：@は役割、時間幅は所要時間、?は条件、!は問題点。すべて任意です—空の行でも有効な行で、誰も言わなかったことは未記入のままで、モデルにでっち上げのゼロが入ることを防げます。ゼロから始めたくなければ、六つのテンプレート（見積、請求承認、クレーム、オンボーディング、サービスデスク、受注処理）のいずれかを開くか、既存の手順書を読み込ませます；提案された各ステップは原文引用とファイルを持ち個別に承認されます。

重要なのは描く手段ではなく配置場所です：モデルは人々が普段使う場所に置かなければなりません。現場にアクセス権がないツールにある図は管理されず、印刷されて壁に貼られて古くなります。

結論

プロセスモデリングは明確なルールのある手仕事です：先に境界を決め、実行者と話し、目的に合った表記を選び、役割とシステムごとに一ステップとし、例外は抑制して、第三者に確認してもらう。これを守れば1〜2日で実用的なモデルが得られます。

モデルが示さないものは、より良い表記にしても示しません：どこから手を付けるかの順序です。そのためには各ボックスに数値を付け、計算する必要があります—到着率、ばらつき、容量、カレンダー。図はその前提であり、答えではありません。

次のステップ：

1. トリガーと結果を二文で書く
2. 実行者と2〜3回の面談を行い上の五つの質問をする
3. Swimlaneで描き、8〜15ステップにする
4. 「どこが違いますか？」で読み直してもらう
5. 各ステップに所要時間の幅、待ち時間、頻度、メディアブレイクを補足する
6. その後にどこを改善するか決める

参考：

• Prozesslandkarte erstellen — 単一モデルの上位レベル
• Lay bare: den Ist-Zustand beziffern — FLOWREFYメソッドのステップ2、つまりボックスの数値化
• Prozessanalyse — モデルから信頼できる結論を導く方法

計算のために： 無料のProzesskosten-Rechnerで数分でモデル化した流れの月次コストを算出できます—削減可能額とステップごとの内訳も含みます。