ペアプロと建設的相互作用

概要

教育心理学概論 の6章2節に建設的相互作用というものが出てきます。建設的相互作用を踏まえてペアプロを行なった方がペアプロの効果を高めるためられるかもという内容です。

本の内容

6章 建設的相互作用論

ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。
ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。
折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことはなかった。ペアで同じ試行を行わせた場合は、第二試行で７割が計算してから斜線を移行した。

分かるまでのプロセス

「分からない」から「分かる」にいつる間に次の5つのステップを踏むと想定されている 1. ある事物や物事が果たしている機能の1つを「同定」する 2. 同定した機能について、その仕組みを「疑問視」する 3. 仕組みをより詳しいレベルでの機能のつながりとして「探索」する 4. 説明の候補になる機能のつながりを「提案」する 5. 提案した説明が十分正しいかどうか「確認」する

12章 問題を解く時に、2人の方が1人よりも有利になる条件

そもそもコードを書くのは問題を解くのとは異なるが、それは置いておく。
12章では、2人の方が1人よりも有利になる条件の話が書いてある。
2人で行った場合に時間が半分になったり、正答率が二倍になることはそうそうない。2人の手が見えやすい作業を行なった方が、回答に早く辿りつくようだ。逆に2人の手が見えない場合は1人で行うのと同程度の時間で回答にたどりつくようだ。

その他の資料

建設的相互作用に関する論文やブログをいくつか読みましたが、教育心理学概論がまとまっててわかりやすかったです。

感想

建設的相互作用をより高めるために2人が手が見えやすい作業することによってペアプロの効果を高めれそう。2人が手が見えやすいように作業するためには、常に考えていることを口に出したり、行うべきことをTodoリストに書き出したり、行うたいことをテストコードで表現したり、間違っても恥ずかしがったり怒らないようにしたり、良いことをしたら褒めたりする必要がある。2人が手が見えやすいように作業することは簡単にはできることではなく、ある程度訓練する必要があると思われる。

ペアプロにはレビューとは違うものがありそうなメモ2

分かるまでのプロセス

「分からない」から「分かる」にいつる間に次の5つのステップを踏むと想定されている 1. ある事物や物事が果たしている機能の1つを「同定」する 2. 同定した機能について、その仕組みを「疑問視」する 3. 仕組みをより詳しいレベルでの機能のつながりとして「探索」する 4. 説明の候補になる機能のつながりを「提案」する 5. 提案した説明が十分正しいかどうか「確認」する

これらを行うにはペアで行ったほうが良さそうである。

問題を解く時に、2人の方が1人よりも有利になる条件

そもそもコードを書くのは問題を解くのとは異なるが、それは置いておく。
12章では、2人の方が1人よりも有利になる条件の話が書いてある。
2人で行った場合に時間が半分になったり、正答率が二倍になることはそうそうない。2人の手が見えやすい作業を行なった方が、回答に早く辿りつくようだ。逆に2人の手が見えない場合は1人で行うのと同程度の時間で回答にたどりつくようだ。

このことから、2人で作業することで確実に効率的とは言い難い。ただ、常に2人の考えていることを共有しながら作業を行うことによって相互作用を発生させやすいと思われる。

ペアプロにはレビューとは違うものがありそうなメモ

まだ調べ中なのです

経緯

教育心理学概論を読んでいて、

と呟いたら興味深いと言われてしまったのでメモしながらまとめることにした。
この本はまだ9章までしか読んでいませんが、6章と9章がおすすめです。

本の内容

教育心理学概論 の6章2節に建設的相互作用論というものが出てきます。ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。
ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。
折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことはなかった。ペアで同じ試行を行わせた場合は、第二試行で７割が計算してから斜線を移行した。

感想

ミシンの話で言えば、新入社員とペアで既存部分のドキュメントの作成するのが良さそうだ。
折り紙の話で言えば、レビューするのは異なる二人で同じような作業をしてすり合わせるような作業だと思って、「1/2と計算して斜線を引く」を思いつくのは確率は2割づつ(4割弱)あるが、ペアで作業したら7割に上がることになる。そんな単純な話でもないだろうが、相互作用による効果はそれぞれ考えるレビューより、ペアで作業した方が高まりそうな気がする。

知らないなら聞きましょうの精神

知らないことは、恥ずかしいことではない。

