コンピューターの使い勝手に対する、経営層と現場の考え方の違い

　現場の人間に、コンピューターの使い勝手を聞くと、そりゃーよくしたほうがいいと答えるのが多い。しかし、経営陣にそれを言うと、「馬鹿かお前！」といわれることがある。

　これは（守秘義務があるので、話をぼやかして書くんで、わかりにくいかもしんないけど）ある会社でのお話。

　ユーザーインターフェースをよくして、仕事の効率が明らかに上がるというシステム開発案件があった。営業が、社長に売り込みに言ったんだけど。。。

社長：「それで、売り上げは、いくら上がるの？」
営業：「いや、売り上げは上がらないですけど、作業効率が上がり、その分、コスト削減になります」
社長：「ばかか？おまえ？？コスト削減してどうする！売り上げなんだよ、会社ってもんは！
　社員が、効率が上がるだって。。そんなことに文句を言う社員なんか、くび切っちゃえばいいだけじゃんか？そんなことに文句言う社員なんて、いらねーよ。それと、開発費比べたら、残業させたほうが安いじゃねーか。おい、そもそも、仕事なくったって、開発費っていうのは払うんだろ！」

　とかいわれ（もちろん、この社長の言葉は、穏やかに書いています。実際には、もっと口汚い言葉で、営業は、ののしられ、それを実演した営業をみて、ウィリアムのいたずらは、笑うに笑えず。。でも笑った＾＾；）、結局、開発は、お流れになったことがあります。

　まあ、経営陣から見れば、現場が効率化といっても、それが、コストカットに結びつかない場合、開発費をかける意味がないし、さらに、仕事量が少ない会社の場合、コストカットも意味ないわけです。売り上げ上げないとね。借り入れも、現実的にできないし。。。（＝借り入れ起こせないから、開発もできない）

　そういう意味で、この記事をみると、現場の課長さんレベルくらいで話しまとめてるんで、眉唾かなあっておもってしまったりする。

　ＵＩなどは、明らかに過剰品質という領域があるわけです。経営者から見ると。だけど、現場や開発者は、永遠にその品質をもとめてしまう。なので、今、どうなっているかというのを、書いてくれたほうが面白かったんだけど、そういう記事は、日経ＩＴプロの記事には、ふさわしくないっていうことなんでしょうな。

　ちなみに、どこで止めるのがいいかというと、情報化投資は、卸なんかだと、売り上げの１％程度（先生によっては、２％でもっていう話をきいた気がするなあ）っていうことだよね（利益で行くと、パーセントは決まらない。つまりね、開発を借り入れでやってるって言うことなんだけど。。。）

　そうすると、そのラインに抑えるための現在構築するシステムの範囲と金額がきまるよね。

　そうすると、その金額でできるＵＩって、決まってきちゃうでしょ。
　なぜって、たとえば、この金額ならＷｅｂで、フォームをつかって。。ほらね、きまるでしょ
　この金額ならＶＢで、って言ったらユーザーフォームを使うから。。ほらね、きまるでしょ
　この金額で、この場合、Ｊａｖａのアプリケーションで。。たしかにＡＷＴかＳＷＩＮＧかＳＷＴかの違いがあっても。。だいたいきまるよねえ。。

　それ以上は、ＵＩを変えて、売り上げがあがるという相関がないかぎり、過剰品質になるよねえ。。
　つーことは、そこで決まったＵＩを、さらに細かく、ガイドラインを作ればいいっていうだけの話になるんだよね。たぶん、上から見ると。。

　でも、これを、大手は理解していないということは（＾＾；）

　大手が、現場と技術者の暴走により、情報化コストを余計にかける危険性がありっていうことで、

　ここに、大手をつぶす商機（勝機）あり！つーことなわけかもかも？（ちがうとおもうよ　＾＾；）

ある程度の規模の開発だとアジャイルが使えるのはF/SとAMS、他はウォーターフォールになると思う

　ちょっと、アジャイルとウォーターフォールの関係みたいな話がこんなとことか、こんなとこにでていたので、まあ、自分がかかわった関係での、独断と偏見をひとつ。
（あんまり、書くネタもないので）

---

　ある程度の規模の（たとえば、総合電気大手５社＋ＩＢＭのうち、１ないし２社が一次請けで、３次、４次（それ以上）請けまであるような）プロジェクトの場合、アジャイルっぽい開発が出てくる部分は、はじめのフィージビリティスタディの部分（ここでプロトを作ったりするけど）と、開発終了後の拡張部分だと思う。それ以外を、アジャイルでやりたくなったら、そのプロジェクト、はっきりいって、やばいと思う。その規模になると、もともとの仕様は、そんなに動かないはず！


　開発終了後の拡張は、ＡＭＳ（アプリケーション・マネジメント・サービス。開発後の保守、拡張などを、一括で支援する形のもの。詳しくはここ）なんかの形で、一括して担当すれば、その期間に応じて、お金がもらえるので、とりっぱぐれない。なんで、結構、毎日チョコチョコ（プログラムを）動かせると思う（ただ、そうやって拡張すると、プログラム自体汚くなるけどね）

