Hatena2014-11-13

code:hatena

<body>

*1415887700*名古屋大学で講演した「学び方のデザイン」の講義資料を公開しました

名古屋大学で情報系の学生さんを対象として講演した「学び方のデザイン名古屋大学版」の講義資料を公開しました。

こちらが講演に使ったままのスライドです。

こちらが音声でやりとりした情報を書き足したものです。こちらのほうが読み物としては話の流れがわかりやすいかとは思いますが、細かい字がたくさんあります。

参加者の皆さんに書いていただいたアンケート用紙の質問には、この後ボチボチと答えていきます。

** Q: コンピュータは増強された人間に勝てなくなってしまうのか？

複数の部品からなるシステムは継ぎ目でオーバーヘッドが生じがちです。「人間＋コンピュータ」システムも、継ぎ目のオーバーヘッドが大きいので、人間があまり有用な働きをしないようなタスクについてはコンピュータだけでやったほうが効率がいいでしょうね。例えばパケットのルーティングとか。

** Q: 「知識が少ない人」は知識が本当に少ないのか？年齢の差以外に何があるだろう？

うーん、知識の量を計測する尺度をどうやって導入するかは難しい話ですね。

一つのシンプルな尺度は「掛けた時間」で、その場合は年齢が同じなら知識の総量も同じということになります。ところがこの定義には「同じ本をAさんは1時間で読めたのに、Bさんは悪戦苦闘して10時間かかった。Bさんの方がその本から得た知識が多いのか？」という問題があります。そうとも言い切れませんね。

二つ目の尺度として「入力ソースの量」を考えると、同じ本を読んだAさんとBさんは同じ量の知識を持っていることになります。ところがこれにも「1時間で流し読んだだけのAさんと、わからないところは何度も繰り返してよんだBさん、得た知識は同じなのか？」という問題があります。Aさんが各1時間で10冊の本を流し読んでいたら、Bさんより10倍知識があるのか？そうとも言い切れませんね。

三つ目の尺度として「アウトプットの市場ニーズによって価値がきまる」があります。例えば二人が読んだ本が未知のプログラミング言語の本で、二人はこれからその言語でプログラムを書くとします。AさんとBさんが同じ効率でプログラムを書けるなら「AさんはBさんと同じ量の知識を10倍の効率で得た」と考え、AさんがBさんに比べて0.1倍以下の効率しか出せないなら「BさんはAさんより10倍時間を掛けて学んだが、それによってAさんの10倍以上の知識を得た」と考えるわけです。

今回の「知識の多い人から少ない人への一方通行じゃないよ」という話をする上では、どの尺度を採用しても実害はないので詳しく考えませんでした。

**Q: SeedsとNeedsの一致を確認してから実行に移すことは重要だけど、難しいのでは？

「SeedsとNeedsの一致を『完璧に』確認してから実行しよう」と考えていると、ハードルが高くて最初の一歩が難しいでしょうね。

** Q: 数多くのことを書いた時に、他人とかぶる内容が多く量も多い人と、他人とは全くかぶらない内容をそこそこ書いた人はどちらが評価されるべきか

まず重要なのは「他人とかぶるかどうかは、書いた後で事後的にしかわからない」という点です。「～と考える人は多いだろう」という考え自体が、未検証の仮説で、本人はありきたりなアイデアだと思っていたものが実は意外とみんな気づいていなかったということもあります。なので、個人が書き出しをするときの気持ちの持ち方としては、他人とかぶるかどうかは気にせずどんどん書くのが良いです。

そうではなく、たとえば研究室内でアイデア出しをした時に誰を褒めるべきか、というマネジメント側の視点ではどうか？

この質問文を見て「他人とかぶらない内容を大量に書いた人」がもっともよいという前提があるように感じましたが、もしその大量のアイデアが全部実現可能性のないものだったら、ゴミの山が生産されただけですね。なので、アイデア出しの段階ではなく、その中から精査していくつか実行して、最終的に実益につながったかものが良いアイデアです。これももちろん、アイデア出しの段階では判断できません。

