見出し画像

モブプロを試してみた

こんにちは!
サービス&デザインアシスト部のマネージャーです。

私たちの部では、定期的に勉強会の時間を設けています。
先日、モブプロをやってみたので、レポートしたいと思います。


モブプロ(Mob programming)とは?

Wikiによれば、
「モブプログラミングは、同じ時間、同じ場所で、同じコンピュータで、同じ作業をチーム全員で行う、ソフトウェア開発のアプローチである」
とあります。


そこで、こんな感じで進めてみました

  • チーム分け:同じプログラム言語を扱っている人どうし、3〜4人(概ね同じプロジェクトのメンバー)

  • お題:AtCorder から2問

  • 使用ツール:paiza.io(https://paiza.io/ja)

  • 言語:Java、Ruby、Swift、Python

ルール

  • 時間は45分程度

  • ナビゲーター(書くコードを指示する)役とドライバー(コードを書く)役に分かれる

  • ドライバーはナビゲーターの指示に従う(自分が書きたいコードを書くのはNG)
    → ドライバーが書きたいコードがある場合は、ドライバーを交代して、ナビゲーターとして指示する

  • ドライバーは時間はタイマーを使って区切る

  • ナビゲーターはドライバーを攻撃するような発言(ネガティブな発言)をしないように気をつける

モブプロの流れ

  • 参加社員はオンライン、オフライン混在のため、全員Teamsでオンライン会議にアクセス

  • Teamsのブレークアウトルーム機能を使用して、チーム分け

  • ドライバーとナビゲーターを決める

  • ドライバーの順番を決める

  • 実装するお題を理解する

  • ナビゲーターが指示し、ドライバーは実装する

  • 10分毎にドライバーを交代する

  • 時間が来る、もしくはお題を解決できたら終了

実際にやってみて

最初はモブプロと聞いて、若手メンバーは「自分に書けるのかな?」と不安になったそうです。
しかし、今回対象としたお題は、難易度としては高くなく、10〜20行程度で書けるプログラムだったため、自分にも書けそうだと、安心できたようでした。
実際にみんなに感想を聞いてみると、

  • 見られてる感あるとちょっと緊張する!

  • エラー処理の細かさに性格が出るよね

  • 人がプログラムを書く時の思考の流れを知ることができて面白い!

  • 音声だけで変数や関数など伝えるのは難しい上に、スペルがわからなくて苦労した・・・

といった、実際に複数人ならではのドキドキ感や新しい発見、日頃使っているIDEの便利さを改めて実感したりと、色々感じることができました。
そのほか、

  • 人によって、処理の確認(標準出力に出して確認)を行う粒度が違うことがわかった

  • エラーが起きた時の原因の探し方、探す手順を知ることができ参考になる

といった、他の人のやり方を見ることで、一人で黙々とコードを書くだけでは気づかない、自分にとっての新しい気づきにもなる面もありました。
日頃一緒に仕事をしているメンバーでも、プログラムを一緒に書く、ということはしないため、新しい視点でお互いを知る機会にもなったようです。

今後、どんな場面で活かせるか?

今回はあくまで勉強会の一環として実施してみましたが、実業務上でモブプロを行う場面はありえるのか、という点についてはどうでしょうか。

  • 有識者もしくはスキルレベルの高いメンバによる、ナレッジ共有の役割として

  • 実装難易度の高い機能について、議論をしながら実装を進められる

このような場面では取り入れるメリットはありそうです。
反面、複数人で同時に同一機能に対応することになるため、倍以上の時間が必要となります。
業務の中でも工夫は必要ですが、チームで開発するプロジェクトでは、選択肢として取り入れる価値もあるのでは、と思いました。