売上の「正しい」名前とは何か

プログラムを書くときには、クラス名、メソッド名、変数名などいろいろな場面で名前を付ける必要があります。このとき正しい名前を付けることが大切なことは、今さらいうまでもないでしょう。たとえば(きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません)とか。
ところで、データーベースにも名前を付ける場面があります。といっても、テーブル名とカラム名くらいですが。こちらも正しい名前を付けたほうがよいのは勿論です。いま関わっているのは、DWHというかBIというか企業内の情報検索およびレポートシステムなので、データーベースのカラム名を付ける場面がたくさんありました(ちなみに、テーブル名は「開発標準」にそって、システム名を表すプレフィックスに連番という古式ゆかしいものでした)。
このときカラム名に困りました。べつに売上でなくてもよいのですが、売上を例にとります。
たとえば海外での販売については、まず現地での売上と円に換算した売上の2つが必要になります。で、売上時点の換算のレートを使うシステムと最新の換算レートを使う(期末に確定する)システムがあれば、3つになります。
また、社内分社制というかカンパニー制というか、そのようなものを採用しているので、ごく簡単にすると次のような商流になります。

[ 組立工場 =(1)=> 商品企画担当 =(2)=> 営業販売担当 ] =(3)=> 顧客

企業(グループ)は[]全体なので、企業としての売上といえば最後の対顧客への(3)を指すことになります。ところが組立工場は(1)を売上とよんでいます。おなじことが(2)にも当てはまります。では、売上というカラムには、どんな値をいれるべきなのでしょうか。
また、(1)は組立工場の売上であると同時に、商品企画担当の仕入でもあります。おなじことが(2)にも当てはまります。こんどは、同じ値に別の名前がついているのです。(1)あるいは(2)は、売上でしょうか、それとも仕入でしょうか。
ところで、組立工場は企業(グループ)以外に外部の顧客へも販売しています。

[ 組立工場 ] =(4)=> 顧客

だから、組立工場の売上は(1)+(4)です。これは企業外への売上ですから、企業としての売上も(3)+(4)になります。
さらに、組立工場に製造を依頼する商品企画担当はひとつとは限りません。

[ 組立工場(A) =(1)=> 商品企画担当(A) ... ]
[ 組立工場(A) =(5)=> 商品企画担当(B) ... ]

組立工場(A)の売上は(1)+(4)+(5)です。(5)は(1)と同じく、企業としての売上には入りません。
もちろん海外の組立工場の場合には先に触れた換算レートも関連します。
とまあ、こういう組み合わせがいろいろあって、売上といわれるものが十数種類も存在するのです。それぞれの値はすべて意味のある値ですし、それを売上とよぶのは「正しい」のです。全社的なDWHは、各部門が持っているデーターの、いわば最小公倍数を持つことになるので、これらをすべて提供する必要があります。
売上の提供の仕方もやっかいです。企業全体の売上は、企業外の顧客への売上です。これを各分社や部門にドリルダウンしていこうとすると、それぞれで売上とよんでいるものとは単純には整合しなくなります。そのため、全社的情報提供システムで、各部門で売上とよんでいる数字を手に入れるためには、「aa区分がbbのときのcc」と「dd区分がeeかつff区分がgg以外のときのhh」を合わせたものが売上になります、と説明することになってしまいます。あるいは十数種類もの「なんたら売上」を羅列することになってしまいます。
こういうときは、どのようにするのが良いのか、正直わかりません。データーベース設計の専門家には、常識なのかもしれません。よい「やりかた」をご存知の方は、ぜひ教えてください。

  • -

私としては、ひとつのシステムで企業のすべての情報が提供しようというのが、そもそも無理な気がします。うまくいえませんが、システムには適切な大きさがあると思います。たぶん、人が扱うことのできる情報の大きさと密接な関連があるのでしょう。実際のところ、企業全体の業績判断から1営業部員のある客先への訪問日時までを一人の人が扱うことはないでしょう。であれば、その人の業務に過不足のない情報を提供できるシステムで十分なのではないでしょうか。そのようなシステムには、せいぜい数個の売上しか登場しないでしょうし、その値の意味もすぐに把握できるでしょう。
あまり受けの良くない見解かもしれませんが、部分最適化というのは悪くないと考えているのです。むしろ、適切な大きさのシステムを構築し、それらのシステム同士で必要な情報だけをやりとりするほうが、うまく行くと考えているのです。もちろんシステム同士でのやりとりが困難であれば(コストがかかるのであれば)ダメでしょう。「相互接続性を念頭に置いたサービス構築」(参照)は前提です。そして、そのように構築されるのが正しい「イントラネット」(参照)で、RESTはその基盤技術なのです。

  • -

それから、このシステム自体は好評で、いろいろな部門から「こういう風に活用したい」というご相談をいただいております(おかげさまで相変わらず残業続きです)。