** Q: 日常で感じていることを整理する時間があまりなくて、こういった整理された講演を聞き、理解、納得と新たな気付きに出会えることがすごく好きで、ありがたく思います。

ありがとうございます。でも、今後ますます時間が細切れになっていくかと思います。どうしますか？

** Q: 発表の内容を現実に当てはめた時に失敗したケースがあればぜひ知りたい

この質疑応答で、講演内容のDoに対してはいくつか失敗と修正をしています。

そうではなく、もっと抽象的な話？講演で話した方法論は自分の経験やいろいろな書籍の情報から抽象化を繰り返した結果なので、少なくとも自分の経験上は成功してしまっているから、失敗して検証するためにはまず「この方法論を他人に教えて、その人がそれを使っているところを観察して、期待の通りの成果を出していない事例を見つける」が必要なわけですよね。例えばワークショップでは「意外と書き出しに苦労している」という失敗があったので「より書き出しやすくするためにトップダウンで枠組みを与えてみる」をやって、その結果「書いた結果をその枠組に戻して分類してしまう」という失敗があったのでボトムアップをより強調するようにしてみて、という感じで試行錯誤を繰り返しています。

** Q:「ソフトウェアによって増強」マウスなどは？

説明が悪かったですね。人間増強の要素の「人工物」の中に、具体例として「ソフトウェア」や「マウス」があるわけです。

** Q: 「Augmenting Human Intellect」最近だとARとかはわかりやすい例？

そうですね。エンゲルバートは人間の知性を増強するため人工物を作ったら、それを使いこなすための訓練が必要だと考えたわけですけど、ARは更に一歩進めて、普段我々が現実を認識している方法を利用して、見かけ上の現実の側をAugmentしてしまえという発想の逆転をしているわけですね。

**Q: アイデアを考えようとすると自分は人工物をイメージしがち、なぜ？

今までの経験によってバイアスが生まれているのではないでしょうか。たとえば研究とか論文とかを意識すると、より人工物に重点がいってしまうとか？

例えば違う分野の人Aさんに問題解決の方法を聞いていると「問題の原因を考えてみましょう。原因とは『誰が、何をした』の形をしているものです」などという発言があったりします。

私にとっては原因をこう定義することには違和感がありました。私を含む、人工物の改善を重視するバイアスを持った人にとって「原因を人間に帰属させるなんてとんでもない。それでは機械やソフトウェアなどのシステムの改善につながらない。原因はシステムの欠陥に帰着させて、システム改善のきっかけにせねばならない」という考えがあるんだと思います。

そこで感情的に反発せずにAさんの話をよく聞いてみると「問題の原因が明確化できたら、次はそれを改善するためのアクションを取る必要がある。アクションを取るためにはそのアクションを『誰が』取るのか明確である必要がある。だから『誰が』アクションすべき状況であるのかを明確化する必要がある」ということだそうです。Aさんは「組織」という、人間で構成されたシステムにフォーカスしているわけです。また、仮に機械やソフトウェアといったシステムを改善する必要があったとしても、それはそれを担当すべき人がいるはずだから、この枠組で統一的に扱えるという考えなわけです。

個人的には、この考え方は理解できますが、違和感は完全には消えていません。何かAさんの見落としている穴があるのではないかという気がしますが、まだ見つけていません。

** Q: 教科書がない状況では、大量の情報をまとめるソフトウェアが有用？

そのソフトウェアに入れる情報はどこから調達するのでしょう。

一つの具体的な例として、まだ教科書がない分野の論文を自動的にサーベイして知識の地図的なものを出してくれるソフトウェアがあれば有用そうですね。

** Q: 図の切り出しの話：クラウドソーシングもソフトウェア。やはりソフトウェアが支配する状況が多い。

その解釈もありですね。僕の解釈としてはクラウドソーシングは「ソフトウェア単体」ではなく「ソフトウェア＋人間」です。これを「ソフトウェアが主で、人間が補助している」と捉えるのか、「人間が主で、ソフトウェアによって人間が増強されている」と捉えるのかは視点の違いでしかありません。

** Q: 書き出していても何のことかわからないこともありそう。書き出し方にもコツがある？

