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

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

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

１・ワークステートエンジンとは何か（はぶさんの記事）
ワークステートエンジンとは何か～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の意味は、仕事（サービス）の状態によって実行される仕事内容が変わるから。
業務フローごとに仕事を実行するために、業務の状態を知る必要がある。
つまり、仕事は生成され、実行され、更新され、完了すると最後は消える。

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアプロダクトラインが解決しようとするもの～品質と再利用

ソフトウェア業界が生まれてからずっと抱えているテーマは、「品質」と「再利用」ではなかろうか？

構造化にせよ、オブジェクト指向にせよ、またRUPやXP、そしてソフトウェアプロダクトラインまで、全てはこの二つをいかに解決するのか、にかかっている。
そして、結局、誰もが納得する答えはまだない。

【１】何故、品質と再利用がそんなに重要なのか？
ソフトウェアは所詮、コンピュータに命令する作業手順に過ぎない。
しかし、それに修正を施して保守・運用し続けていくうちに、複雑化して最後には誰もが触れなくなるようになってしまう時がある。

システムが稼動して品質が保証されると、そのシステムはパッケージ製品・ライブラリとして再利用して、次の製品を安く高い品質で作ろうとする。
しかし、カスタマイズしていくうちに複雑化し、品質を制御できず、落ちてしまう時がある。

品質と再利用はコインの表と裏。
品質が保証されたシステム、プログラムはパッケージ製品、ライブラリとして再利用できる。
再利用できるシステム、プログラムは、色んな使い方で運用されるため、品質が保証されている。

システム、プログラムは運用されて保守されてナンボのもの。
開発時の品質はテスト品質に過ぎず、運用品質に満たない。

【２】SEA関西プロセス分科会にて感じたこと
8月末にSEA関西で、ソフトウェアプロダクトラインの本の翻訳者の講演があった。
小林さんと佐々木の話はとても分かりやすかった。
お二人のソフトウェアプロダクトラインに関する話を聞いていたら、とどまるところ「品質」と「再利用」がテーマそのものだった。
ソフトウェアプロダクトラインが解決しようとしている「品質」と「再利用」の解答は、ソフトウェア工学の知識の集大成みたいなもので、すごく自然なような印象だった。
何も難しいことは言っていない。

興味深かったことは、品質にアーキテクチャとチーム構成が関わること。
アーキテクチャと品質の関係性は当たり前。
でも、後者は、トヨタやアサヒビールの例のように、成果物の品質には、開発チームのマネジメントが密接に関わるという示唆は、最近のIT業界の人間系の流れ(ファシリテーション等)と関連があるのかもしれない。

【歌】Dear XPよもう一度～XP祭り2006公式ソング

　XP祭り関西2006の倉貫さんのセッションで初めて聞いた「Dear XP」。
　そのメロディがすごく残る。
　そして懇親会で、XPJUG東京の有志がライブで弾いてくれて、皆で盛り上がった。
　1日経った後もまだリフレインしている。

　「Dear XP」のビデオクリップはこちら。是非もう一度、XP祭り関西2006の余韻をどうぞ。

Dear XP Movie

　歌詞は下記に掲載されています。誰か弾いてくれないかな？

翔ソフトウェア (Sho's) Fujiwo の日記

【宴】Dear XP～XP祭り関西2006盛況終了

　XP　Dear　XP
　君ともっと話したい
　苦労やなによりも喜びを
　もっともっとわかちあいたい

～XP祭り2006オフィシャルテーマソング

　XP祭り関西2006が大盛況で終わりました。
　懇親会も100人も来て下さり、XP祭りオフィシャルテーマソングのサビで、皆が「X」「P」の格好を決めて、異様な盛り上がりでした。

　参加者から、

すごく楽しかったです！
来年もやるんですか？
XPに興味を持ちました
心が洗われました

の感想をたくさん聞きました。
　キャストの一人として、無事に終了しただけでなく、関西でこれだけの人がXPに興味を持ち、満足してもらえたことが一番嬉しい。

セッション「XP開発ライブ」の一シーン。
アジャイル王子が観客席へ問いかけているところ。

懇親会のライブ風景の一シーン。歌は「Dear XP」(XP祭り2006公式テーマソング)

　当日に参加した人は、下記のスレッドへ感想を是非書いて下さい。

http://xpmaturi-kansai.org/modules/newbb/index.php

※感想を書くには、新規登録が必要です。

　XP祭り関西2006公式ページのBlogにトラックバック用ページを作りました。
　コメント、トラックバックをドシドシお寄せ下さい。

XP祭り関西2006の感想、トラックバックなど下さい