学び方のデザイン名古屋大学版加筆版

学び方のデザイン 2014-11-10 名古屋大学にて

サイボウズ・ラボ　西尾泰和

このスライドは名古屋大学で情報系の学生さんを対象に講演した資料に口頭でのやりとりと質疑を加筆したものです

プログラミング言語Pythonの国際カンファレンスPyCon JPで私が基調講演した内容を見て、今回のお話を頂きました。

今回正解を教えにではなく問題意識と暫定解を共有してアイデアを貰う為に来ました

　　

　　

2

こういう場だとよく「これが正しいんだ」という感じになりがちですが今回は僕が持っている問題意識と僕なりの暫定解を共有してそれに対して皆さんがどう反応するのかを学びに来ました

アンケート用紙を事前にお配りしています。講演中に心に浮かんだことはなんでも書いてもらって構いません。質より量が重視されます。

質の高いことを書こうとすると心のハードルが上がって何も書けなくなってしまいます。

今回正解を教えにではなく問題意識と暫定解を共有してアイデアを貰う為に来ました

　　

　　

3

なんでも自由に書いてもらって構わないのですが、「自由だよ」と言われると困惑する人もいるかもしれません。

例として「今まで自分が思っていたことと、講演で話されていることのギャップ」「講演を聞いていてつまずき、当惑、混乱を感じたところ」などもよいでしょう。

サイボウズ・ラボ !

次世代のグループウェアの基盤となる技術を研究開発

　　

　　

4

まず自己紹介

サイボウズというグループウェア国内シェアNo.1の会社の研究部門子会社。何を研究しているかというと

グループウェアってなんだかピンときます？グループウェアってアレだろ、とイメージわく人？(挙手)→予想通り少ない

グループウェアって何？

　　

　　

5

Group + Software

　　

　　

6

ダグラス・エンゲルバート、知っている人？→少ないコンピュータを普段使っている人→多い

ダグラス・エンゲルバードが何を発明した人か知っている人？→いないダグラス・エンゲルバードは、マウスとか、グラフィカルユーザインタフェースとか、

ハイパーテキストとか、グループウェアとかの発明に関わった人。多くの人が「コンピュータはでかい計算機だ」と思っていた時代に、

「これが普及して誰もが使うようになったら世界が変わる」と考えた人。

　　

　エンゲルバート"Augmenting Human Intellect: A Conceptual Framework" (1962)

7

Augmenting Human Intellect

ソフトウェアによって人間の能力を増強するコンピュータによって計算能力が上がるのはイメージしやすいと思う。情報を見つけ出す能力も、Google以前と以後でだいぶ変わったよね。

インターネット以前なんか図書館に行って図書カードで本を探していたわけだ。

エンゲルバートがどういうことを考えていたか、彼の論文のタイトルが

　　


8

Augmenting Human Intellect

ソフトウェアによって人間の能力を増強するそれから電子組版や電子ジャーナルができたことで、多くの分野で「PDFをネットからダウンロードして論文を読む」が可能になった。

以前は図書館で複写依頼をして、しばらく待って出てきたコピーを読んでいたわけだ。このように人間の能力がコンピュータによって強化されていくというのが

エンゲルバートが1962年に予想した未来だった。この論文もググればPDFで読める。

　　

　　

9

ソフトウェアによって集団の能力を増強する＝グループウェア

Augmenting Group Intellectここまでは人間個人の能力の強化だったけど、それだけじゃない

　eメール、チャット、Twitter、Facebook、これらのものが現れたことで人間と人間の間のコミュニケーションにも大きな変化が起こった。

弊社の例だと東京本社の他に大阪や上海やベトナムに拠点があるんだけど、そこの間ではビデオ会議とか自社のグループウェアとかが使われている。

　　

　　

10

ソフトウェアによって集団の能力を増強する＝グループウェア

Augmenting Group Intellect

Wikiが生まれて遠隔地と文章の共同編集することが用意になった。それによって百科事典を共同編集しようというWikipediaが生まれた。もちろん間違いもあるが、特に英語版は日本語版より充実度が高く、

参考文献から論文などへのリンクが貼られていることも多いのでサーベイに便利。

　　

　　

11

文章を与えるとコンピュータが単語の意味をベクトル化する

基礎研究の一貫として僕が今年の4月に出した本大雑把な解説をすると

似た意味の単語が似たベクトルになるような変換をすることができる。実際にオライリーの電子書籍を300冊ぐらい流し込んでみると…

　　

　　

12

Language

DBMS

OS