よい視点ですね。コツはありそうですが、まだうまく言語化できていません。少なくとも「読める字で書こう」は大事だと思います。

ただ、あんまりルールを増やすと「ルールを守っているか」の検証コストが上がって、書き出しの心理的ハードルが上がってしまいます。トレードオフですね。

** Q: 多くの視点を得る：コンピュータに頼るのも１つ？

はい。自分に欠けている視点を補ってくれる、自分以外の何かがあることが有益という話でした。

具体的にどう実現するかはさておき、その役割をコンピュータなどの人工物が担うこともありだと思います。

たとえば自然言語での議論ができるチャットボットができれば、時間や相手の都合を気にすることなく議論をできて有益そうです。

自然言語ではなく、きちんと定義された人工言語を使うものであれば、例えばCoqやAgdaなどが近いかもしれません。

** Q: PDCAサイクル：Pは必ず最初に必要？

AdjustはCheckの結果を使い、CheckはDoの結果を使い、DoはPlanで作られた計画を実行します。なのでPlanが最初です。

Planに「最初から完成度高くしようとしない」原則を使うとPlanにかかる時間を減らせるので、それを「Doから始める」と表現する人もいる。「まず走りだせ、そして走りながら考えろ」とか。

** Q: 相手が変わらないから変えやすいところから変えるべき？

相手よりも自分のほうが変えやすいですね。これは講演でも話しました。

話しそびれたことを解説するために、まず自分ではないAさんとBさんの葛藤について考えてみましょう。もしAさんが『Bさんが変わらないのが悪い』と考えて自分を変えず、その結果問題が解決されない状態が続いたなら、『Aさんが変わらなかったこと』も『Bさんが変わらなかったこと』も問題解決を妨げた要因ですよね。この状況だとAさんは「自分は悪くない。Bさんが悪い」と考えているでしょう。構造が対称であることから明らかなように、Bさんも「自分は悪くない。Aさんが悪い」と考えていることでしょう。この均衡状態が現実だとしたら、より良い方向に変えるためにはどうしたらいいでしょう？

こうやって自分と切り離して考えてみてから、自分がAさんだったらどうか考えてみましょう。

** Q: ソフトウェアは人間の能力を増強する：電子書籍で論文を読むことが人間の能力？

例えば具体的な例として「Aさんが面白そうな論文のことを知って、それをGoogle Scholarで検索してPDFをダウンローとして読んだ」という現象について考えてみましょう。Google ScholarとPDFをまとめてBと呼ぶことにします。

AさんがBなしで同じことをした場合、つまり「図書館に複写依頼をして、しばらく待って紙で送られてきたコピーを読む」という場合と比較してみると、Aさんが使った時間は減少しているわけなので、単位時間あたりの成果は増加しています。ここで成果としているものは「Aさんの中に増えた論文内容の知識」なので、B単体では成果を出すことができません。あくまでAとBの組み合わせによって起きる効果です。

つまり、A単体で1、B単体で0、A+Bで10、という成果が出る現象です。これを「Aの能力がBによって増強された」と捉えるのが僕の解釈です。

** Q: Wikipedia、なぜ日本語版は英語版より弱いの？

単純に編集する人数の差じゃないかなと思います。「量が質に転化する」の一例ですね。

** Q: 人間増強の4要素：なぜ人間は人工物を作りたがるのか。言語とか方法論はObjectと性質・背景が違うから？だとしたら小学校の教育から考えなおす必要がある？

「人間増強の4要素のそれぞれが持つ性質・背景」という視点は盲点でした。ソフトウェアは人工物に入れて今まで説明してきましたけど、他の物理的な人工物と違って「複製が困難」という性質を持っていないですね。「方法論」という言葉で、人間が実行するものという思い込みをしていましたが、実行主体をコンピュータなどの人工物に広げれば、ソフトウェアはむしろ「方法論」なのかも。興味深い視点です。考えてみます。

** Q: 誰かに何かを教えることは、自分が正しいと思っていることを教えること。その時点で自分は、自分が正しいと思っているので、すでに盲点に入っているの？

