昨日は、Ｗｅｂ＋ＤＢで、ＲＦＰに従うと採用さえれないんだけど、実は、採用されない案のほうが、会社にとっていいこともあるという例を挙げました（そういうつもりで書きました ^^;)
今日は、ＵＭＬで分析しようとすると、しにくい例として、確定申告をあげ、それの打開策を書きます。
なお、確定申告を調べてて、このページに来ちゃった人は、本文を見ないで、一番最後（の水平線から下）をみてね！！
確定申告用紙を見ると、夜明けのスキャットを歌いたくなるぞ！
もし、フリーの人で、事業所得が有り、さらに株をやっている人は、こんな紙が送られてくると思う。
確定申告用紙１表
それについている右側の２表（１表、２表は複写式で３枚）
株のための３表（これも複写式）
株のための計算書、損失を書く紙
青色なら、貸借対照表と損益計算書、白色なら、損益計算書相当のもの（別紙で控）
（ただし、青色の場合、最後の紙は、もっと前に、別に送られてくる）
で、説明書に、一般用と株のもの、それと、貸借対照表と損益計算書の書き方のものがある。
そこで問題なのだが、説明書のどこがどうつながって、なにを見たらいいのかが。。。
。。。初めての人にはわからないのだ。
まさに、これらいっぱいの紙（それもいっぱいますがあって、わけもわからない控除と
わけもわからない用語がならび。。。）
夜明けのスキャットのはじまりを歌いたくなるぞ！
るーるるるーるーるるるるー(;_;)
もっとも、ウィリアムのいたずらは、その歌を知っている世代ではありませんが(^^;)
ほんとーかよー？？
ＵＭＬは、まったく説明できないもの、ヒアリングが掛けられないものをモデル化しにくい
さて、ここで、確定申告の手順をモデル化しましょう。。。
っていうと、ＵＭＬとかだと困るんです。
っていうのは、ＵＭＬの場合、ユースケース図やアクティビティ図を作ることから入ります。これは、ヒアリングができて、業務を説明できる場合は、作れるのですが，今回のように、
「確定申告しなくちゃいけません。でも、やり方が分かりません」
という場合は、説明できないから、ユースケース図も作れません。
こういう場合の解析－ＵＭＬ以前の解析方法の利用
じゃあ、こういう解析は、どういう風にやるのかという話。
ＵＭＬ以前にあった解析方法として、帳票分析というのがあります。
今回の場合、１表、２表、３表、株の計算書、損益計算書等の５種類の帳票があります。
ここから、分析が可能です。
まず、この帳票からＥＲ図を起こし、クラスに持っていけば、プログラムはかけますよね。
その手法は、
Ｔ字型ＥＲ図を提唱する佐藤正美さんが本に書いてるし、
（いま、アキがあるかわかんないけど）早稲田大学のエクステンションセンターでも、
ビジネスの実態がわかるデータベースの作り方
っていう講座があるから、そっちを参照してください。
ここでは、もっと単純にやる方法。
帳票から関連を出してきて、帳票作成の前後関係を見抜き、手順をモデル化する
・とりあえず、１表、２表、３表、株の計算書、損益計算書等のうち、他の紙と関係している（他の紙の値を使っているもの）はどれかをまず探します。
損益計算書の値、２表の値を１表が使っています。
株の計算書の値を３表が使っています
１表の値を３表に持っていき、その３表から１表に戻ってきます。
・数字を使われるほうが先に計算します。使うほうが後です。
そして、交互に使う場合（１表から３表、また１表にもどる）ときは、可能であれば、分けてしまいます。
損益計算書の値、２表の値を１表が使っています。
損益計算書、２表 そのあと １表
かぶの計算書 そのあと ３表
１表を３表の値を持っていくところと、３表から値が帰ってくるところに分けます。
・あとは、適当に順番を並べてね。
そうすると、
株の計算書 詳しくは株の説明書
損益計算書 詳しくは損益を出す説明書
２表 詳しくは一般説明書の控除のところ
１表前半 一般説明書の初めから見る
３表 株の説明書の初めから見る
１表後半 一般説明書ののこりを読む
というふうな手順のモデルが出来、この順に読んでいくと、説明書の意味が通じます。
・実際の開発ではさらに、表の構成要素である、意味ごとのまとまりの関連を見て、
その意味ごとに、関連を調べていきます。
このレベルで出した結果は、大体佐藤正美さんのＴ字型ＥＲと同じようなＥＲになります。
・そして、その関連から、前後関係の手順を並べ、モデル化していきます。
モデル化できれば、だいたいユースケース図はでっち上げられます(^^;)
まとめ：ＵＭＬが使いにくい場合と対処法
まとめると、以下のケースの場合、ＵＭＬは使いにくいと思います
・ユーザーがヒアリングに非協力的である
→開発に失敗した後に、受け持ってしまった場合にある。
失敗した開発会社は、「新しい会社なので、初めから聞いていただいて結構ですよ」
とはいうものの、実際にユーザーに初めから聞くと、「おいおい、そんなことすら
引継ぎしてねーのかよ」といわれてしまい、極端な不信感につながるのに、
それを、失敗した開発会社がまったく意識していない場合（結構、このケースある）
・ユーザー自身が、手順も方法も何もわからない
→新規ビジネスの場合や、新たに国などから提出を求められることになった書類の作り方など
一応説明は来るんだけど、どういう風に作るのか、細かく載っていない場合がある
（何を書け！という説明は明確に書いてあるんだけど）
・ヒアリングには協力的なんだけど、説明できない場合
ユーザーに日本語力がない、言葉にしてあらわせない、対象内容を知らないなどのケース
こういうときは、帳票分析をかけるのが早い
（あと、業界標準手法が分かっている場合、それとのフィットギャップ分析っていう方法もあるけど）
帳票分析には、佐藤正美さんの手法が、やりやすいけど、そこまで肩肘張らずに、帳票間の関連を分析するだけで、その必然性から、ＥＲ、さらにはユースケースが出る場合がおおいね。
ただし
ただし、注意したいのは、（ＥＲ図で書くのならＯＫなんだけど）帳票分析しましたっていうとやばい。この手法は、汎用コンピューターの時代に良く使われた手法。汎用コンピューター時代のものは、すべて時代遅れという考え方が主流なので、それを隠して、現代風の、値段が高く取れるＵＭＬの手法ないしはＥＲ図に落とす必要がある。
さらに、大手の場合、「俺の言ったこと以外やるな！」っていう上司や会社が多い。
（かといって、上の人の言ったとおりになってもできないんだけどね。それは、今、上に書いたとおり）
だから、分析過程は隠して、ＥＲやユースケースにし、あとで捨てるっていうことになる。
ちなみに、確定申告なら、こんな話は、どうでもよくて、この本を見よ！
ビンボーなあなたの確定申告楽勝マニュアル
ウィリアムのいたずらも、はじめて確定申告をするとき、途方にくれたのだが、この本を税理士の知り合いから勧められ、この本を読んで申告することが出来たぞ！
２００５年版はみてないが、たぶん、内容はにたようなもんだろう。
（ただ、最後のおちが、ギョウチュウ検査の紙でないことは、大きく変わっているが）
もし、今、まだ申告してなくて、どうしようと思っているのなら、この本、本屋にいっぱいあるから、立ち読みすることをオススメするぞ！
アクセス
トータル
ランキング