これは事前に「この単語はどういう意味か」などという情報は与えていない。大量の文章を単語列として流し込んだだけで似た意味の単語が近い位置に来る。

　　

　　

13

人間

コンピュータ

これは2013年の論文で、ブログやSNSでこの技術が面白いという話を聞いて論文PDFをダウンロードして読んで、電子書籍で出したわけです。

技術の進歩によって技術の進歩自体が加速している状況です。という話をすると

コンピュータの性能がどんどん上がって、いつか人間に追い付くだろう。いつ追い付いてくるだろうか。というイメージをされる方が多いが

僕はその見方にはあんまり賛成出来ない。

　　

　　

14

人間

人間+コンピュータ =増強された人間

すでに人間はコンピュータによって強化されている。 Google使う人間と使わない人間でどちらが単位時間あたりの生産性が高いか？

情報収集能力が増強されている分だけ同じ時間でもよりよいアウトプットが出せるはず。

それと同じように、いろいろな技術の進歩に従って、より一層技術を使う人間と使わない人間の生産性に差が出てくる。

例えば僕の蔵書400冊はテキスト化してEvernoteに入れてあるのでこのiPhoneでいつでも400冊の横断検索ができる。これは僕には役立っている。

　　

　　

15

人間

人間+コンピュータ =増強された人間

商業的価値

そしてこの差の部分に商業的価値が生まれる。商業的価値を考えない研究者も多いけど、私は営利企業で働いている。

ソフトウェアが商業的価値を生むということが研究のドライブフォースになる。さて、では「人間の増強」にはどんな方法があるだろうか？

　　


16

人間増強の四要素

• 1: 人工物(Artifacts)

• 2: 言語(Language)

• 3: 方法論(Methodology)

• 4: 教育(Training): 1～3を使うスキルを身につける

エンゲルバートが考えた

　　


17


• 1: 人工物(Artifacts)　←ソフトウェア




我々エンジニアはついつい「ソフトウェアで解決しよう」と考えてしまいがちだがそれは「人工物」だ。４つある方法の一つにすぎない。

ソフトウェアだけに偏るのではなく他の手法もバランスよく使う必要があるだろう。

　　


18





• 4: 教育(Training): 1～3を使うスキルを身につける↑どんなよいソフトを作っても

使い方が理解されなければ役に立たない

またエンジニアにありがちな失敗として「よいソフトを作ろう」だけに集中しユーザがどうやって使い方を習得するのかの視点が抜けていて使い方を理解されない例

研究としては新規性はあればよいかもしれないが、ビジネスとしてはユーザが習得して使いこなして

価値を生まなければ成立しない

　　

　　

19

全人類を増強＞顧客を増強＞自社内を増強＞自分を増強身近な方が難易度が低い

もう一点、一般的な原則として

全人類を増強しようとすると漠然としがちターゲットを絞ったほうが具体的な方法論に落とし込みやすい

　　

　　

20

具体例：論文をもっと読む• “研究室の生産性を上げるためにメンバーがもっと論文を読むことが必要だ”

• How？支援ソフトウェア？(人工物) 速読法？(方法論)

• そもそも本当に必要なことはなにか？

そこで具体例としてこういう問題を解決することを考えてみましょう

この問題をあなたならどう解決する？

　　

　　

21

実装例：輪講• アウトプットのデッドラインを設定することでインプットせざるをえなくする施策

• 「自分から論文を読もうとはしない」タイプの主体性のない人は「ルールです」と天下りすれば動かしやすい

• 自発的に読んでる人の、読む速度の改善には有効ではない

この実装例は有用なので多くの研究室で採用されているが、しかし

どうすればこの問題が解決できるだろうか？たとえばword2vecで読む対象を可視化することで速度の改善につながる？研究者の研究能力向上の需要は高いが、現状、広く使われている方法はない。

　　

　　

22

本を読んだり論文を読んだりする速度の増強は個人的にもニーズがある。 !

ところでGoogle Booksが著作権侵害で訴えられた件を知っている人？→1人その結果どうなったか知っています？これ合法判決が出たんですね。

つまりGoogleが本をスキャンして検索可能にすることはアメリカでは合法である、と。 !

一方、日本では最近、書籍のスキャン代行業者が違法判決を受けました。つまり業者が業として書籍のスキャンをすると、日本では複製権の侵害である、と。

もちろんGoogleの方はスキャンしたデータをインデックス化するだとか細かい状況は違っているので一概には比較できない。

!こういう状況下でどうやって技術による人間の読書能力の支援が可能になるか？一つの方向性としてはインデックスなりword2vecみたいなベクトル化なり