　社会人はプロフェッショナル集団である。それぞれの専門性を束ねて金儲けをする。それぞれの専門性があり、それぞれ知っていることが異なる。同じプロジェクトや目標に向かうときに共通の知識としてあった方がいいことはある。知っていることが異なるのため知らないことがあるのは当然である。知らないことは当然あるものとして扱うべきで、恥ずかしいことではない。
　学生の頃に授業でやっていないことを知らないことは恥ずかしいかもしれない。テストで良い点が取れなかったら恥ずかしいかもしてない。しかし、会社は学校ではない。均一に教育されない。仕事は授業ではない。知らないことは大した問題にはならない。業務を推敲できないことが問題になる。推敲するために必要なことをすべきで、知らないことを恥ずかしがっている場合ではない。

自分も聞くし、相手も聞く

　聞くことに対してハードルがある。年齢とか性別とか入社歴とか役割とかとか。聞くためにハードルを超える必要がある。お互いに聞けるような関係性を築いていった方がいい。

聞かれたら嫌がってはいけない

　自分が聞いた時に嫌がられたら次に聞くときのハードルが上がってしまう。聞かれた側は、聞かれたときに嫌がるのはよくない。可能な限り丁寧だが短くすますようにするべきだと思う。解るように説明してあげる方が、そこに労力を割くと疲れてしまう。1000文字書くよりもリンクを貼る方が楽だしわかりやすい説明になりがちである。1000文字書く必要があるのなら、ブログにしたり社内wikiにしたりいつでも検索して取り出せるようにしておいた方が良い。一度聞かれたことは、何度も聞かれがちのことである。
　「前にも言った」「何度も言った」「検索してみて」とかはよくない対応だと思う。 それで解決するならわざわざ聞いてはいない。 　リンクを読め見てもわからないと言われたのに「リンクを読め」というのもよくない対応である。二度と聞く気にはならない。

終わりに

「知らないなら聞きましょうの精神」ってなんか長いのでもうちょっといい感じの表現があるといいなと思う

iOSの社内ライブラリをやめる

この記事の社内ライブラリはアプリとは別にリポジトリを分けて管理しているコードで、CocoaPodsやCarthageでアプリにインストールできるようにしているが、社内のアプリにしか使っていない物のことです。

なぜ社内ライブラリが必要だったか

大抵の会社ではアプリを一つだけ作っていることは少なく、複数のアプリを開発していることが多い。複数のアプリで社内のAPIにつなぐための通信コードやドメイン関連のコードは共有したい。1つのアプリは1つのリポジトリで管理することが多い。。そのため、共有したいコードをライブラリとしてアプリとは別のリポジトリに切り出して、ライブラリ管理ツールを使ってアプリににインストールして解決している。

アプリを一つのプロジェクトで管理する

具体的なやり方は以下のリンクをみて欲しい。 recruit-tech.co.jp

Xcodegenを使えば複数のアプリを一つのXcodeプロジェクトで管理することは比較的簡単にできるような環境が整ってきている。共通に使うコードをframeworkとして複数のアプリで扱うことができる。

社内ライブラリをやめる

全てのアプリを1つのプロジェクトで管理することができれば、全てのアプリを1つのリポジトリで管理することができます。1つのリポジトリでアプリを管理しているため、社内ライブラリをリポジトリに切り出す必要はなくなります。ライブラリに切り出していたコードも一つのリポジトリで管理できるので、社内ライブラリをやめることができます。

終わりに

私はやりましたが、全ての会社で当てはまるような話ではないと思ってはいます。

openapi-generatorで生成されたSwiftのコードが動かないので回避方法

2020年1月20日現在の話です。

OpenAPI(Swagger)で書かれた定義ファイルからswiftのクライアントコードを生成する場合に、openapi-generatorを使おうと考えると思います。しかし、下記のようなコマンドで生成されるコードはコンパイルはできるもののそのままでは動いてもレスポンスを返すことは決してないコードが生成されます。この回避方法を2つ紹介します。

openapi-generator generate -i openapi.yaml -o src/ -g swift5

--library を指定する

生成されるコードにlibraryを指定することによって、デフォルトに指定されている。URLSessionを使った壊れた実装のコードを回避します。libraryで指定できるのは現状だと alamofire だけのようです。

openapi-generator generate -i openapi.yaml -o src/ -g swift5 --library alamofire

swagger-codegenを使う

openapi-generatorを使うのを諦めてswagger-codegenでコードを生成することで回避する方法です。openapi-generatorで生成されるコードと大体同じものが生成されます。