　Ｆ／Ｓ（フィージビリティスタディ）のところでは、開発実現性を確認し、フレームワークをきめて、どーいうパターンにするかを決めるので、この部分は、ある程度、トライ＆エラーになると思う。なので、アジャイルのほうが、いいかも。

　でも、他の部分、アジャイルで、開発しなければいけないとすると、やばくない？？
　（アジャイルのツールを使うのは、もちＯＫ！だけど）

　だって、他の部分って、

　帳票出力、電文入出力＝これって、ふつう業界で決まってたり、法律で決まってるでしょ。
　　　　　　　　　　　　そんなもん、変化ないっすよ。

　モデル部分＝代えないほうがいい。
　たとえば、証券において、追証（「おいしょう」と呼んでね）関係の計算とかは、公式は変わんないでしょ。出金余力、建余力の求め方、約定（やくじょう）後のプロセスとかも。なんで、一度書いたコードが、間違いないなら、変えないほうが、デグレードしないので、いい。
　もちろん、トレーディングルールなんかは、変わる。でも、そこは、あらかじめ変わることを予期して、抽象的につくり、パラメータ変化で対応できるようにしておかないと、大変。

　流通など、ほかのものでも、動く部分は、たしかにある。しかし、それはハードコーディングしないように、設計する。ハードコーディングしてしまい、「だからアジャイルで」といいだしたら、それはやばい（アーキのミスは、開発方法論で解決できるもんじゃない）。

　画面表示部分＝たしかに変えられるけど、変えないほうがいい
　というのは、はじめに、画面のガイドラインを決めてしまい、ツールを使ってしまうと、そんなにかわらないはず。もし、変わるとしたら、入出力がまちがい＝インターフェースかエンティティの間違い＝かるくやばい！

　っていうことで、アジャイルでやりたくても、普通は仕様がそんなに動かない上、やり方は、Ｆ／Ｓのときに決めているので、変わんないはず。

　で、この部分を、アジャイルでやりたくなるくらい、仕様がころころ変わるとしたら、それは、

・インターフェースの切り方に失敗している
・仕様が正しく聞き出せていない
・Ｆ／Ｓのときに無茶なやり方を基準にしてしまった

　なんていうことになる。こうなると、デスマーチのパターン。
　この場合、結合テスト１（ＩＴ１、プログラム間のインターフェーステスト）で破綻する。
　こうなったら、人を投入しても収束しない。

---

　ちなみに、ここで、この理屈がわからないと、ＩＴ１で出るバグを、単体レベルと勘違いする（というか、単体とＩＴ１の境界線が、わかってない）。ＩＴ１でバグが出た場合、プログラム修正は、単体レベルよりはるかに困難（同期をとらないといけないのと、一度できたプログラムに修正を入れるため、ロジックがぐちゃぐちゃになる。なお、そういう場合は、捨てればいいと思っているそこのあなた。だめなんですねーこれが。一度捨てても、またぐちゃぐちゃになるから）。

　ただし、Ｆ／Ｓも、別にウォーターフォールでやれないこともないんだけどね。。。

　ただ、どっちにしろ、いえることは、Ｆ／Ｓに、優秀な人間を投入しないと、あとは、一直線に流さざる「を得ない」ので（考えながらやるというものではない。仕様の変更があるようなら、それはたいていミス）、下流工程で混乱する。

　その混乱は、たいていＩＴ１で出るので、（もっと、おばかなグループのあつまりだと、ＩＴ２でやっと気づいたりする。ＳＴで気づいた場合、救えない）、大幅な工数（というか、コミュニケーション）を必要とし、そこに新たに人を投入しても収束しない。

　なんていうくらい大切なのに、現実には、Ｆ／Ｓっていう工程がなかったり（はじめ、てきとーにＦ／Ｓっぽいことをやる。工程名にＦ／Ｓが、最近は、ない。プロトを作ればいいほう）、そこの工程に、へなちょこな人を投入したりする（そして、見当違いなプロトを作る）のよねー

---

あと、そんなことは知っていて、はじめから、失敗することを覚悟で、投入する場合と、契約の話とかで、お金の回収のからみがあるんだけど。。。

ま、気が向いたら（つーか、書くネタがなかったときに）ね。　

勉強会の参加のさせかたの妙案なのかあ？

昨日（日付的には今日）の深夜、「ご近所の底力」というＮＨＫの番組の再放送をみました。
防災訓練に参加してもらえないとき、参加してもらうには、どうしたらいいか。。
の妙案をやってました。

ひとつの例は、炊き出しの訓練として、ご飯を振舞う。
もうひとつは、子供を使う、チラシを配って、特技のある人を集める、スカウトする

だそうです。

---

これを、ソフトハウスの勉強会に応用すると

（１）勉強会の終わりに飲み会をする。
　→勉強会をかねて飲み会にしてしまうと、勉強会にならない気がする（＾＾；）

