もしペアプロが音楽なら
譜面通りに演奏するクラシックではなく、即興性の高いジャズに近い。
演奏してみれば、何かの音が出る。
例えば一般的なコミュニケーションでも
- Aさん 対 Bさん
- Bさん 対 Cさん
- Cさん 対 Dさん
が話す時では、それぞれコミュニケーションのとり方が変わる。
人 x 人
これと同じでペアプロでも、人対人の種類だけ、バリエーションがあるはず。
固定観念
「ペアプロとは、こういうものだ」という固定観念があると、ハードルが高くなる。(一番の問題)
苦手意識
- 「教える側として自信がない」
- 「質問に答えられなかったらどうする」
- 「答えが見つからず、気まずい空気が流れたらどうする」
とか思うと、いつまでもペアプロが出来ない。
悪循環
ペアプロしない => ペアプロ力が伸びない => 自信がつかない => ペアプロしない => ペアプロ力が伸びない => ...
ゆるさ
「一緒にプログラミングしたら、ペアプロだ」ぐらいのゆるさで良いと思う。
(下手な音が出たら出たで、また演奏の仕方を考えれば良いし、それも成果だと思う)
オブザーバーとドライバーの違い
これもあまり考えなくて良いんじゃないか。
「教える側」と「教わる側」という意識に引きずられがち。
ペアプロ力
プログラミング力やプロジェクト歴とは別に「ペアプロ力」というものがあって、これも経験値ゼロからスタートするはず。
言いたいこと
「これがペアプロだ」っていう固定観念に引きずられず、自由にやってみたい。
具体例 ( 個人的な話 )
- 今まで、ペアプロのオブザーバー経験がほぼなかったので、かなり苦手意識があった。
- 「そんな自分でも、やりやすい方法」を模索してみた。
オブザーバー(自分)
- プロジェクト歴2年
- 分からないことがあったら立ち止まるタイプ
- 質問する前に考えるタイプ
ドライバー
- プロジェクト歴半年
- どんどん先に進むタイプ
- たくさん質問するタイプ
1日目
主にオブザーバーが話しながらペアプロした。
2日目
主にドライバーに話してもらいながらペアプロした。
3日目
オブザーバーはほとんど口を出さず、見学しているぐらいの感じでペアプロした。
時には
教官が教習生に教える感覚。
時には
隣で運転している感覚だった。
気をつけたこと
口を出すレベルを調整する
- オブザーバーとドライバーの性格を考えて、今回は「最小限の関与」をするようにした
- 自分で進める道なら、オブザーバーが指示する必要はない
- 最初はある程度の道筋を立てて、だんだんと関与を少なくしていった
間違いも大事
- ドライバーが道を間違えた時に、一瞬で訂正したりせず、話し終わるのを待ってから訂正した
- 「どんな風に間違えやすいか」「どんな思考パターンで実装をしているか」を理解するのも大事
- むしろ、相手の考え方や、パターンを理解することがペアプロ本来の目的だと思う
分かったこと
スタイル
- 必ずしも「オブザーバーが手取り足取り教える」というスタイルじゃなくても良い。
- 昔、はじめて自分にペアプロをしてくれた人が、手取り足取り教えてくれるタイプだったので、そのイメージが強く残っていたのかもしれないと気付いた。
- 自分と相手に合ったペアプロのスタイルを見つけられると良い。
沈黙も金なり
- ドライバーが分からないことを、オブザーバーが即答する必要はない。
- 分からない部分は「自分も分からない」と伝えた上で、ドライバーに調べてもらったりした。その調べ方を見るのもペアプロ。
- 分からないことを前にして、沈黙しても良い。焦らずに解決方法を考えれば良い。
下調べ
- なおかつストーリーの下調べもしておくことで、オブザーバーとしての自信と余裕が持てた。
話したこと
- プログラミングの内容だけではなく、エンジニアとしての気質や、仕事のやり方の話もした。
改めて
- ペアプロの目的は、まずは「ペアプロすること」自体にある。
- ペアプロでしか分からないことがある。
- ペアプロ経験が少ない場合、まずはペアプロ経験をつけるためにやってみる。
- 最初うちは、ペアプロのスタイルを見つけるための時間だと思っても良いかも。
セオリーはない
- 「ペアプロはこの手法が良い」というセオリーは存在しないかもしれない。
- この記事のテーマのとおり、相手やシチュエーションが変わるたび、最適なやり方も変わってくると思う。
- 試行錯誤することが正解。「良いペアプロは何か」じゃなく「自分に合ったやり方は何か」「相手に合ったやり方は何か」を基準に考えてみる。
以上
チャットメンバー募集
何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。