こんにちは。レッドハットで Chief Technologistとして活動している梅野です。 今日はアプリケーションの中で結構厄介な、「業務のステータス」について書いてみます。
「業務のステータス」とは？
「あの案件の進捗、どうなっている？」とか、上司から聞かれませんか？そんな時、「技術部の高山課長・加藤部長の承認はもらえて、企画部と営業部には承認のお願いに行っていますが、業者から仕様の変更分の再見積もりがまだ来ていなくて、経理部に回せていません！」 「この案件は我社にとって重要な案件だ。関根常務と廣山専務も承認パスに入れておくようにな。来年1月から我社も印鑑レスになるから、プログラムで常務と専務がチェックできるようにしておくように変更要求を出しておいてくれ。ちゃちゃっとな。」 「はい、承知しました... （ぐへぇ、また技術の蒲池さんにお願いするのか... あの人怖いんだよなぁ〜、しかもちゃちゃっとできるわけないっしょ？）」
みたいな話、ありませんか？ この話では社内の稟議の例ですが、受付から契約までの流れや仕様公開から入札までの流れなど、「今、業務としてどこまでできているか」の状況をわかるようにしておくのは、業務上重要なことです。コレがわからないと、稟議やら手続きやらを流れに沿って担当者にいちいち確認しに行かなければならなくなります。これが大変なので、皆さんどうしているかというと、DBにフラグカラムを作成し、承認パスの変遷をデータとして書き込み、その組合せでステータスを報告するという、神業的なことをやられております...
業務ステータスの実態
業務を支えるシステムの一つのパーツとして、データベース(DB)があることは言うまでもありません。ですが、私が見てきたお客様の多くは、「フラグ」という名のフィールドをたくさん作っており、その組合せをロジックで判断しており、さらにはステータスを「乱発」されております。業務データ以上の数の「フラグ」カラムがあったんです。しかも、半分くらいは何に使っているかが今の担当者ではわからないという... ステータスをその組合せで作っているし、そのステータスが業務ロジックの中に混在してしまっていました。そうすると、ステータス毎にロジックがコピペ＆改変され、ステータスの分岐が複雑性を指数関数的に飛躍させていました。 多くのお客様は、「似たようなロジックがたくさんあるのが悪だ！」とおっしゃいますが、それは単にコピペされたロジック。しかも、微妙にちょっとずつ違うのですが、それは必要なロジックなのです。しかも、コピペしているから実装に時間はかかっていないのです。着眼すべきは、「ステータスの複雑さ」ではないでしょうか。ソースコードのスパゲッティ化の原因にさえ見えてきます。
解決策はあるのか？
簡単な話です。ステータスを専用で管理する仕組み（サービス）にして、ステータスが知りたければ問い合わせをする仕組みにすればよいだけです。業務データとステータス管理を分離させます。ただそれだけです。
「え？いやいや、そんな簡単な話じゃないでしょ？ビジネスプロセスマネージメント(BPM)みたいな製品でやろうとしたって何百パターンも作らないといけないし、差戻し処理とかのときはどうするのよ？業務DBとステータスDBを分けてしまって、片方のCommitが失敗した時はどーすんの？.... 」 等の声が聞こえてきます（妄想の会話ではないところが悲しい...）
昔、話としては流行ったものの導入して成功したという事例をほとんど聞かない、BPM。何故流行らなかったのか、私なりに検証したのが下記です。
1. 承認パターンの複雑化
係長→課長→部長 の順が業務上の正解なのですが、課長が入院してしまった時、先に部長の承認をもらう みたいなパターンが出てくるのは容易に想像できます。こういう場合、係長→部長→課長 の順のプロセスを用意したり、課長の代役で部長が入力したり、DBに無理やりデータを放り込んだり... 等が現実解となっていました。つまり、ツールとして柔軟性に欠けていたのです。
2. 差戻し処理
部門内ならまだしも、部門をまたがるプロセスで差戻しが発生した場合、部門ごとに使っているアプリやDBを「元の状態に戻す」ことが要求されたりしていました。これ、私自身もそういう実装を頼まれたことがあるのですが、「めちゃくちゃ面倒」なのです。絵にすると一直線で、これ以上のシンプルさを求めるのは不可能というレベルのぷろせすであっても、この「差戻し処理」を入れると、あら不思議、実装としては絡み合った朝顔のつるのような物が最初から出来上がります...
3. システム的なデータの流れを記述
タスクの連携をお絵かきソフト的な感じで書けるものですから、承認ボタンを押されたあとの後続処理を、トランザクション管理をしながら他システム連携させてしまう使い方をしているケースが結構ありました。上記の差戻し処理もそうですが、ダメだった場合のrollbackが超絶面倒なのです。面倒なくらいならやればよいのですが、他のシステムが格納したデータを「上書き」してしまい、元に戻せない状況まで発生するわけです。 （実際には、その時のエラーハンドリングまでやる必要があります... 吐きそうだった...）
に関しては、今は「Case Management」という考え方、モジュールが提供されています。この場合、とにかく係長・課長・部長の3人の承認が下りればよく、その順序性は問わないのです。だとしたら、「順序は問わずに3つの承認が揃ったら次に進む」ということにすればよいのです。実際には、係長の承認のあと、XXシステムにデータが登録されたことを持って課長が承認を行う みたいなことがあります。その場合も、システムへのデータ登録というイベントを掴むことを開始条件とすることで、課長の承認タスクを開始させるということができるようになっています。ここは単にイベントの組合せを書くだけではなく、ルールエンジンなどでより高度な状況の判断を行うこともできます。
については、諦めてください。笑。 というか、「差戻し」ってその条件では承認できませんよと「却下」されたのと同じなんです。だとしたら、その申請プロセスとしては「却下」として終了させ、もう一度申請を始めるべきなんです。「いやいや、とはゆうても膨大な入力、もう一度やりたくないよ、価格を5%値引けば通るなら、そこだけ変えてよ！」という話もよくわかります。であれば、あるスナップショットまでを「自動的に入力」ということにして、新たなプロセスとして進行させるとしてしまえばよいのです。元には戻さず、前に向かうだけ。このポリシーにするだけでも、かなりスッキリするはずです。
は、業務的な流れをBPMで書くべきであり、システム的な流れはBPMではなく、システム連携ツールで行うべきです。極論でいうと、BPMが管理すべきものは「人の承認の流れ」もしくは「機械査定」のように機械で判定した履歴を残したいケースだけです。システム的な連携(業務DBへの書き込みとか他システムへのデータの送信）などは、BPMを呼び出すアプリ側でやるべき話です。ただ、業務データとステータスの管理テーブルを、同じスキーマで作成して同時にコミットさせる というのはアリだと思います。それは業務データテーブルにステータス管理項目を入れるのではなく、業務データとステータスの管理テーブルを異なるスキーマにしておき、一括コミットさせることでデータの泣別れはかなりの確率で防げます。
Red Hat Process Automation Managerという製品
レッドハットでは、Red Hat Process Automation Manager (RHPAM)という製品を提供しています。これが「案件の進捗管理」にかなり有効です。RHPAMは、プロセスサービスとして、単一のサービス提供型アプリケーションとなります。アプリケーションロジックからデータとプロセスを分離させることで、アプリケーションの簡素化、Case Managementのような非定型なプロセスの作成・管理・実行、DBの軽量化などのメリットが出てきます。それぞれのタスクでどれだけの時間がかかったのか、担当者ごと・タスクごと等にわけてレポートも出ますので、従来のBPMが標榜していたような業務プロセス改善のためのツールにももちろん適用できます。 コロナ禍において、ペーパーレス・印鑑レスに国全体・世界全体が向かっています。従来型のアプリケーションの改修ではなく、サービス提供型のアプリケーション・アーキテクチャを採用し、業務要件への柔軟性を持って対応できるようなアプリケーションにチェンジしてみてはいかがでしょうか。製品単体だけでなく、どのようにしてうまく使えばよいかのノウハウも、レッドハットは提供していますよ！
