BPMは手法でありフレームワークではない

　過去に「BPMはフレームワークだ」と言われたことがありました。IT系の方の発言だったのでPHPやJAVAのフレームワークと同じだと言われているのか、それともPMBOKのようなフレームワークだと言われているのかと思いました。どちらにしても「BPMはフレームワークではないな」という印象でした。そもそも言葉の定義を論ずることが嫌いなので、それ以上、考えることがありませんでした。しかし前回のコラム（BPMはウォーターフォールで失敗する）でのアジャイル開発やPMBOKなどを調べている中でフレームワークと手法（メソッド）の違いが気になりました。「フレームワークとは何か」については、どれだけ議論をして明確な結論が出ることではないでしょう。ここでは「BPMをフレームワークとして捉えている」ことによる誤解や間違った発信があることについて、その背景を考えてみたいと思います。
　一般的な言われるフレームワークとは「ふんわりとした大きな枠組み」（ここでは「曖昧な」という言葉ではなく、あえて「ふんわり」という言葉を使いたいです。）を指していることが多いのかと思います。すなわち「大きな枠ぐみ」があり、それを具体的にどのように使うのか（管理様式、ツール、ルール、手順）という手法までは明確にしていないと言えます。学問で言えば「経営学」がそれにあたり、キチンとした体系がなくビジネスに関係していれば何でも経営学と言えてしまう「ふんわり感」がある。同じ企業研究であったとしても数学を基本とした「経済学」とは明確に異なると思います。
　この「ふんわり感」は経営コンサルタントの方々にとっては便利でＢＰＭを組織管理のマネジメントという大きな枠組みとして捉えることで「あれもＢＰＭ、これもＢＰＭ、なんでもＢＰＭ」という話をされる方々がいますがＢＰＭはそういったものではありません。（「ＢＰＭとは」「ＢＰＭＮとは」を参照）
BPMは「ふんわりとした大きな枠組み」ではなく「明確な業務プロセスの改善手法（メソッド）」と言えます。ゆえに私は「BPMに関して何を質問されても１００％明確に答えることができます」。それはBPMには不確実性が無いからです。すなわち「しくみ」としてはシンプルであるということです。一つの用語、一つの事象をいろいろな意味として捉える必要がないからです。理解して使いこなすまでは時間がかかりますが、実践をして、わかってしまえば簡単だということがわかります。
　ここではBPMに関する過去の書籍などから、なぜBPMが「ふんわりとした大きな枠組み」というような認識をされてしまっているのかを述べてみたいと思います。

目次
１．R.バートンの「Business Process Management」とB.シルバーの「BPMN Method and Style」
２．アジャイル開発におけるメソッドとBPMN
３．まとめ

１．R.バートンの「Business Process Management」とB.シルバーの「BPMN Method and Style」

　 BPMに関する有名なこの２冊が、まさに「ふんわりとしたフレームワークのBPM」と「手法（メソッド）」としてのBPMの違いと言えるでしょう。
簡単に言えば、BPMという手法を導入すれば「こんなすばらしいマネジメント（組織管理）ができる」という話と「BPMというプロセス改善手法の導入方法（BPMN）や技術（BPMS)」を論じているという違いです。
　R.バートンが「Business Process Management」を書いた2001年はBPMの黎明期であり、まだ欧米でもBPMNやBPMSを使った明確なBPMの事例があった訳ではなく机上論だったのだと思います。事例が書いてあるように読めますが、これは「ビジネスプロセスがBPMNやBPMSで可視化管理されると、こんな組織管理と同じことができる（はず）」ということを論じていると思います。よって、この書籍には具体的な可視化に関しての事例も明確ではなく、具体的な可視化事例から何が達成されているかということも書かれていません。この書籍は経営戦略や組織文化の管理ということを論じてしまっているためにBPM＝組織管理といった誤解が生じていると思います。BPMは業務プロセスの改善に焦点を当てるべきものです。　
　一方、B.シルバーの「BPMN Method and Style」はBPMNの正しい記述方法だけではなく、BPMNからBPMS（BPMNエンジン）をどのように作るべきかということまで論じられています。そもそもBPMNが作られた目的は「ITからビジネスへの権限移譲：簡単なフローチャートを描くことによって、あまり技術的でない人が、トランザクション型のアプリケーションを構築できるようになること」（あなたが描いているのはBPMN図ではありません。参照）からスタートしているからです。なぜITからビジネスへの権限移譲が必要なのかというと、経営レベルの人が組織管理をするためでは無く、業務改善に主眼が置かれているからだと思います。それは、どこの国であっても実務者とITシステムの開発者での業務理解、認識のずれが発生すると有効なシステムが作られない、また作り直しなどの不効率が発生するからでしょう。BPMS上でのKPI(Key Process Indicator)の設定も組織管理（人事評価）というよりも業務改善が達成できるているかどうかを、実施している本人たちが確認するためだと考えてよいでしょう（PDCAのCまたはA）。達成できていない場合は、達成するためにどのような改善をさらに行わなくてはならないか。ということを考えることが目的だと思います。KPIによる管理は経営者や管理者が実務者に「やらせる」ために設定し「やらせて」評価するシステムや「しくみ」ではないでしょう。すなわち、ＫＰＩによる管理というのはＢＰＭを導入したことによって管理ができるという結果であり、目的ではありません。これを目的にするという話は経営者ウケをするようです。そして経営者が中心になってＢＰＭを導入する失敗事例が多く見受けられます。経営者が行うべきことは環境（ＩＴ，教育）を整えることを中心としてボトムアップ力を育成することが目的であり監視を強化することではありません。（コラム：BPMと日本型経営システム参照）

