日経コンピューター２０１３年６月号 １６ページの下の表をみて、びっくり！
インターネット上でどんな運動が出来るか
「Ｗｅｂサイトや電子メールを使った落選運動」
へ～、落選運動（この人を投票「しないでください」という運動）
もＯＫなんだ。ただし、電子メールアドレスなんかを書かないといけないらしい
（表示義務）
こりゃ～、落選運動、多くなりそうですね（＾＾）ｖ
Ｐ．Ｓ Ｌｉｎｅって、どれになるの？
日経コンピューター２０１３年６月号 １６ページの下の表をみて、びっくり！
インターネット上でどんな運動が出来るか
「Ｗｅｂサイトや電子メールを使った落選運動」
へ～、落選運動（この人を投票「しないでください」という運動）
もＯＫなんだ。ただし、電子メールアドレスなんかを書かないといけないらしい
（表示義務）
こりゃ～、落選運動、多くなりそうですね（＾＾）ｖ
Ｐ．Ｓ Ｌｉｎｅって、どれになるの？
日経ＢＰは、この前の「データ分析・活用実践講座」を、毎月やる気なのだろうか（＾＾；）
データ分析・活用実践講座＜＜演習付き＞＞
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/nc/130626-2/
これは、６万３千円、この価格だと、毎月やるほど、需要あるんだ～
だけどね・・・
第1期 ビッグデータビジネス実践イノベーター養成プログラム
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/bigdata/1304/
これは、２９８０００円（打ち間違えてないよな、弐拾九萬八千円）
そして、本なんだけど・・・
『ビッグデータ総覧2013』
http://coin.nikkeibp.co.jp/coin/itpro-s/book/dtl/bigdata2013.html
7月1日に発行予定らしい。こいつは198000円（壱拾九萬八千円）
あ～なんか、すごいことになっているう・・・
ＢｉｇＤａｔａは、教育ビジネスから、火がついた感じがしますよね！
価格から見て、３万円台とかはないので、個人的な研修ではなく＊、企業の投資ですね！
マーケティング的には、ここで想起されやすいように、ＢｉｇＤａｔａ教育のキャラクターを
つくるのが効果的なのですが、
ゆるキャラは、何十万という価格帯からして、ふさわしくない。
ＡＫＢ４８も、何十万の投資を決めるお偉いさんには、軽く見られる・・・
ということで、ここは一発、大学の先生でしょうか？女性の・・・
統数研とか、東大のシステム創生、ＴＭＩ
とか、東工大のＭＯＴとか、筑波とか？？
だけど、実は、一番向いているのは、たぶん、大江アナだと思う。
う～ん、アメリカ行っちゃったからなあ～・・・
＊注「価格から見て、３万円台とかはないので、個人的な研修ではなく」：
企業において、１人当たりの教育研修費は、だいたい３～４万円であることが、
以下の調査から知られている
・第35回 教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1110/
・2012年度 教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1210-2/
データ分析・活用実践講座＜＜演習付き＞＞
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/nc/130626-2/
これは、６万３千円、この価格だと、毎月やるほど、需要あるんだ～
だけどね・・・
第1期 ビッグデータビジネス実践イノベーター養成プログラム
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/bigdata/1304/
これは、２９８０００円（打ち間違えてないよな、弐拾九萬八千円）
そして、本なんだけど・・・
『ビッグデータ総覧2013』
http://coin.nikkeibp.co.jp/coin/itpro-s/book/dtl/bigdata2013.html
7月1日に発行予定らしい。こいつは198000円（壱拾九萬八千円）
あ～なんか、すごいことになっているう・・・
ＢｉｇＤａｔａは、教育ビジネスから、火がついた感じがしますよね！
価格から見て、３万円台とかはないので、個人的な研修ではなく＊、企業の投資ですね！
マーケティング的には、ここで想起されやすいように、ＢｉｇＤａｔａ教育のキャラクターを
つくるのが効果的なのですが、
ゆるキャラは、何十万という価格帯からして、ふさわしくない。
ＡＫＢ４８も、何十万の投資を決めるお偉いさんには、軽く見られる・・・
ということで、ここは一発、大学の先生でしょうか？女性の・・・
統数研とか、東大のシステム創生、ＴＭＩ
とか、東工大のＭＯＴとか、筑波とか？？
だけど、実は、一番向いているのは、たぶん、大江アナだと思う。
う～ん、アメリカ行っちゃったからなあ～・・・
＊注「価格から見て、３万円台とかはないので、個人的な研修ではなく」：
企業において、１人当たりの教育研修費は、だいたい３～４万円であることが、
以下の調査から知られている
・第35回 教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1110/
・2012年度 教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1210-2/
昨日の
社内派閥や愛人関係「も」記述できる、ソフトウェア工学手法
http://blog.goo.ne.jp/xmldtp/e/aa87b665b95a125141eb688f291d81e3
の続きのような話。
大学の授業の場合、要求分析のところで、ステークホルダー分析は、そんなに深くやらないと思う。
やる内容は、
「ステークホルダーは、大きく、ユーザーと顧客と開発者です。
ユーザーと顧客は別です。
ユーザーはシステムを利用する人、顧客はシステム開発費用を負担する人。
たとえば、ＥＣサイトだとすると、
ユーザーは、ＥＣサイトのお客さんとＥＣサイトの管理者
顧客はＥＣサイトの社長
です」
くらいかしら・・・え、さすがにそれよりも、もう少しやるって？
「そのほかに抵抗勢力、またそのシステムを導入することにより、不利益を被る人
までも入ります。たとえば、システムを導入することにより合理化し、解雇される
従業員（抵抗勢力）、ＥＣサイトを導入することにより、一日中会社を運営する
ことになるので、会社の周りがウルサクなることで困る周辺住人です。
これらを解析する手法として、オニオンモデルがあります」
このくらいは、やるのかしら・・・でも、ここから、先にすぐにいって、
業務分析と化しちゃうよね。
抵抗勢力など、後ろから殴ってくるような人がいるとか
→殴るのは、抵抗勢力だけでなく、顧客、ユーザー、開発者のときもある
そういう人をどうやって発見するかとか、
実は権力も無く、要件を聞いてしまってはいけない人がいて
→その人の要求をどうするか
とかまで、教えないような気がする。
むしろ、ＫＡＯＳとか、ＣＶＣＡとか教えてしまうと、
これらの人はきえる（そんなこんなで、ＣＶＣＡはオニオンモデルと比べると、ステークホルダー分析が甘い）
実際のソフトウェア工学の世界も、抵抗勢力とかを(とりあえず）考えず、
みんないいひと！で業務分析する、新興宗教みたいな分析方法がある。
それがＫＡＯＳ。
ＫＡＯＳの場合、「どういう状態になっているか」という理想像を分析する。
たとえば、「小さな家を建てる」については、こんなふうに分析（詳細化＝洗練）
させていく
ここで、「あなた」は、「イヌ」レベルだ（＾＾；）
しかし、コレを、昨日やった、社内派閥や愛人関係「も」記述できる、
ソフトウェア工学手法であるi*のＳＤモデルで記述してみよう。
こんなかんじ。
不自然な図に見える
なにが、不自然かというと、ふつうは、
Ｄの文字が
Ｄと
ひっくり返ったＤが
対応関係にあるのがふつう（Ｇｉｖｅ＆Ｔａｋｅの関係）
ところが、ここで、明子さんは（なぜ明子なのか判らない２０代、３０代の人は、リンク先を見てね！）要求だけ（Ｄだけ）しているけど、反対側のＤがない。見返りになにをするのかわからない。
さらに、大工さんから見た場合、明子さんとあなたの関係も良くわからない。
そして、「家を建てる」という要望は、明子さんとあなたで同じなのかどうかもわからない。
ここで、大工さんは不安になる。
明子さん、この図から、はずしてもよくないか？
もし、あなたの「家を建てる」要求と、明子さんの「家を建てる」と違って
明子さんが図から外れたら・・・明子さんの「家を建てる」要求でやっていると、
あとからどんでん返しを食らうぞ？
ということで、大工さんは、明子さんの要望に従っていいのか、不安になる。
ここで、大工さんとしては、あなたと明子さんの間の関係を知りたいが、ここに婚姻関係に基づく
依存性があれば簡単なんだけど、そうでないと、外から観察できる範囲では良くわからないし、
そもそも、婚姻関係でなければ、変更の危険性がある、弱い関係になる。
そこで、大工さんは、「ここで一発、契約だ！」として、
あなたと、大工さん間で契約を結び、
明子さんの要求を文書化し、あなたと大工さんの間で合意をとる。
→明子さんとあなたの要求が違った場合は、明子さんの要求は無視する
この「小さな家を建てるプロジェクト」の結末は皆さん知ってのとおり。
プロジェクトはすぐに終了する（家は建てない）
もし、ＫＡＯＳで分析していたら、「あなた」の存在は、小さなものなので、
家は建つものとして詳細化、ユースケース分析に入る。
そこで、いきなりプロジェクト中止と「後ろから殴ってくるような」事態におちいる。
しかし、i*で分析し、依存関係の不自然さに気づけば、
あなたに契約内容を確認するため、いち早く、家は建てる気が無いことに気づく。
世の中の開発だと、結構そういうことがあって、現場の人はいろいろＵＩ要求を
出してくれるんだけど、「あんたを解雇するためにシステム導入するんだから、
あんたの使いやすさなんて、ど～でもいいんだよ」というかんじなのに、
そこで、要求が膨らんだり、「やっぱり現場のＸさんは、必要です」とかいう話になり、
さらに「お客様のＸさまに喜んでもらい、プロジェクトは大成功しました」とか、
わけわかんないことで、開発者が自己満足、でも次の発注は来ないことになる。
顧客（ユーザーのＸさんではない。カネを出す顧客）は、ユーザーＸさんを笑顔
にすることを求めているのではなく、Ｘさんの首を切ることを求めている。
上記の場合、Ｘさんの首を切れなかったのだから、
顧客から見たら、システム開発は大失敗！
当然、そんなベンダーには、二度と開発は頼まない。
顧客の求めている要望をまったく無視しているのだから、
Ｘさんが喜び、業務が回っても、金をドブに捨てたことになる。
Ｘさんも一時的には幸せだが、
長い目で見ると、古い技術に固定され、転職できず、一生が終わる。
（ＣＯＢＯＬの汎用機での帳票出力のためのパンチしか出来ません！みたいな）
この手のストーリーは、大学では、あんまり教えてないんじゃないかなあ？
でも、そこまで教えないと（上記みたいな）要求変更は教えられず、
システム開発の本質（だれかの首切りをしなければならないが、それによって、
きられるほうも、顧客も、開発者も、次の世界にいけて、実はＨａｐｐｙ）
の話もできないわけで・・・
「ユーザーの要求を満たすことで、みんなハッピー」みたいな
箱庭みたいなソフトウェア工学を
教えることになる
もちろん、箱庭が悪いわけじゃなくって、
議論をするためには、箱庭をつくるんだけど、
その箱庭が、実社会と同じと思っちゃうと、それは勘違い。
これは、「箱庭で、社会はもっとどろどろしてるから、使えない部分があるんだよ」
という、限界を教えることが重要だと思うんですよ・・・
社内派閥や愛人関係「も」記述できる、ソフトウェア工学手法
http://blog.goo.ne.jp/xmldtp/e/aa87b665b95a125141eb688f291d81e3
の続きのような話。
大学の授業の場合、要求分析のところで、ステークホルダー分析は、そんなに深くやらないと思う。
やる内容は、
「ステークホルダーは、大きく、ユーザーと顧客と開発者です。
ユーザーと顧客は別です。
ユーザーはシステムを利用する人、顧客はシステム開発費用を負担する人。
たとえば、ＥＣサイトだとすると、
ユーザーは、ＥＣサイトのお客さんとＥＣサイトの管理者
顧客はＥＣサイトの社長
です」
くらいかしら・・・え、さすがにそれよりも、もう少しやるって？
「そのほかに抵抗勢力、またそのシステムを導入することにより、不利益を被る人
までも入ります。たとえば、システムを導入することにより合理化し、解雇される
従業員（抵抗勢力）、ＥＣサイトを導入することにより、一日中会社を運営する
ことになるので、会社の周りがウルサクなることで困る周辺住人です。
これらを解析する手法として、オニオンモデルがあります」
このくらいは、やるのかしら・・・でも、ここから、先にすぐにいって、
業務分析と化しちゃうよね。
抵抗勢力など、後ろから殴ってくるような人がいるとか
→殴るのは、抵抗勢力だけでなく、顧客、ユーザー、開発者のときもある
そういう人をどうやって発見するかとか、
実は権力も無く、要件を聞いてしまってはいけない人がいて
→その人の要求をどうするか
とかまで、教えないような気がする。
むしろ、ＫＡＯＳとか、ＣＶＣＡとか教えてしまうと、
これらの人はきえる（そんなこんなで、ＣＶＣＡはオニオンモデルと比べると、ステークホルダー分析が甘い）
実際のソフトウェア工学の世界も、抵抗勢力とかを(とりあえず）考えず、
みんないいひと！で業務分析する、新興宗教みたいな分析方法がある。
それがＫＡＯＳ。
ＫＡＯＳの場合、「どういう状態になっているか」という理想像を分析する。
たとえば、「小さな家を建てる」については、こんなふうに分析（詳細化＝洗練）
させていく
ここで、「あなた」は、「イヌ」レベルだ（＾＾；）
しかし、コレを、昨日やった、社内派閥や愛人関係「も」記述できる、
ソフトウェア工学手法であるi*のＳＤモデルで記述してみよう。
こんなかんじ。
不自然な図に見える
なにが、不自然かというと、ふつうは、
Ｄの文字が
Ｄと
ひっくり返ったＤが
対応関係にあるのがふつう（Ｇｉｖｅ＆Ｔａｋｅの関係）
ところが、ここで、明子さんは（なぜ明子なのか判らない２０代、３０代の人は、リンク先を見てね！）要求だけ（Ｄだけ）しているけど、反対側のＤがない。見返りになにをするのかわからない。
さらに、大工さんから見た場合、明子さんとあなたの関係も良くわからない。
そして、「家を建てる」という要望は、明子さんとあなたで同じなのかどうかもわからない。
ここで、大工さんは不安になる。
明子さん、この図から、はずしてもよくないか？
もし、あなたの「家を建てる」要求と、明子さんの「家を建てる」と違って
明子さんが図から外れたら・・・明子さんの「家を建てる」要求でやっていると、
あとからどんでん返しを食らうぞ？
ということで、大工さんは、明子さんの要望に従っていいのか、不安になる。
ここで、大工さんとしては、あなたと明子さんの間の関係を知りたいが、ここに婚姻関係に基づく
依存性があれば簡単なんだけど、そうでないと、外から観察できる範囲では良くわからないし、
そもそも、婚姻関係でなければ、変更の危険性がある、弱い関係になる。
そこで、大工さんは、「ここで一発、契約だ！」として、
あなたと、大工さん間で契約を結び、
明子さんの要求を文書化し、あなたと大工さんの間で合意をとる。
→明子さんとあなたの要求が違った場合は、明子さんの要求は無視する
この「小さな家を建てるプロジェクト」の結末は皆さん知ってのとおり。
プロジェクトはすぐに終了する（家は建てない）
もし、ＫＡＯＳで分析していたら、「あなた」の存在は、小さなものなので、
家は建つものとして詳細化、ユースケース分析に入る。
そこで、いきなりプロジェクト中止と「後ろから殴ってくるような」事態におちいる。
しかし、i*で分析し、依存関係の不自然さに気づけば、
あなたに契約内容を確認するため、いち早く、家は建てる気が無いことに気づく。
世の中の開発だと、結構そういうことがあって、現場の人はいろいろＵＩ要求を
出してくれるんだけど、「あんたを解雇するためにシステム導入するんだから、
あんたの使いやすさなんて、ど～でもいいんだよ」というかんじなのに、
そこで、要求が膨らんだり、「やっぱり現場のＸさんは、必要です」とかいう話になり、
さらに「お客様のＸさまに喜んでもらい、プロジェクトは大成功しました」とか、
わけわかんないことで、開発者が自己満足、でも次の発注は来ないことになる。
顧客（ユーザーのＸさんではない。カネを出す顧客）は、ユーザーＸさんを笑顔
にすることを求めているのではなく、Ｘさんの首を切ることを求めている。
上記の場合、Ｘさんの首を切れなかったのだから、
顧客から見たら、システム開発は大失敗！
当然、そんなベンダーには、二度と開発は頼まない。
顧客の求めている要望をまったく無視しているのだから、
Ｘさんが喜び、業務が回っても、金をドブに捨てたことになる。
Ｘさんも一時的には幸せだが、
長い目で見ると、古い技術に固定され、転職できず、一生が終わる。
（ＣＯＢＯＬの汎用機での帳票出力のためのパンチしか出来ません！みたいな）
この手のストーリーは、大学では、あんまり教えてないんじゃないかなあ？
でも、そこまで教えないと（上記みたいな）要求変更は教えられず、
システム開発の本質（だれかの首切りをしなければならないが、それによって、
きられるほうも、顧客も、開発者も、次の世界にいけて、実はＨａｐｐｙ）
の話もできないわけで・・・
「ユーザーの要求を満たすことで、みんなハッピー」みたいな
箱庭みたいなソフトウェア工学を
教えることになる
もちろん、箱庭が悪いわけじゃなくって、
議論をするためには、箱庭をつくるんだけど、
その箱庭が、実社会と同じと思っちゃうと、それは勘違い。
これは、「箱庭で、社会はもっとどろどろしてるから、使えない部分があるんだよ」
という、限界を教えることが重要だと思うんですよ・・・
う～ん、それもあるかもしれないけど・・・
アメリカのFlash Crashがそれだよね。
Flash Crashって、３つぐらいのアルゴリズムで取引を同時に起こさせると、再現できたんじゃなかったっけ？
なんか、大学院でやった気がする（間違ってるかも）
・・・
ノート確認した。つぎの３つのアルゴリズムを組み合わせるらしい
Ａ．価格を等差数列的に下げて付け、売買成立したら、さらに下げる
Ｂ．Ａと同じ等差数列的価格付けだが、下げ方がＡより細かい
Ｃ．等比級数的に価格を下げる
メモが間違っていたら、ごめん
東証も、たしかにFlashCrashが起こる、ＨＦＴ（高速取引）に対応している。
J.S.エコハ @Koj_Sasaki 5月29日
東証arrowhead高速取引の本質は「約定まとめ」の廃止による約定の個別化。「約定まとめ」とは1991年に取引システム完全電子化の際、情報提供頻度が速過ぎるとの懸念から意図的に3秒のタイムラグを約定間に挿入。最頻時で4秒の集計になる。
とあるように、昔は、約定まとめをしていたが、Ａｒｒｏｗｓになってから、まとめないで、瞬時に執行するので、値段がすぐに動く。
ただし、日本には、値幅制限があるので、ＦｌａｓｈＣｒａｓｈほどにはならないんじゃないか？
また、ＦｌａｓｈＣｒａｓｈの場合、値はもどる。
今回は、それよりも、今まであがりすぎたことと、ヘッジファンドが５月に精算するために利益確定で売りたかった、とか、そっちの理由じゃないかなあ
ま、理由はともあれ、一喜一憂しないという麻生大臣の態度は正しい。
もし、大相場になるのであれば、今まで上がりが急だったので、ここで一回さげて、再挑戦ということであろう（このまま、終わってしまうかもしれないが・・・）
まあ、大相場を期待して、気長に待ちましょう・・
アメリカのFlash Crashがそれだよね。
Flash Crashって、３つぐらいのアルゴリズムで取引を同時に起こさせると、再現できたんじゃなかったっけ？
なんか、大学院でやった気がする（間違ってるかも）
・・・
ノート確認した。つぎの３つのアルゴリズムを組み合わせるらしい
Ａ．価格を等差数列的に下げて付け、売買成立したら、さらに下げる
Ｂ．Ａと同じ等差数列的価格付けだが、下げ方がＡより細かい
Ｃ．等比級数的に価格を下げる
メモが間違っていたら、ごめん
東証も、たしかにFlashCrashが起こる、ＨＦＴ（高速取引）に対応している。
J.S.エコハ @Koj_Sasaki 5月29日
東証arrowhead高速取引の本質は「約定まとめ」の廃止による約定の個別化。「約定まとめ」とは1991年に取引システム完全電子化の際、情報提供頻度が速過ぎるとの懸念から意図的に3秒のタイムラグを約定間に挿入。最頻時で4秒の集計になる。
とあるように、昔は、約定まとめをしていたが、Ａｒｒｏｗｓになってから、まとめないで、瞬時に執行するので、値段がすぐに動く。
ただし、日本には、値幅制限があるので、ＦｌａｓｈＣｒａｓｈほどにはならないんじゃないか？
また、ＦｌａｓｈＣｒａｓｈの場合、値はもどる。
今回は、それよりも、今まであがりすぎたことと、ヘッジファンドが５月に精算するために利益確定で売りたかった、とか、そっちの理由じゃないかなあ
ま、理由はともあれ、一喜一憂しないという麻生大臣の態度は正しい。
もし、大相場になるのであれば、今まで上がりが急だったので、ここで一回さげて、再挑戦ということであろう（このまま、終わってしまうかもしれないが・・・）
まあ、大相場を期待して、気長に待ちましょう・・
アクセス
トータル
ランキング
