入社3ヶ月目社員がリモートペアプロをした話

f:id:mAtsU:20201007190710j:plain

はじめに

こんにちは。今年の7月からメディアドゥにエンジニアとして中途入社した松本です。私はもともと機械メーカーでメカニカルエンジニアとして働いていましたが、現在はソフトウェアエンジニアとして新電子書籍流通システムの運用・保守や開発に携わる仕事をしています。新電子書籍流通システムとはなにか知りたい！と思った方はこちらの記事をご参照ください。

今回は自身として初めての経験であるリモート環境でのペアプロを体験したので、その時の知見をまとめました。

なぜ今回ペアプロをすることになったか

現在弊社では全社的なリモートワーク体制に移行しており、基本的にはSlackを利用したコミュニケーションで業務を進めています。通常はなにか相談事があればチームのSlackチャンネルに投稿するようにしているので、わからないことがあればチャットを利用し、必要があれば通話や画面共有で連絡を取るようにしています。

私は入社して3ヶ月であることに加えてソフトウェアエンジニアとしてのキャリアも浅いため、まだまだわからないことが多いです。そのためタスクの細かい洗い出しや既存コードを利用した機能実装には多くの時間がかかってしまいます。今回もあるタスクに取り組んでいて、いつものようにSlackでわからないことについて逐一確認しながら進めていたのですが、意思共有を早くする目的で一度ペアプロを試してみましょう！という流れになり急遽実践してみました。

どのようなペアで進めたのか

今回のペアプロの目的は教育ではなく、私の取り掛かっているタスクについてリアルタイムにレビューを受けたりアドバイスを貰うことでした。よって、ドライバーとナビゲーターに分かれて作業するのではなくペアで開発するスタイルを取りました。ビギナー（私）とレビュアー（先輩エンジニア）のペアで開発することで下記の成果を得ることを期待しました。

ペア同士で課題を整理することで理解を深める
課題に対する具体的なソリューションを話し合ってその場で決める
手分けして作業することで取り組んだことのない実装箇所を支援してもらえる
疑問点やわからないところをその場で確認する

実践した方法

現在弊社では全社的なリモートワーク体制に移行しているため、すぐに並んで2人で作業しましょう！といったことができません。そのため今回はSlackを使って通話しながらVS CodeのLive Shareを利用して作業を進めました。おおまかな方針は下記のとおりです。

作業時間を2時間と決めて、作業スケジュールを共有する
最初に要件を整理して、ToDoリストを作成する
役割分担を決めてお互い別々に作業する
Live Shareのチャット機能は使わずにSlackでやり取りする
プログラムはターミナルで実行して挙動を確認する

f:id:mAtsU:20201007195600j:plain

今回実装した言語はGoです。コードはすでに実装途中だったので、レビュアーの方にはこれまでの実装をチェックしていただいた後、次に実装すべきことについてアドバイスをいただきました。前半は通話機能を使いながら、意識合わせとToDo作成を一緒に実施した後、実装に入る前に簡単に既存コードのリファクタリングをしてもらいました。後半は作業を分担し、各々の担当範囲を同時に編集することで進めました。

Live Shareではホストがセッションを開始してゲストを招待できます。VS CodeにおけるLive Shareの使い方はこちらの公式ドキュメントを参照ください。

今回はビギナーの私がホストとなり、レビュアーエンジニアの方をゲストとして招待するやり方にしました。Live Shareではホストのターミナルを共有して、ゲストがプログラムを実行することが可能です。設定することで、ゲストがホストのプログラムを編集した後にターミナルで実行して挙動を確認することができました。

実施してみた感想

よかった点

普段なら自分で調査して時間がかかるポイントについて、直接アドバイスを受けることができる
最初に作業レベルでToDoを洗い出したので、作業時間の見積もりができる
具体的な実装がない状態からでも、レビュアーの「こんな感じで書いてほしい」を知ることができる
細かい指摘をリアルタイムで受けることができる
話し合ってToDoを作ったので、ペアプロ後も自信を持って作業に取り組める

私が普段時間をかけてしまうポイントは、具体的な実装方法を調べる時間でした。適切なpackageや既存コードで使用できる実装の有無についてすぐにアドバイスを受けられたことはとても効率が良かったと思います。普段ならGitHubのPR上でコーディングスタイルの違いやコメントの書き方などといった細かい指摘をもらうのですが、直接レビュアーの方に実装で示してもらうと理解が早いです。また、PRのレビューで具体的な実装を元にした指摘を貰うのに対して、実装する前の0の状態からでも方針についてコメントや擬似コードで示してもらえる点も大きなメリットと感じました。最後のペアプロ後も自信を持って取り組めるというのは、やることの明確化がしっかりできた結果です。ペアプロの時間内ですべてを実装することはできませんでしたが、終わった後はデバッグや小さな改善にすぐ取り掛かることができる状態だったため、手が動きやすくなりました。

注意すべき点

エディタ補完や定義ジャンプが意図せず動作しないことがあった
細かくコミットをしなかったので編集領域が大きくなった
ビギナーである自分の手が止まる時間があった
エディタの設定や実行環境の違いに対応しなければならない

役割を分担して同時編集で作業を進めた時、エディタの補完機能がうまく動作しなかったりデバッグを自分のタイミングでできずにビギナーである私の手が止まってしまう時間がありました。同じ理由で細かくコミットをすることができなかったので、あとからgit add -pで部分的にコミットするようにしました。これらは同時に別々の作業を分担して起こったことなので、ドライバーとナビゲーターに分かれて実装者が常に1人になる進行であれば問題にならないでしょう。また、ゲストはホスト側のエディタの設定や実行環境の違いにリモートで対応しなければいけません。今回はビギナーである私がホストになったことで、大きなつまづきはありませんでした。

今後チームで活用できそうか

現在のチーム状況

私の所属するチームでは日常的にペアプロを実践しているわけではありません。リモートワークに移行したことで、お互いのスケジュールを確保することが以前より難しくなってきていることはペアプロの機会を遠ざける要因になるでしょう。また、最近チームの人数が一気に増えたのでレビュアーとなるエンジニア数名の負荷が多くなってきていることが課題となってきています。

リモートペアプロが解決できること

レビューされる側にとって、普段より細かい質問に対する回答や具体的な実装がない状況からでもアドバイスが得られることは大きなメリットです。レビュアー側にとっても多くのPRをさばく為に毎回頭を切り替える必要があるのは大変な労力なので、よりレビュアーの労力の少ない方法でレビューできる方が望ましいはずです。PR上でレビューをすることと、リモートペアプロでサポートをすることをうまく使い分けることができれば、ビギナーのスキルアップとレビュアーの負荷低減に効果的なのではないでしょうか。いずれにせよ大事なのは、ペアプロする双方がメリットを感じた上で作業することだと思うので、またそのような機会があれば積極的に提案したいです。