BPMはウォーターフォールで失敗する

　過去、BPMの導入（BPMSの導入？）で、多くのウォーターフォール型のプロジェクトの失敗がありました。「容易にPDCAサイクルが回らない。」ということがBPMにおいて失敗です。プロジェクト終了直後に「BPMSが動いているから成功」ではありません。
　BPMが対象にしているプロセスは「従来のシステムが担っていない人が行う業務を含めて管理」することです。人が行う業務を含めているということは「業務のやり方は流動的で、ちょっとした環境の変化でもプロセスは修正されていく」ということになります。環境が変化しなくとも「何等かの業務上の問題」（顧客クレーム、業務ミスなど）が発生しても、その改善のためにプロセスは変化します。（この意味がわからない方は一般的な業務フローとＢＰＭＮ図との違い、「プロセス管理」という言葉に騙されることなかれ。BPMにおけるプロセス管理とは。をお読みください。）
以下で書くような基幹システムの導入のようなウォーターフォール型のプロジェクトにしてしまうと、さまざまな問題が発生します。
　現在、多くの企業でDXの要求からアジャイル開発に対応したシステム開発標準（プロジェクト管理標準、以下開発標準）が定められているようです。アジャイル型で小さなプロジェクト（マスターストーリーリスト？プロセス？）ごとでのシステム開発とBPMの改善ステップとの関係について述べてみたいと思います。

目次
１．ウォーターフォール型のBPMプロジェクト
２．アジャイル用語とBPM（暫定）
３．まとめ（ご意見の募集）

１．ウォーターフォール型のBPMプロジェクト

　例えば「１００プロセスを導入する」というプロジェクトを立ち上げ、「要件定義工程」で１００プロセスのBPMN図を描き、１００プロセスの中で開発する作業の自動化（BPMの改善ステップの６で行う）項目を洗い出し、１００プロセスに関係する基幹システムとの連携層を洗い出す（ここまでに数か月を要す）、その後「設計工程」で作業の自動化開発・連携層の設計書を作成する（さらに数か月を要する）。そして「製造工程」ということでプログラミングなどを行う（ここにも数か月を要する）ということで、あっという間に１年以上が経過しているでしょう。
ここから発生する問題は・・
１．時間が経過しているのでプロセスそのものが変化している。
　数人のITコンサルなどが実務者に聞き取りをしてBPMN図を描き、レビューを行うと、それだけで数か月は必要になるでしょう。そうすると数か月前、初期のころに描いたBPMN図は、すでに現実の業務から乖離しており、またプロセス図の修正業務が始まります。要件定義が終了しないと設計後の見積が作れないのため、どこかで終了させたとしても「設計工程」「製造工程」でも時間の経過からプロセスは変化しており頻繁に「後戻り」が発生することになります。それぞれの工程でレビューやステアリング・コミッティ（プロジェクト意思決定委員会）があり、中々確定せずに前に進まなくなるため、さらに時間がかかる、時間がかかると・・という悪循環が始まる。末端のIT技術者にとっては「仕様変更」の連続で、終わりの見えない変更作業が続き大きなストレスとなるでしょう。

２．費用が変動する。
　プロセスは生き物のように、どんどん変化していきます。そうするとステアリング・コミッティ後の修正は追加費用という話になります。プロジェクトが終わるまでに、いくらの費用が必要なのかわからなくなる。いつ終わるのか、最終的な費用が見えないプロジェクトになり「続けるのか」「中止するのか」という判断を迫られることになる。

３．プロジェクトを終了後の費用。
　一時的に集められたコンサルやエンジニアが聞き取りレベルで一斉に作ったので、社内では誰もそれぞれのプロセスがどのように作られているかは分析をしないとわからない。その後の変更管理もシステム会社に任せるしかなく多額の費用がかかり続ける。維持費用がかかかる割には効果がない。「このシステムを維持し続けるのかどうか」という判断を迫られる。基幹システムやExcelなどがあれば業務ができるのでBPMSが無くなっても何とかなる、という判断からやめてしまうという結果になっていることが多いと思われます。そして属人化業務による問題が解決できない・業務改善が継続できないままとなってしまう。すなわち多額の費用と時間をかけたもののDXは達成できなくなるということでしょう。

２．アジャイル用語とBPM（暫定）

　現在、BPMコンソーシアムでは、理事３名でBPMの改善のステップとアジャイル開発との関係を明確にするために検討をしています。ここでは一旦検討中の状態を公開します。

⓪ユーザーが主体となってBPMN図を描き課題を出し解決策を考える（STEP1～２）という考え方はアジャイル開発にはない。（開発者主体で書かれているため）
①この範囲が一般的なアジャイル開発の領域で１回のSTEP３～６がイテレーション。
②STEP３でユーザー要望を出しSTEP４で実現方法を検討する。アジャイル開発で言うマスターストーリーリストを作成（BPMで言うとレベル２のBPMN図）、１回のイテレーションでの開発の優先順位を決める。（１か月～３か月程度で使用開始できるレベル）
③②で決められた開発を行い使用開始する。
④使用後の分析で残りの開発やSTEP５での修正を検討する。そして②に戻りマスターストーリーリストの修正と優先順位の変更をする。

といいうように、アジャイル開発の用語を、BPMの改善ステップに当てはめて考えてみました。
ここからはプロジェクト・マネジメントの世界であり、どのような管理(レビューや資料などを含めて）や体制が必要であるかはPMBOKから決まってくるのではないかと思います。

４．まとめ（ご意見の募集）

　2022年にウォーターフォール型の開発標準がBPM導入の壁になっているということをコラムで書きました。（ＢＰＭ「体制」「しくみ」の重要性:PMBOKの壁？参照）PMBOKも2021年に改訂された第７版からはアジャイル開発に対応していましたが、まだ、このころはウォーターフォール型の開発標準しかない企業、組織がほどんどでした。そのことによって「BPMの導入ができない。」と言われる企業もありました。これはBPMをウォーターフォールで導入すると失敗することがわかっているお客様だったからです。残念ながら今でもウォーターフォール型の開発標準しかない企業、組織は多くあり、特に経営者はその考え方を修正できないでいると聞きます。「ITによるシステム開発＝ウォーターフォール」という固定概念です。（これは過去のシステム導入の失敗が続いたことからの経営者のリスク回避の意識からだと思います。）

　そのためBPMの改善ステップと一般的なアジャイル開発における用語を対比させてみました。以上に示した図は概要を表しており詳細な検討は、まだ継続中です。これらの対比を明確にすることでBPMに対応した「アジャイル開発標準」を作っていただく手がかりにしていただければと考えています。
　しかしながら、我々はプロジェクト・マネジメントのプロフェッショナルではないため、アジャイル開発を実践された経験、アジャイル型のシステム開発標準を作成された経験のある方々のご意見が欲しいです。これらの結果は、現在、改訂作業中の書籍「業務改革、見える化のための業務フローの描き方」に掲載予定です。明確なお礼はできないのですが、ご協力いただいた方々には協力者として書籍にお名前を載せたいと考えております。
　ご協力いただける方はお問い合わせのページからご連絡をいただければと思います。対面でもリモートでも結構ですのでご意見がいただければと思います。よろしくお願いいたします。　

関連ページ