ペアプロをしたら、オンボーディングにおいてメリットが大きかった話

こんにちは。
ホワイトプラスでエンジニアのマネージャーをしている八巻です。(写真左)

今回は、弊社エンジニアの古賀さんが紹介していた「ペアプロ」について、企画した側の視点で振り返りたいと思います。

結論、オンボーディングにおいてはペアプロは「ナレッジ」の共有のメリットが大きく、一方で開発効率低下のデメリットは少ないと感じたので、具体的にどんな感じだったのかご紹介します。

▼目次
・状況・背景・ねらい
・実際にどうだったか
・ペアプロをしてみて起きたこと・わかったこと
 - 開発環境に差異があることに気づく
 - IDEの使い方をお互いに学ぶことができる
 - 次に何をやるか?
 - ドライバーが偏る、ナビゲーターが飽きる
 - 大きな設計は2人でする
 - 空気が伝わる
・まとめ

状況・背景・ねらい

ペアプロを導入した背景に、「新しく入ってくる人にどのようにナレッジを共有していくか」という課題がありました。ここでいう「ナレッジ」は、開発のやり方や進め方、業務知識など、開発を進める上で必要な知識を指しています。

これまで開発のアサインは、比較的大きな機能を一人ひとりに割り当てる方法をとっていましたが、結果として得意分野や経験値によって各エンジニアの「ナレッジ」に大きな差ができていました。

それらを背景に、今回はオンボーディングとしてペアプロをすることで「ナレッジ」の共有が効率よく進むのではないか?というねらいを持っていました。

しかし一方では、2人分のリソースを投入して一つの成果物しか得られないので、開発効率が悪いのでは?という懸念もありました。

実際にどうだったか?

「ナレッジ」の共有については、想定以上にうまくいきました。

開発対象となるクリーニングの生産管理(提携クリーニング工場のシステム開発まわり)は固有の業務知識も多く、資料だけで伝えるのはなかなか難しい領域なのですが、ペアプロで開発を進める中で即座に疑問に答えられるため、理解は早く進みました。

「リネット」の開発は「ドメイン駆動設計」を導入して進めています。ただ、やり方などの細かい部分でチームごとに違いがあるため、今回のプロジェクトで採用している方法や、それを採用した理由などの「意図」を含めて、なぜこうなっているか?が共有できるのはペアプロで進めたからこそだと思います。

また、「開発の効率」についても想像していたようなことは起きず、むしろオンボーディングの段階では効率が良い部分もあると思いました。

たとえば、それぞれが開発してレビューで指摘するやり方だと「ナレッジ」が十分に共有できず、立ち上がりの段階では「指摘」と「戻り」が多くなります。これに費やされる工数や精神的なストレスを考えると「ナレッジ」を移すまでの間は、ペアプロを採用する方がむしろ開発効率が良いと感じています。

ペアプロをしてみて起きたこと・分かったこと

エンジニアマネージャー八巻紘士
古賀さん(右)とペアプロしている様子

ここからは実際に起きた具体例を紹介します。

開発環境に差異があることに気づく

開発環境はKubernetesで構築し、IDEとしてPhpStormを使っています。しかし、PhpStormの設定に微妙な差異があることがわかり、初回はその差を埋めるのがメインになってしまい、まったく作業ができませんでした。PhpStormの設定方法はwikiで共有されているため基本的には同じ設定なはずなのですが、ペアプロを通じて細かい差にも気づくことができたのは想定外ではありましたが、良い意味で発見でした。

IDEの使い方をお互いに学ぶことができる

PhpStormは機能がたくさんあるため、使い方に個人差があります。私はRefactoringの機能を最大限活用して名前の変更や移動を頻繁にやるのですが、ペアプロ相手の古賀さんには新鮮だったようです。逆に、私は移動系のショートカットをあまり使わないので、それを古賀さんに教えてもらったりしました。

次に何をやるか?

ペアプロを始めた頃、次に何をやるのか分からないという問題がありました。そこで、今回のペアプロではコードを書き出す前にGitHubのIssueを使って、やることを整理して認識を合わせる方式を取りました。これによって何をやるのか明確になったのと、私が他の仕事でペアプロができない時にも、一人である程度進められるという効果も生みました。

ドライバーが偏る、ナビゲーターが飽きる

ペアプロでは、実際に手を動かしてコードを書く役割を「ドライバー」、隣で同じコードを見ながら一歩引いた視点で考える役割を「ナビゲーター」としています。

ペアプロ相手に知識などの差がある場合は、知識を持っている方が「ナビゲーター」になることが多い傾向にあります。なので、気をつけないと何時間も役割が固定されてしまうことに。こうなると「ナビゲーター」の方も集中力が続かなくなってしまいます。そこで、「ナビゲーター」にはタイムキーパーの役割も持ってもらい適宜交代できるようにしました。

大きな設計は2人でする

規模の大きな変更や業務ロジックの大きな設計をするときは、手を止めて2人で設計に入ります。これは、大きな修正や追加は、設計の方向が決まらないと何を書いて良いのかわからず止まってしまうことや、そのままコードを書き続けても非効率なことが多いからです。

このときは2人で議論しながらホワイトボードに書き留め、それをスマホのカメラで撮影して設計資料として活用しながら開発をしていきました。

空気が伝わる

ペアプロでは自分のやっていること、思っていることを口に出しながらパートナーとコミュニケーションを取っていくのが基本です。しかし、しばらく続けていくと、ちょっとした間や表情などで「どうしたんですか?」と聞かれるように。
そうすると無意識に感じていた違和感を言語化することで、自分でも何がおかしいと感じているのかが把握できるようになりました。

これもリズムを共有しているペアプロならではのメリットかもしれません。

まとめ

繰り返しになりますが、ペアプロを導入した実感としては、オンボーディングにおいては「ナレッジ」の共有のメリットが大きく、一方で開発効率低下のデメリットは少ないので、効果的な施策だと感じました。

ただ、ペアプロ自体はコミュニケーションの比重がとても大きく、ペア同士の相性や心地よいコミュニケーションスタイルの違いなどにより、人によっては合わないこともあるかもしれない、というのが正直な感想です。

実際に、今回ペアプロを行なった古賀さんの場合は、もともと設計に興味を持っていて自分で勉強していた背景もあり、「なぜこういう設計にするのか」という説明が不要だったり、理解が早かったのでペアプロがしやすかった面があります。

今回は「ペアプロを導入してみて、わかったこと」をテーマに、ペアプロを導入した側の視点で振り返ってみました。ペアプロを通じて設計のことをいろいろ語りながら開発したいエンジニアの方は、ぜひお気軽に面談にお越しください。

ホワプラで働くエンジニアの話を聞いてみたい方はこちら。

八巻 紘士(やまき ひろし
大手化学メーカーのIT子会社に新卒入社し、業務系SIerにおいてプログラマーやSE、PMを7年間経験後、Web系のSIerに転身。2016年4月 ホワイトプラス入社。現在は、システム開発グループのマネージャーとして、組織のマネジメントや社員の育成に携わるかたわら、自らもプロジェクトに参加し業務を進めている。好きな食べ物はカレー。最近はカロリーが気になって食べる回数が減りがち。

記事をシェアする