「元の文章の形」を留めないことで複製ではなくするとか？ !

こういう方向性の研究が今後進んでいくのではないかと考えている。

　　


23






話戻りまして

僕もソフトウェアエンジニアなのでついつい「人工物」に偏りがちでもっと2～4を強化することにリソースを割り振ろうと考えている

　　

　　

24

2～4強化のアプローチ• 京都大学サマーデザインスクール • 灘校土曜講座 • 「エンジニアの学び方」技術評論社 • 「続・エンジニアの学び方」サイボウズ式

3日間のワークショップで「学び方のデザイン」を参加者と考える

ワークショップ「学び方のデザイン」を1コマの授業に圧縮して中高生に教える

雑誌の特別企画で、新社会人向けに解説（Webで読めます）

会社ブログで連載中。いろいろな人に学び方についてインタビューなど

新しいことを学ぶためには盲点に気づく必要がある

　　

盲点：知らないこと、そして知らないということに気づいていなかったこと　

25

その中から見えてきた暫定解をいくつか紹介

新しいものを学ぶためには「あ、自分はこれを知らない」と気づかなきゃいけない。「自分はこれを知らない」と気づかなければ、学ぼうという気持ちは湧いてこない。

では、どうすれば盲点に気づくことができるか？

教科書が与えてくれる !

教科書がない分野はどうすればいい？

　　

　　

26

教科書を読むと、いろいろなことが書いてあって「ああ、これは自分は知らなかった。学ばなきゃ」となる。スピーディに進むことができる。整備された道のようなもの。しかし、すべての分野に整備された教科書があるわけではない。

どうすればいいだろう？

現実を先入観なく観察する

　　

「こうなっているはず」という自分の理解との食い違いを見つける　

27

自分の中に「きっとこうだろう」という理解がある。しかしそれは必ずしも現実と一致しない。これが学びのチャンス。

プログラミングに例えるなら「きっと動くだろう」と思って実装したのにコンパイルしてみるとエラーになる。これも理解と現実のギャップ。学びのチャンス。

ケアレスミスの時もあるけど、言語仕様を誤解している時もある。

先入観なく見るのは難しい

　　

　　

28

←見えていない

プログラミングの場合はコンパイラがチェックしてくれるから楽。でも一般的には先入観なく観察するのは難しい。

ついつい自分の過去の経験から見えやすいもの見えにくいものができてしまう。

たとえば100本の論文から図の部分だけ抜き出して一覧を作ろう、というときそれをやるソフトウェアを書こうという発想が一番に出てくる。他には？

例えば自分で手作業で抜き出すというのも方法。他には？アウトソースとかもある。

多くの視点を得ることで先入観を減らす

!

　　

　　

29

“他人”の視点が有用

学べば学ぶほど自分が学んだことに視点が偏ってしまう、ならば

知識の多い人と少ない人がいる

　　

　　

30

知識多い

知識少ない

知識多い人が教え少ない人が教わる

　　

　　

31

知識多い

知識少ない

この矢印が一方通行であるようなイメージを持ちがち特にみなさん学生なので「教わる役」という役割があり、そばに「教える役」を仕事にしている人がいるから、

その役割分担を固定化してしまいがち

知識の少ない人からでも学ぶことができる

　　

　　

32

右の人は知識の総量が半分しかないが左の人は右の人からも学ぶことができる

自分以外から一方通行で学ぶ

　　

思い込みで壁を作りがち　

33

ついつい自分には知識が少なく自分以外から一方通行で学ぶしかできない

と思い込みがち。でもこれは自分の信念によって自分の能力を制限している状態。

互いに知識を交換して学ぶ

　　

　　

34

思い込みの壁を壊せば互いに知識を交換して学ぶということが可能

何を学ぶか

　　

　　

35

何を学ぶのが良いと思う？

この疑問に僕が暫定解を出したプロセスは今回は割愛したので、興味がある人は

「灘校土曜講座学び方のデザイン」で検索してください

抽象的な知識ほど応用範囲が広い

　　

　　

36

例えば数学の問題を解くことを考えてみよう

特定の問題の答えを覚えるのではなく

「見たことない問題」を解く能力を学ぶ

　　

具体的な答えではなく、抽象化した「答えを得る方法」を学んでいる　

37

具体的な問題を解かずに解き方だけを学べるか？

　　

　　

38

抽象的な知識を効率良く得たい、じゃあ

自分の経験から抽象化を繰り返して理解を育てる

　　

