確率論及統計論輪講

確率論及統計論輪講

1. 1. LT大会応募募集   資料のみの遠隔投稿可     輪講の進め方   SWEST18  2016/08/26     確率論及統計論輪講　  (0/13)   開催場所：下呂温泉   技術士（情報工学）・工学博士   名古屋市工業研究所・岐阜大学非常勤講師   　小川清 @kaizen_nagoya,  kaizen@wh.commufa.jp
2. 2. 輪講の進め方 •  １４枠各５分（５枚から１０枚を想定）の発表を募集してい ます。   •  0/13は　輪講の進め方@kaizen_nagoya   •  1/13は　輪講を始める前に@kaizen_nagoya   •  2/13は　モンティホール問題@遠隔参加者   •  と枠は３つ埋まっています。残り11枠。   •  原則SWEST参加者が優先です   •  枠さえ余っていれば、参加できない方の５分間の確率・統 計に関する資料（LT用）をお願いします。オンラインでの 講演は現地に行ってから調整してみます。うまくいかない 場合は司会が代読。   –  資料は20枚以上でも受け付けますが説明時間は5分です。   @kaizen_nagoya,  kaizen@wh.commufa.jp
3. 3. 内容 •  仕事上の確率・統計の課題を優先します。優先順位２   •  枠さえあれば、趣味での確率・統計の話題でも結構で す。優先順位４   –  例えば、魚釣りにいって、魚の種類による釣果の統計   •  「確率論及統計論」のTeX入力した式の展開、プログラ ム例は最優先させてください。本の式の誤植一覧も歓 迎します。優先順位1   •  「確率論及統計論」を読む前に、勉強するとよい本の紹 介でも歓迎です。優先順位３   •  全体を通じてSWEST参加者(S)優先です。   •  S1,S2,S3,  S4,  O1,O2,O3,O4   @kaizen_nagoya,  kaizen@wh.commufa.jp
4. 4. 申し込み方法（三択） •  Slideshare.netにスライドをあげて、そのURLをお知らせく ださい（下記）。   •  メール:  kaizen@wh.commufa.jpにスライドをお送りくださ い。スライドは当日表示のみか、公開(スライドシェアを 想定）してもよいかの別を記載してください。   •  TwiQer:  @kaizen_nagoyaまたは上記メールにスライドの URLをお送りください。パスワードのかかっている資料の 場合には、パスワードと、当日表示のみか、公開しても よいかどうかを付記してください。   –  Researchmap.jpだとパスワード付きの資料を置けます。輪講 参加者にはIDを発行しています。   –  当日まで何度資料を直していただいて結構ですので、ひとま ず枠だけの資料を送ってください。 @kaizen_nagoya,  kaizen@wh.commufa.jp
5. 5. 輪講を始める前に   SWEST18    2016/08/25   確率論及統計論輪講　LT大会(1/13)     開催場所：下呂温泉   資料のみの遠隔投稿可能   技術士（情報工学）・工学博士   名古屋市工業研究所・岐阜大学非常勤講師   　小川清 @kaizen_nagoya,  kaizen@wh.commufa.jp
6. 6. 要求は変わるか？ •  よく「要求が変わる」というという話をお聞きします。よく調 べてみると、要求が変わったのではなく、事象の、その時 点で判断できる確率が変わっただけだったということがあ ります。   •  もし、適切な抽象度で仕様を記述したり、プログラムを記 述していれば、「変わった」ことは仕様の範囲内で、仕様も 設計（プログラム）も変更しなくてもいいかもしれません。   •  「要求が変わった」から「仕様を変えなきゃいけない」「プロ グラムを変えなきゃいけない」は、最初に確認すべきことを 間違えていただけの言い訳でしかないことがないでしょう か。   •  ここではモンティホール問題を題材に、要求が変わってい ないのに、プログラムを変えるという例を紹介します。 @kaizen_nagoya,  kaizen@wh.commufa.jp
7. 7. 解決する事 •  三つのドアA,B,  Cの向こうに、必要なものが一 箇所だけにあります。   •  今から、どれかのドアを開けることを想定し、 ドアの管理者に告げる。   •  ドアの管理者はそれ以外の二つのドアの一 つを開けて、その向こうにはドアがないことを 示します。例えば、今Bを開けたとします。   •  最終的にどのドアを開けるかを決めて開けま す。   @kaizen_nagoya,  kaizen@wh.commufa.jp
8. 8. 四つのプログラムの依頼 •  今、三種類の依頼方法で、それぞれプログラ ムを作成する依頼があったとします。   •  １　最初にどのドアを開けるかを決める段階 までのプログラムの依頼   •  ２　Bだけを開けた事例でのプログラムの依頼   •  ３　最初はBだけをあけ、次の時にはCだけを 開けた場合。   •  ４　上記３に加えて、その後最初に回答するド アをBに変更してと依頼があった。   @kaizen_nagoya,  kaizen@wh.commufa.jp
9. 9. プログラムの依頼１ •  三つのドアA,B,  Cの向こうに、必要なものが一箇所だけに あります。   •  今から、どれかのドアを開けることを想定し、ドアの管理者 に告げる。   –  ここでプログラムの依頼がありました。ドアAを管理者に告げる プログラムを作りました。   •  ドアの管理者はそれ以外の二つのドアの一つを開けて、 その向こうには必要なものがないことを示します。例えば、 今Bを開けたとします。   –  ここでドアBを開けた場合にドアAを開けるままにするかドアCを 開けるかを決めるプログラムの追加依頼がありました。   •  最終的にどのドアを開けるかを決めて開けます。   •  あなたなどういう仕様書とプログラムを書きますか？   @kaizen_nagoya,  kaizen@wh.commufa.jp
10. 10. プログラムの依頼2 •  三つのドアA,B,  Cの向こうに、必要なものが一箇所だ けにあります。   •  今から、どれかのドアを開けることを想定し、ドアの管 理者に告げる。   •  ドアの管理者はそれ以外の二つのドアの一つを開け て、その向こうには必要なものがないことを示します。 例えば、今Bを開けたとします。   –  ここで、最初にドアAを開けることを告げ、管理者がBを開 けた場合にドアAを開けるかままにするかドアCを開ける かを決めるプログラムの依頼がありました。   •  最終的にどのドアを開けるかを決めて開けます。   •  あなたなどういう仕様書とプログラムを書きますか？   @kaizen_nagoya,  kaizen@wh.commufa.jp
11. 11. プログラムの依頼3 •  三つのドアA,B,  Cの向こうに、必要なものが一箇所だけにあります。   •  今から、どれかのドアを開けることを想定し、ドアの管理者に告げ る。   •  ドアの管理者はそれ以外の二つのドアの一つを開けて、その向こ うには必要なものがないことを示します。例えば、今Bを開けたとし ます。   –  ここでドアAを開けることを告げ、管理者がBを開けた場合にドアAを開 けるままにするかドアCを開けるかを決めるプログラムの追加依頼が ありました。   •  最終的にどのドアを開けるかを決めて開けます。   •  二回目には、管理者はドアCを開けました。   –  ここで、管理者がドアCを開けた場合のプログラムに変更してくれと話 がありました。   •  あなたなどういう仕様書とプログラムを書きますか？   @kaizen_nagoya,  kaizen@wh.commufa.jp
12. 12. プログラムの依頼4 •  三つのドアA,B,  Cの向こうに、必要なものが一箇所だけにあります。   •  今から、どれかのドアを開けることを想定し、ドアの管理者に告げ る。   •  ドアの管理者はそれ以外の二つのドアの一つを開けて、その向こ うには必要なものがないことを示します。例えば、今Cを開けたとし ます。   –  ここでドアAを開けることを告げ、管理者がCを開けた場合にドアAを開 けるままにするかドアBを開けるかを決めるプログラムの追加依頼が ありました。   •  最終的にどのドアを開けるかを決めて開けます。   •  二回目には、管理者はドアBを開けました。   –  ここで、管理者がドアBを開けた場合のプログラムに変更してくれと話 がありました。   •  あなたなどういう仕様書とプログラムを書きますか？   @kaizen_nagoya,  kaizen@wh.commufa.jp
13. 13. 何か要求変更はありましたか？ •  仕様は全く変わっていません。   •  １　仕様が変わっていないけど、作る範囲で 追加が発生し、追加部分の方が難しそうです。   •  ２　最初から全体の依頼がありました。   •  ３　仕様は変わっていないけど、対応する例 が変わりました。   •  ４　仕様は変わっていないけど、対応する例 が変わりました。 @kaizen_nagoya,  kaizen@wh.commufa.jp
14. 14. 仕様、要求、制約、設計 •  何が大事かごっちゃにしてませんか？   •  お客さんが何にお金を払ってくれそうかで決 めていませんか？   •  いわれた通りに作った方が、お金を払ってく れるので、抽象的に作らずに、いわれるたび に変更してお金をもらっていませんか？   •  そうするとどんどん複雑な構造になりません か？   •  確率計算を間違えて作っていませんか？ @kaizen_nagoya,  kaizen@wh.commufa.jp
15. 15. 制約と仕様を明確にしよう •  仕様と制約を区分する。   •  制約   –  社会的制約（国によって違う）   –  時代的制約（５年、１０年で変化しそうな事）   –  市場動向（傾向を把握し、転換点を予測する）   •  統計と確率が必須   •  制約を可変にするかどうか。   –  合わせて設計を検討   •  プログラムでは定数にするか変数にするか   •  変数に定数を初期代入するか、外部入力にするか   @kaizen_nagoya,  kaizen@wh.commufa.jp
16. 16. 長期的に仕事をするには •  短期的に仕事をするには、言われる度に直した ほうが収入が上がるかもしれません   •  長期的に少しのソフトウェアで多くの事に対応で きればうまくいくかもしれません。   •  統計に基づいたり、確率に基づいたソフトウェア にしておけば、確率を1にしたり0にすれば、違う 分岐になったり、分岐を通らなくすることも可能で す。   •  統計と確率を整理して、どういう構造のソフトウェ アがよいか検討しましょう。 @kaizen_nagoya,  kaizen@wh.commufa.jp