（２）（子供じゃなく）上司に参加させる
　→逆効果かも（＾＾；）

（３）特技を報告させ、それをネタに勉強会をする
→って言うのは多いけど、逆に、特技に「したいもの、とりたい資格など」を報告させ、それと実務との関係を勉強会ネタにするっていう手もあると思う。

　たとえば、情報処理試験のプロジェクトマネージャーの勉強会なら、数年前の午後１の問題に出た「変更仕様書を書かないで、変更するとどういう問題が起こるか」（コストがわからない、ユーザーから見ると、サボってるように見える）から、スクラムの問題を探るとか
（変更仕様書を製品責任者が書くことになるが、そんなにすぐに見積もれない。やってみるとわかる。そこでパッケージソフト会社では。。。っていうことは、書かないぴょーん（守秘義務だよね、たぶん））。

　。。。だめだ。。教える側に、相当な知識が必要で、勉強が進まない（＾＾；）

　データベーススペシャリストやアプリケーションエンジニアと、実際の流通業の業務なら、比較的簡単にできるかも？？

（４）社内で（いや、もちろん社外でもＯＫ）きれいな、女の子をスカウトし、勉強会に参加してもらう

---

やっぱ、（１）か、（４）、両方の合わせ技ですよね！！

（半分以上冗談なので、本気にしないでね！）

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

　今日は、以前のブログで


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


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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

ケータイが、なぜ、組み込みに分類されるか、わかるような気がする例

　組み込みなんかの調査をみると、ケータイがふくまれていることがあった気がします。
　今まで、「なんで、ケータイが組み込みなんだ？」と思ってたけど、こんなことがあって、たしかに、そんな気もした。。テストなんかは、組み込みっぽい感じになるのかも？

---

　ある会社のカメラは、非常に短時間に、カメラのインスタンスを生成、リリース、生成、リリースとくりかえすと、ちゃんとリリースしているのに、メモリフルのエラーになります。

　このとき、リリースしたあとで、タイマーをかけて、500ミリ秒とか、１秒とか待ってから生成すると、うまくいきます。

　つまり、カメラのコプロセッサと、本体のほうの、同期がとれてなくて、リリース命令をかけた時点では、完全にコプロセッサのほうが開放できていないから、そのあと、生成命令が来ると、メモリーフルになっちゃうんじゃないかなあ？？

---

　こんなのを見ると、組み込みのテストのときみたいな、タイミングの調整をするかんじのテストになりますよね。

　業務アプリなんかだと、境界値チェックということで、境界値ぴったりで、エラーになるかどうかってやるけど、組み込みのようなやつで、センサーと処理部分が分かれているとき、センサーに、境界値ぴったりの時間で、信号が入ってくると（タイマーで２０秒というとき２０秒ぴったしみたいな）センサーのほうでは感知するんだけど、アプリのほうでは、時間内に検知できなかったものとして、動作してしまうみたいな。

　そうなると、矛盾が起こらないように適当じゃない、適切に調整するけど、そんなかんじっす。
　ケータイのカメラの場合も（ただし、あるメーカーの場合。ほかのメーカーはＯＫ）

　うーん、そんなところが、ケータイも組み込みなのかな？

ＮＨＫが語学講座をネットラジオで放送すれば、ポッドキャスティング広まると思うが、問題は必要性

周りが使っているから…、7割以上が「理解していない IT 用語使う」
　という記事がありました（ここ）
　ここの中で、ポッドキャスティングがでてくるんですけど、私もいまひとつわからない。。。
　そもそも、ネットラジオで聞きたいものがない。
　だから、ポッドキャスティングをしない。
　なので、意味もわからない。。

そんなノリだとおもうんですよ。少なくともウィリアムのいたずらは、そうだ

---

　でも、ＮＨＫラジオの英会話入門・中級・上級などがネットラジオになって、ポットキャスティングできたら、話は別です。

　ラジオをＩＣレコーダーに入れるというものもあるんですが、ラジオって、建物の中によっては、よくはいんない。。。

　そこで、ＮＨＫが、ネットラジオに乗り出せば、べんりべんり！

　っていうことで、みんな利用すれば、意味がわからない人も減ると思うんだけどな。。。

　ただ、この場合、問題がある。

　もし、ホームページで、英会話入門・中級・上級などを、公開してしまったら、わざわざ、ネットラジオを聴く必要性がないじゃん。そっちのほうがいいじゃんっていうことになる。。。
　
　うーん。

社長さんと、従業員のビジネスモデルの考え方の違いと、ソフト開発上の対応について

　土曜日のビジネスモデル的なお話が、意外と見てる人多かったので、今日は、その前提となる、

　社長さんと、従業員のビジネスモデルの考え方の違いと、
　ソフト開発上の対応について

を書きたいと思います
（ただし、社長さん＝管理者、従業員＝作業・プログラムする人と読み替えると、この業界の常駐派遣（請負？）につながる話でもあります）。

---

まず、実は、（自分でも、最近、放送大学大学院の番組を聴いて、気づいたんだけど）ビジネスモデルには、３段階あります。

