process-modeling

プロセスモデリング

このスキルを使用する場面

次のような場合に、このスキルを使用します。

• プロセスモデリングタスク - BPMN 記法やフローチャートのパターンを使用して、プロセスモデリングに取り組む場合。ワークフローの文書化を目的として、アクティビティ、ゲートウェイ、イベント、スイムレーン、判断ポイントを含むプロセス図を作成します。
• 計画または設計 - プロセスモデリングのアプローチに関するガイダンスが必要な場合
• ベストプラクティス - 確立されたパターンや標準に従いたい場合

概要

BPMN（Business Process Model and Notation）およびフローチャート記法を使用して、ビジネスプロセスを作成、文書化します。アクティビティ、判断、イベント、参加者間のやり取りを可視化し、プロセスの理解と改善に役立てます。

プロセスモデリングとは？

プロセスモデリングでは、組織内で業務がどのように進むかを視覚的に表現します。次の内容を文書化します。

• アクティビティ：実行する業務
• 順序：アクティビティの実行順序
• 判断：選択ポイントと条件
• 参加者：各ステップを実行する担当者
• イベント：プロセスの開始と終了のトリガー

BPMN の基本要素

アクティビティ（長方形）

種類	記号	説明
タスク	長方形	最小単位の作業
サブプロセス	+ が付いた長方形	子プロセスを含む
コールアクティビティ	太い枠線の長方形	再利用可能なプロセスを呼び出す

タスクの種類：

種類	説明
ユーザータスク	人による操作が必要
サービスタスク	システムによる自動処理
スクリプトタスク	スクリプト／コードの実行
ビジネスルールタスク	判断テーブルの評価
送信タスク	メッセージを送信
受信タスク	メッセージを受信
手動タスク	システムを使わない物理的な作業

イベント（円）

位置	記号	説明
開始	細い円	プロセスのトリガー
中間	二重円	プロセス途中のイベント
終了	太い円	プロセスの終了

イベントの種類：

種類	トリガー
なし	未指定の開始／終了
メッセージ	メッセージの受信／送信
タイマー	時間ベースのトリガー
エラー	エラー条件
シグナル	ブロードキャストシグナル
終了	プロセスの終了

ゲートウェイ（ひし形）

種類	記号	説明
排他（XOR）	X が付いたひし形	条件に基づいて 1 つの経路を選択
並列（AND）	+ が付いたひし形	すべての経路を実行
包含（OR）	O が付いたひし形	1 つ以上の経路を選択
イベントベース	円が付いたひし形	イベントを待機

コネクター

種類	記号	説明
シーケンスフロー	実線の矢印	アクティビティの順序
メッセージフロー	破線の矢印	プール間のメッセージ
関連付け	点線	成果物と要素の関連付け

スイムレーン

種類	説明
プール	参加者（組織／システム）を表す
レーン	プール内の区分（役割／部門）

ワークフロー

フェーズ 1：スコープの定義

ステップ 1：プロセスの境界を特定する

## Process Definition

**Process Name:** [Name]
**Purpose:** [Why this process exists]
**Scope:**
  - **Starts When:** [Trigger event]
  - **Ends When:** [Completion criteria]
  - **Includes:** [In-scope activities]
  - **Excludes:** [Out-of-scope activities]

**Participants:**
| Pool | Lanes (Roles) |
|------|---------------|
| [Org/System] | [Role 1], [Role 2] |

ステップ 2：モデルの種類を選択する

種類	使用する場面
現状（As-Is）	現在の状態を文書化する
将来像（To-Be）	将来の状態を設計する
概要レベル	概要の把握、コミュニケーション
詳細レベル	実装、自動化

フェーズ 2：プロセスのモデリング

ステップ 1：主要経路（ハッピーパス）を特定する

1. 開始イベント（トリガー）
2. アクティビティの主要な流れ
3. 終了イベント（完了）

ステップ 2：判断ポイントを追加する