そうですね。自分が正しいと思っていることを教えて、それが正しくなかったことに気づいた時に、事後的に自分の盲点に気づくわけです。

「教えてみる」という行動をDoする前には気付かず、Doの結果として事後的に盲点が明らかになるわけです。

** Q: パワーポイントで資料を作ったら、文章にする方がいい。その方が内容の穴に気づける。すると毎回原稿を作る必要がある？

「必要があるかどうか」「やるべきかどうか」ではなく「やった方が得かどうか」で判断しましょう。

極端な例として、時間が潤沢にあって、時間のコストを考えなくて良いなら、やった方が得でしょう。対極の例として、発表まであと1時間しかなくて発表資料がまだ完成してないなら、原稿を作ってる場合ではないでしょう。この場合は多少穴があってでも発表資料を完成させて発表することが大事です。

現実の多くのケースはこの両極端の間のどこかにあるわけです。

** Q: マインドマップはトップダウン型の分類方法ですが、とても使いやすいです。時と場合によって、トップダウンの考え方も必要になるのではないでしょうか？

まず、マインドマップの「カラフルさ」「絵」「枝に文字を這わせる」などの要素はトップダウンかボトムアップかの議論とは無関係なので削って考えましょう。

そうするとテキストエディタで箇条書きのリストを作るときなどがトップダウン方式に相当するのかなと思います。

最初に「まずは書き出してみよう」というフェーズがありましたが、何もなしでとにかく書き出せというよりも、何か取っ掛かりがあったほうが、書きやすくなるようです。

私のワークショップではそこで「問題を理想と現実のギャップ」というトップダウンの枠組みを与えて「まず、理想について書いてみる」「次に、現実について書いてみる」「それから、ギャップの解決策について書いてみる」という実習をしました。これは、それをやらなかった昨年のワークショップと比べて書きだされる付箋の量は増えました。トップダウンでツリー状に書いていくのは、トップダウンの枠組みを自分で作りながら書き出す行為だと思うので、書き出しの効率を上げる効果があるかもしれません。

一方で、自分で作った枠によって、枠を壊すような発想が出にくくなったり、既存の枠にうまく収まらない枝が隅に追いやられて無視されたりしないか不安です。書き出しにマインドマップを使った後、全体を見渡して複数の幹に分かれているけどお互いに関連しているような情報を見つけ出してマークをつけていき、それらが同じ幹に集まるように再構築した新しいマインドマップを書いたりするとその問題を軽減できるのかもしれません。

ちなみに私が「コーディングを支える技術」を書いた時には、各章ごとにマインドマップを何枚か書きましたが、その後はあんまり積極的に使っていません。それがマインドマップ（という人間増強の方法論）の特徴によるものか、僕のマインドマップに対する習熟度（つまり方法論を使いこなすための教育）によるものかは判断材料が不足しているのでわかりません。

** Q: 技術の底上げ→倫理・法律との兼ね合いは？

有用であれば法律を変えることも選択肢の一つです。

法律がまだ変わっていないなら、法律を守らないことによって負の有用性が発生するでしょうね。

** Q: (コンピュータと人間の能力の比較のグラフについて)人は変化しない？

人も変化しえますね。たとえば技術の進化によって、先進国では飢餓を心配しなくてよくなり、その結果食料確保のために使われていた脳のリソースを別のことに使えるようになったわけです。他にも、例えば日本では義務教育の徹底によってほとんどの人が文字を読めるわけです。これもまあ子供が働かずに勉強してても一家が飢えて死なないという豊かさによるものですね。倫理的な反対意見はさておき、遺伝子操作によって認知能力を改良した人間を作り出すことも、論理的には可能でしょう。

** 具体性のない、経験のできないことは学ぶことはできないのか？ボトムアップ的なアプローチが出来ない？そもそもそのようなことに商業的価値はあるのか？

「具体性のない経験できないこと」がどういうものか具体的にイメージが湧きませんが、それを「具体的に実行すること」もできないのだとすると商業的価値はないでしょうね。

** Q: 紙に手で出力するのもある種の人間の増強？

