はじめに
はじめまして。Product Teamの中嶋です。今月からチームシャッフル*1でSPEEDAのR&D機能の開発を担当しています。
Product TeamではフルタイムでのペアプロとTDDを常に実践しています。
この話を社外でお話すると「どんな風にやっていくのかが想像つかない」とよく言われます。
私も前職で一時的にペアプロを導入することはありましたが、それを常にやり続けるというProduct Teamのペアプロ文化が入社するまで全く想像できませんでした。
そこで本記事ではProduct Teamがどのようにペアプロをしているのかをお届けしようと思います。
- はじめに
- ツールについて
- ストーリーとペアはサインアップで決める
- まずはテストから書く
- 1時間に一度は休憩とペアチェンジを行う
- ソースコードのPushとデプロイ
- わからなければすぐ別のペア/チームへ聞きに行く
- おわりに
- 宣伝
ツールについて
まずはどんなツールを使用しているかを箇条書きにしてみます。
- コミュニケーションツール
- Gather
- Slack
- miro
- ペアプロツール
- Anydesk（リモートデスクトップ）
- VSCode LiveShare
- IntelliJ Code With Me
私たちのコミュニケーションの基盤としてGatherと呼ばれるリモートオフィスツールを使用しています。
後にも書きますが、私たちは頻繁にペアをチェンジして、必要があれば別のペアやチームに口頭で質問をすることをよくやっています。
その文化をリモートでも実現する為に、同じ空間にはいるけど別のデスクで作業をしている感覚を作り出すのに向いていたのがGatherでした。*2
コーディングするツールについては大きく分けて二通りの方法があり、
Anydeskというリモートデスクトップを使って、会社のマシンにペアで入ってコーディングするやり方と、どちらかのローカルPC上でLive Share もしくはCode With Meを利用しています。*3
ストーリーとペアはサインアップで決める
Product Teamでは実装すべき機能はすべてユーザーストーリーとして書き出しています。
ストーリーは個人ではなくチームに紐付いていて、誰かどのストーリーをやるかを決めていきます。
コロナ禍になる前は、オフィスにあるホワイトボードに付箋を貼っていたのですが、今はmiroでカンバンを作っています。
カンバンにあるストーリーのどれをやるかをサインアップ*4し、同じストーリーにサインアップしたエンジニア同士がペアとなり、そのストーリーに着手することになります。
私のチームは4人いるので、上図の時はWIPレーンの上のストーリー(緑)と下のストーリー(青)に分かれて作業を開始しています。
まずはテストから書く
Product TeamではTDDを大事にしています。
テストの順番はアウトサイドインが基本となっていて、全体E2E → モジュールE2E → ユニットテストの順番で書いていきます。
前提としてProduct Teamが作っているシステムはマイクロサービスが主体となっており、ざっくりFrontend、BFF、Backendとモジュールが分かれています。
ここで言う全体E2Eテストとは、ユーザーが画面から触ったときにどんな挙動になるのかの期待値を書いていきます。
# ユーザーはログインして、トップページを見ることができる * 一般ユーザーでログインする * トップページが見えていること
モジュールE2Eテストは、そのAPIを利用する側（クライアント側）の視点で見たときに、どんな挙動になって欲しいかの期待値を書いていきます。
# 企業の情報を取得することができる * "/v1/xxx/yyy"にGETリクエストする * レスポンスのステータスコードが"200"である * レスポンスのJSONの"companies.0.name"が"ユーザベース"となっていること
ちなみに弊社のE2EテストはGaugeというツールを使用して、上記みたいに自然言語に近い形でテストを書いています。
Gaugeについては以下の記事で詳しく紹介をしています。
これを見た時に、テストがすごく多いなと感じた方がいらっしゃるかもしれません（私も初見多いなって思ってました）。
ただ、このように小さな単位でテストファーストプログラミングを行うことにより、いま自分達が何を行うべきかに集中することができます。
通らないテストがある＝自分達が何の問題を解決をしなければいけないのかが明確になっているので、それを道標にペアプロすることができるのです。
1時間に一度は休憩とペアチェンジを行う
ペアプロはとても集中力がいるもので、休憩は適度に入れる必要があります。
Product Teamでは60分、長くても大体90分くらいで休憩を挟むようにしています。
休憩明けのタイミングで、ペアチェンジを行います。
ペア①：Aさん Bさん 【ストーリーXを実装中】
ペア②：Cさん Dさん 【ストーリーYを実装中】
ペアチェンジ後↓
ペア①：Dさん Bさん 【ストーリーXを実装中】
ペア②：Cさん Aさん 【ストーリーYを実装中】
これは特定のエンジニアに開発のコンテキストが寄ってしまうことを防ぐのと、別のエンジニアによる新しい視点を持ち込むのが目的となっています。
特にバグ対応や設計に行き詰まったときこそ積極的にペアチェンジを行い、別のエンジニアからの目線の意見を貰ったり、現状を説明することによって頭が整理されて解決に導くことができたりします*5
ソースコードのPushとデプロイ
晴れて全体E2EがPassしたらコードをPushします。
Product Teamは一部を除いてトランクベース開発を採用しています。
トランクベース開発は一言で言うと、常にmainブランチ（トランク）のみで開発を行って直接Pushします。
常にペアプロをすることでリアルタイムにレビューができているので、特にレビュープロセスを挟むことはしていません。
ペアプロのレビュープロセスについては、以下の記事でも紹介しています。 tech.uzabase.com
Pushした後はCI/CDパイプラインを動かし、すべての自動テストが通れば、ステージング環境へとデプロイされるようになっています。
その後、ステージング環境で確認して問題がなければ、本番環境へデプロイして確認し、リリースとなります。
ソースコードのPushタイミングについて
トランクベース開発だと、「1つのストーリーが全て終わり切るまでPushできないのか？」と思われるかもしれませんが、そこはあまり気にせず、テストを書いてRED状態でもPushしたりします。
Gaugeにはtag機能があり、 tags: unimplemented と書いておいて、パイプラインで実行する際にはフィルターして除外する仕組みにしています。
わからなければすぐ別のペア/チームへ聞きに行く
Product Teamのユニークな組織文化の一つになりますが、「何かに行き詰まり、考えたり調べて分からなかったら、2〜3分で別のペアやチームに聞きに行く」とよく言われます。
たとえばあるAPIのパスがわからなかったり、定時バッチがどこのジョブで動いているかなどの社内特有のものから、いま書いている言語仕様がちょっと調べてわからないなどあったら、詳しい人に聞きに行くことを推奨しています。
これは調べている時間を掛けるよりも聞いてしまった方が大抵早く終わるので、チームの生産性を損なわないからです。
また人に聞くことで、知見の共有が活発になっていくのと、教える側も教えることで言語化が出来ていく、という考えがあります。
リモートワークでそれをどういう風にやっているかと言うと、先ほど紹介したGatherに全てのエンジニアがいる為、別ペアがいるテーブルに言って相談しに行っています。
おわりに
以上、簡単ではありますがProduct TeamのペアプロとTDD文化をご紹介させて頂きました。
私たちはどんな風にペアプロをしているのかイメージが湧いてきましたでしょうか？
徹底したTDDや頻繁なペアチェンジは結構変わっているように見えるかもしれません（私も慣れるまで1〜2ヶ月は掛かりました）。
ペアプロの細いコツや取り組む姿勢など他にも色々あるのですが、それはまた別の機会にお話できたらと思っています。
宣伝
ユーザベースではエンジニアを募集しています！
ペアプロ×TDDについて少しでも興味を持った方、ぜひ一度お話できればと思います！