（１）事業計画書などに書くような、何を売って、お金をどうやって、いつもらうというモデル
　　　→モノ（サービス）とカネの流れ、
　　　　ホリエモンみたいな人や買収話で出てくるところ。

（２）その事業を実現するために、誰が、なにをやるかという、業務モデル
　　　→ここで、ヒトと情報が付け加わる。
　　　　システムの業務分析は、ここ

（３）さらに、そのヒトに、いくら払ってという待遇などのインセンティブを決め、組織を作る
　　　→これ自体はビジネスモデルではない。
　　　　ただ、この部分がないと、ビジネスモデルが完成しない。

　で、社長さんなんかが決めるのは、まず、（１）の事業計画です。

　で、このあと、（２）をきめないことが多いと思います（あんまり、偉いヒトは、作業員のことなぞ、決めないというか、考えないのだよ。。）

　そこで、社長さんなどは、（３）の人集めに走ってしまいます。

　一方、一般に従業員が考え、実行するビジネスモデルっていうのは、（２）のことです。
　でも、事業のはじめに、（２）について、組み立てていないので（実は、ヒトが決まっていないので、組み立てられないということもあるが）、本当に、事業内容が、業務に落とせるかどうか、落とせたとしても、その人でできるかどうかは、わからないという状況にあります。

　逆に、既存の組織などで、（２）がしっかりしていると、同じ業種では、似通っているところも多いため、事業計画が多少変わっても、悪くても、売れてしまう（問題なくできてしまう）というところがあります。

---

　ということで、ベンチャー企業などでは、（いや、ベンチャーでなくてもそうなんだけどね）上層部が（１）をきめてから（３）にいってしまい、そこで満足しているため、（２）の業務内容はぼろぼろというところもあります。そうすると、システム開発側で、（２）の通論的な知識をもっていないと、話がゆらゆらゆれて、仕様が固まらないということがあります。

　アジャイルを好む企業は、実はこれ！なんていうことがあります。

　事業内容を組み替えても、必ずしもシステムを組み替えないといけないわけではなく、また、事業の詳細なコンポーネントは、不変なことが多いわけです（じゃないと、商奉行とか、弥生販売とか、成立しなくなってしまう）。だけど、（２）の部分が決まってないと、ゆれます。そうすると、仕様変更が頻繁に起こってしまいます。よくいう、「うち独自のやりかた」というのはなんてことはない「うち独自のごまかしかた」というケース（ただし、ごまかすとはいわれず、臨機応変に処理するとか、柔軟に処理するといわれる）

　ちなみに、じゃあ、開発では、（１）については、出てくるのかというと、出てきます。
　その店の商品構成とか、販売方法（支払い方法）などがそれにあたります。
　ヒアリングの中心は、（２）を聞くことですから、（１）に関しては、ヒアリング前に資料をもらって、調べておく必要があります（商品カタログと、帳票から調べられる）。

　そして、この内容は、用語集に載ります。

　なんとなく、とりとめのないはなしになってしまいました（＞＿＜！）
　なんで、とりあえず、ここまで。
　

中小企業診断士の実務更新の変更について

　コンピューターの話とは、直接関係ないかも知んないけど、まあ、むかし、情報という区分があったということで、コンピューター関係ということで、中小企業診断士の話をひとつ。

　中小企業診断士、持ってる人は、わかると思いますが、来年から、更新条件が、こんなふうにかわります。
・実務更新研修がなくなり、実務のコンサルティングをやらないと、実務のポイントにならない
　→理論は、同じ
・その更新ポイントが、現在の９ポイントから、３０ポイントに変わる
　→１年６ポイント、つまり、１週間実務につかないと、いけない計算になる

で、具体的に、更新できるのか？ということに関して、診断協会からのアンケート用紙の中に入っていました。でも、今、診断士でなく、診断士の資格を取ろうと思っている人は、見れないわけよね。。ということで、ウィリアムのいたずらが、要点をまとめて書いてあげよう！！

---

　企業内診断士の場合、自分の企業が中小企業であれば、自分の企業のコンサルティング、さらに取引先などの企業が中小企業であれば、その中小企業のコンサルティングも、得点になります（無償のコンサルティングでもＯＫ）。

　つまりですね、中小企業のソフトハウスなどで、診断士をとることを推奨している会社ならば、「診断士の資格更新に、会社に文句を言うことが必要なんですよお」（うそ、コンサルティングが必要なだけ　＾＾；）といって、コンサルティングさせてもらい、それで、雇用責任者（＝社長？）の印鑑をもらえれば、それでＯＫ。
　もちろん、自分の会社じゃなく、ほかの会社でもＯＫ

---

　でも、ウィリアムのいたずらみたいに、企業に属していない、フリーの場合、診断協会が提供する、診断実務提供サービスを利用するしかない（まだ、検討中みたいで、はっきりしないけど）
　その内容は、アンケートに入っていた別添の紙の３ページ目に書いてあるけど、こんなかんじらしい。。。

