業務単位は「疎結合」されている - 設計者の発言
業務のあり方には「ロジックで制御される性質」と「イベントで駆動される性質」とが混在している。しかしこれらは業務の記述を階層化することで、別個の性質として取り扱える。階層化せずに記述すれば、それらの性質が渾然一体となってわかりにくくなるか、職場の実態を表さないものになってしまう。 ◆ロジック制御とイベントドリブン 朝起きて顔を洗う。それを「眠りにつく」に後続する活動と考えれば、「活動が実施される順序」を表す矢印を用いて次のように表記できる。何も問題はなさそうだ。 眠りにつく → 起きて顔を洗う では、業務システムに含まれる活動として、「受注」と「出荷」を例にして同様のことを考えてみる。「受注してから出荷する」と言って間違いではないので、次のように表記できそうに思える。 受注する → 出荷する しかし、現実にはほとんどの受注・出荷活動はこのような「ロジック」で制御されているわけではない。誰かが
売掛金と消費税の仕訳 - 設計者の発言
「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」の改訂版（近日公開予定）に関する話題。初版に関して、近所の飲み友達で辣腕のシステムコンサルタントである杉本氏から、メールで詳細なレポートをいただいた。今回はその中から消費税の扱いに関する筆者の間違いを恥をしのんで紹介したい。読者の業務知識の勉強に役に立てばうれしい。 ◆消費税は売上計上と同時に認識される 一般に財務管理システムでは、営業管理システム（販売管理システム）で保持されている売上情報や請求情報を参照しつつ、回収実績を登録するようになっている。「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」の初版では、回収の際に消費税額を登録するようになっていた。つまり、ある新規顧客に対して１万円が課税取引として売上計上されたとすると、次のように仕訳される仕様になっていた。 【売上時】 2/25 売掛金 １０，０００／売上 １０，０００ 【回収時】 4/15 現金(等)
販売管理システムの「会計３要素」 - 設計者の発言
卸売業向けの販売管理システムは、ソフト技術者がシステム設計を学ぶためには最良の案件である。まず卸売業の企業数が多いということがその理由のひとつだが、もっと重要なのは、骨格が共通している点だ。個々の企業の特性に合わせて販売管理システムにはさまざまな違いが生じるが、基本的な骨格は同じである。 その骨格とは、筆者が呼ぶところの「会計３要素」、すなわち「仕入」、「売上」、「受払」だ。販売管理システムはこれらの要素を周到に取り扱って、その数字を財務管理システムに渡さなければならない。それらが集計される過程で企業の特殊性は捨象されてしまう。そういうわけなので、その骨格を正しく理解しておけばシステム設計はぐっと楽になる。武道において腰や腹の安定が基本中の基本であるようなものだ。 「３要素」のそれぞれを説明しよう。「仕入」は買掛残高、「売上」は売掛残高、「受払」は在庫残高をそれぞれ増減させる取引である。も
「定義すること」が苦労の始まり - 設計者の発言
システム開発の仕事は「定義すること」の積み重ねである。データ項目を定義し、帳簿を定義し、仕事のまとまりを定義し、データの処理手順を定義する。これらの諸定義を扱うためのしくみをさらに定義して、組み立てる。 定義できない要素に対して、業務システムは無力だ。事前に内容を定義できない仕事向けには、支援プログラムも業務マニュアルも用意できない。また、事前に様式化できない情報については、摘要欄で自然言語か何かで記述してもらわざるを得ない。ＸＭＬ等を使ってタグ付きで保管することも可能だが、局所的なものでない限り、処理ロジックはその種のアドホックな様式には対応できない。 定義できない要素に対応できないというのは、業務システムに固有の制約ではない。法律や社会制度や学問体系といった、およそ言語を基礎にして出来上がっていて、かつ対応する現実が存在するような体系に共通する特性である。 では、その種の体系において、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
higaさんによるダイコン時代の設計方法 - tpircs
