モブプログラミングをチームで試している話

こんにちは。AndroidアプリでLINE公式アカウントの開発を担当している高島です。今回は、私たちのチームで試しているモブプログラミングの取り組みと、実際に取り組んで感じたことについてご紹介します。

モブプログラミングについて

モブプログラミングは、複数の開発者が1つのコンピュータを共有し、協力して問題を解決する開発手法です。モブである人たち（ナビゲーター）が解決方法を提示してガイドし、キーボードの前に座る1人（ドライバー）がコーディングします。ドライバーは一定時間ごとに交代します。

私たちのチームは、後ほど紹介する本を参考にして、合わないところは変更しながら、現在は次のような形で週に1度90分間行っています。

準備（5分）
- 新しいテーマに取り組む場合、問題を皆に共有し、どう進めるか方向性を話し合って決めます。
- 前回から引き続き同じテーマで行っている場合、前回やったことと、前回の振り返りで次回やろうと決めていたことを振り返ります。
本編（80分）
- 準備で決めた方向性に沿って、ナビゲーターが具体的な解決方法を考え、ドライバーがコードを書きます。
- ドライバーは10分ごとに交代します。
振り返り（5分）
- 口頭で1,2個、良かった点や改善できそうな点を挙げ、次回取り組めるようにします。
- 次回のドライバーの順番をランダムで決めておきます。

次に、そもそもなぜ始めたのか？　どういうことをしていく中で、この形になったのか？　を紹介していきます。

モブプログラミングを始めたきっかけ

もともとは、最初からモブプログラミングを導入しようとしたわけではありませんでした。ある日、チームのオフィス出社日に、ペアプログラミングをメンバーへお願いしたところ、他のメンバーも参加したいと言ってくれたことから、皆で画面を囲んで作業をするようになりました。この時はドライバーは1人のまま固定で、一般的に言われるモブプログラミングの方法ではありませんでした。それでも、既存のコードについての議論や知識共有ができ、メンバーにとって非常に有意義な時間だったため、その後も月に1度のオフィス出社日に1時間集まるようになりました。PRのレビューやデバッグ機能の実装についての議論など、困っていることがある時に一緒に解決する会のような位置付けになっていました。今考えると、集まって皆で作業することに慣れる段階だったと思います。

最終的に、2週間に1度1時間、オフラインだけでなくオンラインでも集まるようになっていました。この時は、課題を持ってきた人がPC画面をディプレイに映し、交代することもなくずっとPCを操作していました。オンラインの時も同様に、Zoomで画面をシェアし、他の人がコメントしていく形で進めていました。

皆で1つの作業をすることに慣れてきた頃、より有意義な時間にしたいと考え、モブプログラミングについて学び、今度は一般的に言われるモブプログラミングの方法を導入してみました。モブプログラミングの利点である知識の共有は、特に私たちのチームに必要なものでした。もともとLINEアプリの公式アカウントの機能を開発するチームがあり、1年ほど前に他のアプリを開発していたチームが合流してできたチームなので、既存のメンバーとのプロダクトコードに関する知識の差を埋めていくために有用でした。また、そういった構成のチームのため、コミュニケーションを取れる機会が欲しかったのもあり、モブプログラミングを試したいと思いました。

参考にした書籍はSoftware Teamingとモブプログラミング・ベストプラクティスです。Software Teamingは、特にモブプログラミングをチームで導入する際の考え方が理解でき、モブプログラミング・ベストプラクティスは、やり方に困った時の具体的な方法が提示されています。

実際にやってみて感じたこと

モブプログラミングを行うには、ルールに慣れる段階があると良いとされています。モブプログラミングの基本的なルールは次の通りです。

"For an idea to go from someone’s head into the computer, it must go through someone else’s hands.” Llewellyn Falco
アイディアが誰かの頭からコンピュータに入るためには、他の誰かの手を通過する必要がある。
引用元: Software Teaming

このため、モブプログラミングではナビゲーターが解決案を考え、ドライバーは伝えられた案を実装して書いていくというルールがあります。1人で開発する時とは違い、ドライバーが自ら実装しようとせず、ナビゲーターが自分の考えを説明して他の人に理解してもらう役割をこなすためには練習が必要です。私たちも本にならい、始めはプロダクトコードを使わないお試し期間を設けました。これは、本当に私たちにモブプログラミングが合っているかを確認する期間でもありました。合えば続けてやりたいし、合わなければチームに合うものが他にないか探そうと考えていました。

お試し期間

モブプログラミングのやり方を伝えた後、プロダクトコード以外のテーマでモブプログラミングをしました。テーマとして使ったのは、バイナリサーチを思いつく何種類かの方法で実装するCodeKata 02 Karate Chopです。CodeKataは参考にした書籍で紹介されていたもので、1〜2時間程度で解決できる問題がいくつか用意されています。全員が集まるタイミングはなかったので、2回に分けて実施し、皆が1度は試せるようにしました。

