台帳とUIとDB

ある新規業務で認証を取り1年近く経ったが、そのとき出来ているはずの業務運用が回っていなかった。不思議である。新規業務を作ったのだから、運用されていなければおかしい。でも、1年後くらいのタイミングで覗いてみたら、ほとんど業務ぽい運用はなく、現場への台帳更新と活動計画のあらましだけがアナウンスされている状況であった。

少ない業務システムの経験から言えば、業務の一部または全てを機械化したものがITのシステムであるから、（ITの手段は何にしろ）業務はどうにかしてでも回すはずで、回っていなければおかしい。

おかしいから呼ばれたのかもしれないが。

業務を端的に表現すれば、台帳に情報を集め、その情報を維持するだけの話である。sの台帳のデザインが見た目からイケていない。

自分の感覚では、台帳などの帳票は、全画面で開いたときに全ての列が収まるようにしたいと考える。1画面に入らないと横スクロールが発生して操作が増え、不便極まりない。余計な操作を増やしたくない。

であるから、ヘッダの行の高さがやたらと高いとアレコレと言いたくなるがそこは些細なことなので言わず、台帳で何をしようとしているのかを尋ねる。

この質問で実は運用できていない理由の片鱗が垣間見えた。1項目ずつ何を入力するのか、選択肢の場合は候補は何かを聞くと、答えが曖昧なのである。よくよく聞くと、認証を取る際に、帳票の雛形を入手してそのまま使ったらしい。

つまり、導入する側が業務にインストールするツールである帳票を理解せずに、いきなり現場に落とし込んで『書いて』とやったらしい。

現場は協力して書いてくれたらしいのであるが、何を言われたかは想像に難くない。

システムに当てはめると、台帳の表題（ヘッダ）はGUIになる。つまり、UI。そして、表題以下の行はDBになる。その台帳の思想や更新の仕組みはDBMSそのものだ。

それらのUIやDBは業務で使う。

でも、UIの項目の意味も型も理解せず他所から持ってきて、『はい、使って』と言って業務が回るだろうか。

業務ならマネジメントシステムとして業務サイクルを回す。そこにイベントやマイルストーンが設定され、年次で処理を行う。

業務を理解していないのであるから、運用である年次処理まで頭が回るわけがない。

しなければならないのは業務の再設計である。

こうした業務の設計の危うさは、エンジニアの仕様書にも潜在的にある。excelなどの仕様書はその典型である。エンジニアのSI業務や維持管理業務で使う。使われない項目やとりあえず埋めるだけになっている項目など見かけたことがあるだろう。

たかだか、帳票を使った業務の設計でも、要件、機能仕様、実現仕様、コード設計などのスキルが役にたつ。

逆に言えば、帳票を作った人にはそうしたスキルはなかったのだろう。

デ ボルトリ ディービー シラーズ/カベルネ [ 2017 赤ワイン ミディアムボディ オーストラリア 750ml ]