はい、そうです。紙とペンという「人工物」、アルファベットという「言語」、アルファベットを並べていくことで考えを表現するという「方法論」および、それらの使い方の「教育」がタッグを組んだ、かなり強力な人間増強手段の一つです。我々は義務教育で何年もかけて読み書きを習ったわけです。

** Q: 現実を考えの違う数人で観察しても、自分の意見（先入観）が一番正しいと感じてしまいやすいのでは？

はい、感じてしまいやすいです。なので、まずそういう傾向があることを自覚し、自分と異なる考えをすぐに捨てないようにすることが有益です。

** Q: 「知識の多い人→知識の少ない人の一方通行ではなく、お互いに未知な知識がある」これは知識に偏りがないと、成り立たないのじゃないか？多い人に少ない人が包まれてしまわないのか？

多い人に少ない人が包まれてしまうケースは、論理的にはありえます。現実的にはどうでしょう。

たとえば知識を研究室の研究分野だけに限定すると、教授の知識量が圧倒的に多くて、配属されたばかりの学生Aさんの知識は完全に包含されてしまうでしょう。ところが、Aさんが特定分野の論文を深くじっくり読み始めると、少なくともそのテーマについては教授より詳しい状態になります。また、Aさんが実装して実験をしたりすれば、その実装の詳細についての知識や、実験結果についての知識は軽く教授を凌駕するわけです。そしてあなたは「こういう論文があって、それにはこう書いてあった」「こういう実験をしたらこういう結果が出た」とゼミで教授に対して教えるわけです。ゼミが授業と一番違うポイントはそこです。

知識を研究分野に限定してでも、このように偏りは容易に起こります。限定しなければもっと容易に偏りが起こることでしょう。なので現実的には完全に包含されるケースはレアケースです。

** Q: 「ハードルを下げ、まずは質より量を優先」は0から1を生み出すプロセス、PDCAはそれをより大きい値にするプロセス。0から100を生み出すのは大変だから、まずは1を産みだして、それを大きくする？

すごくよい整理ですね。納得です。

** Q: 自分の中で「盲点に気づく」は「無知の知」に、「付箋の書き出し」は「TODOリストをたくさん書き出す」に対応しますが、「文章としてアウトプット」は対応するものがなかった。

なるほど、お役に立てて良かったです。

1点、『「付箋の書き出し」は「TODOリストをたくさん書き出す」に対応』というところに関して。「TODOをたくさん書き出す方法」としてはGTDが有名なので、それのことかなと勝手に解釈しています。ところが、GTDって「TODOを書き出せ」とは書いていないんですよ。「気になることを書き出せ」と言っているはずです。気になることを全部inboxに入れて、それからじっくり「これは何であるのか？」「これは実行可能なことか？」「一週間以内に実行すべきことか？」などを考えて、トップダウンの枠組みの中に振り分けていくわけです。最初にinboxに入ったものの一部がTODOリストに振り分けられるわけです。

なので今回の講演の内容と比較すると、書き出しの部分はほぼ同じです。その後、GTDは「上から1つずつ見て、既存の枠組みで分類」するところに大きな違いがあります。この理由もGTDには明記してあります。1つずつ処理することで優先順位に悩まなくなること、他のものを優先したせいでチェックしないものが出たりしないこと、特に初回は時間がかかるので万が一中断されたとしても再開が容易なこと、など。

特に「いつかやる」リストは、たまに見なおしてみると同じこと関連したことを何度も書いていたりするわけですが、その何度かの記述をまとめてひとかたまりにするときはボトムアップのグループづくりに近い感覚だと思います。

** Q: 複数人の視点：意見を得るためには「自分の考え、現状」を伝える必要があるのではないか？⇔伝えていくうちに話しの幅が狭まって、結果的に局所的で、知識差が…という話になりかねない？

なるほど、京大サマーデザインスクールでのワークショップでは「書いてから考えよう」の段階で参加者に「自分の学び方について書き出してみよう」という演習をして、こちらの考えを全部伝える前にアウトプットさせました。今回はこちらの考えを伝えた上で、それに対する意見を聞く、というアプローチでした。

