こんにちは。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人の人が操作し、他の人がコメントして作業を進めることに既に慣れ始めていることが分かりました。当初考えていたよりもドライバーとナビゲーターの役割をスムーズにこなせていたため、実際にプロダクトコードでやってみることにしました。