２．アジャイル開発におけるメソッドとBPMN

　アジャイル開発と「スクラム」というものの関係がよくわかっていませんした。アジャイル開発が概念でしかなく、「スクラム」がフレームワークだということ、今ではスクラム＝アジャイル開発といっていいほど普及しているということは、今回の書籍改訂での実際にアジャイル開発を実践されている方々のご意見、取材で得られました。
　前回のコラムでの（BPMはウォーターフォールで失敗する）での「マスターストーリーリスト」というのは一般用語ではなく「フィーチャー」＝「ユーザーストーリ」というのも認識間違いでした。（「アジャイルサムライ」という書籍からの情報）、別の書籍（アジャイル・プロジェクトマネジメント）とご意見、取材からの情報で以下のように修正します。ただしスクラムにおける用語とＢＰＭにおける階層が一致しているわけではなく、スクラム用語には分解、階層という意味では「ゆれ」があると感じます。すなわちスクラムはフレームワークだということです。しかし必ずしも対象プロセスが３階層になるわけではない。というところはスクラムもＢＰＭも考え方は一致しています。そこは「何がしたいのか」「何を目的としているのか」が両者ともにハッキリしているからです。「業務フローをダラダラと階層化して描くことに意味がある」、または「ＢＰＭＮで業務フローを描くと何か課題が見つかるしくみがある」わけでは無く、業務フローを描くことの目的がハッキリしているという点がスクラムもＢＰＭも同じだということです。

　これらのご意見、取材の中でアジャイル開発「スクラム」における上流工程の曖昧な部分（いろいろな方法でフィーチャやユーザーストーリなどを明確にする部分）をBPMのメソッドとBPMNで明確化することで最小の設計資料で効率的な開発が実現できるのでないかという可能性も感じることができました。これらの点の詳細は、現在改訂中の書籍「業務フローの描き方」で書きたいと思います。

４．まとめ

　ＢＰＭを「ふんわりとした大きな枠組み」とすることでの組織管理を指すのでは無く、ＢＰＭは「明確な業務プロセスの改善手法（メソッド）」であることを説明しました。
　以上のようにＢＰＭとスクラムは類似点が多く、スクラムが上流の整理にＢＰＭＮを使うべきと規定するのであれば、メソッドと言って良くなるかもしれません。
　これらのことからもＢＰＭはウォーターフォールでの導入をしてはならないです。（BPMはウォーターフォールで失敗する。参照）製造業の方、製造業出身の方であればわかると思いますが、製造現場の改善がプロジェクトという形態で実行されているでしょうか。確かに一部分の工程の自動化設備の開発に関してはプロジェクトになっているかもしれません。しかし「一般的に改善は永遠である。」と言われておりプロジェクトのような終わりはありません。製造ラインや工程を対象にして自社の人材では無く、寄せ集めの外部人材が分析や改善をして１年や２年というプロジェクトを経ると「夢のように効率的な製造ラインがポンっと納品される」という事例があるでしょうか。業務を行いながらＰＤＣＡサイクルを回して改善しているのだと思います。それがＢＰＭと同じだということです。
　ＩＴに関しても同じだということに気づくべきでしょう。「ふんわりとしたフレームワーク」の中で「ふんわりとした議論」をして「経営者がそうしろと言ったから」「ＩＴ企業や経営コンサルタントがそう提案したから」という「逃げ道」があれば良いことではありません。実務者である「あなた」が失敗を予見できているにも関わらず「失敗しても自分の責任じゃないからいいや」というのでは、事後の問題を大きくし、やらなくてもよいムダな仕事が増えることになります。その後何年もムダで後ろ向きの仕事をさせられて嘆くのなら「失敗を予見したときに止めろ！」と言いたいです。業務改善をしていたはずなのに、それこそ「プロセス管理におけるチェックが機能していない。」ということから大きなムダを発生させることになります。

関連ページ