一つの方法論としては「自分の考えを部分的に伝える」があるのではないかな。例えば自分の中では「Aという問題がある。Bという方法で解決できると思うが、どうか」という状態だったとしても、まず「Aという問題があるのだが、どうすれば解決できるだろうか？」と聞いてみるとか、「～という現状があって、これにはAという問題があるのではないか？」と聞いてみるとか。

** Q: 「自分の思考」を追えるように残すことが大切？

「追う」と言うと、時系列の順番が重要というニュアンスが出てしまう気がします。それが有用な可能性もあるのですが、今回の講演の意図としては「脳の中にしかない情報を書いて消えなくすることは有用」でした。

** Q: Planばかりが浮かんでなかなかDoに取り組めない。Planの細分化が難しい。

なるほど、その方法論も言語化できると有益ですね。ちょっと今すぐには思いつきません。考えておきます。

** Q: トップダウンとボトムアップは状況によって選ぶほうがいいのでは？

その通りです。それは目的によって決まります。「予期しない、新しい結合を見つける」が目的であって、「書きだした付箋をボトムアップで組み上げる」は方法にすぎません。既存の知識が十分信頼できるなら、ボトムアップで組み上げることに時間を割くのではなく、トップダウンでテキパキ分類して作業を進めるほうが効率が良いでしょう。

** Q: 書きとめながら議論すべきでは？議論によって「量」が増える。

まさにその通り。たとえば「ブレインストーミング」のことを口頭でワイワイすることだと勘違いしている人が多いですが、考案者であるオズボーンは「出されたアイデアは全て書き留めろ」と著書に書いています。

** Q: 文章のアウトプットは応用としてのアウトプットになりえるのか？

文章をアウトプットする目的を明確にする必要があります。例えば「他人に自分の考えを伝えて、納得して、作業を手伝ってもらうこと」が目的なら、相手の中に納得が生まれて、手伝ってもらえれば「成功」です。その際に例えば「伝わりやすい文章の作り方」の解説を読んでその知識を使ったなら、それは「解説から得た知識を実際に応用してみた」ということになります。

他人に考えを伝えて、納得してもらえなかったら、それはCheckとAdjustのチャンスです。

** Q: 理解のためには抽象化することは大切であると思う。ただ、抽象化しすぎるのも本質を見失うおそれがあるので、そこのバランスは取るべき。

私は「実体験とのつながりを保っているかどうか」が良い抽象化と悪い抽象化の境界線だと思います。つながりが保たれていれば、それを介して具体的な応用に降りることができます。それが切れてしまうと、実用することのできない机上の空論になってしまいます。

** Q: 「知識は得るものではなく、個人で作るもの」という言葉には驚いた。知識は得るもので、知恵は個人で作るもの、知識の使い方は知恵である、ということなのでは。

あなたの中では知識に対してそういう抽象化されたモデルがあるということはわかりました。そのモデルを使うことで、具体的な応用として例えば何を説明できるのかがわかりません。

** Q: 教科書などを読むことで盲点が見つかると言っていたが、読んだものが間違っていると誤った先入観ができてしまうのではないか？もしくは読んだものが正しくても、勘違いしていた場合も誤った先入観ができてしまうと思う。誤った先入観や固定観念の修正はどうすればよいのか？

間違った教科書を読んで、もしくは教科書を間違って読んで、間違った理解を持ってしまったとしましょう。

1つ目の方法は「理解に基づいた行動」をして、結果を検証することです。

2つ目の方法は「別の教科書」なり「別の人の授業」なりを聞いて、その「現実」と自分の「理解」にミスマッチがないか観察することです。

** Q: 情報を図にして文章にするというのは、データをまとめたり新たなものを見つけるのにはいいと思うが、作業の量、時間がかかるので、そのための何かが必要だとは思う。

はい。本当に時間がかかります。これが有用な方法論で、かつ時間コストが高いのであれば、時間コストを削減するためのソフトウェアや方法論などに商業的価値があるわけです。

</body>

はてなダイアリー 2014-11-13