KAI_REPORT

導入（５）−「ルール」の意味（続き）

開発担当：「マイナス現金はどうしますか？」

ユーザー：「そんな仕訳、しませんから考慮しなくていいです。」

オシマイ。チャンチャン。

そう言うことです。が、これで納得してしまっては、アプリケーション千里の道も一歩だけ。終点にたどり着けません。

もう少しこの状況の意味を考えてみましょう。

ユーザーの立場からすれば、マイナス現金等というのは仕訳「ルール」の想定範囲外です。現金はプラスであるというのが当たり前のこんこんちきと言うことですが、もっと消極的な意味で、そんなことは思いもよらないこと、です。これに対して開発担当の立場からすると、してはならない仕訳「ルール」が示されない限り、結果的にありとあらゆる勘定科目のマイナス残高を許すプログラムを作らざるを得ません。

どちらの立場ももっともなようで、なにかしっくり来ません。実はこの違和感は両者が考える仕訳「ルール」の意味の違いから来ているのです。

この場合のユーザーが考える仕訳「ルール」とは単なる方法であって、目的ではありません。別な言い方をすると、ユーザーにとっての仕訳とは、実際に行われた「取引」の結果を分類、記録するもので、仕訳自体が目的にならないと言うことです。これに対して、開発担当からすると仕訳は、経理業務として一つの独立した業務になります。経理業務としての仕訳「ルール」の定義が必要になって、そこで定義されない「ルール」は実現されないし、マイナス現金のプロテクトもかからないと言う訳です。

実はこの問題が、一連の問題解決の手がかりを掴む大きなヒントになります。

ルール同士には依存関係がある

ここで得られた重要な知見は、ユーザーの立場から見た仕訳ルールの背景に、実際の取引ルールと言うものがあって、この取引ルールについての言及がすなわち仕訳ルールの決定を導くことになると言う事実です。つまり仕訳ルールは独立したルールではなく、取引ルールと言う他のルールに依存しているのです。

これは何を意味しているかというと、今私たちが検討している「ルール」と言う概念には、ルール同士の間に依存関係があって、通常それは主従関係あるいは相互関係と言う形で記述できる。更に言えば、このルール同士の依存関係こそがそれぞれのルールが持つ意味を担保しているのです。

つまりこう言うことです。

「ルール」の意味とは、複数の「ルール」同士の依存関係のことであって、いくら目的とする「ルール」とだけにらめっこしていても、その「ルール」の持つ意味を理解することはできません。逆にこれらの依存関係を理解することで、それぞれが持つ「ルール」の意味、目的を把握できるようになります。

やっと自己組織化アプリケーション開発のためのアーキテクチャ構築の指針が見えてきました。　KAI