なんか、最近、アクセス数が多いので、今日もこりずに、おかしなプロジェクトの話。
昨日のブログの書いた、「商品台帳に在庫数を記入して、更新する方法を採用したら、ディスクがたりなくなっちゃって出来ない！」っていう話。
この会社、基本的にUMLを採用してるので、たぶん、このプロジェクトもUMLを採用してると思うんです。
実は、そこが問題！
・まず、システム分析に入るため、ユーザーからヒアリングして、UMLのユースケースを作った。
・ユーザーは、在庫を知るのに、商品台帳に在庫数を記入して、（在庫が入ったら在庫数を書き換え）更新していた。
・なので、単純にそのままやった。
・UML上、そのように書いても、矛盾は出ない。
・逆にユースケース図から、別の方法を考えようと思っても。。。考えが浮かばない。
UMLを採用し、業務分析を行う場合、ユーザーからヒアリングしてその内容を書きます（まあ、ユースケース図とか、アクティビティ図とか）。
この場合、本来業務は、いろんなやり方がありえる（場合が多い）。
しかし、いろんなやり方のうち、どのやり方かを決めてやらないと、現場が混乱するので、偉い人（じゃない場合もあるけど、結局自分を含め、誰かが）がえいや！ときめてやる。
その場合、
コンピューターを導入しない前に現場が決めたことは、
コンピューターを「入れない」状態での最適解である。
コンピューターを「入れた後」も、そのやり方がいいとは限らない。
たとえば、上の例でいうと、コンピューターを「入れる前」であれば、在庫を知るのに、商品台帳に在庫数を記入して、更新するやり方は、最適解となる。
入庫伝票、出庫伝票を書いても、それを集計する人がいなければ、在庫数がわからないから。
でも、コンピューターを「入れた（後の）」場合、その集計処理はコンピューターが行うから、入庫処理、出庫処理をしたほうが、システム上よいというケースが多い（今回もそのケース）。
ところが、UMLの図をみてしまうと、そのやり方をもとに考えてしまうので（とくに若手でいろんなやり方を知らない人は）、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。
ユーザーに聞いても、コンピューターを使っていなければ、コンピューターを入れた後で、どんなシステムがよいのかは、本当のところ想像つかない。だから、やっぱり、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。
入出力だけを押さえて、そのプロセスについて、いろいろ発想を広げるか、通論を調べることになる。
しかし、前者は、データ中心指向的な発想だし、後者も最近言われない（業務のパターン化について、クラス化して公開するなんていう話をあまり聞かない。そのため、このブログで、「業務のモデル化」っていうカテゴリで、それをやろうとしたんだけど）。
つーことで、UMLのやりかただけを聞いた若手の人なんかが、システムを切ると、こーいう、困ったことが起こることがある。
っていうことが、以前のブログ「テストの失敗や品質不良の問題は、フレームワークのまずさと、仕様変更のためが多いと思う 」で書いた、「ユーザーがいう業務内容が、はたして、コンピューターを載せたとき、最適な方法かどうかわからない。」の具体例です。
