エンジニアにおける経験学習と1on1とペアプロと
過去2回ほど、1on1とペアプロを通して新人くん（実務経験0~1年）の教育担当をしたので、その際の色々をまとめました。
1on1やペアプロに興味がある方はのぞいてみてください。
1 on 1
ベースはヤフーの1on1本（一番下の参考にリンク載せています）を参考にしました。
1 on 1 is 何？
経験学習を加速させる装置
1 on 1とは、部下が自身の経験を元に内省し、そこから教訓を見出し、それを次に活かすために行う上司との対話です。
上記のように自身の経験から学ぶことを経験学習と言います。
ヤフーの1on1でもこの言葉が頻繁に出てきます。
人は自身の仕事の経験から多くを学ぶ
経験学習に着目する背景としては、人が学びを得る要因の割合によります。
「経験学習」入門(リンクは参考欄を参照)によると人が学びを得る要因は、
- 仕事の経験：70%
- 他者から：20%
- 書籍や研修など：10%
とのことで、人は自身の経験から学ぶ割合が圧倒的に多いのです。
その一方で、自分一人で内省していても自分では気づけないポイントが多々あります。
そのため、 部下が自分の経験から何を学んだのかを深掘りするための装置 として上司が部下と対話します。
メリット
部下の視点
相談をタイムリーにできる
- 上司の意向を伺わなくても会話する時間が取れる
- 相談などがより気軽にできる
目標に対する現在の自分の状態がわかる
- 3ヶ月や半年単位の目標に対して、現在自分がどの辺りにいるのかがわかる
- フィードバックを受ける場としても利用できる
上司の視点
部下の状況が分かる
- PRで送られてくるコードでは分からない部下のリアルな状況が分かる
- 当人だけではどうにもならない困りごとがあった場合にはすぐにサポートできるので、詰みゲーになる可能性が減る
信頼関係が構築しやすい
- 単純なタスクの受け渡しを超えた会話を行うため、上司と部下の信頼関係を築きやすい
デメリット
上司のリソースが逼迫する
- 上司は複数の部下を持っていることが一般的なため、部下の人数分だけリソースが削られる
- 私見としては、それに見合うだけの価値はあると思う
やり方
私の場合はヤフーの1on1をほぼそのまま適用しました。
- 週1回1時間程度、上司と部下で行う
- 私の場合は相手が新人ということもあり、時間を1時間に伸ばした
- 上司は部下に対して「何を話しましょうか？」というところからスタートする
- 部下の成長を促進する場所なので、お題は部下に委ねる
- 上司は部下から出たお題について、会話を通して部下の考えの真相を深掘りする
- 部下が内省を深掘りできるよう、質問や間を提供する
- 上司の意見/批評はNG
- 部下が今回の経験から得られたこと（教訓）を見出す
- 発見がある場合にはそれが何であるかを部下が自分で見出せるように誘導する
- 今後どうするかを決める
- 今回の経験を踏まえて、今後どうするかのコミットメントを部下から引き出す
- 次回の1on1ではその結果を中心に会話する
- 達成できたか？できなかったか？そこから何を学んだか？
- とはいえ、必ずそれを話さなくてはならないというわけではない
ポイント
あくまでも 部下のための時間 である
1 on 1は部下の経験学習をより良いものにするための時間であり、上司のための時間ではありません。
そのため、部下の発言に対して上司が答えを出したり、指示を出したり、部下の意見を否定したりすることはNGです。
上司が意見を出してしまうと部下は自分で考えることをやめてしまったり、「自分の話は聞いてもらえない」と考えて心を閉ざしてしまいます。
重要なことは部下の考える力を伸ばすこと
繰り返しですが、1 on 1は部下が自らの経験から学び、それを次に活かすことに重きを置いています。
そのため、部下の発言に対する上司の意見を言う場ではなく、部下の真意を深掘りし、部下がこれからどうすべきかを部下自身が勧化出すための手助けを行うことが最も重要です。
部下の言動は人事評価とリンクさせない
人間は精神的・身体的安全が保障される場でない限り本音を打ち明けようとはしないため、1 on 1での部下の言動は人事評価とリンクさせないことが望ましいです。
実践しての雑感
- 1on1で特に難しいのは自分にとって容易なことで悩んでいる相手を目の前にして答え/意見を言えない点
- 新人くんからは、「初めての業務経験で不安な中で気軽に相談できる環境があってよかった」とお褒めの言葉を頂いたので、ひとまずは成功かな
- エンジニアのコミュニケーションはslackやPRがメインだからこそ、1on1のように明示的に自己開示する場を設けるのはアリだと思う
ペアプロ
ペアプロ is 何？
2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法という説明が起源である。
一方が単体テストを打ち込んでいるときに、もう一方がそのテストを通るクラスについて考えるといったように、相補的な作業をする。
プログラム開発の現場では、一人で複数台を同時に使ったり、一台に複数台のディスプレイを使うことも多くなり、具体的なやり方は変わっている。実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。
30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。
要は、
- ペアプロとは、2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法
- 登場人物は以下の2人
- ドライバ
- 実際に手を動かしてコードを書く人
- ナビゲータのサポートの元、プログラムを完成させることに集中する
- 実装の細かい部分を考える
- ナビゲータ
- ドライバが気持ちよくコードを書く事をサポートする人
- ドライバが書いたコードを横から常にレビューする(コーディングスタイル、バグのチェック、コードの簡潔化の提言、etc)
- プログラムを書く上での大局的な問題を考える
- ドライバ
目的
1. 自分のレベル <= 相方のレベル の場合
- 出来る人の考え方などから学びを得る
- PRでは「何をしたか」は見れるが、「どうやって考えたか」は追えないので設計/十曽する上でのヒントが沢山得られる
- 技術面での学びを得る
2. 自分のレベル > 相手のレベル の場合
- コーチングスキルの向上
- 教える(考えを言葉にする)ことで整理する力を付ける
- 相手がどこまで理解しているか把握する力を付ける
利点
- チームの技術力を全体的に上げられる
- チーム内でお互いの設計/実装の考え方や実装方法をシェアできる
- 各自が持つ業務知識、開発ツールの効率の良い使い方、開発自体の進め方や考え方などをシェアできる
- 新メンバーのフォローアップに役立つ
- 個人がコードに責任を持つのではなく、チーム全体でコードの責任を持つ組織になりやすい
- 難しい問題に取り組みやすくなる
- 一人じゃないので心強い！
- レビュー/指摘対応の手戻り工数を減らせる
- リアルタイムにレビューを受けたり相談しながら開発するので、手戻りを減らせる
- コードの品質も良くなりがち
- 質問しやす
- ペアが共に同じコンテキストにいるので、気軽に質問できる（回答する側もしやすい）
- チームビルディングにもなる
- コミュニケーションを通してメンバーの仲が良くなる
欠点
- 実力に大きな差がある人と組むと、ドライバー/ナビゲーターの役割交代が難しい
- できる人がドライバーになっても、ナビゲーターが指示を出すまえに実装できてしまう
- ナビゲータ役のエンジニアへの負担
- ベテランエンジニアがナビゲータ、新メンバーがドライバーとして行うことが多いと、ベテランエンジニアに負担が大きくなる
やり方
今回は新人君へのティーチング/コーチングを目的とし、ほぼ全てのタスクを新人君とペアプロで設計/実装していきました。新人君が近い将来、自分で設計/実装できるようになるための助走期間という位置づけで、手集めにやっています。
役割としては基本的に ナビゲーター：私 、 ドライバー：新人君 で行いました。交代もしたかったのですが、時間の都合上役割は固定しました。
進め方としては例えば何らかのメソッドを実装する場合に以下のような形で進めました。
- やりたいことは何かを書き出す
- このメソッドを実装する目的が何であるかを考えてもらう
- 意図をもってコードを書くためには目的の理解が大事！
- このメソッドを実装する目的が何であるかを考えてもらう
- それを満たすためのステップや条件を書き出す
- 目的を達成するためにはどのようなオブジェクトやデータの操作が必要であるかを予め整理しておく
- 実装する
- 実装した処理に対してリファクタリング
- 主に関心事の分離を意識してリファクタリングする
- 「その処理は、そのメソッドが気にしなきゃいけないことなんだっけ？」というのをシツコク聞く
- 主に関心事の分離を意識してリファクタリングする
- テスト実装（上記1,2を参考にして場合分けする）
ポイント
- HRTの原則を守りましょう（心理的安全性、大事！）
- 特に技術レベル差がある人同士でペアになる場合
- HRTとは（参考： HRTの原則 ～ソフトウェア開発はバーでしっとり語り合うように ～ ）
- 謙虚(Humility)
- 尊敬(Respect)
- 信頼(Trust)
- 上記の進め方ですんなり行くことはほぼ無いので根気強く
- 人間は初めてのことに直面すると「自分が今何をやっているのか分からない」状態になる
- どうして良いか分からない素振りを見せたら、「やりたいことって何なんだっけ？」と質問して、今いる場所と次に行きたい場所を整理し直すのが良いと思う
- 新人君に考える切っ掛けを与える
- 新人教育なので、ある程度指示しながらも新人君が考える切っ掛けを作るのが良いと思う
- 単に言われたことを実装する場ではなく、新人君が近い将来、自分で設計/実装できるようになるための助走期間であるので、新人君が自分で考えるような流れにするのが大事だと思う
- 「この場合、●●という問題がありそうだけど、何か良い解決案あるかな？」みたいな感じで手を動かすだけではなくて方針を考えてもらったりすると良いと思う
- 新人教育なので、ある程度指示しながらも新人君が考える切っ掛けを作るのが良いと思う
- 適度に休憩をとる
- ペアプロ中は必然的に集中してやらざるを得ないので、こまめに休憩を取る
実践しての雑感
- 新人君と話していく中で、自分の知識の整理になった
- 根気強く一歩一歩やっていくのでメチャクチャ疲れた
Discussion