１．テーマ別実務実習
　週末や、夜間を利用して診断をする
　昔（数年前、新制度になってなくなった）、更新研修を、実際にコンサルして、取得するっていう方法があったとき、診断協会がやってたやつみたいなのだとおもう。
　あれって、週末を主に利用する形だったとおもうけど、それだとおもう。

２．集中実務従事
　１．のやつは、週末だったけど、いっぺんにまとめて１週間！ってかんじ。
　３次実習（って、今言わないのかなあ？？）の１週間分みたいなかんじ？

３．窓口相談
　よんで字のごとく、説明不用。。。じゃないか、診断士でない人は、わかんないよね。
　自治体とか、商工会に、相談窓口があるので、その相談窓口にいて、相談を受ける。
　ただね、問題は「相談補助者からは、参加料を徴収！」お金とられるのよ。。。？？
　（もちろん、相談する、中小企業の人は、ただ）

４．グループ診断実務従事
　研究会とかが中心となってやるみたいなんだけど。。。
　ウィリアムのいたずらは、よく知らないんだけど、研究会によっては、こういう話、持ち上がってるとかっていうことを、ちょっと、この前の（今回最後の）実務研修のとき、ある人からきいた。

５．診断パートナー
　よくわかんないや（＾＾；）

６．診断、助言の斡旋
　実際に診断する。協会は、そのあっせんをしてくれる

---

　つーことで、この制度、企業内診断士つぶしになるんじゃないか？っていう話もあったけど、むしろ、企業にいる人にとっては、有利なんじゃないかなあ。。。
　会社にもちかけて、自分の会社や、取引先の診断ができるようになるかもしんないし。。

　そうすれば、自分の不満も正々堂々と？？会社にいえて、資格も維持できる。。。

　おー、いいかもしんないよ！！

　それに対して、ウィリアムのいたずらのような、フリーの人間は、完全に不利。
　診断協会のサービスを受けないといけないけど、東京とか、さばききれるのか？
　あと、全部費用がかかるみたいだけど、いくらなのか。。はらえる金額なのか？？
　土日にしろ、夜にしろ、完全につぶれるわけだから（って、それだけではもちろんすまないわけだけど。。）
　平日の７日間は、たぶんきついよねー。３次実習と同じでしょ。。。

（診断士の資格を持って「いない」人に。。。
　１週間で、報告書を仕上げる場合、結構たいへん。昼間の時間は打ち合わせにとられるので、その打ち合わせが終わってから報告書を書くことになる。
　ただし、大変とはいっても、ウィリアムのいたずらの３次実習の場合、会社で、１０時とか、１２時とかまでの残業をしていたり、お持ち帰り残業をしている程度の大変さくらいでした。
　大手のユーザーで、ソフト開発だと、夜中の３時とか、４時くらいに、監視してる人３人、作業しているのが１人で、朝の６時までに仕上げないといけない。仕上げたら、タクシーで、その監視してる人が客先に持って行き、客先で怒られるといった、大手では常識的にある光景にくらべたら、３次実習は、楽でしたよ）

　下手すると、更新しないで、５年ごとに試験受けなおしたほうが、安上がりだったりして。。

　うーん、ウィリアムのいたずらは、更新できるのだろうか？

　最近は、更新できなかったら、まずいので、中小企業診断士であるとは、ほかの人には、言わないようにしていたりする。。。更新できなかったら、名乗れないので。。。

個人情報保護士に、情報セキュリティ検定、テクニカルエンジニア（情報セキュリティ）試験

　情報セキュリティ関係の試験について、いろいろ見つけたので、まとめ。

個人情報保護士に、情報セキュリティ検定については、ここ

情報処理試験の『テクニカルエンジニア（情報セキュリティ）試験』はここ

小売業や、サービス業における、標準的（通論的）なエンティティと分析方法のまとめ

　ちょっと前のブログで、ER図を書くのに、通論をおさえておき、帳票などを見て、その通論にあるものないものをチェックして、それを付け足すと早いと書いた。

　その通論を導くのに、統一伝票って書いたけど、普通の人はやってられないと思う。ので、こんなかんじ！っていうのを、こっそり書いてみた。

　教科書ガイド的なもんなんで、こっそり見てね！

---

　小売など、消費者に対して、製品やサービスを提供する（いわゆる、ビジネス　とう　こんしゅーまーのBtoC）の場合、正規系の大きなイベントは、以下の３つ。

　　（１）注文（受注）
　　（２）受け渡し
　　（３）支払い

　なお、イベントとは、２つの判別法がある。
　　　１つは、はぶさんの書かれていた、「～する」といえるもの
　　　　（例：受注する、注文する、支払いする（支払う））、
　　　もうひとつは、佐藤正美（男性です）氏の方法で、「日時の属性をもてるもの」
　　　　（例：受注日、注文日、支払日OK）
　この２つは、たいてい一致する
　（一致しないものもある。　例：お茶　お茶する○　お茶日X：言葉があいまいだから）

　このほかに、細かいイベントとして、請求書発行などがあるが、はじめは、正規系だけで考え、ほかに必要なイベントが出てきたら、付け加える。

