広告技術部合宿行ってきました Part.2 〜モブプログラミング編〜

こんにちは、広告技術部Gunosy Adsチームです。

先日、広告技術部で開発合宿を実施しました。前回はアドネットワークチームの合宿の様子の紹介でしたが、今回の記事ではGunosy Adsチームの様子を紹介します！

tech.gunosy.io

私たちGunosy Adsチームでは「チーム全員でモブプログラミングをしてみよう！」という話になり、合宿ではモブプログラミングをやりました。本記事ではモブプログラミングの簡単な紹介とやってみてどうだったかをレポートしたいと思います。

モブプログラミングとは
- モブプログラミングの役割
モブプログラミングの実践
モブプロやってみた感想
- 良かったこと
- 悪かったこと
まとめ
【宣伝】Gunosyでは一緒にモブプロする仲間を募集しています！

モブプログラミングとは

まずモブプログラミングとはなんでしょうか？

モブプログラミング（Mob Programming）をご存じだろうか。簡単にいうとペアプログラミングの人数をもう少し増やし、4、5人のグループでひとつのプログラムを開発していくスタイルだ。

コーディングもテストも持ち回りな新プログラミング手法「モブプログラミング」とは何か――本場 Hunter社に学ぶ (1/2)|CodeZine（コードジン）

ペアプログラミングは皆さん聞いたことあると思います。ペアプログラミングは文字通りペア（二人）でやるプログラミングのことです。一方、モブプログラミングはペアプログラミングの複数人版です。モブが「群衆」や「群れ」を意味するものなので、群れになってプログラミングする様子からこのように名付けられました。

プロジェクタから投影される画面を囲んでモブプログラミングする様子（合宿一日目）

モブプログラミングの役割

モブプログラミングにおける役割はペアプログラミング同様、ドライバーと ナビゲーターの２つがあります。

ドライバー

　キーボードを操作してコードを書く人。ナビゲーターの指示に従い、実際にプログラムを書いていきます。基本的には指示通りにコードを書いていきますが、レビュアーも兼ねているので、「それはおかしい」とか、「こっちの実装の方が良いのでは？」というコメントも行います。

ナビゲーター

　仕様に合わせて、どのようなアルゴリズムを採用し、どのようなコードにするのかを具体的に指示します。コードを口述するイメージです。

グラス片手にアジャイル開発第6回－アジャイル開発手法「ペアプログラミング」 (1/3)|CodeZine（コードジン）

ざっくり言うと、ドライバーがコードを書く人、ナビゲーターはドライバーがコードを書けるようにガイドする人って理解でよいかと思います。

モブプログラミングの実践

今回モブプログラミングを行ったGunosy Adsチームは全員で４人なので、一人がドライバー、残り三人がナビゲーターという役割分担で臨みました。

モブプログラミングするにあたり事前にモブプロで取り組むIssue/やるべきことをチームで相談の上決めておきました。またモブプロのための専用のSlackチャンネルを用意しておきました。

計三日間の合宿のうち、一日目と二日目はプロジェクタを囲んでのモブプロ、三日目は（プロジェクタを用意できなかったので）Slack画面共有機能を使ってのモブプロとなりました。

使用するマシンに関しては全員の開発環境が共通化できているわけではないので、各自のマシンを使うかたちとしました。

モブプロやってみた感想

チームで実際にモブプログラミングを実施してみてチームで出た感想についてポジティブな面・ネガティブな面の両面でまとめてみたいと思います。

良かったこと

チームで出たモブプログラミングをやってみて良かったこと・ポジティブな感想を紹介します。

事前準備をしっかりやった
- 取り組むIssueが明確だった
- モブプロをするメンバーだけのSlackチャンネルを用意することで、URLリンクの共有や画像の共有などがスムーズにできた
モブアラート対応
- （これは予定しなかったタスクだったが）合宿中にアラートが鳴ったためみんなでモブアラート対応ができた
Slack画面共有が良かった
- Slackの画面共有機能を使えば大きいディスプレイが無くてもモブプロ実施可能
技術レベル格差の解消
- 他の人の開発の進め方がわかった
  - 他の人のデバッグ方法が参考になった
- RubyMineのショートカットの理解が深まった
レビューが不要
- その場でレビューするからレビューによる手戻りの工数が発生しなくて嬉しい
ナビゲーターのガイド
- ナビゲーターがミスに気づいてくれる（typoとか）
- ナビゲーターがライブラリの使い方を教えてくれた
- 一人でプログラミングするより困ってる時間が少なかった
仕様の共通認識
- 取り組んだIssueの仕様についてチームで共通認識が得られた
  - 「この仕様はxxxさんしか知らない」という状況をなくせた
- 仕様を決めるときの考え方をチーム内で共有できた
  - どのような思考プロセスを経て仕様を決めているかが共有できた
生産性向上
- ドライバーのコードを書く集中力高まる
  - 同時にナビゲーターのレビューの集中力も高まる
- 人数4人（チームの人数）はモブプロに丁度良かった
  - ナビゲーターがサボりにくい人数
- 仕様や実装方針を決めないと先に進められないのでそれらを決める強制力が働いた
  - 仕様を決めやすかった
  - コードの設計・実装方針をすぐ決められた
  - 技術検証がやりやすかった
楽しさ
- ワイワイ感あって楽しかった

Slack画面共有しながらモブプログラミングをする図（合宿三日目）

悪かったこと

次にチームで出たモブプログラミングをやってみて悪かったこと・ネガティブな感想を紹介します。

休憩が必要
- 休憩のタイミングが難しい
- 約2時間毎に休憩は挟んだほうが良さそう
（各自のマシンを回す形式だったので）ドライバー交代のときにやや手間がかかった
- 一台のマシンにした場合、それはそれで各人の環境の違いの問題が出そう
技術レベル格差によって普段より時間がかかる場合があった
- 例えば、ドライバーがJavaScriptよくわからないけどナビゲーターがJavaScriptよくわかっている場合、そのナビゲーターが直接コード書いたほうが早く終わりそう
- 一方で、これは良かったことで書いた「技術レベル格差の解消」にも繋がる話なので良いことでは？という感想も
ドライバーが先走ってコードを書く場面があった
- 黙ってコードを書くのではなく、ちゃんとナビゲーターに説明しながら書くべき
- モブプロ後半になってドライバーもナビゲーターも疲れてくるとなあなあで進んでしまう傾向
単純作業はモブプロに適さない
- 作業内容がはっきり決まっていて誰がやっても同じようなタスクはモブプロじゃなくてよい
モブプロメンバーが喋れてみんなの声が聞こえる場所の確保が必要
プロジェクタ問題
- プロジェクタの排熱が暑かった
- 画面が見えやすいように部屋を暗くする必要がある