エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

ペアプログラミングで「強いエンジニアチーム」を作る! ヤフーが実践する全てペアプロ開発の手法

ペアプログラミング(ペアプロ)のメリットや導入方法について、ヤフー株式会社の山下真一郎さんが、フリマアプリ「ヤフオク!」や「PayPayフリマ」での実例をもとに紹介します。

ペアプログラミングで「強いエンジニアチーム」を作る! ヤフーが実践する全てペアプロ開発の手法

ペアプログラミング(以下、ペアプロ)は、2人のエンジニアが共同でプログラムを書いていく開発スタイルです。メンバー同士での知識の共有や、プロダクトの品質向上が見込めるとされており、多くの企業が導入を進めています。

本稿では、ヤフー株式会社のヤフオク!カンパニー開発本部でペアプロを導入し、現在はPayPayフリマの開発の取りまとめを行う山下真一郎@shin_yahoojpさんに、ペアプロに取り組む意義やその手法について解説してもらいました。

なぜペアプロが必要なのか?

ペアプロの利点は、チーム内の技術力を底上げしてくれることです。強いエンジニアチームを作るために、極めて有効な方法となります。強いエンジニアチームの定義とは、チーム全体の技術力が高く、特定の業務が属人化していないことです。

最終的なコードが完成するまでに、優秀なエンジニアはどう試行錯誤しているのか? 不具合やエラーをどのように調査して解決しているのか? コードを早く正確に書くためにどうエディタを使いこなしているのか?

こういった技術書には載っていない情報を伝えられるのが、ペアプロの素晴らしさです。メンバー全員の技術力が、短期間で底上げされます。

質の高いコードレビューとしてのペアプロ

ペアプロは、質の高いコードレビューでもあります。ヤフオク!の開発チームでペアプロを行う際には、プルリクエストを作成してコードレビューを挟むようなステップは存在せず、実装したコードはレビューなしにそのまま本番コードにマージしています。

プルリクエストをコードレビューしていて「そもそも初期の設計があまり良いものではなく、修正すべきだが、すでに実装がかなり進んでいるコードを無駄にするのも、良くないかな?」と悩んだ経験がある方も多いかもしれません。

ペアプロでは、最初の設計方針から、変数のネーミングといった細かい部分までを話し合って決めるので、このような手戻りは発生しません。

また、ペアプロで周りのメンバーから与えられるのは、技術の知識だけではありません。刺激もあります。これは副次的な効果ですが、私たちのチームではペアプロ導入以前と比べて、業務が終わった後に自主的に学習するエンジニアが増えました。

ペアローテーションで知識共有を加速

ペアプロを行う上でお薦めなのが、毎日ペアを組み替えるペアローテーションです。毎日ペアを変えることで、知識や情報を共有する速度を、加速度的に向上させられます。

このため、技術力に格差が生じているプロジェクトの立ち上げ時や、新卒や転職者のプロジェクト参画時に、ペアプロは最も効果を発揮します。

ヤフオク!の開発チームでは、毎日のペア決めに、プロジェクトメンバーである武田悠暉 @0__1_teaが開発した「席替えくん」というツールを使用しています。

GitHub - teakun/SekigaeKun: 席替えくん

前日に組んだペアのうち、どちらか片方だけが必ずそのペアに残り、もう片方は別のペアから迎え入れてペアを組ませるツールです。組んだペアの情報が毎週月曜日にリセットされるので、エンジニアが最大10人まで機能します。オープンソースとして公開されているので、自身のチームにカスタマイズしてお使いください。

ペアプロを実践して何が変わったか?

ヤフオク!では、1チームのエンジニア数を4〜10人にしており、細かくチームを分けています。前述したペアローテーションを導入しているため、毎日ペアが変わります。

次の日に組むペアは、前日に作業をしたペアのうちどちらか片方が必ず残り、他のペアから1人がやって来るというルールがあります。そして、その日の作業を始める前に、前日に取り組んでいた作業を、新しくペアを組む人に10分程度レクチャーします。

ペアローテーションのルール

ペアローテーションのルール

このルールで毎日違うペアと開発すると、一週間以内に各メンバーがチーム内の全ての作業に触れることになります。ペアローテーションを繰り返すことで、全員が案件全体の仕様に詳しくなり、属人化を防ぐことができます。