　異常系として、キャンセル／返品（返金）処理があるが、これは、正規系が決まらないとできないので、今回のせつめいからは、のぞく

---

　各イベントに対し、お店側の人間と、客側の人間がいる。したがって、エンティティは、

　　　　　受注者 -- 注文 --　発注者

　　　　　送り主 -- 受け渡し -- 受取人

　　　　　支払先 --- 支払い -- 支払い者

　と、そのイベントで取引される「モノ＝商品」と、それに対応する「おかね」となるはずだが、

　ここで、エンティティをまとめる際

　　（１）同一人物（同一カテゴリ）の場合、わざわざ、わけなくていい
　　（２）１対１で行われるイベントに対して（特に同時に行われるような一連の処理）、
　　　　　わざわざ、エンティティをわけなくてもよい。

　という特徴（傾向？サボり方）がある。

　また、匿名なものの場合や明らかに自明な情報は、システムに入ってこない。
　　　　その場合もエンティティがかかれないことがある。
　さらに、そのシステムにおいて、関心のないエンティティ（お金とか）は、かかれない。

この性質を使うと、実際には、以下のようになる。

---

＜＜飲食店や、お店の物売り＞＞

　注文と受け渡し、支払いが同時に行われる。
　したがって、分析結果が注文だけという形で書かれるケースもある。
　→この場合、エンティティ名は、「販売」のほうが、いいかもしれない。

　同時に行われない場合、エンティティを分けるケースもあるが、分けないで、注文エンティティの中にかかれることもある（お弁当の指定時刻受け渡しの場合、注文エンティティの中に指定時間とかかれることもある）。

　顧客に関しては、（ラーメン屋さんで、自分の名前を名乗らないように）匿名である場合がある（というか多い）この場合、顧客のエンティティを書かなくっても、問題はない。
　お店に関しては、自明なので、エンティティを書かないケースも多いが、（注文を受けた、受け渡した）担当者を記入することもある（レジなど）。

　たいていのケースは、
　　　　顧客＝発注者＝受取人＝支払い者であり、
　　　　お店＝受注者＝送り主＝支払い先である。
　そのため、エンティティは、お店と、顧客しか出てこない
　さらに、顧客が匿名の場合、顧客エンティティが、お店が自明な場合は、お店エンティティがかかれないこともある。その一方。受け渡しに関し、お店側の従業員名や、レジ番号が書かれることがある。

　これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。

　　　　お　み　せ　　　　　－　　販売（注文）　　－　　　　　　　お客　
　　　　｜　　　｜　　　　　　　　　　｜
　　　従業員　　レジ　　　　注文明細（＝注文ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　商　品

・レジのかわりに、飲食店だと、テーブルになったりする（テーブル番号）
・商品は、さらに、いろんなエンティティがつく
・商品の代わりにお金をうけとるわけだが、お金をエンティティとすることは少なく、その情報は、販売（注文）の中に入る。

---

　
＜＜通販／ECサイトなど＞＞

　注文、受け渡し、支払いがわかれるが、実際には、注文書の中に、受取人が違う場合の、受取人の場所を書かせたり、支払い方法を書いたりするので、販売というエンティティで１つにまとめてもかまわない。ただし、商品の分納や、支払いの分割を認めている場合には、エンティティを分けたほうが無難。

　注文の場合は、お店なので、省略されることもある。
　顧客が省略される可能性はかなり低い（届け先がわからない）。
　受取人は、省略されることもある。支払人は、省略されるケースとされないケースがある。
　（口座名義人の話とか、会社が支払うケースとか）

　支払い方法によっては、お店と、支払先が異なるので（支払先は、銀行とか）これが分かれることがあるが、送り主は、お客に明示しない（佐川か、ヤマトかセイノーか、いわないこともおおい）ので、エンティティとして出現しないことが多いとおもう。
　これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。

　　　　お　み　せ　　　　　－　　販売（注文）　　－　　　　　　　お客　
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　注文明細（＝注文ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　商　品
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　納品明細（＝納品ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　納品（受け渡し）　－　　　　　（送付先）


　　　　支払先 －　　　　　　支払　　　－　　　（支払う人）　　　　

　なお、支払先は、クレジットカード会社、銀行などに分かれる場合もある。
　注文と受け渡し（納品）商品がまったく同じの場合には、納品明細はないが、分納の場合は、かならず（といっていいかな）ある。
　支払う人、送付先は、お客と同じビジネスモデルの場合は、これらのエンティティはあらわれない。

　納品（受け渡し）と、支払は、本来、販売にリレーションがひかれるが、絵の都合で引けなかったので、ひいてあるとおもってください。

---

　　

＜＜その他：一般的な考え方＞＞

一般的には、つぎのように考えていく

（１）イベントについて：
　　注文、受け渡し、支払いが、同時に起こる、もしくは一連のながれであり、
　　１対１に対応されるか？
　　→１対１なら、１つのエンティティでもかまわない。
　　　１対１でなければ、分けたほうが無難

