1.
エンジニアのための
学ぶ技術
2015-10-27 BPStudy #98
サイボウズ・ラボ 西尾泰和

2.
自己紹介
サイボウズ・ラボ
次世代のグループウェアの
基盤となる技術を研究開発
2

3.
グループウェアって何？
3

4.
Group + Software
4

5.
Douglas Engelbart
5
https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg

6.
Douglas Engelbart
マウス
GUI
ハイパーテキスト
グループウェア
6
https://commons.wikimedia.org/wiki/File:Douglas_Engelbart_in_2008.jpg

7.
Augmenting Human Intellect
ソフトウェアによって
人間の能力を増強する
7
"Augmenting Human Intellect: A Conceptual Framework" (1962)

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

9.
人間
コンピュータ

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

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

12.
これが顧客価値
ソフトウェアを売るということ

13.
Augmenting Human Intellect
ソフトウェアによって
人間の能力を増強する
13
"Augmenting Human Intellect: A Conceptual Framework" (1962)

14.
人間増強の四要素
• 1: 人工物(Artifacts)
• 2: 言語(Language)
• 3: 方法論(Methodology)
• 4: 教育(Training)

15.
人間増強の四要素
• 1: 人工物(Artifacts) ←ソフトウェアなど
• 2: 言語(Language)
• 3: 方法論(Methodology)
• 4: 教育(Training)

16.
増強方法はソフトだけではない
• ソフトウェア（人工物）を作り出すこと
だけが増強の方法ではない
• 思考の助けになるような言葉を作り出す
• 「やり方」を言語化・体系化する
• そしてそれらの使い方を教育する

17.
人間増強の四要素
• 1: 人工物(Artifacts)
• 2: 言語(Language)
• 3: 方法論(Methodology)
• 4: 教育(Training)←1～3を使うスキルの教育
↑どんなよいソフトを作っても
使い方が理解されなければ役に立たない

18.
筆者のソフト以外のアプローチ
• 京都大学サマーデザインスクール
• 「学び方のデザイン」灘校土曜講座
• 「エンジニアの学び方」技術評論社
• PyCon JP キーノート講演
• 「続・エンジニアの学び方」サイボウズ式
• サイボウズラボユース公開講座（準備中）

19.
Q: 「学ぶ」プロセスの
最初の一歩は何か？
19

20.
新しいことを学ぶためには
盲点*に気づく必要がある
20
* 自分が知らないこと、かつ「知らない」ということに気づいていなかったこと

21.
21
先入観なく現実を観察し、
自分の理解とのズレを探す

22.
エンジニア向けの具体例
エラーメッセージをちゃんと読む
「きっとこうだ」と決めつけるのではなく
確認のコードを書く
どこが遅いかプロファイル取ってから高速化
マニュアルを読め（たとえ英語でも）
自分の理解（＝思い込み）と現実のズレに注目
22

23.
先入観なく見るのは難しい
23
←見えていない

24.
多くの視点を得ることで
先入観を減らす
24
“他人”の視点が有用

25.
これは正しいか？
知識多い人が教え
少ない人が教わる
知識多い
知識少ない

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

27.
× 自分以外から一方通行で学ぶ
「自分に教えられることはない」
という思い込みが作った心の壁

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

29.
多くの視点を得ることで
先入観を減らす
29
“他人”の視点が有用

30.
30
先入観なく現実を観察し、
自分の理解とのズレを探す

31.
それが盲点を見つけ
学ぶために必要なこと
31

32.
これを妨げるバッドパターン
「聞くだけ人間」と「言うだけ人間」
個人の問題ではなく
「『教わる役』『教える役』の固定化」
という構造的問題。
これを解消するにはどうすればいいか？
32

33.
まず「聞くだけ人間」を考える
「勉強会などで話す側に回ろう」耳にタコ
実行する人は少ない
自分が何を教えられるかがわからない
→最初の一歩が踏み出せない
33

34.
何を学ぶか
34

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