もし誰かがプロジェクトから離れることになっても、他の誰かが仕様を知っているので、引き継ぎ作業は発生しません。全員が全体の仕様に詳しいため、ドキュメントもほとんど書いていません。

このようにペアプロとペアローテーションを実践することで、ヤフオク!は強いエンジニアチームを作っています。

属人化をペアプロでどのように排除するか

ペアプロ以前は、一般的なgit flowとプルリクエストを用いて開発を進めていました。ですが、このやり方ではコードレビューや仕様についての問い合わせが、プロジェクト経験が長く、技術力のあるエンジニアに偏ってしまいました。

技術力の高いエンジニアにしてみれば、なるべくコードを書く時間を確保したいのですが、レビューや問い合わせの対応に時間が奪われてしまいます。その結果、経験の浅いエンジニアやプロジェクトの新規参画メンバーが成長しづらい環境になっていました。

そして、全体仕様に誰も詳しくない状態でタスクを引き継ぐと、事故が発生しやすくなります。従って、エンジニアを早期に育てることと属人化を改善することは、品質の高いプロダクトを作ることに直結します。

教育の一環として新人からペアプロに参加する

新メンバー参加時には、コードを読んで理解するコードリーディングを、既存メンバーとペアで行います。すでに設計やソースコードの意図を知っている既存メンバーと読み進めることで、全体仕様をより早く深く把握できます。

ヤフオク!では、チーム参加の初日からペアに参加してもらっています。不定期に増員が行われる大規模なチームでは、特にこのメリットは大きいと感じています。

次のグラフを見てください。ヤフオク!がペアプロやペアローテーションを取り入れてから約2年がたちますが、リリース数の増加、受け入れテストの失敗率や残業時間の減少など、さまざまな良い効果がもたらされました。ヤフーは、今後もペアプロ実践者を拡大していく予定です。

月別リリース数

月別リリース数

ペアプロ導入のハードルを乗り越える方法

チームにペアプロを導入するにあたって、どのようなハードルが生じるのか? また、ヤフオク!ではそれをどう乗り越えているのかを紹介します。

周囲の理解を得るには何回も丁寧に説明する

導入にあたって最も難しい点のひとつが、周囲からの理解でしょう。2人でひとつのコードを書くペアプロは、ともすれば「コードの生産性が半分になってしまうのではないか」と思われてしまいがちです。

大規模なサービスでは特に言えることですが、ものを作ること自体よりも、その品質を高めたり、不具合発生時に原因を特定してスピーディに修正することの方が難しいものです。ペアプロはその難しい点を解消するのに最高の方法だと筆者は考えていますが、それを周囲(特に非エンジニア)に理解してもらうことは難しい場合が多いでしょう。

私の上司は幸いなことに以前からプロダクトの品質と属人化に対して課題を感じていたので、ペアプロの導入には前向きで、説明は不要でした。

周囲はペアプロになじみがなかったので、企画・エンジニア・デザイナー合わせて全15チームに対して、ひとつひとつ説明会を行いました。ペアプロは今までの働き方を大きく変えることになるので、参加者を少人数にして、何回も丁寧に説明することが、理解を得るために重要なポイントです。

セミナーを少人数にすることで質問がしやすくなったのか、多くの質問が寄せられ、活発な質疑応答が行われました。その後も、ペアプロ導入により品質がどう向上したかをレポートにまとめて報告するなど、チームの外からも理解してもらえる活動を継続しています。

ペアを組むメンバーの選び方やコミュニケーションの取り方

ペアプロは良くも悪くも「人次第」なところがあります。ペアの人と1日中会話をしながら開発するわけですから、人の相性がとても重要になってきます。

ヤフオク!では、新メンバーがチームに参加する前に一度ペアプロを体験してもらい、既存のチームメンバーに意見を聞くなどして、メンバー選びには時間をかけています。

すでにメンバーが決まっており、そのメンバー内でペアプロを実施する必要がある場合には、まず1カ月ほどお試し導入してみることをお薦めします。