（２）各イベントに対する登場人物に関して：
　　お店側の人間と、客側の人間にわかれる。
　　このとき、おなじ人は、省略可能。

（３）イベントにおいて、その登場人物間を介してやり取りされるもの：
　　ふつう、お金と商品、サービスだが、お金は省略される（金額以外の情報はあまり必要でないから）、ただし、これが商品券、チケットの場合は、そのエンティティは生成されることもある。
　商品のリソースと、注文のイベントを結びつけるため、商品ー注文対応表としての注文明細が発生する。
　なお、受け渡しと注文を沸けた場合、受け渡しー商品対応表としての、納品物明細が発生することもある。納品物明細と、注文明細は、かならずしも同じとは限らない（分納）
　さらに支払いエンティティを分けた場合は、支払い（うけとり）金額は必要だが、商品との明細はつけないほうがいい（つけると、物と金の関係が切りにくい）

　こんなかんじで考えていき、どの標準を使うかきめて、あとは帳票から、一致するところ、しないところを確認する。しないところは、本当に必要ないのか、たまたま抜けているのかを確認する。

---

　その後、標準的な属性の分析に入る。この属性にも、通論がある。

　その通論は、覚えていたら今度。。

「最近のコンピューターやソフトは、仕様書どおりには動かない」ことを、昔の人は理解してないよね！

　昔の、ＣＯＢＯＬ時代との違いについて、もう一言付け加えると、

　　　　汎用機の時代は、マニュアルに書いてあることが、ほぼ正しかった。

　なので、動作が予測でき、ウォーターフォールでも、あまり間違いなく開発できたけど、

　最近のオープン系のソフトや端末は、

　　　　　マニュアルどおりにうごかない。

　したがって、それに対応した開発方法論にしないといけないっていうことに、
　昔の人は、気づいてなかったりしますよね。

---

　やっぱ、一番ひどいケース（と、経験上、個人的に思うのは）はＢＲＥＷで、
　　　マニュアル自体、まちがっていたり
　　　　（というのが、読んでいるだけでわかったり）、

　　　マニュアルに書いてあるのは、あるケースの端末だけで、
　　　　　ほかのケースの端末では、違う動きをしたりというか、
　　　　　リセットかかったり
　　　　　（その情報が公開されていない）

　　　で、端末ごとに、動きが違う
　　　　（それが、どこにも書いていないし、予測不能。
　　　　　思いもかけない動きをすることも。。）、

　　　その上、守秘義務があるから、それを言っていいかどうかすらわからない

　っていうのがあるよね。

　こういうケースだと、ウォーターフォールで開発できない。

　なぜなら、仕様を書いても、端末によって、その仕様を満たすような動きをさせるためのコードの書き方が違う、いや、ひどい場合、その仕様を満たすことはできなかったりする（ある端末において、その機能は、実装されていない。ということは、どこにも書いていない）。
　だから、全端末で（と言うのは無理なので、ある程度の端末で）動くかどうかを確認しながら、仕様を決めていく、っていうやり方でないと、できない。

　ここまでひどくはないけれど、オープン系のソフトは、こんなかんじのケースがある。

　なので、ＴＤＤやアジャイルなどの開発方法でしか、「できない」のだけど、この現実を、昔の人は、知らないというよりも、言っても、想像つかなかったりする。
　　　　

アジャイル的方法で、引越し中だったりする

　なんか、アジャイルと引越しの話題？？を書いてあるブログがあるようで（ここ、そういう意味じゃない！！って、みんなからツッコミをいれられそうだけど）、ここの、


３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。


の豪邸ではないけど、ウィリアムのいたずらが、似たような状況なんで、今日は、その、ショーもない失敗談を、報告しちゃいます！（ただし、失敗談までは行かない）

---

ウィリアムのいたずらのケースは、


１個の部屋があるへなちょこ借家を考える。この借家から、６ヵ月間に引越しをするように言われた。全部屋（＝１個）を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、６ヵ月というデッドラインを守れるか。


で、ウォーターフォール的な方法では、やれません。
理由＝見積もれない
　　　→部屋にどれだけのものがあるかを把握できない
　　　　：１部屋しかないのに。。。というツッコミは入れないこと。


ということで、そこに書かれている、「1個流し的（アジャイル的）計画」みたいなやり方でやる。。。

つまり、こんなかんじ。


１．日割りで、すこしづつ、掃除、分類、箱詰め、して、引越し先に送る
　　→電車を使って
２．６ヶ月後には全部屋（＝１部屋）の箱詰めが終わる

---

　でも、ここのブログの大きな特徴は、「箱詰め、チェックまで終える」と書いてあることと、「豪邸」にしていることだ（３０個の「倉庫」ではない）。
　決して、引越しの荷物を運んでいないところが、おおきなミソだ！

　これを、荷物を運んでしまうと、ウィリアムのいたずらみたいに、お馬鹿な結果になる。。。
（引っ越す前に、そのことを、みんなから指摘されたが、こんなに大変だとは思わなかった　＞＿＜！）

