ステータス管理

請求・入金に限らず、ロックの話をもうちょっと考えると、結局はステータス管理って事に行き着く。

Accessに毛が生えたような支援ツールぽいのは除けば、今まで関わって来た業務システムの殆どは、各データのステータス中心で動いていた。

受注なら受注で、受注登録、確定済み、出荷済み、売上済み、キャンセルなどなどのステータスを区分として持っていて、各ステータスによって出来る事、出来ない事をきっちりマトリックスとして表せる様になっていた。

確定済みの受注に対しては出荷指示書が出てるので、受注管理システム側からは修正不可、とか。売上済みだったら、出荷管理側からも不可、とか。請求済みならまだ売上計上訂正はオッケーだけど、消し込み終わってたらダメよ、とか。

で、業務システムにおいては、稼動後の致命的な障害ってのは、大概このデータに関するセキュリティモデルに反するデータが出来ちゃいました、って奴だ。変更されちゃ困る金額があるタイミングで変えられちゃった、とかさ。

如何にステータスを制御するか、そしてステータスに運用が制御されるかが、安定したシステムの秘訣だと、師匠格の人にバカアホ死ね原始人と罵られながら教わった。とてもためになって、今じゃ完全に血肉となってる。

まあ業務フローって事なんだろうけど、それをただの処理手順じゃなくて、「出来る事」「出来ない事」までを明確にする事が最優先であるって説いた師匠格の人は偉いと思う。今まで読んだシステム設計云々だのモデリングだのって本に当たっても、そこに言及したものは見た事ないからだ。

UMLに最初に触れてびっくりしたのは、ステータス管理を表記する記法が貧弱だって事だ。確かにステートマシン図とか云うのはあるけど、切符を入れた、ゲートをあける、ゲートが閉まっているだのなんだの、あれでお客様に承認貰えるか？データに対するセキュリティモデルが判るか？無理だよ！

特に仕訳を作ったり、ファームバンキング用のファイルを生成して実際に銀行につなげたりと云った、お金の動きに関わる部分を、ステータスに対する意識が低いまま、お客様の「出来たらいいな〜」の一言で「出来ますよ〜」で作られると本当に困る。

開発プロセス云々モデリング云々DOAだOOAだとても面白いし俺も読んだり語ったり大好きだけど、ここらへんの事がここまで無視されてるってのは、皆とっくのとうに押さえてて、云わずもがなの不文律なんですかね。俺、今恥ずかしい事書いてますかね。