圧倒亭グランパのブログ

30年後の自分にもわかるように書くブログ

「スキル伝授にはペアプロが最速」というのは何故か

この問いに対して、自分なりの答えを言語化できたのでまとめます。

目次

疑問

きっかけは、下記の方々のやり取りをTwitterで見かけたからです。

サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。

もしこの「ペアプロが最速」である要因が分かれば、チーム内のレビュー方法や、自分の勉強方法にも応用できるのではないかと考えました。

このツイートには @t_wada さんから返信をいただいています。

なるほど。確かに過程を学べるのはペアプロならではかもしれません。しかしまだ、「本当にそれは最速なのか？」「過程を学ぶことができれば、ペアプロ以外の方法でも速度は出せるのではないか？」という疑問は拭えませんでした。

実践する機会

そして先日、 @t_wada さんとペアプロをさせていただく機会がありました。上述の疑問を持っていた自分にとってはまたとないチャンスで、疑問に対する答えを導き出せるかもしれないと思いました。

ペアプロでは「今業務で行っていることを題材にしましょう」とのことだったので、「数年前に自分が書いたバッチのロジック変更」を題材としました。実際に仕事で使っているコードの改修です。ペアプロ中、特に意識したのは「やろうとしていることを積極的に話す」です。これにより議論が生まれ、「それで良さそうですね」「こうしたほうが良いでしょう」などのアドバイスを頂きました。アドバイスに疑問を持った場合は、「それはどのような意図ですか？」「さらに自分はこう思うのですが」など、もう一歩深く議論をしました。結果、納得して開発を進めることができ、コミット時には「なんという濃密な１コミットだ…」と感慨深くなったことを覚えています。

頂いたアドバイスの一部を紹介します。

  • 名前付けやインターフェースはかなり吟味する
    • 名前と役割が異ならないか
      • 「averageというメソッド名だと一見小数を期待するが、to_iを返しているのは意図と反していないか」など
    • インターフェースに迷ったら、使用者側からの視点で考えてみる
      • 「そのメソッドを使う部分にフォーカスし、どういう引数だったらわかりやすいか」など
  • 抽象的なコメントは書かず、具体的なコメントを書く
    • hoge = 1.0 # テスト用というコメントでは、何のためにその値を設定しているかがわからない
    • 「なぜそうしたか」をコメントに書く
  • 慣習に従う
    • 「rubyではExceptionではなくXxxErrorが一般的」など
  • コミットメッセージは丁寧に書く
    • 「何をしたか」と「なぜそうしたか」を簡潔に

14:00〜17:00くらいまで約３時間ペアプロを行いましたが、体感時間はあっという間でした。集中していたせいで、準備していた水は一切飲んでいませんでした（終わった後にハッと気付きました）。

そして、ペアプロを終えたあとに自分の疑問を再度考えてみたところ、ある答えが見えてきました。

自分なりの答え

「スキル伝授にはペアプロが最速なのは何故か？」という問いに対する自分の答えは、

　　・「コードを書く瞬間の思考」にアドバイスを貰えるから 　　・他の方法で代替できないから

です。@t_wadaさんの返信と同じような内容なのですが、個人的にはこの言語化がしっくりきました。一つずつ見ていきます。

「コードを書く瞬間の思考」にアドバイスを貰える

これは、成長やスキルアップに大きく影響を与えると思います。エンジニアは結局、コードを書いて技術力を発揮するわけで、書く際の思考がそのまま技術力になります。「コードを書いている時にいかに考えられるか」が大切であり、それが全てです。いろいろと勉強をして知識を身に付けたとしても、コードを書く際にその知識を反映できなければ、知識が無いも同然です。

これがなかなか難しいんですよね。勉強と実践がかけ離れてしまいがちです。勉強してもコードには反映されない。咀嚼が必要で時間がかかる。オブジェクト指向はさんざん勉強したけど、書いているコードはそうじゃない。。。（耳が痛い