判断ごとに、次の項目を定義します。

• ゲートウェイの種類（XOR／AND／OR）
• 各経路の条件
• 再合流ポイント

ステップ 3：例外経路を追加する

• エラー処理
• タイムアウトのシナリオ
• エスカレーション経路

ステップ 4：参加者を追加する

• アクティビティをレーンに割り当てる
• 参加者間のコミュニケーションをモデル化する
• プール間にメッセージフローを追加する

フェーズ 3：検証と文書化

ステップ 1：完全性を検証する

チェック項目	確認内容
すべての経路が接続されている	すべてのアクティビティに入力フローと出力フローがありますか？
行き止まりがない	すべての経路が終了イベントに到達しますか？
ゲートウェイの対応が取れている	分岐ゲートウェイに対応する合流ゲートウェイがありますか？
役割が割り当てられている	すべてのアクティビティがレーンに配置されていますか？
トリガーが定義されている	すべての開始イベントに明確なトリガーがありますか？

ステップ 2：ドキュメントを追加する

## Process: [Name]

### Overview

[Brief description of process purpose and flow]

### Triggers

| Event | Description | Frequency |
|-------|-------------|-----------|
| [Trigger] | [What causes it] | [How often] |

### Activities

| # | Activity | Role | System | Duration |
|---|----------|------|--------|----------|
| 1 | [Activity name] | [Role] | [System] | [Time] |

### Decision Points

| # | Decision | Conditions | Paths |
|---|----------|------------|-------|
| 1 | [Decision] | [Criteria] | [Path A], [Path B] |

### Exceptions

| Exception | Handling |
|-----------|----------|
| [Error] | [How handled] |

出力形式

Mermaid フローチャート（BPMN スタイル）

flowchart TD
    Start((Start))
    Task1[Receive Order]
    Gateway1{Valid Order?}
    Task2[Process Payment]
    Task3[Reject Order]
    Task4[Ship Product]
    End1((Complete))
    End2((Rejected))

    Start --> Task1
    Task1 --> Gateway1
    Gateway1 -->|Yes| Task2
    Gateway1 -->|No| Task3
    Task2 --> Task4
    Task4 --> End1
    Task3 --> End2

スイムレーン図

flowchart TD
    subgraph Customer
        A[Place Order]
        G[Receive Product]
    end

    subgraph Sales
        B[Review Order]
        C{Approved?}
    end

    subgraph Warehouse
        D[Pick Items]
        E[Pack Order]
        F[Ship Order]
    end

    A --> B
    B --> C
    C -->|Yes| D
    C -->|No| A
    D --> E
    E --> F
    F --> G

概要

## Process: Order Fulfillment

**Version:** 1.0
**Date:** [ISO Date]
**Owner:** [Name]

### Summary

This process handles customer orders from receipt to delivery.

### Flow Description

1. **Start**: Customer places order (online or phone)
2. **Review Order**: Sales validates order details
3. **Decision**: Is order valid?
   - Yes: Proceed to fulfillment
   - No: Return to customer for correction
4. **Pick Items**: Warehouse locates products
5. **Pack Order**: Items packaged for shipping
6. **Ship Order**: Handed to carrier
7. **End**: Customer receives product

### Metrics

| Metric | Current | Target |
|--------|---------|--------|
| Cycle Time | 3 days | 2 days |
| Error Rate | 5% | 1% |
| Automation | 40% | 70% |

### Improvement Opportunities

1. Automate order validation
2. Parallel picking for multi-item orders
3. Real-time tracking integration

構造化データ（YAML）