プラトンは哲学を産婆術に例えた。本質的な知識は各人が産み出さねばならない野中郁次郎・紺野登(2003)『知識創造の方法論―ナレッジワーカーの作法』東洋経済新報社, p.33

39

プラトンは哲学を産婆術に例えた。本質的な知識は、本を読んで自分の中に取り込むような方法では得られない。個々人が自分で生み出さなければならない。哲学ができるこ

とは生み出すプロセスを助けることだけである。

僕もこれが一番しっくり来る。自分の経験とボトムアップで結びつけていく…

経験と結びつかないと応用ができない

　　

　　

40

根無し草の知識

応用

根のある知識

なんで経験と結びつく必要があるのか。たとえば哲学の本を読むと例えば「知識とは正当化された真なる信念である」とか書いてあるわけですよ。

これを読んで覚えたとする。で、それは何に使えるの？オウム返ししかできない。

経験と結びつかないと応用ができない

　　

　　

41

根無し草の知識

応用

根のある知識

数学を例に上げると、公式とか解法を丸暗記しただけじゃ問題が解けるようならない。抽象度の高い解法の知識を、具体的な問題の解き方と結びつけている、

中間層の知識があるはずで、これが欠けていたのでは応用することができない。

実世界の問題に応用できない知識はなにも価値を産まない

　　

　　

42

価値が生み出せるレベルにきちんとした、経験と結びついた知識の体系を自分の中で育てていく必要がある。

応用して価値を生み出すことができる知識の体系を自分の中で育てるには？

　　

どうすればいいのだろうか？　

43

“わかった” は仮説にすぎない

　　

　　

44

これは2013年の京大サマーデザインスクールの講義資料を作っている時に自分の中で結晶化した考えなんだけども

勉強していて「わかった」と思う瞬間があると思う。「わかったわかった、次の問題も解けるだろ」と思って解いてみたら、解けなかったりする。つまり「わかった」ってのはあくまで仮説。

仮説は実験して検証しよう

　　

　　

45

　PDCAサイクル

　　

計画行動

結果の考察計画の修正

46

マネジメントを勉強しているとPDCAサイクルってのがよく出てくる。計画して行動し、行動の結果を見て、計画を修正する。このサイクルを回すことで

より良い計画、より良い行動へと育てていこうという考え方。

　PDCAサイクル

　　

仮説実験

結果の考察仮説の修正

47

科学的方法論も似た構造を持っている。仮説を立てて実験し、結果を考察して仮説を修正する。

　PDCAサイクル

「うまくいくと思って行動したけど失敗した」が理解修正のチャンス　

理解理解に基づく

行動

結果の考察理解の修正

48

物事の理解も同じで、理解に基づいて行動し、結果を見て理解を修正する。

このサイクルを小さく回すことで素早く学ぶ

　　

例えばプログラミングなら小さいプログラムを書いて動かすビジネスなら最小限の製品を作ってリリースしてみる

　

49

プログラムを1000行書いてから大量のコンパイルエラーを見るよりもっと小さい単位でPDCAサイクルを小さく回す。

Dropboxの例（詳しくは “リーンスタートアップ” を参照）

最初の計画、仮説、理解はどうやって作るのか

　　

　　

50

しかし、

これに関してPDCAサイクルは何も答えてくれない

　　

　　

発散干渉

成長

収束選択

整理

発表

付箋づくりグループ編成

図解化A型

書き出し

発表資料づくり

B型

京都大学サマーデザインスクールで3日間掛けて行ったワークショップのでは自分の学び方の盲点を見つけ、改善計画を建てることを目標とした

書いてから考えよう

　　

　　

52

具体的にどういうことをやっていったか見てみようまず最初の原則は：

なぜか？

どちらが簡単？ !

・暗算・筆算

　　

　　

53

筆算のほうが楽だよね（そろばんの上級者でもない限り）

どちらが簡単？ !

・頭の中だけで考える・書いて、見ながら考える

　　

　　

54

頭のなかだけで考えるというのは暗算に似た状態。覚えて、かつ、考えないといけない。

書いて見ながら考えるのは、紙が覚えておいてくれる。筆算と似ている。

まずは全部書き出し “覚えておく負担”をなくし考えることに集中しよう

　　

　　

55

これが「書いてから考えよう」という原則の理由具体的な演習としては…

京大サマーデザインスクール2014演習課題

他人が読める字で。この演習では質ではなく量が評価される。時間は2分　

学び方の改善に「関係あるかもしれないこと」を時間内に数多く書いてみよう

56

