こんにちは、エンジニアサマーインターンねこチームです。
今回のインターンでは、社員のメンターさん 1 人とインターン生 4 人のチームで、開発を全てモブプログラミングで行いました。
インターン生は全員モブプロ未経験でしたが、色々と試行錯誤しながら自分たちなりの方法を見つけました。
この記事では、モブプロに挑戦していく中で気づいたモブプロのコツや、モブプロで陥りがちな問題とその解決策を紹介していきたいと思います。
最初のモブプログラミング
最初の 2,3 日目までのモブプロはうまくいきませんでした。知り合って数日の人とオンライン上で初めてのモブプロをやるというのは、やはり難しいことでした。以下のような 2 つの問題点がありました。
- ドライバーがただ実装を進めていき、ナビゲーターは見ているだけになる
- 一人が長時間ナビゲーターをやり続けてしまう
ドライバーがただ実装を進めていき、ナビゲーターは見ているだけになる
これは悲しいですね。モブプロとは、となります。
原因は二つあると考えました。
- ナビゲーターが実装についていけなくなる
- ナビゲーターが発言しにくいと感じる
ナビゲーターが実装についていけなくなる
自分で手を動かしていないためか、ナビゲーターは今ドライバーが何をしているのか、何をしようとしているのか、といったことが分からなくなりがちでした。
ナビゲーターが発言しにくいと感じる
出会って数日の人に画面越しにコードを書いているところに積極的に発言していくことにハードルを感じる人が多かったです。
一人が長時間ナビゲーターをやり続けてしまう
これではドライバーもナビゲーターも疲れてしまい、チーム全体にとってよくありませんでした。時間の区切りがなくなり、メリハリのない雰囲気になってしまいます。これも悲しいですね。
原因はこのように考えました。
ドライバーの交代するタイミングがわからない
どの辺まで実装が進んだら交代しようね、といったことがチームで共有されていなかったからとりあえずドライバー交代せずにそのまま進めていく流れになることがよくありました。
モブプログラミングの改善
以上のような問題を解決するため、チームで話し合い、以下のような工夫をすることにしました。
実装方針の確認
ドライバーの人が手を動かし始めるときに、どこに何を書くのか、といったことをメンバーたちに宣言してから作業に取り掛かるようにします。そうすることでチームで実装方針が共有され、ナビゲーターがついていきやすくなります。
また、こんな感じでドライバーの人からナビゲーターたちに呼びかけてみるのも効果的です。
- 作業する前に、「こんな方針で実装するつもりだけど、OK？」と確認してみる
- 作業した後に、「このように実装したけど、OK？」と確認してみる
こうすることで、ナビゲーターが発言しやすい空気作りにもなります。
30分でドライバー交代
試してみた結果、自分たちのチームでは 30 分ぐらいでドライバー交代するのがちょうど良さそう、ということになりました。
30 分で交代するために、あらかじめ 30 分程度で終わりそうなところまで課題を切り分けて、そこまで終わったら交代するという手順にしました。
しかし、課題にかかる時間を誤って見積もることもあるので、作業のキリがいいかは放っておいて 30 分で強制交代！とすることもありました。これも意外とうまくいきました。
ナビゲーターの役割分担
ここまでくると形式的にはだいたいいい感じにモブプロっぽくなってくるので、次はより効率的なモブプロをするための工夫です。
5 人チームなのでナビゲーターは 4 人いるわけですが、それぞれでいろんな役割をカバーできるといいよね、という話になりました。
以下のような役割が例として挙げられました。
実装を見守る
実装にバグを埋め込んでいないか、ドライバーが実装に詰まっていないか、といったことに注意しながら、時にそれを指摘しながら画面を見守ります。気をつけないと全員この役割になってます。
タスクをまとめる
実装を進めていくと、「これ後でやらなきゃね〜」みたいなタスクが見つかることがよくあります（エラーハンドリングとか）。それを発見したらスッと GitHub の Issues とか Slack とかにまとめてあげるとモテます。
先回りして実装を考える
「ドライバーが今取り掛かっている実装が終わったら、次はこれをやらなきゃいけないな」とか「この後あのライブラリを使うことになりそうだから先に API を調べておこう」とか、ドライバーが後々考えることになることを先に考えておきます。これもモテます。
以上のように、単にナビゲーターと言ってもいろんな役割があります。「じゃあ私はこの役割やるからあなたはこれをやってね」とかやってもうまくいかないので、ナビゲーターが周りを見ながら空いている役割を埋めようと心がけることが大事です。
モブプログラミングの環境
最初、自分たちはドライバーが画面共有することでモブプロを行っていましたが、途中で VSCode Live Share というものがあることを知りました。
これを使うと、例えばナビゲーターがコードの一部を引用したいとき、今までは「〇行目で〜」とか「〇〇っていう変数が〜」とか言わなくてはいけなかったのを、カーソルで示すだけでよくなるといったメリットがありました。
その他にも、ナビゲーターがドライバーが作業してるところから離れてコードを見に行けるようになったり、ドライバーの交代がスムーズになったりと、いいことづくめでした。Live Share はいいぞ。
モブプログラミングの Tips まとめ
以上、自分たちが三週間モブプロをやってきて発見したことは以下の通りです。
- 実装の方針を共有してから手を動かそう
- ドライバーは30分ぐらいで交代しよう
- ナビゲーターは色んな役回りをしよう
- VSCode Live Share を使おう
感想
モブプロって、「せっかく複数人いるのに 1 人しか作業していないのってもったいなくない？」と思われがちで、自分も同じことを思っていました。
確かに、自分たちが最初に行っていたような効率の悪いモブプロよりは、複数人で分担して開発した方が効率が良いと思います。
しかし、効率よくモブプロを行うことができるようになると、仕様や実装についての情報や、メンバーの困っていることやわからないことがチームで共有されたり、実装のミスを漏らさずに気づけたりすることで、手戻りの少ない作業を行うことができるというメリットがあります。また、メンバーがコードを書いている様子を見ることで、その人が持っている知識や技能を盗む機会にもなります。
このように、モブプロを上手に行うことで、作業を効率良くかつ楽しくすることができます。チーム開発の形態としてモブプロを採用するためのコツや、そのメリットについて考えることができたことが、このインターンで得られた最も大きな収穫の一つだと思っています。
