エンジニアのための 学ぶ技術 2015-10-27 BPStudy #98 サイボウズ・ラボ 西尾泰和
自己紹介 サイボウズ・ラボ 次世代のグループウェアの 基盤となる技術を研究開発 2
グループウェアって何？ 3
Group + Software 4
Douglas Engelbart 5 https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg
Douglas Engelbart マウス GUI ハイパーテキスト グループウェア 6 https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg
Augmenting Human Intellect ソフトウェアによって 人間の能力を増強する 7 "Augmenting Human Intellect: A Conceptual Framework" (1962)
Augmenting Group Intellect ソフトウェアによって 集団の能力を増強する ＝グループウェア 8
人間 コンピュータ
人間 人間+コンピュータ =増強された人間
人間 人間+コンピュータ =増強された人間
これが顧客価値 ソフトウェアを売るということ
Augmenting Human Intellect ソフトウェアによって 人間の能力を増強する 13 "Augmenting Human Intellect: A Conceptual Framework" (1962)
人間増強の四要素 • 1: 人工物(Artifacts) • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)
人間増強の四要素 • 1: 人工物(Artifacts) ←ソフトウェアなど • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)
増強方法はソフトだけではない • ソフトウェア（人工物）を作り出すこと だけが増強の方法ではない • 思考の助けになるような言葉を作り出す • 「やり方」を言語化・体系化する • そしてそれらの使い方を教育する
人間増強の四要素 • 1: 人工物(Artifacts) • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)←1～3を使うスキルの教育 ↑どんなよいソフトを作っても 使い方が理解さ...
筆者のソフト以外のアプローチ • 京都大学サマーデザインスクール • 「学び方のデザイン」灘校土曜講座 • 「エンジニアの学び方」技術評論社 • PyCon JP キーノート講演 • 「続・エンジニアの学び方」サイボウズ式 • サイボウズラボユ...
Q: 「学ぶ」プロセスの 最初の一歩は何か？ 19
新しいことを学ぶためには 盲点*に気づく必要がある 20 * 自分が知らないこと、かつ「知らない」ということに気づいていなかったこと
21 先入観なく現実を観察し、 自分の理解とのズレを探す
エンジニア向けの具体例 エラーメッセージをちゃんと読む 「きっとこうだ」と決めつけるのではなく 確認のコードを書く どこが遅いかプロファイル取ってから高速化 マニュアルを読め（たとえ英語でも） 自分の理解（＝思い込み）と現実のズレに注目 22
先入観なく見るのは難しい 23 ←見えていない
多くの視点を得ることで 先入観を減らす 24 “他人”の視点が有用
これは正しいか？ 知識多い人が教え 少ない人が教わる 知識多い 知識少ない
知識の少ない人からでも 学ぶことができる A B
× 自分以外から一方通行で学ぶ 「自分に教えられることはない」 という思い込みが作った心の壁
○ 互いに知識を交換して学ぶ
多くの視点を得ることで 先入観を減らす 29 “他人”の視点が有用
30 先入観なく現実を観察し、 自分の理解とのズレを探す
それが盲点を見つけ 学ぶために必要なこと 31
これを妨げるバッドパターン 「聞くだけ人間」と「言うだけ人間」 個人の問題ではなく 「『教わる役』『教える役』の固定化」 という構造的問題。 これを解消するにはどうすればいいか？ 32
まず「聞くだけ人間」を考える 「勉強会などで話す側に回ろう」耳にタコ 実行する人は少ない 自分が何を教えられるかがわからない →最初の一歩が踏み出せない 33
何を学ぶか 34
35 抽象的な知識ほど 応用範囲が広い
具体的問題の答えを覚える →その問題が解けるだけ 解き方(抽象的方法論)を学ぶ →新しい問題を解ける 36
抽象的な方法論を 具体的な問題を解かずに 学べるだろうか？ 37
自分の経験から抽象化を 繰り返して理解を育てる 38
経験という「根」と結びつかないと 応用できる知識にならない 39 根無し草の知識 応用 根のある知識
経験 40
「自分が経験したこと」は 自分が世界で一番詳しい 41
よくある例 発表者「失敗が怖い、間違えるのが怖い」 →教科書を丸写しして発 →質問されても「そう教科書に書いてあった」 としか答えられない →質疑が盛り上がらない 失敗を避けようとしたことによって より大きな失敗が引き起こさてれいる 42
間違えることを避けようとしない • 自分が「教える役」だと思っていると、 間違えることは失敗だと思うのかもしれない • でも「教えあう」が目的なのだから、 間違いじゃないかとつっこまれて議論をする そのプロセス自体が有益なもの • 教科書などの...
経験がメインディッシュ 自分はこういう経験をした(事実) (オプション)教科書にはこう書いていた(事実) 自分はこう理解した(解釈) →これなら聞いている人に 自分の解釈を言える余地がある 44
理解の検証について 45
自分の中で育てた「理解」が 応用できる知識かどうかは どうすればわかるのか？ 46
「理解した」は 仮説にすぎない 47
仮説は実験して検証しよう 48 検証： 思った通りの 結果になった？
エンジニア向けの具体例 プログラミング言語を学ぶ時： A: マニュアルを読んで理解した！終わり！ B: マニュアルを読んで理解した気がしたので 確認のためのプログラムを実装してみた！ 49
計画 行動 結果の考察計画の修正
仮説 実験 結果の考察仮説の修正
理解 行動 結果の考察理解の修正
53 先入観なく現実を観察し、 自分の理解とのズレを探す
「PDCAサイクルを回して学ぶ」 の最初の一歩は？ 54
「何か発表しよう！」 ↓ 「何を発表しよう…」 55
理解 行動 結果の考察理解の修正 最初の一歩はどう踏み出すのか？
書いてから考えよう 57
関係あるかもしれないことを まずは全部書き出して 覚えておく必要をなくす 58
具体例 「発表のネタになるかもしれない ものを付箋に50枚書く」 59
「発表資料を作ろう」は 大きくて計測不能なタスクなので やる気が失われがち 「ネタを付箋に50枚書く」は 計測可能で隙間時間で実行可能 60
書いたものを 机に広げる 61
62
人間の作業記憶は7個程度 書いたものを机に広げれば 100個をひと目で見渡せる 63 紙と机（人工物）による作業記憶の増強
ボトムアップで グループを作っていく 64
65
トップダウンに分類すると 既存の考え方の枠に情報を 押し込めているだけになる ボトムアップが重要 66 発表資料作りの今回の例であれば、ストーリーとして関連するものを近くに置く
束ねて 表札をつける 67
68
束ねて要約して表札をつけることで 見た目の枚数が減り脳の負担が減る 69
ボトムアップで集め、束ね、表札 チャンクを形成 70
図解化と文章化 71
72
図解は自分の理解の 全体像を整理するのに 向いている →しかし他人に伝わらない 73
図解は二次元 文章は一次元 人に話すときも一次元 人に伝えたいなら一次元 74
75 ↑ 文章としての アウトプット
文章化して他人に伝え フィードバックを得る 76
書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 最初の一歩はどう踏み出すのか？ 人に伝える フィード バック
書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 僕にとってこの講義は… 人に伝える フィード バック
「聞くだけ人間」脱出法 • 他人にアウトプットして フィードバックから学ぶ。 • 隙間時間で付箋を50枚書き、 ボトムアップで組み立てる。 • 「自分の経験」にフォーカスする。 自分が世界一詳しいテーマだから。
今ここまで終わった
「言うだけ人間」の問題 81
「言うだけ人間」の問題 「互いに知識を交換して学ぶ」を目指すうえで 聞くだけの人以上に問題なのが言うだけの人 過去の成功体験から自信と先入観が生まれる 82
年末の社内納会で、 自分のコンフォートゾーン （自分のぬるま湯）から抜け出て コンフォートゾーンを広げよう と、会社メンバーの前で話した 83 2015-10-14 - ビープラウド社長のブログ http://shacho.beproud.jp...
先入観・考え方の枠 コンフォートゾーン どうやって壊していくのか？ 84
枠を壊す流れ 1. 自分には既成の枠がある、と気づく 2. 自分の枠で判断するのではなく、保留する 3. 「枠を変えても意味がない」 という考えをのりこえる。 4. 「枠を変えるのが怖い」 という恐怖を乗り越える 85
エンジニア向けの具体例 エンジニアのNさんは自称「人間と話すより機械 と話す方が気が楽」な人。 ↓中略 「インタビュワーをやらないか」という打診が。 そんな経験はないし自信もない！ →でもやる(枠を変える恐怖の乗り越え) 86
「聞く」方法 聞く方法なんて学んだことない！ インタビューに関する本を10冊買って 全部付箋化してKJ法してみた 重要なコンセプトはさほど多くない。 87
相手の使う言葉は 自分が考える意味で 使われているとは限らない 88
顧客「タイムマシンを作って」 エンジニア 「そんなことできるわけないだろ」 89
相手が「タイムマシン」という 言葉で表現しようとしているものが 自分の考えるタイムマシンと 同じだと考えている 90
冷静に考えたらその前提が 事実でないのは明らかなのに 自分の枠で現実を歪めている 91
顧客「タイムマシンを作って」 エンジニア 「どんなタイムマシンですか？」 「そのタイムマシンがあることで 何がどうなるとよいのですか？」 92
前提に敏感になる 93
二者択一法(選択話法) 「Aという商品とBという商品の どちらがお好みですか？」 どちらかを買う前提が入っている →暗黙に前提を認めさせる 94
前提のある質問は 答えを引き出しやすいが 回答を歪めてしまう 95
「最近のお悩みは何ですか？」 →悩んでいることが前提 96
「最近興味を持った技術は？」 →技術に興味を持ったことが前提 97
勇気づけることが大事 98
言葉がなかなか出てこない人 話すことに自信がない人 話すことを勇気づけて やる気を引き出していく必要がある 99
「教わる役」「教える役」の固定化 を解消するには「教える役」が コンフォートゾーンを抜け出して 積極的に「教わる役」をやることが 重要なのではないか 100
「言うだけ人間」脱出法 • 「教える役」を抜け出し 「教わる役」をプレイする。 • 前提や単語の意味は自分と相手で違う。 自分の枠を相手に押し付けない。 • 相手が話すことを勇気づけ、 やる気を引き出していく。 101
○ 互いに知識を交換して学ぶ
多くの視点を得ることで 先入観を減らす 103 “他人”の視点が有用
104 先入観なく現実を観察し、 自分の理解とのズレを探す
それが盲点を見つけ 学ぶために必要なこと 105
書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 僕にとってこの講義は… 人に伝える フィード バック
書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 Question & Comment 人に伝える フィード バック
Upcoming SlideShare
Loading in...5
×

