首都大学東京情報通信特別講義 2017 #tmutalks
- 未整理
- 機械と人間に関して
-
縦軸をあいまいにしがちだけど、例えば具体的に「正確に覚えて置ける情報の量」を縦軸に取ったら機械は人間を既に超えている。「1秒間にできる足し算の回数」でも超えている。
-
世の中の人が「機械が人間を超える！」って言う時、縦軸は結構曖昧。
-
「すべての能力で機械が人間を超える時が来るか？」
-
研究は加速しているように見えるけど、AIの力で加速しているわけじゃないよね。論文が「紙の論文誌」ではなく、インターネット上でPDFで流通するようになったこととか、かつては査読という形で専門家が質をレビューするプロセスが公開前にあったが査読前の原稿をネット上に公開することが一般的になったこととか、すごく儲かったIT企業が強力な計算機環境に投資したこととかが要因だよね。
-
コンピュータが人間を使役する。
- Twitterを眺めてると、地震があったら「地震だ！」って人間たちが書きこむんだけど、あれってそれ自体は地震を感知するセンサーを持たないプログラムが、人間をセンサーとすることで地震を検知している、という解釈が出来そう。
-
比較優位。
-
- 機械が人間を超えたら
- 機械と人間に関して
西尾のTweet
- Q: 人は自分の能力を超えるものを作ることができるのか？ A: 「能力」は一つではない。自転車を作った人は「自転車に乗った人間より早く走れる能力」を持っていたわけではないので「自分の走る能力を超えるものを作った」わけだが「自分の考える能力」を超えてはいないだろう。
- 質疑の時に当てられて詰まってしまった人に「次のセッションで最初に当てるよ」と予告するテクニック有用そうだなー。予告されたことで心の準備ができてちゃんと質問できてたし、質問出来たという経験で次回以降の心のハードルが下がる。
- 「学びたいことを学ぶのは楽しいが、こればっかりやってると身を亡ぼすんじゃないかと不安」深い質問だｗ 小町先生は学びたいことをやって運よく成功したというスタンス。僕は何であれ「教科書のないものを学ぶ」というスキルを高めれば将来分野を変えても大丈夫じゃないかと思う
小町先生のTweet
- 午後の @nishio さんの話が始まりました〜。グループウェアとは何か？ソフトウェアによって集団の能力を増強する、という目的のソフトウェアについての話からスタートです。
- 西尾さんの務めるサイボウズラボの主力はグループウェア。コミュニケーションを円滑にする「場」を提供するソフトウェア。検索エンジンで人間の情報収集能力が強化された。機械学習で仕事がなくなる、と恐れるものではなく、人間の能力をサポートするものだと認識してほしい。
- コミュニケーションの「場」を提供する。複数のトピックが混在する問題をどう解決するか。話題ごとに分ければいい。しかし話題を事前に決めないといけないのは敷居が高い。なんでも発言していい場を作ればいい。しかし、それでは情報洪水が起きる。これは解決の方法が分からない。
- 働くというのはどういうことか？対価を得ること。対価とは何か？顧客価値。お金を払う価値は増強された能力。グループウェアで生産性や創造性が上がるのでお金を払う。でも、生産性向上法はソフトウェアだけではない。言語化・体系化することや、その教育も有用。#tmutalks
- どんなよいソフトウェアを作っても、使い方が理解されなければ役に立たない。マニュアルを書かずに使ってもらえるというのはエンジニアにありがちな罠。ソフトウェア開発でも、使ってもらうためには教育が大事。いいものを作ったら理解される、などということはない。
- ジェームズ・ヤング「アイデアのつくり方」いいアイデアは自分で成長する。よいアイデアは見る人を刺激するので、その人々が手助けしてくれる。考えたことは自分の中で留めておかず、周りに喋るといい。整理されてなくてもなんでもいい。盲点に気付く。
- 大学に入るとだんだん教科書がない中で学ばないといけなくなる。そういう状況でどう学ぶか？自分の理解と現実のズレに注目する。ズレているところが盲点。そこから学ぶ。プログラミングだと、こう動くはずだと思って書いて実行する。エラーが返ってくる。そこが学ぶポイント。
- 高校までだと、一方的に知識のある人から学ぶのが普通に思えるかもしれないが、実は一方的に知識がある人なんてほとんどいない。そこでどう学ぶ？専門分野が違えば、互いに知識を交換し合える。相手にとって価値のある情報を提供すれば、教えてもらえる。相手に価値を提供して学ぶ。
- 何を学ぶかも大学以降では自分で探さないといけない。何を学べばいいかは他の人は教えてくれない。初めて書いた本は「Jython プログラミング」。書いている途中でバージョンが上がって陳腐化。若いうちは具体的な内容に興味が出がちだが、抽象的な内容の方が長く使える。
- 具体的な手法を学んでも、その問題が解けるだけ。抽象的な方法論を学べば、他の問題に応用することができる。抽象的な方法論を学ぶにはどうすればいいか？自分の経験と結びつける。自分が経験したことは、自分が世界で一番詳しい。
- 勉強会でよくある間違い。間違えるのが怖く、教科書や論文を丸写しする。参加者から質問が出るが、「こう書いてあった（自分のせいじゃない）」と答えるしかない。最悪の発表。失敗。自分はこう解釈した、というのが大事。間違っていても、議論ができる。盛り上がる。これは成功。
- エンジニア向けの話。マニュアルを読んで理解した、で終わるのはもったいない。マニュアル（論文）を読んで実装してみた、という話はおもしろい。実装は経験になる。理解できていないところも分かる。理解、実装、考察、そして理解の修正のサイクル（いわゆるPDCA）を回す。
- PDCAサイクルは有益だけど、じゃあ最初をどうすればいい？という問題。丸写しじゃない発表資料を作るためには？「発表資料を作ろう」という大きく計測不能なタスクではなく、「ネタを付箋に50枚書く」は計測可能で隙間時間に実行可能なタスク。書き出して作業記憶を拡張する。
- KJ法の紹介。書き出した大量の付箋をクラスタリング。クラスタに名前をつける。図解で自分の理解の全体像を整理。言語化と体系化。しかし図解（2次元）は他人に伝えるには向かない。他人に伝えるには1次元にする。他人に伝えてフィードバックをもらう。これでサイクルが回る。