すげー、富士通のお菓子（クッキー？）なんてあるよ！

　富士通すげー、富士通のお菓子（写真からみると、クッキー？って、javascriptでgetCookieとかやる、クッキーじゃなくって、お菓子のクッキー）があるよ。

　それを紹介？してるのが、ここ

　すげー、どーやって、入手するんだ？
　富士通行くと、売店で売ってるのかなあ？？（まさか？）
　それとも、株主総会かなんかで、帰り際にくれるとか？？
　総会で売ってるとか？
　まさか、まさか、まさか？？？株主優待品？？

　うーん、なぞだ。。。
　つーか、なんで、富士通、こんなお菓子作ってるんだろう？？

　というわけで、ほんとうにどーでもいい、小ネタでした
　（ただ、ウィリアムのいたずらのツボに、はまったもんで）

UMLとDOAとパッケージの利用を考えるとき

今日は、忙しいので小ネタ。

UMLのようなOOAを使ったほうがいいとき、DOAを使ったほうがいいとき、あるいは、両者のような、１からの開発（スクラッチ開発？）でなく、パッケージを使ったほうがいいときの、ウィリアムのいたずらの考え
（つまり、昨日のブログの続き）

---

　既存の業務で、その手順などがきまっている場合（手順が動きにくい場合）は、UMLを使って、OOAで分析していったほうが早いと思います。なぜなら、プログラムとの親和性が高いから。

　しかし、既存の業務でない場合、手順が本当のところわかりません。それをUMLで開発すると、手順が抜けたり、変更して、鬼のような仕様変更になる場合があります。

　たとえば、たしか、どっかのサイトで話題になってたと思うけど、オークションサイトを２日で作る場合。
　これをUMLで開発すると、多分、経理とのつなぎ部分は、

　手数料収入の発生の仕訳
　　　（売掛金）XXXX　　　　　　（売上）XXXX

　手数料徴収時
　　　（現金預金）XXXX　　　　　（売掛金） XXXX

　とするため、手数料発生と、お金を受け取る、ユースケースが出てくると思う。
　しかし、これだけしかないと、仕様は大幅変更になる。

---

　これには、キャンセルがない。たぶん、社長あたりは、「キャンセルの場合でも、手数料はもらう！」などと強気に発言をするが、社長の本当の目的は金儲けであり、金儲けのためには上場しないといけないわけで、その際、キャンセルの場合（たとえ、会社側が悪くても）すべての場合手数料をもらうというやり方では、たぶん、監査が降りない。

　そこで、急に、「やっぱ、キャンセルを作れ！」となり、仕様変更になる。

　当然、この程度のこと（ベンチャー企業の社長は、「絶対あり得ない」と言い切っておきながら、後日「なんで、そうなることを想定してなかったんだ」と、自分がいったことをまったく忘れ、無責任な発言をする）は、SEにとって、想定の範囲内なのだが、問題は、このとき、業務内容は聞けないこと。

　なぜなら、絶対あり得ないと言い切ってるんだから、「その絶対あり得ない業務は、どうやりますか？」とは、聞けない。

　このような、新規業務、ユーザーに聞きにくい業務や、ユーザーも想定していない業務、ユーザーもどうやったらいいのかわからない（ベンチャーには、おおい。っていうか、ぜんぜん考えてないでしょう！っていうときもある。例：放送と、ネットの融合って？？）。
　そんな場合は、データからDOAで解析をかけて、そのデータをそろえるには、どういう業務が必要なはずかをかんがえたほうがいい。

---

　ただし、データから解析をかけると、やりかたが何通りにもなったり、よくわかんなかったりすることがある。
　たとえば、上記のキャンセルの経理処理などは、どうやったらいいか、よくわかんなかったりする。
（売上返品に相当するんだけど、売上返品という科目を設ける場合と、売上の逆仕訳の場合がある。また、現金をもらう前か後かで、またかわる）
　で、そういうときは、その業界のやりかたの通論があるかないかしらべる。とくに、パッケージがあれば、それをしらべる。そして、今回、その通論どおりでいけるか（あるいは、パッケージを使ってやれるか）、しらべる。
　通論どおりいけない場合、
　　　　それが、営業の競争上、有利になる点であれば、その部分のカスタマイズ（新規作成）
　　　　そうじゃなきゃ、通論やパッケージに、業務をあわせる
　という形になると思う。

---

　なので、OOAもDOAも、パッケージも、みんな、必要。
　とくに（パッケージがなくても）、これが、この業界の標準的なやり方という通論は必要だと思う。
　ただし、かならずしもその通論や、パッケージにあわせるわけはない。
　自分たちと、標準との違いを知るために必要。