完全ペアプロは「やりすぎ」だった。失敗を経て辿り着いた、ペアプロ×開発組織の最適解【Tebiki渋谷】

アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。

かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社は、ペアプロを組織に浸透させるために、一時は全てのプログラミングをペアプロで行う「完全ペアプロ」に振り切ったものの、そこで多くの課題に直面したと言います。

「完全ペアプロ」によって、Tebiki社はどんなメリットを得たのでしょうか。そして「完全ペアプロ」でどんな課題が生まれ、それらをどのように課題を乗り越えてきたのでしょうか。「現在はペアプロをうまく取り入れられている」と語るCTOの渋谷さんに、これまでの取り組みを振り返りながら、ペアプロ導入時の注意点について話してもらいました。

• keyboard_arrow_down レビュー時間削減のために、「完全ペアプロ」を開始
• keyboard_arrow_down メンバーから離職を切り出され、方向転換を決意
• keyboard_arrow_down チーム内でペアプロ・ソロプロを選択する運用へ
• keyboard_arrow_down ペアプロ導入を成功させる4つのポイント
• keyboard_arrow_down 大事なのはメンバーにオーナーシップを持たせること

――Tebiki社では2022年9月に完全ペアプロを始めたそうですが、何がきっかけだったのでしょうか。

渋谷：ペアプロ導入を検討し始めたのは、開発スピードが低下していると感じたことがきっかけでした。2022年1月頃にエンジニアの数が僕1人から5名ほどに増えてから、「新機能リリースのお知らせ」を出す頻度が、毎週から隔週ペースに落ちてしまったんです。

そこでFour Keysの測定を行ったところ、非同期的なレビュー作業にコーディングの2倍以上の時間がかかっていることがわかりました。

――なぜそのような状態になっていたのでしょうか。

渋谷：エンジニア間のスキル差が一つの要因だったと思います。実は当時、5人のエンジニア中2人は、ジョブチェンジを経て初めてエンジニアとして働き始めたメンバーだったので、シニアのエンジニアたちが彼らのコードをレビューするのに時間がかかっていたんです。

業務に真剣に向き合っていたからとはいえ、流石に時間がかかりすぎていましたし、これだけ時間をかけてのレビューが続いたらお互いに疲弊してしまうかもしれない。そのため、まずはもっとレビュー時間が短くなるように、コーディング中に困ったらシニアエンジニアに直接話しかけるようにしてほしいと呼びかけました。しかし、話しかけること自体に遠慮してしまう部分もあったのか、あまり効果はありませんでした。

渋谷：ペアプロという選択肢が浮上したのはそのときです。ペアプロなら、コードレビューに似たやりとりをその場でできるので、レビュー時間が短縮できますし、シニアとジュニアが一緒に取り組むことで育成効果も期待できると思いました。

当時は「やるなら一度徹底的にやったほうが、大きなメリットを得られるのでは」と考え、全てのコーディングをペアプロで行う「完全ペアプロ」を始めようと決断しました。

――組織にはペアプロの導入をどのように伝えたのですか？

渋谷：もともとペアプロに興味を持っていたメンバーから、ペアプロのメリットについて10分ほどチームにプレゼンしてもらいました。その際、数字に基づいて具体的に説明してもらったことで、メンバーにも受け入れてもらいやすくなったように思います。

2人のエンジニアがそれぞれソロプロで開発を進めた場合、2ラインが走ることになります。ただ当時は、レビューやその後の修正に、コーディングの2倍時間がかかっていました。コーディングに1日かかるとしたら、レビューや修正に2日かかり、デプロイまでは3日を要するわけです。

ペアプロで開発する場合、2人のエンジニアで1ラインしか走らせることができません。でも、レビューや修正の時間を別途確保せずとも、その場で済ませることができます。そもそもフィードバックが早ければその分修正コストも減るため、コードのブラッシュアップにかかる時間は、ソロプロでのレビューや修正にかかっていた時間と比較して10分の1に減るだろうと概算しました。そうなれば、同じ時間あたりで開発できる量は結果的にソロプロよりも増えるでしょう。

渋谷：こうした説明をした結果、当社は顧客に早く確実に価値提供したいと望むエンジニアばかりだからか、「そんなに速く開発できるようになるなら、とりあえずやってみよう」と前向きな雰囲気を醸成することができました。CTOとしても「うまくいかなかったらやめればいい」程度に考えていたので、当時は特に懸念はありませんでした。

――完全ペアプロを始めてみて、いかがでしたか？

渋谷：メリットはたくさんありました。導入前まではPull Requestをマージするまで4日かかっていたのが、24時間以内に短縮できましたし、停滞していたユーザーへのリリース告知の回数も、遥かに多くなりました。期待していた以上の効果が得られて「これはいいぞ」と感じました。