2分間のタイムトライアルで書いてください。質より量が評価されます、数多く書いてください。

こういう演習を質問の内容を変えて何回か繰り返していくと脳内の情報がどんどん書き出されていく

こういう演習初めての人はなかなかスラスラ書けない

　　

訓練すると書けるようになる　

57

みなさんイメージしてみてください。今から2分間で書いてください。戸惑ってしまう人も多いかと思います。

書けない理由を掘り下げてみると、いくつかのパターンがある。その中でも一番よくあるパターンは：

完璧主義がハードルを上げる

　　

　　

58

ハードルを下げないとたくさん出すことはできないのに、自分でハードルを上げてしまい、量を出すことができない

“アイデアは一時に　完全な形で現れるものだと思っている人が多いが　そんなものではない”

トーマス・エジソン

　　

p256A.オスボーン(2008)『創造力を生かす : アイディアを得る38の方法』豊田晃訳, 創元社

59

あんだけたくさんのアイデアを出したエジソンもこう言ってる：

彼も、アイデアはまず完成度の低い状態で出てきてそれを磨き上げて良い物にしていくんだ、と言っている

最初から完璧なものを作ろうとして手が止まる

完成度高めるのは後でやろう

　

　　

60

のは良くない状態。そうではなく、まずは書いてみて

という発想の転換をすると、たくさんアイデアを出せるようになる。でも、質が大事なのではないか？と思う人もいるだろう。でも、自分の中で良い状態にしてから出そうと思って、

心の中だけに置いていると、ちょっとした割り込みですぐ忘れてしまう

書いたものは改善できる書かなかったものは消えてしまう

　

　　

61

割り込みなしにずっとそのことだけを考えていられる状況でもない限り「質の高いアイデアを作る」を達成するにはまず「質の低いものを書く」ことで

消えない形に変換してから時間を掛けて徐々に改善する

本の内容をまとめるなら本の内容だけではなく思ったことすべて書き出す

　　

　　

62

例えば本で勉強した内容を後でまとめようと思う人多いと思います。マーカーで線を引いたり、ノートに抜書きしたり…でも重要なのは

本を読んでいる時に思ったことは、書き留めなければすぐ忘れる。抜き書き作って、1年後に読み返し「なんでこれを抜書きしたんだろう？」とかなる「どうしてこれが重要と思ったのか」「これが自分にどう関係あると思ったのか」

という大事な情報が失われている。文脈が失われた断片になってる。

本の内容をまとめるなら本の内容だけではなく思ったことすべて書き出す

　　

　　

63

先ほどの演習は自分の脳内の情報をまず外に出そうというものだったけど、本を読んでいる時にも本に書かれた内容だけではなく、

読んだことで思い出した過去の経験や、思ったこと感じたことがあったはず。それは脳の外に出さないと消えてしまう。だから書き出す。

盲点に気づく良い方法

他人に意見を聞いて判断保留して書き留める

　　

ついつい「それは違うだろ」とか「それは関係ない」とか判断しがち　

64

先ほど

として「他人に話を聞く」というのがありました。ところが人に話を聞きに行ったのに議論を始めてしまうことがある。やりがち。他人の話に「それは違うだろ」と反論したり「それは関係ない」と切り捨てたり。目的は「自分の視点から見えないもの、自分の脳内にない情報を得る」なのだから

相手が自分の考えと違うことを言い出したら収穫のチャンス。

じっくり聞いて書き留めて持って帰って、後からじっくり考えればいいのに。「少なくともこの人からはそう見えている」「この人は関係あると思っている」

「なぜそう思うんだろう？」と考えて話を聞くほうが有用。

　　

　　

65

特に我々は、科学の用語をメタファーとして使われるとイラッとしがち。 !

最近あった話としては「これは熱力学の法則と関係があると思う」と言われて「は？何を言ってるんだ？それのどこが熱力学だ？」と反発する心が生まれた。

!でも「少なくともこの人の脳内では『熱力学』のメタファーで捉えられているんだな」

「脳内にどういうモデルがあるんだろう」と考えなおして「それはどういう点が熱力学に似てるんですか？」と質問した。

!「オープンシステムだから」という解答でなおさらわからなくなった。

「システムが開かれるとその後何が起こるのか？」「自己組織化が起こる」「オープンであるとはどういうことか？」「外からの影響」などとやりとりした結果僕の中で「過冷却の水が外部からの衝撃で結晶化する現象」のメタファーで

理解をすることができ、有益な結果に結びつけることができた。 !