筆者の経験では、ペアプロをまだやったことのない人で、ペアプロに対して好意的なのは全体の約4割、そして残りの約6割は否定的です。そして、お試しでペアプロを1カ月続けると、否定的だった6割の約半分は、ペアプロが好きになります。試したこともなく、感覚だけでペアプロを否定するのは本当にもったいないので、実際にやってみましょう。

実際にやってみて「ペアプロが肌に合わない」と感じた人に対しては、別の期待値を与えてチームを分けています。最終的に全体の約3割が、最後まで「合わない」と言います。実践しても肌に合わなかった人に続けさせることは、お互いにデメリットでしかないので、ペアプロは好きになった人のみで続けています。

リモートワーク時には無理にペアプロをしない

対面でのコミュニケーションを重視するペアプロでは、リモートワークとの相性はあまり良くはありません。ヤフオク!では、リモートワーク時には無理にペアプロに参加することはせず、開発環境を整えたり、技術調査、軽微なデザインの修正などのソロタスクをするようにしています。

疲れたときは気分転換を

最後に、ペアでの作業は、想像以上に気力と体力を消耗するものです。安定したパフォーマンスを出せるよう、休息をとることも仕事の一部として、過度な残業は避けましょう。疲れたときも無理をせず、気分転換をしましょう。

ヤフオク!では、リフレッシュするために、執務エリア内にある卓球台で卓球をすることも業務のうち。その日のペアでダブルスを組み卓球をすることで、ペア力を高めることにも一役買っています。

卓球でリフレッシュ!

テスト駆動開発(TDD)とペアプロは相性が良い

ヤフオク!が実践するペアプログラミングは、ただ2人がペアになってプログラミングするだけではありません。ペアプログラミングと相性の良いテスト駆動開発(TDD、Test-Driven Development)という開発手法を用いて、ペアで作業をしています。

テスト駆動開発は「最初に失敗するテストを書き、テストを通すように実装をして、最後にリファクタリングをする」という一連のサイクルを素早く繰り返す開発手法です。

ここでは具体的にイメージしやすいよう、iOS開発を例にとって説明します。言語はSwiftで、エディタはXcodeですが、他の環境に置き換えても理解しやすいはずです。

整数を引数に取り、3桁ごとにカンマ区切りされた文字列にして返す関数を実装します。それでは、簡単なテストから書いてみましょう。

TDDでペアプロ1: 失敗するテストを書く

失敗するテストを先に書くので、エディタを起動したら、左側にテストを書くエリア、右側は実装エリアになるよう半分に分割します。

まず、Aさんが、次のような失敗するテストを書きます。

import XCTest
@testable import TestProject

class PresenterTests: XCTestCase {

    func test_整数から3桁ごとにカンマ区切りされた文字列が取得できること() {
        let result = Presenter().makeMoneyCountText(for: 11111)
        XCTAssertEqual(result, "11,111")
    }
}

テストを書き終わったら、テストを実行して失敗することを確認します。

TDDでペアプロ2: テストを通るコードを実装

次にBさんが、テストが通るように関数を実装します。

final class Presenter {

    private lazy var numberFormatter: NumberFormatter = {
        let formatter = NumberFormatter()
        formatter.numberStyle = .currency
        formatter.groupingSeparator = ","
        formatter.groupingSize = 3
        formatter.currencyCode = "JPY"
        return formatter
    }()

    func makeMoneyCountText(for value: Int) -> String {
        return numberFormatter.string(for: value) ?? ""
    }
}

実装が終わったらテストを実行して、失敗していたテストが通ることを確認します。

TDDでペアプロ3: リファクタリングして次のサイクルへ

最後に、Aさんがリファクタリングをします。この例では特に重複もないのでリファクタリングは不要ですね。これでTDDの1サイクルが終わります。

次のサイクルに入るときには役割を入れ替え、AさんではなくBさんが失敗するテストを書きます。これが筆者が実践しているペアプロの流れです。

役割を頻繁に入れ替えているので、片方が実装をし続け、もう片方がレビューをし続けるということにはなりません。ペアプロとテスト駆動開発の相性の良さが少しでも伝われば幸いです。

組織全体にペアプロを適用する

2019年10月現在、私はPayPayフリマの開発の取りまとめをしています。2019年4月から開発が始まったPayPayフリマは、バックエンドからフロントエンドまで、全ての開発をペアプロで行なっています。