定性的な面でも、メンバーから「書いたコードに対する安心感がある」「難しい課題をペアで解決したときに達成感が得られる」という反応が多くありました。特に不安を感じやすい、複雑な設計に取り組むときの手段として、ペアプロがうまくハマっている印象がありました。

「完全ペアプロ」を始めてから1年間ぐらいは、全てが順調に進んでいると思っていました。

――実際は違ったのでしょうか？

渋谷：振り返ってみると、完全ペアプロを開始して半年ぐらい経った頃から、小さな不満の声は聞こえていたんです。メンバーと雑談しているとき、ふと「じっくり考える時間がほしい」と言われたこともありましたし、リーダーから「自分の仕事のリズムと合わないと言っているメンバーがいる」と報告を受けたこともありました。一部のメンバーに、少しずつ不満やストレスが溜まっているような予感はしていました。

でも、期待以上の効果が出ていたからこそ、そのデメリットにはあまり目が向いていなかったんです。まだ半年しか経っていないから、もう少し続けてみたら、今やりづらいと感じているメンバーもいずれペアプロに慣れるのではないか、と軽く捉えていました。

それに、広報との兼ね合いの問題もあったと思います。当時はKaigi on Railsで、完全ペアプロの導入を大々的にプレゼンした直後だったので、すぐにやり方を変えることはなかなか考えられませんでした。

――では、何が完全ペアプロをやめるきっかけになったのですか。

渋谷：頼りにしていた業務委託のメンバーから、「契約終了を考えている」と打ち明けられたんです。

「Tebikiのプロダクトやチームは好きだしもっと貢献したいけれど、ペアプロでしか開発できないのであれば、私には合わないし、もうここで働き続けられない」と。その人も「ペアプロがしんどい」とこぼしていたメンバーの1人でした。彼の話を聞いたときに初めて「ペアプロで開発するしかない状態は、ここで働きたくないと思ってしまうほど辛いことなんだ」と気づかされ、愕然としました。

よくよく考えてみると、当時はチームの状態もあまり良くありませんでした。リリースの内容やデリバリーの頻度は悪くなかったのですが、「完全ペアプロ」への不満やストレスがメンバーに溜まっていたからか、全体的に雰囲気がピリピリしていて、1on1でもネガティブな意見が多く出てしまっていました。

信頼していたメンバーが離れかけ、チームもうまくいっていない。ペアプロのデメリットから目を背けてきたことを深く反省しました。

――その後、組織にはどのような変化がありましたか。

渋谷：チームで対話した結果「ペアプロかソロプロか、どちらか好きな方を自由に選ぶ」という方向性でまとまりました。もちろんペアプロのメリットは今まで通り活かしたいので、会社としては推奨しています。しかし強制はしていません。

「完全ペアプロ」として徹底的にやったことで、開発案件の中にはペアプロに向いていない案件もあるとわかってきていました。そういった案件に取り組むときや、ソロプロでやりたい気分のときは、遠慮せずソロプロを選んでほしいと伝えています。

――ペアプロかソロプロか選べるようになると、ソロプロを選ぶタイミングが増え、かつての「開発スピードの低下」という課題がまた生じてくるのではないかと思います。どんな対策をしていたのですか？

渋谷：開発スピードを低下させないために、

①マージまでの時間を計測して、もし数値が悪化していれば、リーダーが主導してチーム全体で原因を探ること
②その要因がソロプロによって生じるものであるならば、ペアプロの時間を増やす検討をすること

を、全チームに依頼しています。

数値低下の要因分析をした結果、ソロプロ時に実装者とレビュアーの間で設計や実装の方針が異なり、Pull Request上でのやり取りが増えていることが課題となっている場合は、ペアプロで同期的に作業する機会を増やしたほうが、より効率よく開発を進められるようになるでしょう。

ただ、数値が悪いからと言ってすぐにペアプロに切り替えるべきだと考えているわけではありません。ソロプロ時のレビューなど非同期的なフィードバックに時間を要していることが明らかな場合でも、それ以外にもリリーススピードの低下につながる課題が存在しているときもあります。例えばlintに任せられる内容が多かったり、CIに時間がかかっていたり。であればまずは、そうした課題を適切に解決していくべきです。

渋谷：チームには、「どんな場合でも数値が落ちたら直ちにペアプロを行うべき」とするのではなく、リリーススピードが落ちている要因を特定し、適切な解決策を協議する中で、ペアプロがそれに資するのであればペアプロを選んでほしい、と伝えています。

こうして、チームのパフォーマンスが低下している真の原因を、メンバーが自分達で考え解決策を選んでもらう方が有効な解決策を見極められますし、その結果ペアプロで進めることが決定しても、以前よりもメンバーが納得感を持って進められるようになったと思います。

今ではエンジニア30名程度まで組織が拡大していますが、今のところこの方法で、新メンバーとも協力しながらスピード感をもって開発を進めていけています。