最初に「それのどこが熱力学だ？」と反発して耳をふさいでいたら得られるものも得られなかっただろう。

書いたものを机に広げる

　　

　　

66

話がだいぶそれてしまいましたが、「書いてから考えよう」という話でした。「書いてから考えた結果付箋が100枚くらいになっちゃったどうしよう」

その次どうするかというと：

具体的には…

　　

　　

67

これは京大サマーデザインスクールの2013年の講義資料を作ってるところ

一時記憶は7個程度書いたものを机に広げれば 100個をひと目で見渡せる

　

　　

68

でも

一時記憶を物理的な人工物を使うことで拡張できる方法論だ拡張された一時記憶を使って物事を考えたほうが生まれつきの7つの一時記憶だけで考えるよりも

より生産性が高くなるように、少なくとも僕は思います。

ボトムアップでグループを作っていく

　　

　　

69

この広げたものをどうするか？次は：

なぜか？

何のために？ !

情報量が多いと脳が考えることを拒否してしまう。数枚のグループにするとアイデアが出やすくなる。

　　

　　

70

　　

　

ボトムアップが重要トップダウンに分類すると既存の考え方の枠に情報を押し込めているだけになる

　　

　　

72

重要な事は

これでは盲点に気づくという目的を達成することができなくなる

目的は予期しない構造の発見

　　

書いたり広げたりまとめたりは手段　　予期しない構造＝盲点　

73

既存の考え方で分類すると新しいものが生まれなくなる

表札をつけて束ねる

　　

　　

74

グループができたらどうする？次は：

何のために？ !

場所を変えているだけでは枚数が多い状況は変わらない

束ねることで見た目の枚数を減らす

　　

　　

75

少し構造化されてきただけで、情報洪水の状態は変わらない、そこで

グループの複数枚を束ねて、グループの内容をなるべくうまく表現した「表札」を上につける。

　　

　　

77

ボトムアップで組み合わせて圧縮していくプロセスはさっき出てきたこの図と関係がありそうだね

図解化と文章化

　　

　　

78

表札作りをした後どうするかというと：

をします

　　

図解化の例　

79

　　

図解化の例　

80

付箋を束ねただけでは「関係のありそうなものが近くにある」というだけで、その関係がどういう関係かという情報がない実際にやっていると「これとこれとは対立関係にある」「そして対立関係を解消するためにこれがあるんだ」

などという考えが出てくる。これを「書き留めないと忘れてしまう」ので書き留めていくと、勝手に図解が出来上がる。

図解は全体像を見るのに向いている

文章は飛躍がないかを確認することに向いている

違うフォーマットに変えることで足りない部分に気づきやすくなる

　　

　

図解化の次に文章化をする、それはなぜか？

「AとBは対立していて、Cがそれを解決するんだ」みたいな構図を確認しやすい

図解を元に文章を書いていくと、うまく話がつながらないところが出てくる。「この図解で『わかった』から説明できる」という仮説を文章化によって検証すると

「うまくつながらない」という学びのチャンスが得られる

新しい発見がある。日本語の論文を英語で書き直すと論理のギャップが見つかるとかスライドで発表するのはできたけど論文にしようとしたら話がつながらないとか

そういうのもフォーマットを変えることによる発見の例。

　　

　

特にスライドで箇条書きを多用している人は文章化してみると盲点に気づきやすいかも。箇条書きっていうのは図解に近い表現方法で

「AとBとCは関連があると思うのでまとめておきました」という状態。これを文章にすることを考えると

「Xには3つの方法がある。AとBとCだ」かもしれないし、「Xという状況でAが起こると、それによってBが起き、Cに至る」かもしれない。

　　

　　

83

図解→

↑文章としてのアウトプット

図解したものを具体的な文章にしてアウトプットするのは、応用

文章にすると他人に伝えやすい

文章化してアウトプットし他人のフィードバックを得る

　　

　　

84

文章にするとか、プレゼン資料を作ってプレゼンするとか、他人に伝えるためのフォーマットにして伝えることで、

フィードバックが得られる

　　



行動


85

アウトプットすると結果の考察ができるようになる。自分の理解に基づいて他人に伝え、

その他人がどう反応したかという結果を考察することで自分の理解を改善するきっかけが得られる。

　　



行動


86

今回のこの発表も僕の「理解に基づく行動」でした。結果を考察して、理解を改善していきたいと思っています。

異論反論大募集どんなコメントが来るか楽しみにしています。

　

　　

87

質疑応答

　

　　

88

Q: 固定観念が激しい人をなんとかするにはどういったアプローチがあるか？

　

　　

