« 予算テーブルと実績テーブルを分ける? | トップページ | システム開発企業のスリム化戦略 »

2018.10.25

「試算表テーブル」を設計する?

 前回記事で、「関数従属性にもとづくデータの論理構造」に着目してDB設計すべきだと説明した。しかしそのスタイルはひどくマイナーで、「データの扱われ方」に沿ってテーブルを切り出すやり方が今でも圧倒的多数派である。

 多数派のやり方の何が問題なのか。非効率で混乱している現行業務をシステム化する場合、ふつうは抜本的合理化が求められる。ところが「データの扱われ方主導」ではそれが起こりにくい。現行業務のあり方が追認されたうえでの効率化しか起こらない恐れがある。

 具体例を「簿記」を使って説明しよう。紙とペンで伝統的な経理事務をやっている組織があるとして、業務を合理化するためのコンピュータシステムがスクラッチ開発されることになったとしよう。

 「データの扱われ方主導」で設計する技術者は、開口一番「(現行の)仕事の進め方を教えてください」と尋ねるだろう。ユーザは次のように答えるだろう。「まずは勘定科目の体系を決めて、適宜に仕訳伝票を起票して、月次で仕訳帳と総勘定元帳に転記します。期末になったら試算表と精算表の形にまとめ直して、最終的にP/LやB/Sの形に整形します」

 そのような説明にもとづいて「データの扱われ方主導」で設計すれば、次で示すようなテーブル群が切り出されるだろう。業務様式は現状と替わり映えしない。勘定や仕訳の登録から始まって、仕訳帳転記、総勘定元帳転記、試算表転記、精算表転記、などと続くだろう。

・勘定科目テーブル
・仕訳伝票テーブル
・仕訳帳テーブル
・総勘定元帳テーブル
・試算表テーブル
・精算表テーブル
・P/Lテーブル
・B/Sテーブル

 あなたが実際の会計システムがどういうものかを知っているのであれば、このような設計は噴飯モノに違いない。コンピュータを使う場合、紙とペンの時代に必要だった転記や集計の作業が要らなくなるため、帳簿組織(DB構造)や業務様式はすっかり変わってしまうからだ。外部システムとうまく連係すれば、ユーザは仕訳さえ意識する必要がなくなる。

 極端な事例と思われるかもしれないが、あなたはこの設計を稚拙だと笑えるだろうか。ユーザが「A業務を実施して、その後でB業務を実施します。月末にはC業務を実施して、最終的にDの帳票を出力します」と説明したとして、あなたはA、B、C、Dのテーブルやクラスを自動的に想像してしまわないだろうか。

 「xxする」という表現を耳にしたら「xxエントリー」のUIを設計して、そのアプリを動かすために「xxテーブル」を切り出す。そのように考える癖がついてしまっている開発者はじっさい少なくない。なにしろシステム設計に関する書籍にさえ、「xxする」と言えるのであれば「xxイベントのエンティティ」が求められていると書いてあったりする。

 繰り返すが、そのやり方では現状の非効率が温存されやすい。個々の仕事がそれなりに効率化されたとしても、システム化に伴って不要になる仕事や新たな仕事が明らかにならない恐れがある。システム導入後に「試算表を作りやすくなりました」では全然ダメで、「コンピュータを使えば試算表を作る意味なんてないんですね」の気づきがもたらされなければいけない。「データの扱われ方主導」では、現状の業務態勢が合理的であるかどうかが俎上に載りにくいということだ。

 だからこそ我々は、「従来のデータの扱われ方」とは関係ない「扱われるデータのあるべき形」をまずは洞察したうえで、これにもとづく「新しいデータの扱われ方」を創造しなければいけない。もちろん私も「現行のデータの扱われ方」を確認することはあるが、それはあくまでも「扱われるデータのあるべき形」の参考にするためだ。少なくとも「試算表をまとめています」と聞いて自動的に「試算表テーブル」を想像するようなマネはしない。

 新しいデータ構造にもとづく新しいデータの扱われ方――それは現状の業務様式とはまるで違っているかもしれない。昔からのやり方にこだわる関係者にはイヤがられるだろう。しかしコンピュータを用いて業務を合理化するというのはそういうことである。嫌われて上等なのだ。

|

« 予算テーブルと実績テーブルを分ける? | トップページ | システム開発企業のスリム化戦略 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「試算表テーブル」を設計する?:

« 予算テーブルと実績テーブルを分ける? | トップページ | システム開発企業のスリム化戦略 »