無茶なことをいうユーザーが増えた理由？

周りが使っているから…、7割以上が「理解していない IT 用語使う」
という記事があるそうです（ここ)

　えー、これを元に考えるとですよ、
　部下が言っている言葉、上司はわかんないけど、適当に使っている。。。っていうことも、ありえるわけですな。あぶないあぶない。。。

　さらにいうと、
　ユーザーはわかんないけど、適当にＩＴ用語を使って、仕様を出している。。。
　かも知れないですね。７割の人が、理解しないＩＴ用語を使ってるんだから。。。

　どーりで、無茶なことや、おかしなこと、ありえないことを言うユーザーが増えたわけだ。。。

　でも、その無茶なことを言っているユーザーも意味わかんないで言葉を使っていて、それに対して答えるエラーい人も、意味わかんないで使ってたら。。。どーなるんだ（＾＾；）

失敗させないと、自分の言っていることのおかしさが、気がつかれないこともある。。

　あることをしたい！と部下なり、上司なり言い出したとします。
　明らかに失敗することがわかっています
　（ただし、失敗しても会社的に致命傷でない。フォロー可能）。
　あなたは、どおしますか（むかしの桜田淳子風に。。意味通じないって）

・反対する
・やらせる（失敗させて、自分で経験させて気づかせる）
　→自分は、失敗した場合どうなるということを計算し、フォローの体制に回る。

　これに関してなんですが、中国の場合、注意！と教わったことがあります。

　日本なら、上司が言った場合は後者、部下が言った場合は前者が多い（いや、今は、部下がいっても後者なのかなあ）だと思います。でも、中国の場合、基本的に後者だと、何かの本に書いてあったか、誰かから聞いた気がします。実際、一緒に仕事してて、そう思いました。

　中国のような「面子」（めんつ）のある文化において、ある人がやりたいといったことを、ほかの人がとめることは、失礼にあたります（と聞いた気がする。ただし、下の人間に対し反対するのはもちろんＯＫ）。

　この場合、やらせてみて、気づかせるのが一番で、ほかの人は、その失敗したあとに、どうフォローするかが問題になります（中国において、たとえ、一度決まったことでも、問題が起これば、その決まったことが覆る。なので、先読みしていないと、自分が悪者になり、悲惨な結果になる）。

---

　で、これって、実は中国に限らず、最近は、部下でも、上司でも、ユーザーでも、「あきらかに失敗するぞ」、と思っても、やりたいといった場合、失敗するダメージが（会社＆その言った本人が）甘受できる範囲であれば、やらせるような文化になってきたと思います。

　でないと、フリーソフトとか、新しい開発方法論とか、怖くて使わないと思いますよ。

　使って失敗させないと、一生言ってますからね、「それを使えばうまくいったのに」って。。。

　でね、世の中で怖いのは、それで失敗すると、すぐにフォローの体制に入るんだけど、そのときには、やりたいといって失敗した人は、一切無視されること。。そして、新しい時代（体制）に切り替わる。

　そういった意味で、現在の開発方法論の怖さは、その瀬戸際までいっているのかもしれない。。
（意味わかんないこといってますよね。たぶん。。。）

一般的に使う属性値の話題（注文を一意にする、消費税、イベントＩＤ、受注に単価を入れるか、とか）

　今日は、以前のブログで


　標準的な属性の分析に入る。この属性にも、通論がある。
　その通論は、覚えていたら今度。。


と書いたけど、その、属性の通論についての話

---

（１）イベント系のエンティティには、年月日、時間が入る
　エンティティは、モノをあらわす、リソース系と、出来事をあらわすイベント系の２種類ある。
　ちなみに、リソース系のものは、属性値と、イベント系のものは、メソッドと区別がつきにくいときがある。

　で、そのうち、イベント系のものには、たいてい年月日や時間などが属性として入る。
　（これが入れられないものは、リソースである可能性が高い）

　年月日が入っていない場合は、管理する必要がないか、あるプロセスを見落としている場合が多い。
（たとえば、レストラン等の注文伝票に、注文年月日がないが、これは、その日の終わりに集計し、伝票をまとめた上に、日付を書いたり、紙を入れたりして、税理士事務所に渡すから。日付をそれぞれの伝票に入れる必要がないので、省略している。このとき、集計プロセスが見落としていることが多い）

（２）イベントが多数ある場合、
　イベントの順序が明確であれば、
　　　　後からおきるイベントに、前者のイベントのＩＤが入るか
　　　　一連の取引をまとめたエンティティを作成し（作業指示書に相当する）、
　　　　　　そこに行うイベントのＩＤが入る。
　イベントの順序が明確でない、多数のイベントが平行して行われる場合などは、
　　　　作業指示書を作るほうで行う。

（３）注文主を一意にするためのＩＤ
よく使われるのが、
　電話番号＋氏名（よくＰＯＳレジで電話番号を聞かれるのは、このためが多い）
　生年月日＋氏名（または生年月日＋電話番号）
　したがって、この属性は、顧客データに入ることが多い。

　ただし、かならずしも、一意にならない。また、電話番号は、変わることが多い
　住所は、通販でないと、カードを発行しない限り、あつめにくい

（４）消費税は、
計算で求めている場合、
　　・免税関係がない
　　・介護関係をやっていない
と思ったほうがいい。

逆に、これらをやっている場合は、単純に計算では求まらない。
消費税区分を、商品側等、データの中に持つ必要がある。
（上記のものは、消費税は払わない。
　これ以外も、葬儀・土地・賃貸住宅・学校関係などあり。
　なお、消費税を払わない状況には、０％課税と非課税がある。
　会計システムの場合は、区別が必要になるが、ほかは、区別はしないと思う）

（５）金額について
　商品に金額をもつが、これは現在値をあらわす。

　受注、発注に、この商品の金額を持つかどうかは、
　　もし、商品の金額が値上がりしたら、この伝票の数字が変わって、いいか
　　（売り上げとか、仕入れ金額が、かわっていいか？）
　　と考える。
　たいてい変わってはいけないので、受注、発注にも、当時の時価としての単価をもつ。

　ただし、商品名に関しては、「伝票の再発行以外は」変わっても、かわらなくても
いい場合が多いので、商品名は、除く場合が多い。
→伝票の再発行は、伝票をシーケンシャルファイルに落として、そのファイルを読みこんで再発行するという手もある。

　消費税に関しては、消費税の「非課税のもの」が変わると困るのだが、実際、この法律、ここはいじられないことが多い（税率は変わったし、今後も変わるかもしれない）。
　ただし、それは、「いままでの話」今後はわからない。
　なので、消費税も、受注、発注に入ったほうがいいのかもしれない。

（６）商品カテゴリについて
　商品は、集計上、カテゴリを持つことが多い。そしてこれを利用して、ＩＤにしたりする。
　ただし、このカテゴリは、ヒアリングを行う前に、事前に調べておいたほうがいい。
　ヒアリングは、昨日のブログで言う（２）の業務分析にあたり、それ以前に、提供する商品などは先に決まっている。そのため、業務担当者に聞くと、自分の担当分しか答えられず、体系がみえないことがある。
　商品カテゴリなどは、たいていわかる資料や、メニューなどがある。
（まったくないと、お客さんが、買えないので、たいていなにかある。）

---

ちょっと思いついたのは、こんなかんじ。
またなにか、思いついたら、続けるかも（思いつかないかもしんないけど）