KAI_REPORT

導入−ルールと言う機能からの導入

具体的な事例で検討した通り、アプリケーションとは、ルールと言う機能を具体的なプログラムの形に定式化したものとみなします。

このルールが変わるたびにアプリケーションを作り直していては大変ですから、通常は、事前に想定されるルールを網羅することで、多少の変化に耐えるアプリケーションが出来上がります。

このプロセスには、二つの大きな問題が内在します。

ルールの意味が理解できていないと言う問題

先の具体例では、二つの仕訳の意味の本質的な違いはありませんが、なぜこう言った仕訳をする必要があるのか、その意味を理解して、想定されるルールを準備するのと、しないのとでは、全く結果が違ってくることになります。

今回の具体例のルールで言えば、会計上のB/S、P/Lと言う概念、意味への理解があるかないかで、出来上がるアプリケーションは全く違ったものになります。

理解できていないエンジニアあるいはユーザー側のシステム担当者は、恐らくこの二つの仕訳の違いがわからず、結果的に以下のような同じ仕訳をしてしまうのです。

■4/11　（消費者）売掛金／売上

■4/25　普通預金／売掛金（消費者）

もう一方が、

■4/11　（消費者）売掛金／売上

■5/10　普通預金／売掛金（消費者）

これではたった一日ですが、会社の資産（負債）の計上漏れが発生することに気付いていません。4/10が決算日と言う期末の一日であれば決算に多大なる影響を与えます。

ユーザーの無知の問題

アプリケーション問題は、このもう一つの内在する問題であるユーザーの無知に起因するものがほとんどであると筆者は考えていますが、これは次回に論じます。　KAI