――メンバーがペアプロをする際、うまく進めるためのポイントとして蓄積されているノウハウには、どんなものがありますか。

渋谷：特に意識しているポイントが大きく4点あります。

1つ目は、ペアプロに取り組む2人に、お互いの役割を理解してもらうことです。

2人の役割が明確になっていないと、「一方がコードを書くのを、一方がただ見ているだけ」という状況になりがちです。そうならないよう、ペアプロにおけるナビゲーターとタイピストの役割を全員で理解しておくために、書籍『モブプログラミング・ベストプラクティス』の読書会を定期的に行っています。その結果、お互いに期待されている役割やその意義が明らかになり、スムーズかつ有意義にペアプロを進められるようになりました。

2つ目は、休憩のルールをつくることです。

ペアプロ中は、ナビゲーターもタイピストもとても頭を使います。しかし乗ってくるとつい休憩を取らずに進めてしまい、あとで急激に疲労が押し寄せてくる場合があります。それではかえって生産性が落ちてしまうし、取り組むメンバーたちにとってもつらいので、最低でも1時間に1回、10〜15分の休憩を取ることをルール化しました。

3つ目は、ペアを変えるタイミングは、ペア同士で決めてもらうことです。

ペアの組み方については特に試行錯誤を重ねています。ペアプロを始めた当初は、1つの機能をつくり終わるまでは同じペアを継続させていました。しかしそれでは、その機能についての知識がその2人の間に閉じてしまい、ナレッジ共有が進まない。そこでペアを毎日変える運用にしてみたのですが、引き継ぎは大変だし、相手が毎日違うからそのたびにコミュニケーションを取り直さないといけないしで、結局混乱を招いてしまいました。

これらの失敗を参考に、今は、ペアの変更を希望制としています。ペアを継続するかどうかはペア同士で相談して決めてもらい、もし余るメンバーが出てきた場合は、GitHub CopilotなどのAIと組んでもらっています。今のところはこの運用において目立った課題は出てきていないので、当面はこのままやっていこうと考えています。

ちなみに、ペアの組み合わせについての規定は設けていません。必ずシニアとジュニアが組むわけではなく、ジュニアエンジニア同士で組むこともあります。その場合、もし必要であればシニアエンジニアが自発的に見守りに入ったりしてフォローしてくれています。ジュニア同士など近しいスキル感のメンバー同士でフラットに議論し、よりよい設計やコードの書き方を探求することで、必要な情報を集めて考える力が身につき、スキルアップにつながっています。

4つ目は、開発中の意思決定をペアの中に閉じることです。

ペアプロの意義は、同期的なコミュニケーションにより、その場で全て2人で決められることにあります。だからこそ、ペアプロのメリットである「スピード」が出る。つまり「この仕様どうなっているんだろう、聞いてみよう」と誰かに質問した時点で作業が非同期になり、効率が落ちてしまいます。そのため、開発中の意思決定はペアの中で全て行ってもらうようにしています。それに、2人で意思決定してつくった機能がそのままリリースされること自体が成功体験となり、ペアプロならではの達成感にもつながっています。

――ペアプロとソロプロを自由に選択できるようになってから、開発組織はどのように変化しましたか。

渋谷：定性的な部分では、ペアプロによって、メンバー同士が日常的に忌憚なくコミュニケーションをとれるようになったことで、お互いを尊重しながら開発を進められるようになりました。また、2人で意思決定した機能がリリースされる体験が積み重なることで、全員がコードへのオーナーシップを持てるようになっています。

そのうえで、ソロプロを自由に選べるようになったことで、メンバーの心理的な負担も軽減できました。さらに、チームの課題への解決策をチーム内で決める経験を繰り返すことで、チーム全体の結束力も高まり、雰囲気も良くなっています。

もちろん、マージまでの時間やベロシティなど、定量的な数値面も、完全ペアプロを採用していたときよりも改善しています。

こうして良い結果が出て改めて、完全ペアプロをやっていた当時は、ペアプロをやるべき部分ではないところでもペアプロをするよう強制してしまっていたせいで、効率もエンゲージメントも下がってしまっていたんだなと実感しました。

結果論ではありますが、完全ペアプロを一度経験したからこそ、「ペアプロでやるべき仕事かどうか」をメンバー自身が適切に判断できるようになった側面もあるので、後悔もありつつ、学びも大きかったように感じます。

十人十色の志向性を持つ多様なメンバーが協力して良いサービスを開発していくために、「適切にペアプロを選ぶこと」は間違いなく効果的な施策だと思います。これからもメンバーの特性や、開発する機能の特性に合わせて適切にペアプロを選びながら、全員でコードやチームにオーナーシップをもって開発を進めていきたいですね。

取材：青山 祐輔
執筆：一本 麻衣
編集：光松 瞳
撮影：曽川 拓哉