ペイトナーでエンジニアをやっている脇田慎平（@shimpeee_）です！
僕が入社した2022年5月からチーム内でペアプロ導入を提案し、実際にこれまで何度か実施して得た経験や気づきを書きます！
結論
めちゃくちゃにイイです！！！ これからも続けていきます！！！
以降、始めたきっかけや良かった点、苦労したことなどを書きます。
きっかけ
ペイトナーには、「同期作業」という文化があります（僕がとても素敵だと思う会社文化のひとつです）。
「オンラインで繋いで、仕事の会話するもよし、雑談するもよし、黙って作業するもよし」 というものです。
業務上でのもくもく会みたいなものです。
「biz側（PM） x エンジニア」の同期作業を週2回、各30分ずつやっているのですが、これがもうすごく良くてですね。。。
ペイトナー社では現在、フルコミットメンバーは週2の出社でオフィスの席数の関係で出社日を曜日で分散させています。ですので、だいたいどのメンバーともオフィスで顔を合わせるのは週1回程度です。
リモート下ではどうしても全員が出社している時と比べるとコミュニケーションコストは上がります。PMと仕様の詳細やプロダクトの在り方等までがっつり議論できる場は、エンジニアとしてもすごくありがたい時間です。
他の人が会話しているのを聞いてるだけでもかなり学びがあります。
まだまだチームとしても課題だらけ（そもそも解くべき課題は何なのか？を探るフェーズでもある）なので、密にコミュニケーションを取りながら仕事を進めるのが好きな僕にとって、個人的にも非常に大切な時間です。
、、、で、思いました。
「これ、エンジニア同志のコミュニケーション活性化のために、エンジニアだけの同期作業もやりたいな！」
「てかそれってもう、ペアプロでよくね！？」
これがきっかけです。
チームのコアメンバーである社員3人ともペアプロ初心者。どう始めたらいいのかも全く無知の状態でしたが、「ペアプロやってみたい！」という気持ちだけで、えいやーで始めてみることにしました（向いてなければすぐ辞めればいいだけの話！）。
てかペアプロってどうやるん？
「よし、ペアプロやるぞー！」とSlackで盛り上がっていると、少しずつ周りのメンバーから情報が集まってきました。
過去、毎日8時間ペアプロをする（！？）現場を経験された方がいて、その方からペアプロ始めるにあたって役に立ちそうな記事をいろいろとシェアしていただきました。
これらをざっとインプットして、とりあえずはスクラムスプリント外のリファクタ系タスク（ペアプロがうまくいかなくて進捗出なくても問題ない）から始めてみることに。
実際やってみてどう？
ってことで、ここまで数回実際にやってみて感じたことを以下まとめてみました。
良かった点
学びがえぐい
これはもう一番のメリットです。
普段はスキル感の近い3人でやっています。常にコミュニケーションをとりながら、全員の持っている知識を総動員し、1つのタスクに向き合います。
Railsのお作法・設計・命名のテクニックなどの技術的な知識、ドメイン知識、細かい仕様についてだけでなく、エディタの使い方にいたるまで、補完し合いながら進めます。
やはり3人集まると、自分は知らないけど他の人が知っていること（逆も然り）がめちゃくちゃ出てくるので、時間当たりのインプット量がえぐいです。
また、一度CTOの三浦さん(@kazuman519)をナビゲータに迎えて「ストロングスタイル（つよつよエンジニアがナビゲータとなり、知識を伝授するスタイル）」で実施したこともあります。
このときは、いつもの3人が倒すことができなかった敵に対してどうアプローチしていくのかを、三浦さんがナビゲータとなって我々にデバックの過程を見せてくれました。
具体的には、「ActiveRecordで発生したバリデーションエラーの中身が見れない」という、Railsチュートリアルですら触るような初歩レベルで行き詰まっており、自分達の未熟さを痛感。。
三浦さんのデバッグをリアルタイムで見せてもらい、結局は地道に1つずつ、確実に原因を切り分けていくしかないんだな、、、と再認識する結果となりました。
レベルが近い人同士でやっても、つよつよな方とストロングスタイルでやっても、どちらでも大きな学びを得ることができます。
1人でうんうん悩まなくてよいので、早い
1人で実装していると、行き詰まったときにどうしても長時間考え込むことがあります。
そうならないよう、Google15分ルールを引用しながら、「適切に助けを乞うようにしましょう」という共通認識を持つようにはしています。
しかし、ああでもないこうでもないと試しているうちに、気づくと数時間経っていた、、、なんてことは、エンジニアだと誰しも経験したことがあるのではないでしょうか。
ペアプロではみんなで考えるので、行き詰まってから次の打ち手を見つけるまでの時間が圧倒的に短いです。
仮に全員の知識を以ってしても倒せない敵の場合であっても、「これは自分達には無理だからヘルプを呼ぼう」とスムーズに次のアクションにつなげられます。
一人でやっていると、意外と難しい部分じゃないかと思います。
コミュニケーション量が増える
ペアプロの心得にもあるように、ペアプロ中は「15秒の沈黙ですら長い」と感じてしまいます。そのため、ずっと会話しています（本当に、ずっと会話してる）。
そうしてたくさんコミュニケーションを取ることで、日々の仕事におけるお互いへの質問のハードルもかなり下がったように思います。
いわゆる「心理的安全性の高い」チームビルディングにおいても、ペアプロは非常に有効だと感じます。
単純に、楽しい！
みんなで「あーでもない、こーでもない」とわいわい会話しながらやる開発は、シンプルに楽しいです！！！楽しみながら仕事をすることは、取り組みを長く続ける上でも、生産性の上でも、非常に大事です！楽しい！
苦労した点
疲れる
ずっとコミュニケーションとっているので、すごく疲れます。疲れるので、定期的に休憩をとりましょう！（ペアプロの心得にも、一番最初に書いてあります。それだけ重要なことです！）
でも、たくさん学びがあって楽しい！！！
自分の意見を言語化する難しさ
実装方針等で議論しているとき、「ここはこうした方がいいんじゃないか？」と自分の意見を言う場面が何度もやってきます。これが結構難しい・・！
うまく言語化できない部分は理解が不十分なところなので、それが炙り出されてまた成長しちゃいますね！伸びしろ！！！
キリが悪い状態で終わる難しさ
ある日のペアプロで、予定していた時間がきてしまったけど、会議室空いてるし、キリが悪いからもうちょっとだけ延長しよか・・・！と延長したことがありました。
しかし、あと少しで終わると思ったところで新たな沼にハマり、1時間延長してさらにカオス化して終わる結果となりました。
すぐ解決するとは限りません。時間になったら中途半端でも終わらせる強い心が必要。
具体的には、終わる時間の10分前になったら、今日やったこと、今詰まっているポイント、次回最初に確認することを簡単にまとめることをルールとしました。
開発効率が落ちる！？
「ペアプロやると複数人で同じコードを触っているから開発効率が落ちる」という言説があります。これは、リソース効率・フロー効率の観点でいうとリソース効率重視の考え方だと思います。
www.slideshare.net
私たちのチームでは、スクラム開発を行っています。スクラム（およびアジャイル）開発は、まさにフロー効率を高める活動そのものです！
今はペアプロに慣れていないことで短期的に開発効率が落ちることがあっても、仕様・ドメイン理解の向上、メンバースキル向上, チームビルディングの側面を考えると、すぐにペイできるコストだと考えています！
まとめ
ここまで述べてきたように、苦労ポイントもありますが、生産性向上が期待でき、学びの多い楽しい取り組みとなっています！
これからはもっと頻度を増やし、スプリントのタスクに複数人をアサインし、ペアプロベースで開発を進めるということもできたらいいなと考えています！！！
おわりに
ペイトナーは「スモールビジネスにやさしい支払い・請求で新しい挑戦を後押しする」というミッションのもと、
オンライン型ファクタリングサービス「ペイトナー ファクタリング」とクラウド請求書処理お任せサービス「ペイトナー 請求書」を開発・運営しております。
これらのプロダクトを爆速でさらに成長させるために絶賛エンジニア募集中です！
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください！！
paytner.co.jp