バックエンド開発ではフレームワークはSpring Boot、プログラミング言語はKotlinを選択しています。開発当初のバックエンドチームは人数が少なく、Kotlinも未経験の方が多い状況でした。そこで「Kotlinやテスト駆動開発に精通している」Androidアプリエンジニアと、「Spring BootとJavaに詳しい」バックエンドエンジニアでチームを作り、ペアプロを進めました。お互いの足りない技術スキルが補完され、2週間ほど経過したころには進捗状況が一気に伸びました。

テストコードのカバレッジは特に重要視していないのですが、リリース間近のテストコードを省きがちなフェーズである現時点(執筆時である2019年9月時点)でも、カバレッジ90%を維持しています。

チーム編成の都合上、iOSアプリエンジニアはBFF(Backends For Frontends)の開発にも入っています。iOSアプリはSwift+Xcode、BFFはTypeScript+Visual Studio Codeと、扱う言語もエディタも異なるのですが、お互いの知識やスキルを補いあってペアプロを進めました。

今では、アプリエンジニアであっても必要であればBFFやバックエンドの修正をするなど、領域にとらわれずに柔軟に開発を進められる理想的なチームが作れています。

エンジニアからは「PayPayフリマの開発を通して、技術の幅を大きく広げることができた」という声をよく耳にします。ペアプロを毎日行うことはこれまでの開発方法とは大きく異なりますし、体力の消耗も激しいです。人によって好みも分かれる手法ではありますが、チームにもたらすメリットは非常に大きいです。興味のある方はぜひチャレンジしてみてください。

ヤフーにおけるペアプロ環境の作り方

ここまで、ペアプロの導入によって受けられるメリットや、ヤフオク!・PayPayフリマでの実例を紹介しました。興味をもっていただいた方のために、ヤフーにおけるペアプロ環境の作り方を紹介します。

ヤフーでは、次の2種類の方法でペアプロ環境を作っています。

iMacを使う
iMacにミラーリング用モニターを接続し、さらにキーボード2台とマウス2台をiMacに接続する
MacBookを使う
MacBookと1枚目の外付けのディスプレイをつなぎ、MacBookの内蔵ディスプレイを閉じる(クラムシェルモード)。さらに、2枚目の外付けディスプレイをのミラーリング用として1枚目とつなぎ、キーボード2台、マウス2台をMacBookに接続する

キーボードとマウスは、ペア間の物理的な距離を離すため、必ず2台ずつ用意してください。もちろん私物を使っても大丈夫です。

デスクはオカムラの上下昇降デスク、椅子は同じくオカムラの座面が高いバロンチェアを使用しています。プログラミングスタイルはスタンディングだったり椅子に座ったり、気分によって変えています。

ペアプログラミングの様子

もともとMacBook Proが貸与され、良い机もそろっているのでiMacや昇降デスクは不要なのですが、クリエイティブな空間で働きたいというエンジニアのモチベーションは大いに刺激されました。

現在120席あるこのペアプロ専用施設は820Labs(ハチニーゼロラボズ)と名付けられ、ヤフーCTOの藤門千明は「エンジニアの聖地」と呼んでいます。興味があれば施設の見学も可能なので、ぜひペアプロを体験しに来てください。

ヤフーの作業環境は、Pivotal Labsのやり方を元に構築されました。Pivotal Labsは、アジャイル開発の一種であるエクストリーム・プログラミングを教えるサービスを展開している企業です。ヤフオク!は、Pivotal Labsに参画して、エクストリーム・プログラミングを伝授してもらいました。そのプラクティスのひとつにあったのが、ペアプログラミングです。

山下 真一郎(やました・しんいちろう)shin_yahoojp

shin_yahoojp
ヤフー株式会社 ヤフオク!カンパニー開発本部。2011年度にYahoo! JAPANに新卒で入社し、Yahoo!メッセンジャー、Yahoo!メール、ヤフオク!などでiOS、Android両OSの開発を経験。現在はPayPayフリマアプリのプロダクトマネージャーを務め、Lean XPという開発手法を導入した高速で高品質なソフトウェア構築を行っている。

関連記事