業務フローで非同期キューが現れる理由

プログラムを書くよりも「絵を描いて説明してくれ」という仕事が多くなって、いつも感じる疑問は「業務を分析する時の基本的な観点は何か？」ということ。

その疑問に対する解答のひとつとして、僕が何度も読み返している記事は下記の３つ。

１・ワークステートエンジンとは何か（はぶさんの記事）
ワークステートエンジンとは何か～Long Way To S2Buri～　その１

ワークステートエンジンとは何か～Long Way To S2Buri～　その２

２・SOAの実現: サービス設計の原則～柔軟なITのためのサービス設計（IBMの記事）

【１】業務フローの分岐が業務分析を難しくする

大抵の業務システムのプログラムは、そんなに難しいアルゴリズムを使っているわけではない。
でも、難しくなる理由は、業務フローを制御する分岐処理がデリケートだから。
分岐にはフラグとIF文が組み込まれているだけなのに、カスタマイズしていくうちに誰もが手に負えなくなる。

はぶさんの記事にある「休日判定処理」の例はすごく分かりやすい。
「完全週休２日制」から「第４土曜日は会議のため出勤」へ条件が変わった時、IF文を複雑化させていませんか？

ビジネスルールと業務要件をきちんと分離して分析していますか？

【２】フロー制御＝状態遷移、つまり業務フローはステートマシンそのもの

仕事とは、IPO（Input→Process→Output）に過ぎない。
その仕事を実行させるには、月末締めとか上司の指示待ちとか、イベントに依存する。
つまり、仕事を起動するためには、その前の仕事の状態が完了、あるいは、起動する仕事が実行状態になって、初めて動く。

だから、業務フローを制御する分岐とは、前の仕事、あるいは今の仕事の状態を判定すること。
つまり、業務フローとはステートマシンそのもの。

実装者は仕事そのもの（消費税の計算とか）の詳細に陥りがちだが、分析者は仕事がどのタイミングで切り替わるか、業務の状態管理に力点を置く。

では、状態とは何かというと、業務のライフサイクル。CRUDそのもの。
業務インスタンスは、あるタイミングで生成され、更新され、あるタイミングで消える。
まさに状態遷移図そのもの。

【３】業務の状態が重要な意味を持つ2つの理由と２つの指針

理由の一つは、業務の状態にアクターが依存するから。
例えば、支払いが完了するまでは顧客、支払いを請求する時は業務オペレーターが仕事を管轄している。
業務フローで業務が変わる時、業務に関わるアクターが変わる。
これは結構見落としやすい。

理由のもう一つは、業務の状態遷移によって、別の業務システムへ切り替わるから。
例えば、支払いが完了すると、注文システムから請求処理システムへ支払データが流れる。
業務フローで業務システムが変わると、インターフェイスのやり取りや更新の責任に注意を払う必要が出てくる。

このための指針として、IBMの記事では、下記２点を挙げている。

A・サービスはステートレス・インターフェースを持つべきである
B・サービスはステート・トランザクションを使ってモデル化すべきである

Aの意味は、仕事（サービス）に前の仕事の状態を参照しないようにすること。
前の仕事の状態の判定処理後、仕事を実行するようにすればいい。
つまり、業務状態の判定処理のIF文は、仕事の外に置くこと。

Bの意味は、仕事（サービス）の状態によって実行される仕事内容が変わるから。
業務フローごとに仕事を実行するために、業務の状態を知る必要がある。
つまり、仕事は生成され、実行され、更新され、完了すると最後は消える。

【４】非同期キューの使い道

例えば、支払いが完了すると、注文システムから請求処理システムだけでなく、別の情報系(分析系)システムへデータが流れる。
二つの別々のシステムを同時更新する時、どちらか片方が止まると、もう片方のシステムへの更新も止まってしまい利用できなくなる。

その対策として、非同期キュー機構を使う。

業務フローはいつも同期である必要はなく、むしろ非同期であってもいいし、その方が使いやすい。
先延ばしにしてよい業務処理は非同期にして、負荷をかけず、レスポンスを向上させる利点がある。
そもそも、次に実行する業務が実は手一杯で実行できない状況にあることもよくある。

更に、非同期キュー機構によって非同期キューにキューイングされているので、非同期業務がダウンしても、回復後に実行可能になる。

同期、非同期、更には非同期キューの機構はネットワークでスレッド通信で使うだけのものと思っていたが、業務フローでは自然に現れる。

業務フローが難しいのは、複雑な分岐と同期・非同期機構の使い分けにあるのではなかろうか？

【５】最後に、最近購入して、バイブルにしている２冊を紹介。

２冊ともデータモデリングの本だが、業務分析の具体例を考えるのちょうど良い。

はぶさんの本は、帳票(レシート)からモデリングする。
渡辺さんの本は、お客さんとの会話からモデリングする。

二人の性格が出ていてすごく面白い。