ですが、いざコードを書く際に「それはこうした方が良いですね」とアドバイスされたらどうでしょうか。「なるほど」と納得できれば、その瞬間からその人の書くコードが変わるわけです。これが「コードを書く瞬間の思考へのアドバイス」です。コードを書く際にどう考えるかを、キーをタイプするその瞬間に得られるので、より実践に近い形で学ぶことができます。大きなコストをかけて咀嚼する必要もなく、実際に手を動かして正しいことを即座に実践できるので、後に一人でコードを書く際にも再現性が高くなります。つまり、その人の技術力が向上しやすいのです。

「コードを書く瞬間の思考」にアドバイスを貰えること、これがペアプロが最速である理由の一つだと思います。

他の方法で代替できない

このようなアドバイスを他の方法でも実践できれば良さそうです。しかし、よくよく考えてみると、他の方法だと膨大なコストがかかりそうです。例を挙げます。

  • コードレビュー会
    • コードの１行１行に対して「当時、なぜそう書こうと思ったか」を言ってもらう
      • 情報量が多すぎて言う側が辛い
      • 同時に受け手も辛い
  • Pull Request
    • 「この部分は、なぜそう書こうと思ったか」を細かくコメントに記載してもらう
      • 情報量が多すぎて書く側が辛い
      • 同時に受け手も辛い

このように、「コードを書く瞬間の思考」を後から伝えるには膨大なコストがかかります。受け手のコストも膨大です。

そもそも、コードレビュー会やPRは各々目的が違うものなので、そこにいろいろと求めすぎると歪が生じてしまうわけです。例えば、コードレビュー会は「コード品質向上」が目的であり、スキルアップが主とした目的ではありません。故に、コード（思考の結果）に対してのアドバイスはしやすいのですが、その人の思考そのものへのアドバイスは比較的難しいのではないかと思います。（もちろん、思考へのアドバイスを目的としたレビュー会も開催できますが、その場合は参加者の目的を合わせておくことが大切です）

このように、他では代替できない点もペアプロが最速である理由ではないでしょうか。

ペアプロの欠点

これまでを振り返ると「ペアプロ最強」という感じがしますが、もちろん欠点もあります。それは「揮発性が高い」という点です。実際にペアプロを終えて感じたことの中に、

というものがありました。その場その場で議論を記録することは難しいです。メモを取るなどの方法もありますが、実際にペアプロを行ってみると、そんな余裕はないことがわかりました。また、当時のコミットログや修正したコードを見ても、当時の議論はなかなかわかりません。結果しか残っていないのです。このような「揮発性」といった欠点は、ペアプロ特有のものであり、やはりそれぞれ一長一短があるんだなと感じました。

ともあれ、実践的に手を動かしたことは身体で覚えやすく、実際にコードを書く際は自然と思い出せそうです。

まとめ

今回は@t_wadaさんとペアプロを行い（お付き合い頂いた@t_wadaさん、本当にありがとうございました！）、自分の疑問である「スキル伝授にはペアプロが最速なのは何故か」ということを考えてみました。理由は以下だと考えます。

  • 「コードを書く瞬間の思考」にアドバイスを貰えるから
  • 他の方法で代替できないから

「他の方法に応用できればいいなぁ」という自分の考えは見事に打ち破られました。言い換えれば、よほど何か革命的なものが出てこない限り、ペアプロの有用性は生き続けるのだと思います。

「ペアプロは本当に学びがある」というのは周知の事実ですが、今回は「それはなぜなのか？」ということにフォーカスしました。その結果、ペアプロの特徴がわかり、「あぁ、やはりペアプロは最速だなぁ」と改めて実感できました。

また、先程は書きませんでしたが、もう一つ欠点を挙げるとすれば「ペアプロは体力が必要」という点です。有用性は理解できたので「もっと気軽に省エネでできないかなー」というのを、最近は悶々と妄想しています。エンジニアなら、この問題も技術力でなんとかしたいですね。