エンジニアのための学ぶ技術

236

Published on

BPStudy #98で講演した資料です

Published in: Education
0 Comments
3 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

No Downloads
Views
Total Views
236
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • まず自己紹介、サイボウズ・ラボっていう、サイボウズというグループウェアのシェアNo.1の会社の研究部門子会社
  • 何だと思う？
    言及不要：“Peter and Trudy Johnson-Lenz によって1978年に作られた用語” 『組織とグループウェア』p.63
  • ダグラス・エンゲルバート、知っている人？
  • 1960年代、コンピュータはまだ個々人の手元には普及していなかった。彼はコンピュータ普及後の世界を考えた人だった
  • 1960年代、コンピュータはまだ個々人の手元には普及していなかった。彼はコンピュータ普及後の世界を考えた人だった
  • 最近、人工知能とか色々と話題になることが多いですよね
  • 「コンピュータが人間のレベルに到達するのはいつかな」みたいなイメージを持たれることが多いのですが、これは物事の片面だけを見ている
  • コンピュータによって人間が増強され、もっと能力を上げる
  • コンピュータ（電子計算機）が生まれてまずは計算能力を増強した。単位時間に計算できることができることが増えた。インターネットが生まれて人間が単位時間にやり取りできる情報量が増えた。そして検索エンジンが生まれて、人間が単位時間に見つけることのできる情報が増えた。どんどん生身の人間との差は広がっていく。
  • ここで、人間の能力の増強についての話に戻りましょう
  • ソフトウェア、ハードウェア、システム、その他技術的だと僕らエンジニアがイメージするもののほとんどは人工物。
    人間増強の一つの方法にすぎない。
  • エンジニアにありがちな失敗として、よいソフトウェアを作ろうとか、よいシステムを作ろうとかそういう「人工物の改善」ばかり考えてしまって、実際にそれを使うユーザにどうやって使い方を習得させるかって視点が抜けていたりってことがある
  • 知らないこと、そして知らないということに気づいていなかったこと。それはどうやればいい？
  • 自分が知らないこと、かつ「知らない」ということに気づいていなかったこと。それはどうやればいい？
  • エンジニアリングの学びでは比較的容易
  • どうしても今までの経験から見えやすいもの見えにくいものができてしまう
  • この矢印が一方通行であるようなイメージを持ちがち。学生で、教わる役割を演じている。すぐそばに先生という教える役割を演じている人がいる。
  • AさんとBさんを比較するとAさんの方が知識の絶対量は多い、だけど得意分野がイコールでないならば、Aさんが知らなくてBさんが知っている知識が存在する。
  • これがよい状態。
  • 一休み
  • 一般論、例えば数学に関して考えてみる
  • 具体的な答えではなく、抽象化した「答えを得る方法」を学んでいる。じゃあこの抽象的な「方法論」はどうやって学ぶのか
  • 僕は無理だと思う
  • 本質的な知識は各人が自分で産み出さねばならない。
  • 抽象的なことを机の上で学んでも自分の経験と結びついていないと新しい問題に応用できない
  • キーワードは経験
  • 経験に基づいて育てた理解が、正しく応用できる「正しい理解」かどうかはどうすればわかるのか？
  • 勉強をしていてわかったという気持ちになることがあると思う
  • PDCAサイクル
  • 理解した気持ち→その理解に基づいて行動→結果が期待したとおりにならなかったら→理解を修正する。
    このサイクルを素早く回すことが大事。
  • 現実と理解のギャップ、盲点を見つける、それが学ぶために必要なこと
  • 囲み線や関係を書き足す。「これとこれは対立する」とか「これをこうするとこうなる」みたいな関係が見えてくる。
  • フィードバック期待してますよ！
  • 電話よりチャットがいい。人と話すのは苦手。これはずばりコンフォートゾーンに留まろうとしている。とどまっていてはいけないのでは、変わる必要があるのでは。
  • →昨日ファイルを上書きしてしまった→要するに欲しいのは定期的にバックグラウンドでバックアップする仕組みだな
  • 営業系のHowTo本にはだいたい書いてある。
  • 「聞くだけ人間」「言うだけ人間」という個人の問題ではなくて、役割を固定化させない、人と人の関係性の問題。
  • 一休み
  • フィードバック期待してますよ！
  • フィードバック期待してますよ！

    • エンジニアのための学ぶ技術

    1. 1. エンジニアのための 学ぶ技術 2015-10-27 BPStudy #98 サイボウズ・ラボ 西尾泰和
    2. 2. 自己紹介 サイボウズ・ラボ 次世代のグループウェアの 基盤となる技術を研究開発 2
    3. 3. グループウェアって何？ 3
    4. 4. Group + Software 4
    5. 5. Douglas Engelbart 5 https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg
    6. 6. Douglas Engelbart マウス GUI ハイパーテキスト グループウェア 6 https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg
    7. 7. Augmenting Human Intellect ソフトウェアによって 人間の能力を増強する 7 "Augmenting Human Intellect: A Conceptual Framework" (1962)
    8. 8. Augmenting Group Intellect ソフトウェアによって 集団の能力を増強する ＝グループウェア 8
    9. 9. 人間 コンピュータ
    10. 10. 人間 人間+コンピュータ =増強された人間
    11. 11. 人間 人間+コンピュータ =増強された人間
    12. 12. これが顧客価値 ソフトウェアを売るということ
    13. 13. Augmenting Human Intellect ソフトウェアによって 人間の能力を増強する 13 "Augmenting Human Intellect: A Conceptual Framework" (1962)
    14. 14. 人間増強の四要素 • 1: 人工物(Artifacts) • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)
    15. 15. 人間増強の四要素 • 1: 人工物(Artifacts) ←ソフトウェアなど • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)
    16. 16. 増強方法はソフトだけではない • ソフトウェア（人工物）を作り出すこと だけが増強の方法ではない • 思考の助けになるような言葉を作り出す • 「やり方」を言語化・体系化する • そしてそれらの使い方を教育する
    17. 17. 人間増強の四要素 • 1: 人工物(Artifacts) • 2: 言語(Language) • 3: 方法論(Methodology) • 4: 教育(Training)←1～3を使うスキルの教育 ↑どんなよいソフトを作っても 使い方が理解されなければ役に立たない
    18. 18. 筆者のソフト以外のアプローチ • 京都大学サマーデザインスクール • 「学び方のデザイン」灘校土曜講座 • 「エンジニアの学び方」技術評論社 • PyCon JP キーノート講演 • 「続・エンジニアの学び方」サイボウズ式 • サイボウズラボユース公開講座（準備中）
    19. 19. Q: 「学ぶ」プロセスの 最初の一歩は何か？ 19
    20. 20. 新しいことを学ぶためには 盲点*に気づく必要がある 20 * 自分が知らないこと、かつ「知らない」ということに気づいていなかったこと
    21. 21. 21 先入観なく現実を観察し、 自分の理解とのズレを探す
    22. 22. エンジニア向けの具体例 エラーメッセージをちゃんと読む 「きっとこうだ」と決めつけるのではなく 確認のコードを書く どこが遅いかプロファイル取ってから高速化 マニュアルを読め（たとえ英語でも） 自分の理解（＝思い込み）と現実のズレに注目 22
    23. 23. 先入観なく見るのは難しい 23 ←見えていない
    24. 24. 多くの視点を得ることで 先入観を減らす 24 “他人”の視点が有用
    25. 25. これは正しいか？ 知識多い人が教え 少ない人が教わる 知識多い 知識少ない
    26. 26. 知識の少ない人からでも 学ぶことができる A B
    27. 27. × 自分以外から一方通行で学ぶ 「自分に教えられることはない」 という思い込みが作った心の壁
    28. 28. ○ 互いに知識を交換して学ぶ
    29. 29. 多くの視点を得ることで 先入観を減らす 29 “他人”の視点が有用
    30. 30. 30 先入観なく現実を観察し、 自分の理解とのズレを探す
    31. 31. それが盲点を見つけ 学ぶために必要なこと 31
    32. 32. これを妨げるバッドパターン 「聞くだけ人間」と「言うだけ人間」 個人の問題ではなく 「『教わる役』『教える役』の固定化」 という構造的問題。 これを解消するにはどうすればいいか？ 32
    33. 33. まず「聞くだけ人間」を考える 「勉強会などで話す側に回ろう」耳にタコ 実行する人は少ない 自分が何を教えられるかがわからない →最初の一歩が踏み出せない 33
    34. 34. 何を学ぶか 34
    35. 35. 35 抽象的な知識ほど 応用範囲が広い
    36. 36. 具体的問題の答えを覚える →その問題が解けるだけ 解き方(抽象的方法論)を学ぶ →新しい問題を解ける 36
    37. 37. 抽象的な方法論を 具体的な問題を解かずに 学べるだろうか？ 37
    38. 38. 自分の経験から抽象化を 繰り返して理解を育てる 38
    39. 39. 経験という「根」と結びつかないと 応用できる知識にならない 39 根無し草の知識 応用 根のある知識
    40. 40. 経験 40
    41. 41. 「自分が経験したこと」は 自分が世界で一番詳しい 41
    42. 42. よくある例 発表者「失敗が怖い、間違えるのが怖い」 →教科書を丸写しして発 →質問されても「そう教科書に書いてあった」 としか答えられない →質疑が盛り上がらない 失敗を避けようとしたことによって より大きな失敗が引き起こさてれいる 42
    43. 43. 間違えることを避けようとしない • 自分が「教える役」だと思っていると、 間違えることは失敗だと思うのかもしれない • でも「教えあう」が目的なのだから、 間違いじゃないかとつっこまれて議論をする そのプロセス自体が有益なもの • 教科書などの「外部の権威」 を自分の発表の正当化に 使うとそのプロセスが 回らなくなる 43
    44. 44. 経験がメインディッシュ 自分はこういう経験をした(事実) (オプション)教科書にはこう書いていた(事実) 自分はこう理解した(解釈) →これなら聞いている人に 自分の解釈を言える余地がある 44
    45. 45. 理解の検証について 45
    46. 46. 自分の中で育てた「理解」が 応用できる知識かどうかは どうすればわかるのか？ 46
    47. 47. 「理解した」は 仮説にすぎない 47
    48. 48. 仮説は実験して検証しよう 48 検証： 思った通りの 結果になった？
    49. 49. エンジニア向けの具体例 プログラミング言語を学ぶ時： A: マニュアルを読んで理解した！終わり！ B: マニュアルを読んで理解した気がしたので 確認のためのプログラムを実装してみた！ 49
    50. 50. 計画 行動 結果の考察計画の修正
    51. 51. 仮説 実験 結果の考察仮説の修正
    52. 52. 理解 行動 結果の考察理解の修正
    53. 53. 53 先入観なく現実を観察し、 自分の理解とのズレを探す
    54. 54. 「PDCAサイクルを回して学ぶ」 の最初の一歩は？ 54
    55. 55. 「何か発表しよう！」 ↓ 「何を発表しよう…」 55
    56. 56. 理解 行動 結果の考察理解の修正 最初の一歩はどう踏み出すのか？
    57. 57. 書いてから考えよう 57
    58. 58. 関係あるかもしれないことを まずは全部書き出して 覚えておく必要をなくす 58
    59. 59. 具体例 「発表のネタになるかもしれない ものを付箋に50枚書く」 59
    60. 60. 「発表資料を作ろう」は 大きくて計測不能なタスクなので やる気が失われがち 「ネタを付箋に50枚書く」は 計測可能で隙間時間で実行可能 60
    61. 61. 書いたものを 机に広げる 61
    62. 62. 62
    63. 63. 人間の作業記憶は7個程度 書いたものを机に広げれば 100個をひと目で見渡せる 63 紙と机（人工物）による作業記憶の増強
    64. 64. ボトムアップで グループを作っていく 64
    65. 65. 65
    66. 66. トップダウンに分類すると 既存の考え方の枠に情報を 押し込めているだけになる ボトムアップが重要 66 発表資料作りの今回の例であれば、ストーリーとして関連するものを近くに置く
    67. 67. 束ねて 表札をつける 67
    68. 68. 68
    69. 69. 束ねて要約して表札をつけることで 見た目の枚数が減り脳の負担が減る 69
    70. 70. ボトムアップで集め、束ね、表札 チャンクを形成 70
    71. 71. 図解化と文章化 71
    72. 72. 72
    73. 73. 図解は自分の理解の 全体像を整理するのに 向いている →しかし他人に伝わらない 73
    74. 74. 図解は二次元 文章は一次元 人に話すときも一次元 人に伝えたいなら一次元 74
    75. 75. 75 ↑ 文章としての アウトプット
    76. 76. 文章化して他人に伝え フィードバックを得る 76
    77. 77. 書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 最初の一歩はどう踏み出すのか？ 人に伝える フィード バック
    78. 78. 書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 僕にとってこの講義は… 人に伝える フィード バック
    79. 79. 「聞くだけ人間」脱出法 • 他人にアウトプットして フィードバックから学ぶ。 • 隙間時間で付箋を50枚書き、 ボトムアップで組み立てる。 • 「自分の経験」にフォーカスする。 自分が世界一詳しいテーマだから。
    80. 80. 今ここまで終わった
    81. 81. 「言うだけ人間」の問題 81
    82. 82. 「言うだけ人間」の問題 「互いに知識を交換して学ぶ」を目指すうえで 聞くだけの人以上に問題なのが言うだけの人 過去の成功体験から自信と先入観が生まれる 82
    83. 83. 年末の社内納会で、 自分のコンフォートゾーン （自分のぬるま湯）から抜け出て コンフォートゾーンを広げよう と、会社メンバーの前で話した 83 2015-10-14 - ビープラウド社長のブログ http://shacho.beproud.jp/entries/2015/10/14
    84. 84. 先入観・考え方の枠 コンフォートゾーン どうやって壊していくのか？ 84
    85. 85. 枠を壊す流れ 1. 自分には既成の枠がある、と気づく 2. 自分の枠で判断するのではなく、保留する 3. 「枠を変えても意味がない」 という考えをのりこえる。 4. 「枠を変えるのが怖い」 という恐怖を乗り越える 85
    86. 86. エンジニア向けの具体例 エンジニアのNさんは自称「人間と話すより機械 と話す方が気が楽」な人。 ↓中略 「インタビュワーをやらないか」という打診が。 そんな経験はないし自信もない！ →でもやる(枠を変える恐怖の乗り越え) 86
    87. 87. 「聞く」方法 聞く方法なんて学んだことない！ インタビューに関する本を10冊買って 全部付箋化してKJ法してみた 重要なコンセプトはさほど多くない。 87
    88. 88. 相手の使う言葉は 自分が考える意味で 使われているとは限らない 88
    89. 89. 顧客「タイムマシンを作って」 エンジニア 「そんなことできるわけないだろ」 89
    90. 90. 相手が「タイムマシン」という 言葉で表現しようとしているものが 自分の考えるタイムマシンと 同じだと考えている 90
    91. 91. 冷静に考えたらその前提が 事実でないのは明らかなのに 自分の枠で現実を歪めている 91
    92. 92. 顧客「タイムマシンを作って」 エンジニア 「どんなタイムマシンですか？」 「そのタイムマシンがあることで 何がどうなるとよいのですか？」 92
    93. 93. 前提に敏感になる 93
    94. 94. 二者択一法(選択話法) 「Aという商品とBという商品の どちらがお好みですか？」 どちらかを買う前提が入っている →暗黙に前提を認めさせる 94
    95. 95. 前提のある質問は 答えを引き出しやすいが 回答を歪めてしまう 95
    96. 96. 「最近のお悩みは何ですか？」 →悩んでいることが前提 96
    97. 97. 「最近興味を持った技術は？」 →技術に興味を持ったことが前提 97
    98. 98. 勇気づけることが大事 98
    99. 99. 言葉がなかなか出てこない人 話すことに自信がない人 話すことを勇気づけて やる気を引き出していく必要がある 99
    100. 100. 「教わる役」「教える役」の固定化 を解消するには「教える役」が コンフォートゾーンを抜け出して 積極的に「教わる役」をやることが 重要なのではないか 100
    101. 101. 「言うだけ人間」脱出法 • 「教える役」を抜け出し 「教わる役」をプレイする。 • 前提や単語の意味は自分と相手で違う。 自分の枠を相手に押し付けない。 • 相手が話すことを勇気づけ、 やる気を引き出していく。 101
    102. 102. ○ 互いに知識を交換して学ぶ
    103. 103. 多くの視点を得ることで 先入観を減らす 103 “他人”の視点が有用
    104. 104. 104 先入観なく現実を観察し、 自分の理解とのズレを探す
    105. 105. それが盲点を見つけ 学ぶために必要なこと 105
    106. 106. 書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 僕にとってこの講義は… 人に伝える フィード バック
    107. 107. 書いて まとめて 図解化して 文章化 行動 結果の考察理解の修正 Question & Comment 人に伝える フィード バック

    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×