36.
具体的問題の答えを覚える
→その問題が解けるだけ
解き方(抽象的方法論)を学ぶ
→新しい問題を解ける
36

37.
抽象的な方法論を
具体的な問題を解かずに
学べるだろうか？
37

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

39.
経験という「根」と結びつかないと
応用できる知識にならない
39
根無し草の知識
応用
根のある知識

40.
経験
40

41.
「自分が経験したこと」は
自分が世界で一番詳しい
41

42.
よくある例
発表者「失敗が怖い、間違えるのが怖い」
→教科書を丸写しして発
→質問されても「そう教科書に書いてあった」
としか答えられない
→質疑が盛り上がらない
失敗を避けようとしたことによって
より大きな失敗が引き起こさてれいる
42

43.
間違えることを避けようとしない
• 自分が「教える役」だと思っていると、
間違えることは失敗だと思うのかもしれない
• でも「教えあう」が目的なのだから、
間違いじゃないかとつっこまれて議論をする
そのプロセス自体が有益なもの
• 教科書などの「外部の権威」
を自分の発表の正当化に
使うとそのプロセスが
回らなくなる
43

44.
経験がメインディッシュ
自分はこういう経験をした(事実)
(オプション)教科書にはこう書いていた(事実)
自分はこう理解した(解釈)
→これなら聞いている人に
自分の解釈を言える余地がある
44

45.
理解の検証について
45

46.
自分の中で育てた「理解」が
応用できる知識かどうかは
どうすればわかるのか？
46

47.
「理解した」は
仮説にすぎない
47

48.
仮説は実験して検証しよう
48
検証：
思った通りの
結果になった？

49.
エンジニア向けの具体例
プログラミング言語を学ぶ時：
A: マニュアルを読んで理解した！終わり！
B: マニュアルを読んで理解した気がしたので
確認のためのプログラムを実装してみた！
49

50.
計画 行動
結果の考察計画の修正

51.
仮説 実験
結果の考察仮説の修正

52.
理解 行動
結果の考察理解の修正

53.
53
先入観なく現実を観察し、
自分の理解とのズレを探す

54.
「PDCAサイクルを回して学ぶ」
の最初の一歩は？
54

55.
「何か発表しよう！」
↓
「何を発表しよう…」
55

56.
理解 行動
結果の考察理解の修正
最初の一歩はどう踏み出すのか？

57.
書いてから考えよう
57

58.
関係あるかもしれないことを
まずは全部書き出して
覚えておく必要をなくす
58

59.
具体例
「発表のネタになるかもしれない
ものを付箋に50枚書く」
59

60.
「発表資料を作ろう」は
大きくて計測不能なタスクなので
やる気が失われがち
「ネタを付箋に50枚書く」は
計測可能で隙間時間で実行可能
60

61.
書いたものを
机に広げる
61

62.
62

63.
人間の作業記憶は7個程度
書いたものを机に広げれば
100個をひと目で見渡せる
63
紙と机（人工物）による作業記憶の増強

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

65.
65

66.
トップダウンに分類すると
既存の考え方の枠に情報を
押し込めているだけになる
ボトムアップが重要
66
発表資料作りの今回の例であれば、ストーリーとして関連するものを近くに置く

67.
束ねて
表札をつける
67

68.
68

69.
束ねて要約して表札をつけることで
見た目の枚数が減り脳の負担が減る
69

70.
ボトムアップで集め、束ね、表札
チャンクを形成
70

71.
図解化と文章化
71

72.
72

73.
図解は自分の理解の
全体像を整理するのに
向いている
→しかし他人に伝わらない
73

74.
図解は二次元
文章は一次元
人に話すときも一次元
人に伝えたいなら一次元
74

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

76.
文章化して他人に伝え
フィードバックを得る
76

77.
書いて
まとめて
図解化して
文章化
行動
結果の考察理解の修正
最初の一歩はどう踏み出すのか？
人に伝える
フィード
バック

78.
書いて
まとめて
図解化して
文章化
行動
結果の考察理解の修正
僕にとってこの講義は…
人に伝える
フィード
バック