その後、全員で集まって試す機会を設けようとしましたが、テーマ選びが難しく試せませんでした。他のCodeKataや競技プログラミングの問題をテーマとして取り上げようとしたものの、問題自体が理解しにくいものを選んでしまうことがありました。プロダクトコード以外のテーマを選ぶ際は、自身が人に伝えられるほどに問題を理解できたものかつ、メンバーが解いたことがなさそうな問題を選ぶと良いと思います。また、海外メンバーがいる場合、日本語のアルゴリズム用語は難しい可能性があるので、用語を英語で言うように心掛けるか、もともと専門的な用語が出にくいような問題を選ぶのも良いと思います。

結局プロダクトコード以外をテーマにしたのは1度だけでしたが、試す中で、集まって皆で作業したり、1人の人が操作し、他の人がコメントして作業を進めることに既に慣れ始めていることが分かりました。当初考えていたよりもドライバーとナビゲーターの役割をスムーズにこなせていたため、実際にプロダクトコードでやってみることにしました。

プロダクトコードで実践

週に1度という頻度での開催なので、機能実装ではなく、テストが不足しているクラスにテストを追加することをテーマにしています。テストを書くことに慣れているメンバーの知識が共有されることも狙いの1つです。各々が機能を実装している際にテストが足りていないと思ったクラスを、Wikiページにメモしてもらっているので、そこから選んでいます。

もしテストを実装している中で、設計やテスタビリティの観点から、プロダクトコードのリファクタリングもした方が良いと決まった場合、テストの実装終了後にテスト対象のプロダクトコードのリファクタリングもモブプログラミングで行っています。

プロダクトコードでモブプログラミングを行っている中で、いくつか課題点が見えてきました。これらの課題点について、開催後に都度改善案を決め、次回に取り組んで改善していきました。また、ある程度の回数を開催した後に30分くらい時間を取って、KPTでしっかり振り返りをしたのも、皆の意見がいつも以上に聞けたり、開催している側として気になっていたことも聞ける時間になって良かったです。

以下に、私たちが開催する中で改善した点や決めたことを紹介します。

ドライバーの実装方法：初めはオフライン、オンライン問わず、私のPCをドライバーに操作してもらっていました。オンラインの時はZoomのリモートコントロールを使っていました。よく聞くのは、Gitにブランチを用意して、ドライバーにプルしてビルドしてもらっておくという方法だと思いますが、最初からこれをするにはハードルが高いと思ったので、参加者に準備が必要がない形で行っていました。しかし、他の人が設定しているIDEの操作の難しさや、オンラインの時のラグなどによりやりづらさがありました。振り返りで、ブランチをプルしておくことにそこまで抵抗がないことが分かったので、今はGitにブランチを用意して、ドライバーにプルしてもらう形で行っています。$git worktreeを使ったり、リポジトリを2つ用意しておくなど、各自工夫して、自分の作業中のブランチに影響が出ないようにしています。
ディスカッション：プロダクトコードを使ってモブプログラミングをしていると、既存の仕様についての質問や、改善方法についてのディスカッションがよく発生します。時間で区切ったり、別で話し合うことも考えましたが、チームで振り返りをする中で、そのままディスカッションを続ける方針に決まりました。
開催時間：当初は60分で行っていましたが、ディスカッションや質問に時間がかかることが多く、1つのクラスに対して回を重ねていました。そのため、もう少しまとまった時間を取りたいということで、開催時間を90分に延長しました。
インターバル：初めは7分でドライバーを交代していました。しかし、短すぎるとのことから10分に変更しました。もっと長くするか検討しましたが、皆1度はドライバーを担当するようにしたいと考えると、10分が妥当かなと思っています。ただし、きっちり10分ではなく、ある程度キリが良いところまでやったりと柔軟に交代しています。
オンラインでの顔出し：オンラインでドライバーをしている時、全員がカメラをオフにしている中で無言になると、ナビゲーターが考え中なのか、同意されているのかが分からず不安に感じます。振り返りの中で改善を検討し、可能な限りカメラをオンすることにしたところ、ナビゲーターの反応が分かりやすくなりました。離席している時はカメラをオフにするので、声かけもしやすくなりました。

おわりに

モブプログラミングを通して、チーム内の知識共有やコミュニケーションがしやすくなったと感じています。

参加メンバーからも、軌道に乗るまでは「皆の時間を使って開催し続ける価値がある会になっているのか」と悩む声がありました。しかし、リーダーが「まずはやってみよう」と背中を押してくれたり、任意参加にもかかわらず毎回全員が積極的に参加してくれたおかげで、安定して開催できるようになりました。本当に感謝しています。

これからもチームにとってより良い時間にしていけるよう、皆で改善していこうと思います。