　その失敗談については、今、時間がないので、またこんど。

オブジェクト指向で考えたときと、昔ながらの方法でやったとき、差が出たらどうする（その２）

さっきのブログの続き。
（あと、言い忘れたけど、この話は、昨日のブログの２つ目の話のこと）

帳票から、項目を切り出し、ＥＲ図を作る方法について
（１）入出力項目の切り出し、
（２）第一正規形
（３）第二正規形
までもってきたので、今度、（４）第三正規形にします。

---

（４）（第三正規形）計算項目で求まる場合は、はずしてもいい。
　第三正規形までやる場合は、計算すれば求まる項目、ほかのテーブルの値を参照すれば、求まるようなものは、項目からはずします。でも、それって時間かかるという場合、正規化をしないこともあるけど（っていうと、佐藤さんの流派の人からは、怒られそうだけど）
　それと、計算で求めるべきものは、その項目に変えます。

■■　注文用紙の例では
　前の説明の場合、税込価格は、金額から「このケースでは」消費税率をかけて求められるので、はずしてもいいといえます（ＤＢに落とすとき、おそくなるからやだという場合、本質的な話でないんだけど、のこすこともある）。

　それと、Ｎｅｗマークは、たまたま、今Ｎｅｗ（新製品）なわけで、本来は、商品投入年月から、何ヶ月間の間は、Newマークをつけるという形になるので、ここは、商品投入年月のほうがいいかも

---

　ということで、今回の場合は、はぶさんの示した形と、たまたま同じになりましたけど、ぜんぜん、同じにならないケースがあります。

　そのケースは、オブジェクト指向の場合、イベントを取り出して、その後、それに対する動作対象を取り出します（このため、業務のヒアリングからでも、エンティティが切り出せます。動詞句を利用し、その動作対象を見極めればよい訳ですから）

　ところが、帳票から、上記の方法によって切り出す場合、その動作対象の情報が、
　　（１）入手不可能または、入手する必要がない、
　　（２）自明の場合
　には、帳票に書かれなかったり、あたかも印刷の固定項目のように書かれたりします。

---

　たとえば、今回の「注文」というケースの場合、
　「お店は、顧客から商品の注文を受ける」

　というふうに、動作対象を取り出した場合、今回の例では、「お店」エンティティが抜けています。

　このお店エンティティの情報は、（消されているけど）一番下に書いてあります（印刷の固定項目のように見える）。

　また、レシートのような場合は、「顧客は、お店からレシートを受け取る」といった場合、レシートには、顧客情報はかかれていません。顧客の情報を集める必要がないからというのもあるし、もし集めようとすると（ポイントカードなど）大きなコスト負担になることもあります。

　ということで、レシートを分析してしまった場合、顧客というエンティティは、出てこない。

　で、実際、システム上、顧客というエンティティを出さなくてすむシステムもあります。
　ＤＢ上、顧客テーブルは、（ポイントカードをやってない場合）情報が収集できないので、作れないでしょう。

---

　なーんて言うかんじで、帳票分析したものと、ヒアリングなんかで、動詞から（イベントから）追っていったもので、差があることがあります。で、この差は、間違いの場合もありますが、このシステムの特殊性（販売で顧客がない＝顧客の情報は、扱わなくてもいい）のときがあります。

---

　とはいうものの、まずは、はぶさんのいうやり方でできることが大切ですよね！

　片っ端から、帳票を、ＥＲ図にして、練習だあ！！

（よい子、お勉強熱心な人、「フィジカル」という言葉がわかる人は、ここまでで、以下は読まないでくださいね！！！）

---

　なーんていって、よく練習させられるんだけど。。。？？

　オブジェクト指向の場合、結局言葉が中心なんで、恣意的になってしまうのよねえ。。
　で、現実的に、帳票分析をしたものと合わない。。。。
　そうすると、だよ、現場では、差異があった場合、偉い人や声の大きい人、権威のある人が正しいことになっちゃうよねえ。。

　その人の言っていることは、正しいとは限らない、もし間違っていたら。。。！！

　で、そこで、ここだけの話、業界の通論っていうのがあるから、それをまずおさえてしまい、その通論と、現実との差異を、項目比較によって、おさえておくほうが早いと思う。
　もし、声の大きい人の意見に収束したとしても、通論との差異を知っていれば、どこに注意すればよいかが見えてくるし。。。

　通論に関して、ＥＲ図、クラス、テーブル構造を作っておけば、あとは、その差分でできるじゃん。

　で、その通論なんだけど、普通流通では、統一伝票を使う。

　統一伝票の見本として、入手しやすいのは、前にもブログに書いたけど、eお菓子ネットの統一伝票（ここにいろいろとあるみたい）とかとか。。
これは、卸→小売間なので、小売→消費者の場合は、変形が必要だけどね。きほんはこれ。

　そのうち、こっそり、このブログで、そのＥＲ図とか、ひまができたら、しょうかいするかもお。。。　（いま、ひまじゃないからだめ）