ローコード開発とBPMの違いとは

 DX(デジタル・トランスフォーメーション)と関連して「ビジネスアジリティ」という言葉が出てきます。ビジネスアジリティとは「ビジネスの環境変化に機敏に対応する能力」と言われているようです。これを実現するためにITを俊敏に対応させなくてはならない。それで「アジャイル開発」「ローコード開発」ということに短絡的に結び付けてしまうようです。しかし、その両者とも気が付けば普通のウォータフォールのシステム開発(要件定義、設計、製造、テスト)という流れと何ら変わらなくなることがあります。BPMとその他のシステム開発との違いから「なぜ一般的なシステム開発に陥ってしまうのか」を明らかにできればと思います。

目次
1.ツールを選んでも何も変わらない
2.ローコード開発とBPMの対象業務
3.ローコード開発とBPMの違い
4.まとめ

1.ツールを選択しても何も変わらない

 今、世の中ではITツールを使って業務を標準化して業務改善をしたいという要求があるようです。ただ便利そうだ、というだけでツール選択し導入しても良い結果は得られないでしょう。ローコード開発というと必ず名前が出てくるツールとしてキントーン、PowerApps、セールスフォース、GeneXus・・・、多機能なワークフローツールとしてServiceNowやアジルポイントなどが出てきます。「これらとBPMは何が違うのか」と問われると「BPMはマネジメント手法なので、それらと比較する対象ではありません。確かにBPMSは、それらの製品に似ていますがBPMSはBPMを実現するためのツールです。そうではない使い方をするとBPMSを使ってもBPMではありません。」と答えています。すなわち、その他のツールには上位のマネジメント手法が存在しないので、単なるシステム開発に陥ってしまうということだと思います。 

2.ローコード開発とBPMの対象業務

 以前はBPMとその他の開発ツールの違いは容易にPDCAが回るか回らないかである。というような内容を、今までのコラムなどでも書いていると思います。「容易に」というのは「設定・開発が容易であること。ゆえにユーザーが自ら追加、修正、変更が可能である。」と思われている人も多いかと思います。よってその視点でツール選びをする。その一方でユーザーが「設定・開発が容易である」というのは、かつてのエンドユーザーコンピューティング(EUC)の失敗を繰り返すのではないか。という懸念を持つ情報システム部門担当者もいるでしょう。
 ここまでの議論で欠落しているのは「どのような業務を標準化して改善しようとしているのか」ということです。業務統合パッケージシステム(俗称ERP)で行う業務とEUC(Excelなども含む)で行っている業務を混同して議論していないかです。ローコード開発ツールを選定している方々は恐らく、その整理ができないままツール選定をしてしまっていると思います。BPMが対象とするのは、Excelなどを使った業務を含んだ人の行っている業務です。ERPが対象とするような業務はBPMSを使って自動化対象とせずERPの機能をそのまま使います。
 「対象業務の違い」を理解していないと大変な事態が発生します。今までシステムが対象としてこなかった詳細な業務を標準化、自動化を実現しようとすると、導入の方法論を誤ると巨大プロジェクト開発になってしまいます。今後、DXという名のもとで、これをやってしまう企業が増えるのではないかと懸念しています。
 かつての日本企業の長所は、事実上の権限移譲だと言われていました(前回に引き続き、今もそういった企業もあると思います)。BPMが対象とする業務を改善する主体は、情報システム部門など(外部コンサル会社、システムベンダーなどへの丸投げは論外)ではなく、実際に業務を行っている実務担当者でなくてはならないです。

3. ローコード開発とBPMの違い

 誰が主体かということで、PDCAサイクルが容易に回せるかどうかが決まります。実務担当者が主体となる場合の可視化ツールがBPMNになります。よってBPMを実現するためのシステムツールはBPMN準拠のBPMSでなくてはならないです。一般的なローコード開発ツールには実務者が事前検討のための議論に使え、かつ、実装にも使えるBPMNがないことが大きな違いです。その違いを以下の絵図で表しています。

 上図のように「PDCAの容易さ」というのは、単にシステムツールで決まるものではないということになります。BPMNとBPMSがあるからこそ実現できることです。かつてのEUCの失敗はBPMNのように改善前の議論で中心に置くことができ、かつ、そのままBPMSの実装に使える可視化ツールが無かったことが問題だと言えます。すなわち各現場が直接システムツールで作成や追加、修正してしまうことで収拾がつかない事態に陥ったと言えます。(RPAでも同様の問題が発生した組織もあると思います。)

4.まとめ

  BPMを実現するためにBPMNとBPMSの両方が必要になることは、以前からお伝えしている通りです。別のシステムツールでも、同様に実現できると思っている人は、ここで考え方を変えていだければと思います。BPMN準拠でないローコード開発ツールを使っていた場合、例えば内外の環境変化対応のために実務担当者がBPMN(社内で標準化された業務フローでも良いです。)で改善検討をする。そしてIT担当者は、そのフロー図で業務を修正、変更したい内容は理解できたけれども、ローコード開発ツールでどう実現するか、という「変換作業」をしなくてはならないです。BPMSを使っていれば、その変換作業は必要ありません。BPMS環境があれば、どのシーン(実務者の改善検討、IT担当者の実装)でもBPMNは共有言語的に使用することができるということになります。他のローコード開発ツールには、この一連のマネジメントができる「しくみ」がないと言っていいでしょう。たとえあったとしても、それはそのツールだけに依存しているのではないでしょうか。

関連コラム・ページ

・導入プロジェクト体制は存在しても、BPMはプロジェクトではない
BPMとIT
・BPMとは
BPMSとは
BPMNとは
DX?BPMが失敗する理由1
DX?BPMが失敗する理由2
DX?BPMが失敗する理由3
BPM モデルプロセス導入支援サービス