ワークフローサンプル: 第512話：世界で一番短い業務プロセス？

「業務フロー設計を試してみたいのですが…」

『プログラミング』の世界においては「唯一の道はプログラムを書いてみること」と言われる。事実、プログラミングを始める時、誰しもが "Hello World" という文字列を表示させるプログラムを書く。これと同様に『モデリング』の世界でも「業務プロセスを描いてみること」はとても大切だ。

以下の業務プロセスは、「メール受信」で開始され、「チャット投稿」で終わる。

そもそも業務プロセスとは、何かの『キッカケ』で始まり、そして幾つかの『工程』が続くものだ。しかし、この例には『チャットに投降する』という処理工程が１つあるだけだ。しかもそれは「コンピュータによる処理」（自動処理）であって「人による処理」は一切ない。（何ということだ！）

[チャット投稿フロー]

日ごろ様々な会社の実業務をモデリングしている人間からすれば「認めたくないレベル」（？）のワークフローだが、、、そこそこ実用性もありそうだ。

たとえば工事現場の担当者が「現場写真」を社内共有するシーンを考える。もちろん、社内MLに「画像付きメール」を送るという方法もあるが、できれば Slack や OpenChat などの社内チャットに送りたい場合は少なくない。そのような場合にこのプロセスがあれば、メールの宛先を「社内チャット投稿用アドレス」にするだけで対応できる。

ちなみに、この様な「受信メールによる連携機構」だが、クラウド型ワークフロー『Questetra BPM Suite』が提供する API においては、以下の B1 に位置づけられる。

A. ワークフローシステムが常に提供する『ソフト開発 API』 (OAuth2/Basic)

A1. ユーザの操作（ワークフローAPIs）
A2. システム管理者の操作（システム設定APIs）

B. 各業務アプリが提供する『プロセスモデル接続 API』 (HTTP/WebForm/Email)

B1. プロセスの開始（メッセージ開始イベント）
B2. プロセス途中での待ち受け（メッセージ受信中間イベント）
B3. プロセス途中で外部発信（メッセージ送信中間イベント）

つまるところ、「メール着信」という外部からの制御を受けつけるようにモデリングされているため、この業務プロセスにおいては「工事現場からの現場写真」によってプロセスを開始することができるのだ。

※ B1の「メール連携」を API (Application Programming Interface) の一つと言って良いか、については議論が分かれるところではある。また B3 のいわゆる「Webhook」についても API と呼ぶべきかイロイロ意見はある。（「リバースAPI」「Webコールバック」「HTTPプッシュ」といった呼ばれ方をする場合もある）

なお、実際に自分の手でモデリングしてみて、実際に自分の手でメールを送ってみて、そして実際にチャットに自動投稿される様をみる、、、そういう時にこそ「作り上げることの面白さ」を実感できるような気がする。『Hello World』を表示させた時に感じた、あの時と同じように。。。

※ 追伸
ここで使われている『OpenChat 投稿』は標準で組み込まれた自動工程ではない。スクラッチ設計する場合は、自ら追加する必要がある。(M415)

＜Post OpenChat、Config 画面＞