この記事はfreee Developers Advent Calendarの3日目です。
皆様こんにちは。freeeでスクラムマスターをやってます ichy こと Takeru Ichiiです。過去にアジャイル開発関連の記事を2本ほど書かせて頂いており、去年のアドベントカレンダーでは私のスクラム開発と無関係なペペロンチーノを混ぜて書かせていただきました。
今年もなにか無関係なものを混ぜつつ新作を書こうかと思ったんですが、ちょっと本業が立て込んでおり、間に合いませんでした。そこで、今回は社内Blogの転載に近い形になってしまうのですが、小噺を楽しんでいただこうかと思います。なお本来であればビーフシチューのレシピを紹介しようかと思っていましたが、そのお話はまた今度させていただこうかと思います。
今回の記事の元ネタのご紹介
今回の記事は2021/10/1~2021/10/2に開催されましたScrum Fest Mikawa 2021の建設的相互作用の論文 (通称「ボビンの論文」) とスクラムの源流 “The new new product development game” を読んでペア作業からスクラムについて考えてみりんというセッションがベースとなっております。このセッションで題材となったConstructive Interaction and the Iterative Process of Understanding(建設的な相互作用と反復的な理解のプロセス)という論文のご紹介と、その中で扱われた「建設的相互作用」とペアプロの関連性を紹介していきたいと思います。なお題材となった論文はfree accessになっていますのでぜひ読んでみてください。
どういう論文なの？
論文冒頭の概要には以下のことが述べられていました。
- 複雑な装置を理解するときは反復的な方法によって実施される。
- 人が理解したと感じるポイントは複数あるが、その理解自体は完全な理解ではなく、新たな理解が必要になる。人は物事を理解した状態と理解していない状態を循環することになる。
- 今回の実験では2人3組の人々を観察し、ミシンが布を縫う仕組みを理解するプロセスを観察した。
- 理解には前述の反復的な理解のプロセスの他に、建設的な相互作用が見られた。
- 話し手の発話を分析すると話し手がどのような視点からミシンを見ているか（C-POV）がわかるようになった。この視点は理解をしているときとしていないときでの変化があった。
理解とは何か
理解する行為
この論文では、「機能-機構階層（the function-mechanism hierarchy）」というものを提唱し、対象の実際の機構や機能と心理学的な理解のレベル（深さとも言える）の関連付けを行いました。ちなみに、ここで言う「機構（Mechanism）」は現象の仕組みを指しており、「機能（Function）」は機構の仕組みを実現するために実際に実行されるタスクを指しています。
（出典: Constructive Interaction and the Iterative Process of Understanding - Miyake - 1986 - Cognitive Science - Wiley Online Library 内のPDF）
Level nの機構は機能を1つ以上内包しており、機能の集まりで説明されます。内包された機能はその機能を実現するために必要なLevel n+1 の機構を複数有しています。 理解をしていく作業というのは、Level nの機構の機能を特定し、この機能を構成しているLevel n+1 の機構を特定し、これを繰り返す行為 になります。この論文ではミシンの機構を「縫い目を作る」という機能から深堀りをしていくという例でこの「機能-機構階層」を説明していきます。
理解している状態としていない状態
機能からLevelを下げて機構を明らかにして理解していく作業は具体的にこのように説明されています。
（出典: Constructive Interaction and the Iterative Process of Understanding - Miyake - 1986 - Cognitive Science - Wiley Online Library 内のPDF）
- Level nの機構の機能の特定(Identified)
- 機能がどのようにして実現されるのか疑問を抱く(Questioned)
- Level n+1の機構の探索(Searched)
- 暫定的な解決策としての機構の提案(Proposed)
- 提案の批判(Criticized)
- 提案された機構の確定(Confirmed)
図中の四角が点線から実線、太線となっていくのは批判を行うことでこの提案されたLevel n+1の機構がより確定していっている様子を表しています。
Step4暫定的な解決策で出てきた機構が批判された場合、再度機構の探索（Step3）と機構の提案（Step4）を行い、これが成功しなければ「不可能」という状態になり、放棄されることになります。
理解している感情はこの「特定(Step1: Identified)」「提案(Step4: Proposed)」「確認(Step5: Confirmed)」のステップを踏んでいるときです。この状態はLevel nの機能に足していLevel n+1の機構で説明がつくと思っている状態を指しています。逆に、「わからない」感情は「探索(Step3: Searched)」「批判(Step4.5: Criticized)」「疑問(Step2: Questioned)」のステップを踏んでいるときは下位Levelや今のLevelの機構そのものが確定していない状態です。
ダニング・クルーガー効果を「完全に理解する」
ここまできて皆様は理解した状態を完全に理解しました。なので完全に理解した私はこれをダニング・クルーガー効果と当てはめて考えてみます。
システム全体の話はおいておいて、システムの一部に一旦フォーカスしましょう。最初の自信満々な状態は無知の状態から先程の「特定(Step1: Identified)」の状態を指しています。これは同時に「確認(Step5: Confirmed)」の状態とも言えます。そして、「疑問(Step2: Questioned)」「探索(Step3: Searched)」を行っていくうちに自信喪失状態に陥り、「提案(Step4: Proposed)」を行って実際の能力が上がっていきます。
次にシステム全体の理解も合わせていきましょう。無知の状態からシステムの表層における機能を「特定(Step1: Identified)」し、先程のフローをへて「確認(Step5: Confirmed)」しますが、その頃にはまた新たな機構に対する機能が「特定(Step1: Identified)」され疑問(Step2: Questioned)」を持ち、わからない状態へと陥ります。
すごい雑ですが、ダニング・クルーガー効果を細かく理解しようと思うと先程の「機能-機構階層」を利用した理解のプロセスを使うととても説明しやすくなります。ということで、これを読んでる皆様は『「完全に理解した」を完全に理解』できましたね。
建設的相互作用とペアプログラミング
さて、この論文は「建設的相互作用」という方法を模索するのが目的になっています。ユーザーテストなどで一般的な手法に「被験者に自分のやっていること、考えていることを口頭で報告してもらう」という方法があります。この方法は自然な環境では被験者は黙々と実行するようなタスクでも強制的に発話をすることで、人の思考を表出しデータをとる方法ですが、そもそも沈黙して行うタスクなので不自然で有ることと、加えて言えば「ラバーダッキング」のような状態になってしまうので、自然な環境よりも取り組んでもらうタスクそのものの理解が深まってしまうという問題点もあります。
建設的な相互作用をもたらす実験環境では、被験者は二人（もしくは複数人）で一組になり、その組がタスクを遂行する必要があります。その場合、組の意思疎通をとるために発話をしなければならない状況なので、より自然な状況と言えるでしょう。見えないプロセスの可視化が発生し、理解が深まることでお互いに建設的な相互作用をもたらすのでこの名がついています。また、被験者が何らかの問題の解決を主張した場合、その検証のための凡例を一人で考えるのはできないことは無いですが難しいです。二人であればこれは自然と発生することになります。
この論文では建設的な相互作用が発生する実験環境においてミシンの構造理解をミシンそのものの理解度や経験が違う・または同じ2人組の3ペアで実施してもらい、発話内容を分析しています。
自分にとって興味深かったのは理解のプロセスにおける批判の使い方の部分でした。この論文では「上から目線の批判」と「下から目線の批判」、「自己批判」の3つの出現数をカウントしています。この実験環境では理解度や経験が違う・または同じとは言いつつもお互いの理解度は基本的にずれている状態です。「上から目線の批判」とはこの理解度・経験が多い被験者から少ない被験者への機構提案の批判で、「下から目線の批判」はその逆です。「自己批判」はそのとおり、自らの機構提案の批判を指しています。この論文における実験では「上から目線の批判」は3回でしたが、「下から目線の批判」は22回と7.3倍も観測されました（ちなみに自己批判は4回でした）。
「下から目線の批判」の内容は評価的な内容というよりは「不満」のような内容だったようです。つまり、提案されたメカニズムが理解できないという内容だったようです。ここで特徴的なのは、「理解力のある相手がメカニズムを探し続けなければならなくなった」ということです。実験では実際に、理解力のある被験者は自分の説明に自信を持っていましたが、そうでない被験者が批判を行ったことで機構を変更した事例がありました。この論文ではこれを 「二人のレベルや焦点が異なる場合に、批判が起こる可能性があるということです。単純に、どちらかが優れた知識を持っているとか、両者が "同じレベル "で仕事をしているということではない」 と論じています。
ペアプログラミングに当てはめてみましょう。前提として、ここで取り扱うペアプログラミングは一般的な「問題解決に焦点を当てた」ペアプログラミングで、知識伝承を目的とはしていません。ペアプログラミングではドライバーが実際にコードを書き、ナビゲーターはドライバーを誘導しつつコードを評価する手法になります。ペアプログラミングの目的は様々なものがありますが一つに「より良いコードを書く」というものがあります。例えばドライバーは経験が少ないエンジニア、ナビゲーターは経験豊富なエンジニアが担当するとします。おそらく一般的な手法はこのスタイルになることが多いかもしれません。この場合、経験が少ないエンジニアは経験豊富なエンジニアの言う通りに書くことだけをすると、建設的な相互作用によるコード品質の向上はおそらく期待でき無いでしょう。 先程の研究の例でもあったように、提唱されたコードに対する批判があって初めてそのコードが正しいか検証されます。経験の少ないエンジニアは不満でも良いのでわからないコードがある場合は、積極的に批判（というと強い言葉に聞こえるので質問）を行いドライブすることが期待されますし、経験の豊富なエンジニアはコードの意図や意味の説明を積極的に行い、ナビゲーションする必要があります。そしてこの効果は理解度や経験の差が離れれば離れるほど起こりやすくなります。なので ペアプログラミングをするときは意識的に経験の差があるペアで組むことが良いでしょう。 （もちろん、これはペアプログラミングの目的によっては当てはまらない可能性はあります。）
--
明日のAdvent Calendarはfreee Tech Nightの司会でもおなじみ nobjas さんです！なにやらオンライン配信について面白そうな記事を書いてそうなので皆様乞うご期待！
