[jfriends-ml 11352] Re: 「 UML モデリングの本質」を読 む会第３回議事録

["Takashi Yamamoto" <yamamotot@xxxxxxxxxx>]

  山本です。こんにちは。

> > 　B/S.P/Lともマイナスを入力することはありえないので、
> > +は、貸方（収益）-は、借方（損失）と決めても混乱は起きないと思います。
>
> これは、駄目です。取引にはマイナスもありますから、勘定科目で一意には決ま
> りません。
>

　オリンピックの野球の試合を思い出したら、いい説明が思いつきました。
日本はカナダに11対2で勝ちましたね。
日本が点を取られるたびに「日本2失点！！！」
などとアナウンサーが絶叫してましたが、スコアボードに
日本     カナダ
-2   -   -11
などと書いてないですよね。
カナダのスコアが+2であることが日本のスコアが-2であることを暗示しています。

　簿記もこれと一緒で、
借方に　現金 : \2,000 = 現金\2,000 のプラス
貸方に　現金 : \2,000 = 現金\2,000 のマイナス
を暗示しています。
（僕のメール貸・借が逆でしたすいません。）

　B/S P/Lでマイナス値が入力されるのは、決算での一部の科目とローカルルール
ぐらいしかありません。（暇だったので本屋で調べた）
http://www.smcjapan.co.jp/management/bookkeeping_le1.htm



　で、簿記の話ではなくモデリングの話ですが、
「うちの会社では便宜上、帳簿にマイナスを入力することがある」
見たいな話であれば、借方、貸方　：　+ 、 - のような設計はあっという間に
破綻します。

　でも、「四半期ごとの経常利益を楽に計算したい」
みたいな話であれば、複式簿記の仕組みをそれほど意識しなくても
良いのではないでしょうか？



要するに、
> 経理の世界では複式簿記が憲法なのだから、
でもなく
> 機械が扱うためのルールとは無関係で，考慮するに値しません．
でもなく
　モデリングにとってはユースケースこそが憲法なのではないでしょうか？

概念モデル（人間のルール）->実装モデル（機会のルール）と進めると、
当初の目的と乖離したものになってしまう危険性は高いとおもいます。

そのときにユースケースを見直して、「間違ってないよね？」のような
コンセンサスをとることは重要じゃないでしょうか？

＃あくまでUMLの世界の中の話なので、
＃「ユースケース図で要件定義できるの？」といった話はしません。

以上です。