私たちはどう学んでいるのかを読んで、ペアプロにどう取り入れるのかメモ
新しいメンバーに対してペアプロ・モブプロを行っている。
メンバーが一人で自走ができるように、より良いやり方・考え方は無いかどうかを模索している中で、「私たちはどう学んでいるのか」という本を読んで、いくつか参考にできそうだったので、書いておく。
※まだ試してないので、あくまで机上の空論、アイデア状態
この本を読んで面白いと感じたところのメモ
※あくまでメモなので要約ではなく、個人の感想
知識は伝えられない
一番最初に度肝を抜かされたと思ったのが、知識は伝えることはできなくて、構築されるものというところだった。
私たちが伝えられるのはあくまで「情報」であり、その情報を元に個人の経験と組み合わせて知識を構築していくしかできないといった趣旨のことが書いてある。
有用な知識とは
この本では、有用な知識について、一般性・関係性・場面応答性の3つの性質があると書いている。
特に面白かったのは場面応答性で、ざっくり理解で書くと「必要なときに必要な知識が使える」こと。
たとえば、設計だと高凝集・低結合が良しとされているという知識を覚えていたとしても、普段コードを書くときにそれが実践できていなかったり、ただ一度きりしか使わないようなスクリプトで頑張って実践する*1といった事かなと思っている。
認知的リソースと状況のリソースの組み合わせ＝知識の創発
有用な知識には、場面応答性という性質があるとすると、その知識が使える場面の情報もセットになってしまうし、それを覚えておくことは不可能
知識をモノとして扱うものじゃなくて、個人が持っている情報や記憶という認知的リソースと、周りの環境という状況のリソースの組み合わせによって、ある目的に沿った知識を創発するという考え方＝コト的知識観
状況のリソースっていうのは、自分の周りのリソース。
たとえば、
- 自分が使っているPC、モニター、キーボード、ツール
- IDEに出てくるエラーメッセージ、警告
- 自動テストの成功・失敗の結果
- 周りのチームメンバー
本を読んで思ったこと
今まで自分はペアプロ中に一生懸命相手に、自分の知っている知識を伝えているつもりだったが、それらは単なる情報。相手にとっては知識の素材（リソース）を提供しているだけに過ぎないなと思った。
自分が100言っていることは30しか伝わらないみたいなことを社会人になってから、よく言われていたし、自分の体感でもあったけど、この本を読んで腑に落ちた。
近接項と点を打つ
6章の中で、近接項と遠隔項の話が出てくる。
自分なりにざっくりまとめると、
- 近接項
- 自分自身が体感できる情報
- コードを書いてエラーが出た、運用などの作業手順書を読んだ内容、他人から聞いた言葉など
- 自分自身が体感できる情報
- 遠隔項
- 近接項が生み出される原因
- エラーの原因、作業手順書の各手順の背景、他人が発言した意図など*2
- 近接項が生み出される原因
人は近接項から、脳内に内部モデルを作り出し、それが遠隔項に繋げることができると理解が進むという話。
（脳内の）内部モデル --- 近接項 --- 遠隔項
みたいな形。
よく現場では理解を進めるために「点を打つ」という言葉を使っていたり聞いたりするが、自分が考えていたのはこの近接項を増やすことに終始していたなと思う。
ペアプロ・モブプロをやっていると、いろんな情報が飛び交う。自分の知っていること・知らないこと、それらの近接項を処理するだけで手一杯になっていく。
ペアプロ中に使えそうなアイデア
主に新しく入ってきたメンバー相手（先生・生徒の関係性になってしまいがちなペアの組み方）*3
リッチな経験値を積む
知識は、その人の五感で得た認知的リソースと状況のリソースから創発される。
そう考えた時に、認知的リソースを増やす取り組みをする。
ペアプロであれば、ドライバーがメインになると思う。
キーボードを叩く（触覚）、コードを見る（視覚）、ナビゲーターの話を聞く・自分の実況を聞く（聴覚）
五感を駆使してペアプロができるようにして、いろんな視点から情報を得て身体化を促していく。*4
ナビゲーターであっても、いまのコードの状況を見る、相手との会話から状況を知る、相手の声音、表情から相手の状況を知る（楽勝な雰囲気なのか、それともわからなすぎてパニック状態なのか、疲れているのか）、自分たちがやりたいことを頑張って言語化していく。
たぶんナビゲーターは、状況リソースを的確に判断するための訓練になりそうだなと思った。
自分が意識できそうなものリスト
パートナーを状況のリソースと考えたときに、パートナーの状況への理解度を深め、いま必要な自分の認知的リソース（相手にとっての情報）を、どう伝えるか作戦を立てるかが肝要だと思う。
- ただやることを伝える、にしない
- 相手の状況に応じて、アクセル踏むときとブレーキを踏むときを使い分ける
- 相手の状況を言葉にする
- 相手が沈黙している時など、「黙ってるけど何か悩んでる？」などの問いかけて、こっちから見えている相手の状況を伝える。そこから、相手の状況・思っていることを引き出す。
- 状況のリソースを把握する
- 相手が沈黙している時など、「黙ってるけど何か悩んでる？」などの問いかけて、こっちから見えている相手の状況を伝える。そこから、相手の状況・思っていることを引き出す。
- 「わからない」の解像度を上げる
- パートナーがどう進めていいかわからない、となったときに、「やりたいことがわからないのか」「やりたいことはあるけど、コードの書き方がわからないのあｋ」「これからやろうとしている意図がわからないのか」などの分解をしていく
- ナビゲートする時は思考の流れを伝えるように
- ◯◯をやりたいから、このコードを書いて下さい
- ナビゲートの伝え方は、抽象度高めから伝え、手が止まるようなら抽象度を下げていく
- xxxClassを書いて、次にxxxメソッドを書いて〜という詳細をナビゲートするのは、最後。
- 沈黙が続くのであれば、沈黙が続く人にドライバーになってもらう
- 自然と言葉と手が動かす状況に持っていく