89

A: それは他人を変えようとしてますよね。「自分は観察者であって変わらず、対象者を変えよう」というアプローチはうまくいかないという研究結果があるらしい。

　

　　

90

追記: 「Xさんが話を聞かない人だから問題が起きる」というのはあなたの解釈であり、あなたがその解釈に固執して行動を変えないのであればあなたもXさんと大差ない。

　

　　

91

Q: 「他人に話を聞く」って聴きやすい人は友人などで彼らは自分と価値観が近い。もっと遠い人に聞くべきか？

　

　　

92

A: 価値観の近い友人も100%自分と同じではないので、ある確率で盲点に気づく助けになる。聞くのに掛かるコストが安くて確率が低い人と、コストが高くて

確率も高い人とどちらを選ぶかという問題。

　

　　

93

A: やりたいほうからやって、そこから徐々に広げていくのが良いかと。

いきなり全然分野の違う人に話を聞きに行くのもハードルが高いしね。

追記:「ハードルを下げる」「最初から完璧を目指さない」

　

　　

94

Q: 相手を変えようとするのではなく自分が変わるという話だが、

チームとして見ると自分が変わることで結果として相手も変わるということが

あるのではないか？

　

　　

95

A: Yes、ただどちらがやりやすいかというと自分が先に変わるほうがやりやすい。ターゲットが身近な方がやりやすい。人類の強化より、自分の強化の方が

やりやすいのと同じ。

　

　　

96

A: 「相手が間違っている」というあなたの解釈は正しいか？彼は狂っているわけではなく、しかもそれなりに頭がいいはず。ただ、彼の今までの経験やそれに基づく物の見方によって、ある特定の思考のパターンを取っており、それがあなたと異なる。なら、そのパターンとはどういうものか？

　

　　

97

A: Xさんの思考のパターンがを、観察し解明していく必要がある。おそらくあなたの思考のパターンとは異なっており、その結果、出てくる結論が

異なったものになるのだろう。そのギャップを埋めるためには、まず

ギャップについての情報を集める必要がある。

　

　　

98

追記:

“自分は変わる必要はないがXさんは変わる必要がある”という主張は正しいのか？

　

　　

99

Q: チームワークとしてみた時に、周囲の意見と異なった意見を出すXさんを

「喜ばしいものだ」と考えて周りのみんなが変わり

受け入れていくべきなのか？コスト対効果を考えると…

　

　　

100

A: Xさんの意見Aと周囲の意見Bが異なっている時に「Xさんの意見Aに合わせるべき」と言っているのではない。両方を踏まえた上で別の意見Cに到達する必要があるので

はないか？

　

　　

101

A: 理想としては「チーム一丸となって進みたい」のだろう。ところが大部分がB案なのにXさんがA案を主張しているのが現実。

その問題（理想と現実のギャップ）を解消したいのであれば、その現実が一体なぜ起こっているのか詳しく知る必要がある。

　

　　

102

A: 自分の視点から見ると「Xさんが悪い」と見えるかもしれないがそれは一旦、判断保留しておいて、

「Xさんから見るとどう見えているのか」についての情報収集が必要。

　

　　

103

A: 情報収集したあとどういう結論になるかはわからない。やっぱりB案がいいと思うかもしれないし、意外とA案がいいと思うかもしれない。X

さんがA案を推す理由がわかったら、B案を修正して両方が満足する案にできるかもしれない。

!

現状でどうしようと考えてもわからない。なぜならXさん視点の情報が不足しているから。

　

　　

104

Q: （詳細シチュエーション省略）こういう人を受け入れるのは大変じゃないか？

　

　　

105

A: 「彼の問題行動を受け入れろ」と言ってるわけじゃないですよ。「彼がなぜそういう行動をしているのかについての情報を収集しなければ、彼の行動によってあなたが不利益を被る状況を変えることはできない」と言ってるのです。

　

　　

106

A: 「彼の行動」と「それを受けてあなたの感じた感情」は、あなたの視点から見てわかりやすい。だけど「あなたの行動」と「それを受けて彼が感じた感情」は見えにくい。今の話を聞いているとそちらを無視しているように聞こえる。そちらをもっと掘り下げていく必要があるのではないか？

　

　　

107

Q: 彼に直接聞くことは難しいのではないか？

　

　　

108

A: 彼に直接聞くことだけが情報収集の手段ではない。彼をよく知る人や付き合いの長い人などに

聞くことはできないか？

　

　　

109

Q: 人間増強の四要素の「言語」がよくわかりません

　

　　