process_model:
  name: "Order Fulfillment"
  version: "1.0"
  date: "2025-01-15"
  type: "as_is"  # or "to_be"
  owner: "Operations"

  boundaries:
    trigger: "Customer places order"
    end_state: "Customer receives product"
    scope:
      includes:
        - "Order receipt"
        - "Payment processing"
        - "Fulfillment"
        - "Shipping"
      excludes:
        - "Returns"
        - "Customer support"

  participants:
    - pool: "Company"
      lanes:
        - name: "Sales"
          activities: ["Review Order"]
        - name: "Warehouse"
          activities: ["Pick Items", "Pack Order", "Ship Order"]
    - pool: "Customer"
      lanes:
        - name: "Buyer"
          activities: ["Place Order", "Receive Product"]

  elements:
    events:
      - id: "start_1"
        type: "start"
        name: "Order Received"
        trigger: "message"

      - id: "end_1"
        type: "end"
        name: "Order Complete"

    activities:
      - id: "task_1"
        type: "user_task"
        name: "Review Order"
        lane: "Sales"
        duration: "15 minutes"

      - id: "task_2"
        type: "service_task"
        name: "Process Payment"
        lane: "Sales"
        system: "Payment Gateway"

    gateways:
      - id: "gw_1"
        type: "exclusive"
        name: "Order Valid?"
        conditions:
          - path: "task_2"
            condition: "Order validated"
          - path: "task_reject"
            condition: "Validation failed"

  sequence_flows:
    - from: "start_1"
      to: "task_1"
    - from: "task_1"
      to: "gw_1"
    - from: "gw_1"
      to: "task_2"
      condition: "valid"

  metrics:
    cycle_time:
      current: "3 days"
      target: "2 days"
    automation_rate:
      current: 40
      target: 70

よくあるプロセスパターン

順次プロセス

アクティビティを厳密な順序で、1 つずつ実行します。

flowchart LR
    A[Step 1] --> B[Step 2] --> C[Step 3] --> D[Step 4]

並列分岐と合流

同時に実行できるアクティビティです。

flowchart TD
    A[Start] --> B{Parallel Split}
    B --> C[Task A]
    B --> D[Task B]
    B --> E[Task C]
    C --> F{Join}
    D --> F
    E --> F
    F --> G[End]

排他的な決定

条件に基づいて、1 つの経路のみを選択します。

flowchart TD
    A[Review] --> B{Decision}
    B -->|Approve| C[Process]
    B -->|Reject| D[Notify]
    C --> E[End]
    D --> E

ループ／反復

条件を満たすまでアクティビティを繰り返します。

flowchart TD
    A[Start] --> B[Process]
    B --> C{Complete?}
    C -->|No| B
    C -->|Yes| D[End]

例外処理

エラーや例外を処理します。

flowchart TD
    A[Process] --> B{Success?}
    B -->|Yes| C[Continue]
    B -->|Error| D[Handle Error]
    D --> E{Recoverable?}
    E -->|Yes| A
    E -->|No| F[Escalate]

ベストプラクティス

プラクティス	説明
シンプルに始める	通常の経路から始めて、複雑さを加えていきます
開始点は 1 つ、終了点は 1 つ	プールごとに 1 つが理想です
アクティビティに名前を付ける	動詞と名詞の形式を使用します（例：「注文を確認する」）
ゲートウェイにラベルを付ける	決定に関する質問を示します
条件にラベルを付ける	各出力経路の内容を説明します
ゲートウェイの対応を取る	同じ種類の分岐と合流を対応させます
線の交差を避ける	明確になるように配置を調整します
例外を文書化する	エラー処理の経路を示します

統合

上流

• stakeholder-analysis - プロセスの参加者
• domain-storytelling - 現在のプロセスの把握
• capability-mapping - ケイパビリティのコンテキスト

下流

• value-stream-mapping - 価値の流れの分析
• Requirements - プロセス要件
• System design - 自動化の機会

関連スキル

• value-stream-mapping - プロセスフローのリーンな視点
• data-modeling - プロセス内のデータエンティティ
• journey-mapping - 顧客体験の視点
• capability-mapping - プロセスとケイパビリティの整合

バージョン履歴

• v1.0.0 (2025-12-26)：初回リリース