BPMNの「本来の使い道」と「お勧めしない使い道」と「異なった使い道」

　一般社団法人BPMコンソーシアム　代表理事　山原雅人

　’２５年９月に前著の改訂版「ビジネスプロセス・マネジメントのための業務フローの描き方」を発売した影響からかBPMNに興味を持たれる方が多くなったと感じます。そのために、まったくBPMの予備知識無しに「ＢＰＭＮレベル１記述・演習セミナー」に参加される方がいます。
　目的をお聞きすると多くの受講者は「BPMNの記述法を学びに」って言われるのですが、それは「受講の目的であってBPMNを学ぶ目的ではないですよ」って言うと、あまりハッキリとした答えが返って来ないです。
　そこで目的をハッキリさせようということで、コラムを書いてみることにしました。「本来の使い道」［お勧めしない使い道」は過去のコラムで簡単に説明し、「異なった使い道」については「ＢＰＭは古い？経験から考え方を変えてみる」を発展させて述べてみたいと思います。

目次
１．BPMNの本来の使い道
２．BPMNのお勧めしない使い道
２．BPMNの異なった使い道
３．まとめ

１．BPMNの本来の使い道

　BPMNが作られた目的は「簡単なフローチャートを描くことによって、あまり技術的でない人がトランザクション型のアプリケーション（BPMSに実装されるアプリ）を作れるようになること」で「IT技術者」から「ビジネス（一般の実務者）」に権限移譲をすることです。（「あなたが描いているのはBPMN図ではありません」「BPM導入が『いつの間にか普通のシステム開発』になる原因」参照］）

すなわち、BPMNはBPMSのために作られた記述法です。と言うと
・「BPMSベンダーからお金をもらって売りつけようとしているんだろう。」ということを言われる方がいますが「BPMコンソーシアムとは」を良く読んでいただければと思います。
・「システムは関係ないんだよ。業務フローを描いて業務改善をするんだ。」という人もいます。「ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念」を参照してください。業務フローを描いて、その通りに業務をしてもらうことができますか。その通りに業務ができていることが見えますか。
　では「BPMSとは何か」という話は「BPMに関する誤解のまとめ」を参照してください。さらに「３．BPMNの異なった使い方」で後述します。

２．BPMNのお勧めしない使い道

　最初に、このような使い方を絶対にしてはならないとは言いませんが「システム開発の要件定義時に使用する業務フローとしてBPMN図を使う。」という使い方はお勧めしません。「BPMに関する誤解のまとめ」にも書きましたが、総務省が中心となってシステム調達のためのシステム要件をかためるためにBPMN図を使うことを推奨したためにBPMN図の誤解が広がりました。
　なぜお勧めしないかというとBPMN仕様を守って描いていると、BPMSが登場しない場合、なぜそのルールを守るのかを説明できなくなります。そうすると仕様違反の勝手なルールを作り始めます。勝手なルールで描き始めると、その業務フローは国際標準ではありませんので読む人によって意味が異なるという結果となりBPMN図ではありません。すなわち「誰が読んでも同じ意味として伝わることで共通言語として使用できる。」というBPMNの特徴を失うことになります。
　システム開発の要件定義としてのBPMN図を三階層で描くとBPMSが管理すべきフローは第二階層であるが、第二階層で、どこが作業の自動化ができるかを検討し、第三階層にその自動化対象業務を描くという使い方となります。これは「BPM導入が『いつの間にか普通のシステム開発』になる原因」で説明しました。そして第二階層のBPMN図は二度と使うことはありません。これは想像や空想で言っているのでは無く、実際に私がBPMN図を要件定義時に使用した経験から言っており、システム開発では二度とBPMN図に戻って何かを検討するということはありませんでした。

３．BPMNの異なった使い道

　「ＢＰＭは古い？経験から考え方を変えてみる」で書いたように、BPMN準拠でないBPMSはBPMSではないと考えていましたが必ずしもそうではない。と考えるようになりました。
　BPMSの定義は
　１．BPMN図とプロセスデータ関連表が設計図、設計書となってBPMの改善ステップの５（ＢＰＭの改善ステップ参照）までが実装でき稼働できる。
　２．稼働実績として、誰がどのタスクを何時から開始して何時で終了させたかという記録が残っていて、自由に分析に使用できる。
　３．タスクを管理するポータル画面で「個人の実施するタスク」（BPMNのレーンに個人が割当たっている、または自分が引き取ったタスク）と「グループが実施するタスク」（レーンにグループが割当たっており、グループの中の人に全員にタスクが表示されており、そのタスクを自分の判断で引き受けることができる）管理ができる。
　４．タスクを管理者が強制的に引き剥がし別の人のタスクに変更させる。自分が引き受けたタスクを手を離しグループに戻したり、他の人に渡したりすることができる。
という機能があればBPMSと言えます。そのシステムをBPMSと言っているか言っていないかに関係無くです。

　この中で最も大切なのは１．になります。BPMN図とプロセスデータ関連表を簡易的な設計書としてノンプログラミングで実装できるかどうかです。

・インシデント管理システム
・案件（プロセス）管理システム
　といったパッケージシステムなどは、BPMN図とプロセスデータ関連表で実務者がBPMSと同様にBPMの改善ステップ４で議論することができるでしょう。
　それはBPMN図の流れがBPMS(上記の他のシステム）の流れに一致して管理できているからです。一致していればBPMN図とプロセスデータ関連表だけで、どのようなシステムを作っているかが想定でき、稼働後も外部環境の変化、問題の発生、業務改善といった対応を行うときにBPMN図を中心に容易に議論ができるようになるからです。
　またアジャイル開発における開発要件をまとめることはBPMSの改善ステップ６における管理と同じでありBPMN図を使うことが有効であるということは「BPMはウォーターフォールで失敗する」「BPMは手法でありフレームワークではない」で述べました。

４．まとめ

　「BPMN図が実際に動いているシステムを、そのまま表せているか。」ということが重要であるということです。
BPMSはもちろんそれができます。他のシステムでもできる可能性があり、BPMN図を有効に活用することができるでしょう。
　ただ「作業の自動化の検討」をするだけであれば第三階層のフローはBPMN図で無くとも、伝統的なフローチャートでも構わないでしょう。どうせ捨ててしまうプロセス図にBPMNのルールを適用して正しいBPMN図を描くことがムダだと感じることになると思います。「なぜ国際標準なのか」を冷静に考えていただければと思います。総務省の情報から独自ルールを勝手に作って各自治体が描いているのであればBPMN図である必要はありませんし、それは国際標準のBPMN図ではありません。