ストーリー
田
田中VPoE
「ボトルネック分析で課題が見えてきた。次はこれを誰が見ても分かる形で文書化する。経営層への報告にも、開発チームへの要件伝達にも、共通言語としてのドキュメントが必要だ。」
あなた
「フローチャートを描けばいいですか？」
あ
田
田中VPoE
「フローチャートでもいいが、ビジネスプロセスの国際標準であるBPMNを使うと、より正確に伝えられる。加えてデータフロー図とRACIマトリクスで、情報の流れと責任の所在も明確にしよう。」
BPMN（Business Process Model and Notation）
BPMNの基本要素
BPMNはビジネスプロセスを可視化するための国際標準記法（ISO/IEC 19510）だ。
| 要素 | 記号 | 用途 | 例 |
|---|---|---|---|
| イベント | 丸 | プロセスの開始・終了・中間イベント | 請求書受領、支払い完了 |
| アクティビティ | 角丸四角 | 実行されるタスク | データ入力、承認 |
| ゲートウェイ | ひし形 | 分岐・合流の判断ポイント | 照合一致？、金額10万円以上？ |
| フロー | 矢印 | アクティビティ間の流れ | シーケンスフロー、メッセージフロー |
| プール/レーン | 横帯 | 役割・部門の区分 | 経理担当、経理課長、システム |
NetShop社 請求書処理のBPMN表現
[プール: NetShop社 請求書処理]
[レーン: 経理担当]
(開始) → [請求書受領] → <受領方法?>
├── メール → [PDF→データ変換]
└── 郵送 → [スキャン・PDF化] → [PDF→データ変換]
→ [発注書との照合] → <照合結果?>
├── 一致 → [承認依頼作成]
└── 不一致 → [差異確認・問い合わせ] → [発注書との照合]（ループ）
[レーン: 経理課長]
[承認依頼受領] → <承認判断?>
├── 承認 → [承認処理]
└── 差し戻し → [修正依頼] → 経理担当へ戻る
[レーン: 経理システム]
[支払いデータ登録] → [バッチ支払い処理] → (終了)BPMN作成のポイント
| ポイント | 説明 | やりがちな間違い |
|---|---|---|
| レーンで役割を分ける | 誰がどのタスクを担当するか明確にする | 全タスクを1レーンに入れる |
| ゲートウェイで分岐を明示 | 判断ポイントと条件を明記する | 条件なしの分岐 |
| 例外フローも描く | 正常系だけでなく異常系も含める | ハッピーパスのみ |
| 粒度を揃える | 同じ抽象度でタスクを分割する | 「請求書処理」と「印刷」を同列に |
データフロー図（DFD）
請求書処理のデータフロー
データフロー図は、データの流れに着目してプロセスを可視化する。
外部エンティティ プロセス データストア
───────────── ──────── ────────────
[取引先] ──請求書PDF──→ [1.0 請求書受領]
│
請求書データ
│
↓
[発注システム] ←─発注情報照会─ [2.0 照合処理] ──照合結果──→ [[照合ログDB]]
│
照合済み請求書
│
↓
[経理課長] ←─承認依頼─── [3.0 承認処理] ──承認記録──→ [[承認履歴DB]]
│
承認済み請求書
│
↓
[銀行API] ←─支払い指示── [4.0 支払い処理] ──支払い記録──→ [[会計システム]]データフロー図から見える課題
| 発見事項 | 詳細 | AI化のポイント |
|---|---|---|
| 手入力のデータ変換 | PDF → 会計システムへの手入力 | AI-OCRで自動化可能 |
| 発注システムとの手動照合 | 画面を見比べて手動で照合 | AIによる自動マッチング |
| 紙ベースの承認 | 承認依頼がメール + 印刷 | ワークフローシステムで電子化 |
| データの二重入力 | 会計システムと管理Excelに二重入力 | データ連携で一元化 |
RACIマトリクス
RACIとは
RACIマトリクスは、各タスクに対する関係者の役割を明確にする。
| 役割 | 英語 | 意味 |
|---|---|---|
| R | Responsible | 実行責任者（実際に作業する人） |
| A | Accountable | 説明責任者（最終的な承認者） |
| C | Consulted | 相談先（事前に意見を聞く人） |
| I | Informed | 報告先（事後に結果を知らせる人） |
NetShop社 請求書処理のRACIマトリクス
| タスク | 経理担当 | 経理課長 | 発注部門 | システム部 | 財務部長 |
|---|---|---|---|---|---|
| 請求書受領 | R | I | - | - | - |
| PDF→データ変換 | R | - | - | I | - |
| 発注書との照合 | R | - | C | - | - |
| 差異確認 | R | I | R | - | - |
| 承認依頼 | R | A | - | - | - |
| 承認判断 | - | R/A | - | - | I |
| 支払い処理 | R | A | - | C | I |
| 月次締め処理 | R | A | - | C | A |
RACIから見える課題
| 課題 | 詳細 | 改善の方向性 |
|---|---|---|
| 経理課長への集中 | ほぼ全タスクでA（説明責任者） | 金額による承認権限の委譲 |
| 発注部門との連携不足 | 差異確認時のみ関与 | 発注時点での情報品質向上 |
| システム部の関与が薄い | 支払い処理のみ | AI導入時のシステム連携が課題 |
As-Is文書化のテンプレート
プロセス概要シート
プロセス名: 請求書処理
プロセスオーナー: 鈴木経理課長
対象範囲: 請求書受領から支払い完了まで
月間処理量: 約2,000件
平均所要時間: 5.2日（目標: 3日）
関連システム: 経理ソフト（オンプレ）、メール、Excel
主要KPI: 処理日数、照合一致率、支払い遅延率
ボトルネック:
1. 承認待ち（28時間）- 承認者集中
2. 支払いバッチ（48時間）- 週次処理
3. リワーク（36%）- 照合不一致、入力ミス
年間コスト影響:
リワークコスト: 3,350万円
遅延による機会損失: 推定1,200万円
合計: 約4,550万円まとめ
| 項目 | ポイント |
|---|---|
| BPMN | 国際標準の記法でプロセスフローを正確に表現 |
| データフロー図 | データの流れに着目し、手入力・二重入力等の非効率を発見 |
| RACIマトリクス | 責任の所在を明確にし、集中やボトルネックを特定 |
| As-Is文書化 | プロセス概要シートで全体像を一枚にまとめる |
チェックリスト
- BPMNの基本要素（イベント、アクティビティ、ゲートウェイ、レーン）を理解した
- データフロー図からデータ処理の非効率を特定できる
- RACIマトリクスで責任の所在を整理できる
- As-Is文書化のテンプレートを活用できる
次のステップへ
次は演習として、NetShop社の3つの業務プロセスについてAs-Is分析を実際に行おう。
推定読了時間: 30分