「ちくしょう、こうなったらペアプロだ！」　新人＋古い社員のリモート開発教育の最強ベストプラクティス

癒着を2日実践して感じた違和感

花川直己氏（以下、花川）：こんな感じで2日間やってみましたが、「なんだか様子がおかしい。なんかうまくいっていないな。なんでだろうな」と。イマイチ噛み合っていない感覚がありました

「なんかおかしいな」と思ったら、我々は絶対やることがあります。そう、「ふりかえり」です。毎回1日癒着するたびに、「今日どうだったかな？」と振り返ってみました。KPTみたいに、「KeepとProblemをまじめに考えてTryをしよう」といったカッチリしたものではなく、もっとラフに「感想だけでいいよ」「今日思ったこととかをラフに書けばいいよ」くらい。

ふりかえり自体が負担になるのがすごく嫌だったので、簡単に書いてもらって、それを見て僕がどう直していくかを考える意図で、すごくラフにやっていました。

書いてもらったことをベースに、次の日どうやろうかを、僕がやり方を変えて試してみるようなトライアンドエラーをずっと繰り返していました。もちろんこのふりかえりには、当然「これがよかった」のようなことは書いていいよ、と伝えています。

「ふりかえり」で見えた問題点と改善策

2日やって見えてきた問題。僕はJohnを見ながらやっているので、手が止まったな、John悩んでいるのかな、とか。Johnがけっこうリアクション薄いので、大丈夫かな、と思って僕が話しすぎちゃう問題。

僕がJohnの状況を、うまく把握できていなかった問題がわかってきました。Johnとしては手が止まっているのは、わからないから止まっているんじゃなく、わかっているんだけど「この問題をどう解決しようか」とか、そういったものを考えているステートでした。そこでミスマッチが発生していたり。

実はわかっているんだけど、詳しく説明されているので、言いづらいような。そういった状態でした。Johnとしては、自分が置かれている状況や感想をうまく発信できていない、2020年リモートワークが流行った頃によく出てきた“コミュニケーションのミス”がすごく発生していた、ということが見えてきました。

「ふりかえり」で見えてきたから、修正していこうと。手が止まった、それは実は悩んでいるんじゃなくて、考えているだけだというところでは、Johnは長考タイムというかたちで「今考えているのでちょっと待ってください」みたいなことを宣言する仕組みを導入しました。

Johnがこれを宣言したときは、僕は「じゃあ何分待つね」のような感じで、ちゃんと時間を区切ったうえで、邪魔をしない仕組みを作りました。

あと「リアクションないな、大丈夫かな？」というのは、とりあえずJohnに「今何をしようとしているかを、口に出すことを意識してもらっていいかな？」とお願いしました。これも慣れなので、最初はどうしてもできないんですが。慣れないとどんどんできなくなるので、慣れてもらうという意味でもお願いしました。

一方で、ここはなにか仕組みや方法でうまくできないかなということで、僕が引き続きうまくいくことを考えていくことにしました。できるだけコミュニケーションを重視して、お互い理解していくことを意識するように修正していきました。

さらに出てきた別の問題

変えてみて、またやってみて。さらにまた別の問題が出てきました。このときのやり方は、最初言ったようにJohnがずっとドライバーをやって、僕がサポーターをやるかたちでした。Johnはわかっているんだけど、どう書けばいいか思いつかなくて止まる。

あと実装していくうえでコードを読むと、「ここってどういうふうに動いているんだろう」って疑問が出てきます。僕としては「ここはこんな処理を書けばいいのにな」って横で思ったり、「ここはこういうことやってるんだよ」みたいなことを思って話しますが、Johnは僕が口頭で話しても理解が追いつかないというか。Johnはこのとき「わからない」と教えてくれたんですが、聞いていて「え？」っていう状態が発生してしまいました。

あと、Johnが「ほかの人の仕事の様子が見たかった」という、もともと発信していた知りたいことが、実は解決できていないことに気づきました。

「ちくしょう、こうなったらペアプロだ！」

ここで原点に立って、「ちくしょう、こうなったらペアプロだ！」ということで。ペアプロの正しいメソッドを導入しました。ちゃんとドライバー、サポーターを交代して、お互いにコードを書いて開発していきましょう。ただ、ペアプロだとサポーターが指示を出してドライバーは基本的に手を動かすだけですが、そこは少し変えています。