79.
「聞くだけ人間」脱出法
• 他人にアウトプットして
フィードバックから学ぶ。
• 隙間時間で付箋を50枚書き、
ボトムアップで組み立てる。
• 「自分の経験」にフォーカスする。
自分が世界一詳しいテーマだから。

80.
今ここまで終わった

81.
「言うだけ人間」の問題
81

82.
「言うだけ人間」の問題
「互いに知識を交換して学ぶ」を目指すうえで
聞くだけの人以上に問題なのが言うだけの人
過去の成功体験から自信と先入観が生まれる
82

83.
年末の社内納会で、
自分のコンフォートゾーン
（自分のぬるま湯）から抜け出て
コンフォートゾーンを広げよう
と、会社メンバーの前で話した
83
2015-10-14 - ビープラウド社長のブログ
http://shacho.beproud.jp/entries/2015/10/14

84.
先入観・考え方の枠
コンフォートゾーン
どうやって壊していくのか？
84

85.
枠を壊す流れ
1. 自分には既成の枠がある、と気づく
2. 自分の枠で判断するのではなく、保留する
3. 「枠を変えても意味がない」
という考えをのりこえる。
4. 「枠を変えるのが怖い」
という恐怖を乗り越える
85

86.
エンジニア向けの具体例
エンジニアのNさんは自称「人間と話すより機械
と話す方が気が楽」な人。
↓中略
「インタビュワーをやらないか」という打診が。
そんな経験はないし自信もない！
→でもやる(枠を変える恐怖の乗り越え)
86

87.
「聞く」方法
聞く方法なんて学んだことない！
インタビューに関する本を10冊買って
全部付箋化してKJ法してみた
重要なコンセプトはさほど多くない。
87

88.
相手の使う言葉は
自分が考える意味で
使われているとは限らない
88

89.
顧客「タイムマシンを作って」
エンジニア
「そんなことできるわけないだろ」
89

90.
相手が「タイムマシン」という
言葉で表現しようとしているものが
自分の考えるタイムマシンと
同じだと考えている
90

91.
冷静に考えたらその前提が
事実でないのは明らかなのに
自分の枠で現実を歪めている
91

92.
顧客「タイムマシンを作って」
エンジニア
「どんなタイムマシンですか？」
「そのタイムマシンがあることで
何がどうなるとよいのですか？」
92

93.
前提に敏感になる
93

94.
二者択一法(選択話法)
「Aという商品とBという商品の
どちらがお好みですか？」
どちらかを買う前提が入っている
→暗黙に前提を認めさせる
94

95.
前提のある質問は
答えを引き出しやすいが
回答を歪めてしまう
95

96.
「最近のお悩みは何ですか？」
→悩んでいることが前提
96

97.
「最近興味を持った技術は？」
→技術に興味を持ったことが前提
97

98.
勇気づけることが大事
98

99.
言葉がなかなか出てこない人
話すことに自信がない人
話すことを勇気づけて
やる気を引き出していく必要がある
99

100.
「教わる役」「教える役」の固定化
を解消するには「教える役」が
コンフォートゾーンを抜け出して
積極的に「教わる役」をやることが
重要なのではないか
100

101.
「言うだけ人間」脱出法
• 「教える役」を抜け出し
「教わる役」をプレイする。
• 前提や単語の意味は自分と相手で違う。
自分の枠を相手に押し付けない。
• 相手が話すことを勇気づけ、
やる気を引き出していく。
101

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

103.
多くの視点を得ることで
先入観を減らす
103
“他人”の視点が有用

104.
104
先入観なく現実を観察し、
自分の理解とのズレを探す

105.
それが盲点を見つけ
学ぶために必要なこと
105

106.
書いて
まとめて
図解化して
文章化
行動
結果の考察理解の修正
僕にとってこの講義は…
人に伝える
フィード
バック

107.
書いて
まとめて
図解化して
文章化
行動
結果の考察理解の修正
Question & Comment
人に伝える
フィード
バック