110

A: 例えばデザインパターンってわかる？プログラミングであるパターンの構造を作るとある目的を達成するのに有用という知見がある。だけどそれに名前がついていないと扱いづらい。例えばプログラミングで6つの部品があってそれぞれが通信をする必要があるとしよう。それぞれがお互いに通信すると15本の接続が必要になる。

　

　　

111

A: しかし真ん中に通信を仲介する部品を置いて、それぞれの部品は仲介者とだけ通信すれば接続の本数は6本で済むようになる。

!

この解決方法にはデザインパターンでは「メディエイター（仲介者）パターン」

という名前が付いている。

　

　　

112

A: 名前が付いていることによって、類似の問題に出会った時に

「あ、これ仲介者パターンでいけるんじゃね」と気づきやすくなる。

「ここのコード、仲介者パターンにした方がいいんじゃない？」と設計についての議論のコミュニケーションもスムーズになる。

　

　　

113

A: 皆さんの研究分野にも、研究者同士だけで通じて一般の人には通じない「専門用語」があると思う。これによって

議論や思考が効率化されている。 !

例えば「オペレーティングシステム」って一般の人には通じないらしい。

　

　　

114

Q: 抽象的な情報と具体的な経験の結合の話がよくわからない

　

　　

115

A: 例えば今、抽象的なことを学ぼうと思って哲学の本を買ってきて読んだとして、しっくりきます？こないよね。

どういう時にしっくり来るのかというと自分の経験と「あ、これがあれか」と結びついた時なのだと思う。

　

　　

116

A: 例えばさっきの仲介者パターンの話も「仲介者パターンというものがあります。これはこういう構造で、こういうメリットがあります」ってプログラミング未経験者に説明しても

ピンと来ない。 !

自分でそういう状況に悩んだことがあれば「あ、こういう時にこれをやればよかったんだ」

としっくりくる。

　

　　

117

Q: アルゴリズムを作っていくみたいな？

　

　　

118

A: アルゴリズムを作るのも、もっと抽象的な知識があって、それを具体的な目的のためのアルゴリズムとしてアウトプットするということだよね。

で、そのアルゴリズムが正しかったかどうかは、実行して結果を見ることでわかる。正しくなかったら葛藤が生じる、そして葛藤を解消することでアルゴリズムを生み出した抽象的な知識も含めて

改善される。

　

　　

119

CheckDo Adjust

　

　　

120

追記：応用のDoによって具体化して出力、 Checkで発覚した現実との差を、遡りながらAdjust

Q: ボトムアップに主観を入れずに組み上げるのは難しいのでは？

　

　　

121

A: 難しいです。組み立てるところで主観を入れないようにしようとするとグループを作れなくなってしまう。「なんとなくこれがグループになりそう」ってのは主観だから。なので、データを集めるところで主観を入れないようにする。

　

　　

122

A: あとは、分類をしようとするのはありがちなミス。そうではなく、部分部分がなるべくそれ単体でストーリーを持つように工夫する。

　

　　

123

Q: ボトムアップのアプローチは機械的な支援に向いているのでは？

　

　　

124

A: これを支援するシステムはぜひ作りたい。特に、現状紙でやっているのはめんどくさい。なのでデジタル化したい。デジタル化したら関連付箋をサジェストしたりとかできるかも。

!

実はプロトタイプは作ったんだけど、Google Docs APIで作ってたらAPIが変わったのかいつの間にか動かなくなっていてデモが出来ない

　

　　

125

A: ボトルネックとしては画面のサイズが辛い。机の上に広げると結構な広さを使えるが、そのサイズのタッチ入力可能なモニターは

まだまだ高い。 !

まあ、いずれそういうものがもっと安価になって手軽に使える時代が来るだろう

　

　　

126

A: デジタル化すると何が嬉しいって、履歴の情報を持つことができるから

「以前はここにあったけど、その後移動した」という情報を取ることができる。

!

一度作った付箋を再利用した時に、以前に作ったグループ編成の情報を使って

編成のサジェストができる（有用かはさておき）

　

　　

127

A: この講義資料を作った時の付箋と他の講義資料を作った時の付箋が全部電子化されて、再利用されて、後からどの付箋がどこで再利用されて

スライドのや文章のどの部分になったのかをトレースできたらきっとすごく面白いと思う。僕がどういう脳内の構造でこれを作ったかを

知ることができる。

　

　　

128

Education

学び方のデザイン名古屋大学版 加筆版

学び方のデザイン名古屋大学版加筆版