Johnがドライバーをするときは質問オーケー。「naosukeさんどうやっているんですか？」みたいに聞いたりとか。あと、書きながら「ここどう書くかわからない」というのを、できるだけコメントを残してくれとお願いしました。

一方で僕は、「わからない」と書いたコメントに対して一気に解説をしたり、「どう書けばいいのでしょう？」と、できるだけ“指針”というかたちで、コメントベースでコードを書くかたちでドライバーをしていく方法でやっていました。

お互い質問したり、「ここはこうなんだよ」と解説するのはオーケー、というレギュレーションです。もちろん、ふりかえりをしながら少しずつ工夫していきました。やはりペアプロってすごいもので、この形式を採用すると、すごくいい感じに仕事が捗るようになってきました。

最終的には画面共有で全体を見せつつ、LiveShareを使ってエディタはエディタで別途同期する。必要があったら、iPadとかApple Pencilを使って図を描いて解説する。こういうかたちで落ち着いてきました。

少しずつ試行錯誤しながら、無事バグ修正Doneになって、コードもマージされて。癒着完了と、ぴったりくっついた状態になりました。

1か月取り組んでみた振り返り

こういった取り組みを1ヶ月してみて、Johnに「どうだった？」って聞いてみました。まず感想ヒアリングすると、「すごくよかった」と。気軽に質問できたり、ほかの人の仕事の進め方を通して「こう進めればいいんだ」ってわかったり、コメントベースのコードが、道標を出してもらって、長考が減ってスムーズだったと。

一方で、「先輩社員と新入社員の2人分の稼働が使われているので、やはり焦りや不安が生まれてしまう」という感想をもらいました。あとはコミュニケーションの負荷が高いとか、けっこう体力を使うようなことを改善、もうちょっとうまくできたらいいね、と感想をもらいました。

僕的にこういうのを聞きながら考察すると、オンボーディングのペアプロは、うまく空気作りができると感じました。本当はドキュメントに書ききらないといけませんが、書くまではいかない細かいノウハウを口頭で話したりとか。

タスクに関連した周辺知識を、ふと「こういうことなんだよ」とインプットできたり、そういったメリットがすごくありました。

考慮すべき点としては、気合いでどうにかするにしても、やはり体力を使う。あと口数が少ない子はペアプロが合うのかな、と。先輩社員的には、理解度の見極めがかなり難しいとすごく感じました。

そのため、初手でペアプロやって終わりとか、単発でやるというよりは、例えば「最初の時期」「入ってしばらく経った時期」「もうしばらく経った時期」みたいな感じで、定期的にやっていくのがよさそうだと個人的には考えています。

新入社員＋古い社員のペアワークベストプラクティス

そういうことをしながら、“ぼくのかんがえるさいきょうのペアワークベストプラクティス”。特に今回みたいな新入社員＋古い社員という構成でやるにはどうしたらいいかと考えたら、環境としてはやっぱりVSCodeとLiveShareが、同期もなかなか優秀なので、これを使うのがいいかと思います。

一方で、画面全体を共有したうえで、個人の進め方の共有で、　Google Meetなどを使ってやるのがいいのかなと。お互い何をやっているかを、無駄な忖度をできるだけなくしてやったほうが、脳の負荷を下げられる、ペアプロに集中できるようになります。

時間設定としては90分から120分を1回として、終わったらちゃんと休憩して、続くならまた90分から120分というかたちでやるのがいいかなと。けっこう想像以上に、脳の負荷がかかります。90分、120分やってもけっこうヘロヘロなので、これ以上やると絶対集中力が保たない感じです。

Driver timeを非対称にして、新入社員を少し長めにDriver timeを取ります。というのも、ペアプロ中にインプットと高度なアウトプットでけっこう複雑な処理をしなきゃいけない。新入社員は脳の整理をしながらコードを書いてもらうかたちで、少し多めに時間を設定しておいたほうがいいかと感じます。

逆に、古い人たちはさっさと手を動かしちゃうので、新入社員があんまり力を得られなくなります。逆に既存社員は、ちょっとセーブするかたちで、短めに設定したほうがいいです。

これはペアプロによくありますが、やっていることは全部口に出せ、という話があります。同じことですが、オーバーヘッドをなくす。先輩社員はコードを書きすぎない。あくまで新入社員のパワーアップが目的です。「俺強ぇ！」ってやりたいならやりたいでいいから、別のペアプロ、同じ立場の人たちでペアプロやるときにやれと（笑）。