システム設計の最近のブログ記事
入学式のころ、金沢では桜が咲き始めます。
本日、地元の小学校の入学式に来賓として参列しました。
新一年生は本日、9年間の義務教育の最初の一日を迎えました。
大切な成長の日々の始まりです。病気にならず、いじめに負けず、不幸な事件に巻き込まれることもなく、メタボにもなることなく…
すこやかに成長していってくれることを祈ります。
ところで、最近の特定健診・特定保健指導で話題のメタボリックシンドロームですが、ＩＴの世界でもメタボ的な姿が気になるところです。
ＩＴのメタボとは、私が勝手に考えていることですが、…
あまり使わない機能を満載した機器やＯＳ…
もちろん、その機能をしっかり使いこなしている人にとってはメタボでもなんでもありませんが。
例えば私は、windows２０００を使っていて、ＣＰＵはｐｅｎｔｉｕｍ３の８００ＭＨＺ前後。これでまったく不具合を感じていませんが、ここでＶＩＳＴＡを使い、機器は最新のものをそろえたとすれば、…
もったいないし、やはりメタボのように思います。
使うアプリケーションは汎用パッケージがよいか独自に開発した方がよいかということですが。
不要な機能をつけずスリムな独自開発パケージが理想ですが…
汎用パッケージはなんといっても価格が安いです。独自に開発すると、ものにもよりますが数十万円の投資は必要になったりします。そして、汎用パッケージは様々な機能が付いていますから拡張性にも優れています。
そんなこんなで、多少メタボ的でもアプリケーションは作るより買う時代になった、と思っていたのですが…
長年、会計帳簿をつけてきました。これまでは市販の汎用パッケージと自分で開発したＥｘｃｅｌによる帳簿の両方を使ってきました。市販のものは「一般用」に使い、Ｅｘｃｅｌのは「不動産（賃貸）用」と「農業用」に使っています。
Ｅｘｃｅｌのシステムは取引量が年間２００アイテム以内の少ないものに使用しています。
で、どちらが使いやすいかというと、最近はシンプルなＥｘｃｅｌの方だと思うようになりました。
総勘定元帳への転記処理などは、マクロを組み込んだボタンを押さなければならない「半自動」なのですが、不要な機能がいっさいなく、あとで印刷して残すときも不要なページや空白行がなく、たいへんわかりやすいものになるのです。
いずれ、このシステムはホームページ上で紹介したいと思っていますが、仕訳帳とＢＳ／ＰＬだけ、貼り付けてみます。↓↓
↑上が仕訳帳。ここに日々の取引を入力していきます。
← 左が貸借対照表、損益計算書（ＢＳ／ＰＬ）です。
このＢＳ／ＰＬは仕訳帳への入力と同時に数値が更新されます。
このまま印刷して、青色申告決算書として保管します。
取引件数は200件と限定付きですが、500件くらいまで増やしても処理スピードは変わらないと思います。
Ｅｘｃｅｌは多くの人が使っているアプリケーションです。ＶＢＡ（Ｖｉｓｕａｌ Ｂａｓｉｃ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓ）は使っていません。マクロは総勘定元帳への転記処理に少し使っています。Ｅｘｃｅｌのマクロは、「マクロの自動記録」機能により、操作をそのままレコーダーのように記録して作成するものです。
このシステムなら必要に応じてカスタマイズすることも可能でしょう。
ＶＢＡを使用すれば、簡単に自動化したプログラムを入れることも可能でしょう。しかし、Ｅｘｃｅｌはそれ自身が備える機能を使用すれば、プログラムを組めない人にも工夫することでかなりの処理ができるたいへん優れたアプリケーションです。
もてる力をフルに引き出すことが、メタボにならない秘訣でしょう。
ユーザー様よりの電話問い合わせの内容です。
ユーザー様： 「請求一覧表の繰越金額が合わない。つい先日まではあっていたのに。」
私： 「１ヶ月ずつさかのぼって、一覧表をとってください。繰越金額が正常になるまで。その繰越が正常になった月の取引金額に異常がありますので、今度は請求明細書で確認してください。」
どこの会社にもある、コンピュータによる経営情報システムにおける繰越処理についてのことです。
例えば、請求一覧表であれば、帳票に、
前月請求額 、 当月入金 、 当月売上 、 当月請求額 の累計項目が表示されます。
そうして、締め切り処理をおこなうと、「当月請求額」が「前月請求額」に移動し、当月の取引（入金や売上）をゼロにした状態で翌月に繰り越すというわけです。
前月請求額（前月残高）は得意先ごとのレコードに記憶されています。請求明細書を印刷するときのために、当月分の取引データはすべて保管しておきます。
得意先固有の情報を記憶したファイルをマスターと呼び、日々の取引データはトランザクションと呼ばれます。
一昔前は、コンピュータの記憶装置（ＨＤＤ：ハードディスク）の容量が少なくまた高価でもあり、こうしたマスター、トランザクション方式がシステム設計の常識でした。
例えば月末処理は、通常月末になったら行えるかというとそういうわけにはいきません。３１日の営業時間ギリギリまでの取引も考慮しなければなりません。では翌月１日にそれができるかというとそうもいきません。遅れて到着した伝票、営業政策として前月に含まなければならないなどと２日も３日もずれることもざらでしょう。
その間、１日以降の伝票処理はできません。でも並行してなんとか進めなければならないことで、システムが複雑になります。そんなシステムですから、コンピュータがダウンしたりカミナリにやられたりしたときはそのたびに復旧におわれていたものです。
ところが、近年そのコンピュータが大容量でかつ高速になり、トランザクションデータを何年も保管したデーターベースが容易に構築できるようになりました。
日々の取引を確実にこなしてさえいれば、わざわざ繰り越し処理などをしなくてもよくなりました。わたしたち古い時代のプログラマーにとってはこれは夢のシステムでした。
復旧作業で、てんやわんやさせられるたびに、そんなシステムがあればいいのになあといつも思っていたものです。
このシステムには繰り越し処理はいりません。
開始日と終了日さえ指定すれば、その２点間の間の管理資料をとることができます。
開始日で前月残高を算出します。開始日以前の取引データをすべて集計して出します。
開始日の次の日から終了日までの取引データ（売上、入金）がトランザクションです。
開始日と終了日は現在でも過去でも、どんな長さの期間でもかまいません。
たったこれだけです。
これだけで一定時点（開始日、終了日）の有り高と、一定期間（開始日〜終了日）の取引内容を表現するわけです。
しかし、注意しなければならないこともあります。
�ー莪�の日付を間違えないこと、
��過去のデータでも更新できるということ、
この２点です。
いつでもどこでも自由自在に数字が更新できることが、あだになることもあります。
先のユーザー様は、約１年ほど前の伝票が、１枚なぜか取り消されていました。
それだけでその時点以降の数字はくるってしまいます。通常は間違っていても、一度繰り越されれば、そのままになってしまうものですが、このシステムはけなげにも最後まで真実の数値を導き出そうとします。
でも、復旧作業などに手を焼くことに比べれば、やはり夢のシステムです。
これは間違いなく…
