はじめに
こんにちは。エンジニアの津崎です。 皆さんモビングしてますか？ 一人でコーディング、もしくはペアプロでしょうか。
ちなみに、この記事も初の試みとしてモブプログラミングによって作成されています(笑) モブブロギングです。
共同編集者の、やも(@yamotuki)さん、はまちゃん(@hamakou108)、ありがとうございます。この場を借りてお礼申し上げます🙇♂️
M&Aクラウドの開発チームのうち、僕が所属する３名構成のサブチームにてモブプログラミングを試験的に導入しています。 今日は、1ヶ月ほどモブプログラミングを経験した上での学びを共有します。
モブプログラミング
モブプログラミング（モビング、以下モブプロ）とは、3人以上のエンジニアで1つのプログラムを書き、チームで成果物を完成させる、チーム作業のテクニックです。
なぜモブプログラミングか？
開発チームではコミュニケーションコストを減らすために部分的にペアプログラミング（以下ペアプロ）を導入していましたが、ペアプロを行っているのは主に、レビューのタイミングと、作業が詰まってしまったときに限られていました。 一部ペアプロを行うことでベロシティ（スプリント内の消費ストーリーポイント）が高まる傾向にあることはわかっていたので、ペアプロの機会を増やせば、もっとベロシティが上がるのではないか？ と考え、3人で同時に作業を進めるモブプログラミングを試してみることにしました。
モブプログラミング ベストプラクティス
僕たちのチームではモブプログラミングの導入にあたって、「モブプログラミング ベストプラクティス」を参考にしています。
「モブプログラミング ベストプラクティス」では、同じ部屋にメンバーが集まり、1台のPC、1台のキーボードを共有するスタイルでモブプログラミングをすることが前提になっています。
モブプログラミングでは「タイピスト」と「その他のモブ」という役割に分かれて作業を行います。タイピストは、その他のモブの指示に従ってコーディングを行います。タイピストが暴走して勝手にコーディングすることは許されません。 タイピストは、ただの入力者ではなく、その他のモブの「スマートアシスト」です。 一字一句指示していると時間がかかりすぎてしまうので、齟齬が起こらない範囲でざっくりとした粒度で指示し、作業を行います。
初めてのモビングセッションは2時間程度から始めることが推奨されています。 1つのモビングセッションを10分の小さなモビングインターバルに分割します。 それぞれのインターバルでタイピストを交代しながらモブプログラミングを進めていきます。
最後に20分ほどで締めくくりでレトロスペクティブ（振り返り）を実施し、次のモビングセッションに向けて改善できることを話し合い、モビングセッションを終えます。
実際にやってみて感じたモブプログラミングのメリット
複数人で問題解決した方がより良い答えがでる
これは体感として、話し合いの中でいいアイデアが浮かぶことが多いなと感じています。 1人でタスクを終わらせることばかり考えて実装していると、つい安直で長期の保守性の悪い手法を選択しがちです。そういった思考で作ったPull Requestでも「既に書かれてしまっているから」と多少品質が低くてもマージされてしまう、そういうことはよくあるのではないでしょうか。 一方でモブプロで方針を話し合うと、「このタスクの目的ってなんだっけ？」から始まります。その目的に叶う最も良いと思われる設計方針を複数人で話し合うことになります。場当たり的な対応なんて恥ずかしいので出づらくなります。
キーパーソンに頼らない
1人でタスクを進める前提だと、どうしても得意な人に特定のタスクが偏りがちです。 その人だけが詳しくなっていき、その他の人は情報共有を受けるだけとなり、より属人化が進んでいきます。 モブプロで進めることで、チームでタスクに当たるので特定の誰かに情報が偏ることが減ります。 プラクティスとして「ちょっと付いていけなくなってもタイピストをやればOK」というものがあります。タイピストは必然的に他の人から指示を受けて書くことになるので、知見を得られやすいポジションになります。 これにより、各人のスキルアップに繋がることになります。
ペアプロより中断しにくい
1人より2人、2人より3人で話している方が外部からの妨害は入りにくいものです。 また、3人で進めている場合には、そのうち1人ミーティングで抜けたとしてもモブプロは続いていきます。 これにより成果物の完成速度が安定します。
レビュー高速化
「レビューお願いします」「リマインドですが、こちらレビューお願いします！」 「ここ修正してください」「修正しました。確認お願いします！」「ここもお願いします」「修正しました！再度確認お願いします」・・・
モブプロを初めてからのコードレビューは爆速化しました。事前にモブプログラミングをしているため、コードレビューでは「余計なものが入っていないかな？」という確認をさっとするだけでよいのですぐに終わります。 レビューしてもらうまで待ったり、リマインドしたり（されたり）する必要もありません。
技術の共有化
コーディングのテクニックや、ツールのショートカットなど、GitHub上のプルリクエストのコードには現れないスキルを間近に見ることができます。 同じような仕事をしていると思っていた同僚がすごいショートカットを使っていた時の驚きをぜひ体感してみてください。
未知領域、苦手領域のキャッチアップが楽に
メンバー内に得意な人がいれば、リードしてもらうことで一人で進めるより理解が進みます。
実際にやってみて感じたモブプログラミングのデメリット
技術を深ぼる時間が取りづらい
1人でやっている時にはタスク完了にはそこまで影響しないけど技術的に気になったことを深掘りする時間が取りやすいです。自分がきちんと全て理解していなくてもタスクをDONEにすることができるので理解が曖昧なまま終わってしまうことがあります。 この問題には強い気持ちで「ここの技術的背景をもうちょっと深掘りたい」とチームに提案することが必要です。案外他のメンバーも曖昧になっているところで、全員の技術理解を深めることになるので積極的に提案していきましょう。
傍観者モードになってしまう
これは僕だけかもしれませんが、自分以外のモブが議論して自分以外のモブがタイピングしている状況では、気を抜くと簡単に傍観者モードになってしまい、話についていけなくなってしまいます。 適度に休憩しリセットする。タイピストを適切に回し、集中を切らさないようにするなどの対策が必要です。 （原則に則ればタイピストは 10分交代なのですが、後述の理由でなかなか難しいケースがあります）
リモートでのモブプログラミング
PhpStorm Code With Me の活用
Code With Me: JetBrains が提供する共同プログラミングサービス
僕たちチームでは、リモートでの作業が主なため、PhpStormの共同プログラミング機能、「Code With Me」を使ってモブプログラミングを行なっています。
Code With Me は、誰か1人がホストとなって、その人のPhpStormに接続する形で共同編集を行います。Googleドキュメントやスプレッドシートを複数人で触ったことがある方はイメージできるかと思いますが、利用者ごとに複数のカーソルが存在し、それぞれがコーディング作業できます。
（弊害）平行作業できてしまう
コーディングをしていると、「平行作業した方が早くない？」となり、タイピスト以外がタイピングしたくなる時があります。 並行で作業をしてしまうと、何がどのように変更されたのかわからなくなるため原則禁止ですが、僕たちは以下のルールでその他のモブがタイピングするのを許可しています。
- ちょっとしたタイプミスや誤字脱字の修正
- 単純な作業の分業
- タインピングのための参考コードやURLの入力
（弊害）タイピストが偏ってしまうケースがある
PhpStorm上で完結する作業であれば、タイピストがシームレスに交代できますが、フロントエンドのマークアップ作業でコーディング→ビルド→ブラウザでの動作確認をやるケースなどでは、PhpStormのホストが作業しないと効率が悪くなってしまいます。後者のケースでは、どうしても数十分間タイピストが固定になることがあります。
（弊害）ホストのスイッチングコスト問題
PhpStorm の Code with Me は、2022/05/13現時点ではホストへの接続にやや時間がかかります。 コードはホストとなる人の環境にしかありませんので、会議でホストが抜けると、その環境で動作確認ができなくなってしまう問題があります。 その緩和策としては、テストを潤沢に書くことで手動動作確認を減らし、コード上だけで完結させることがある程度ワークしました。
また、誰かの環境である程度書いたコードを、なんらかの事情で他の人の環境で続きを書きたいケースでは、新しいホストの環境にコードをフェッチする必要があります。これが地味にめんどくさく、ホスト交代をする頻度が下がりがちです。
Slack Huddleとの併用
動作確認などのコーディング以外の作業を行う際は画面共有が必要です。 僕たちはSlackのHuddleにて通話や画面共有をおこなっています。Code With Meにも通話、画面共有機能があるのですが、僕たちは普段Slackを利用することが多いためSlackの方を利用しています。
休憩に対する考え方
複数人で作業を進めていると、どうしても話しながら休憩するタイミングを逸してしまいます。 自分が疲れていても、他の人はまだいけそうかな？など忖度してしまうとなかなか休憩しようよ、とは言いづらいものです。 これはチームが成熟していくとお互いの状態を見て休憩をうまく取っていけるようなのですが、現時点ではルールを作って対応しています。
- 10分でタイピスト交代（ベストプラクティス準拠）
- アレクサやスマホのタイマーをセットしてアラームをみんなに聞こえるようにします
- 30分に一回 10分ほど休憩 （これは最近厳密ではなく、区切りのいいところで休憩しがち）
- 2時間ぐらいごとに20分ほどの長い休憩
- （休憩中はチャットの確認なども含む）
タスクの進捗に関して
個々人でタスクをやっている時には、3人チームでベロシティ（1週間に消化できるストーリーポイント）は10pt程度だったのですが、モブプロを始めてからは概ね8pt程度になりました。1/3まで低下することもあり得ましたが、そこまでは低下しませんでした。 それは1人で進めているときには以下のような時間があったのが減ったためだと考えてます。
- 設計方針を決めるのに時間がかかる
- 細かい実装でいちいち詰まる
- プルリクエストのタイミングで前提共有をして全部ひっくり返る
- 実装詳細の共有の時間
一方で、1人で考えている時にはなかなか取られなかったであろうシンプルな設計方針をチームで考え出せたりします。シンプルな設計に加えて、その設計を確実にそのチームメンバー全員が理解しているのも長期でのリターンとなると考えています。
おわりに
モブプログラミングを実施してみて、当初期待していたチームのベロシティ向上という期待に反してベロシティが下がってしまいましたが、 知識共有や大きなバグの防止、慎重な設計による長期的なリターンなどを考えると、ベロシティ以上の便益があると感じています。 今後、モブプロのやり方を改善していく上で、ベロシティの回復、そして向上を目指しています。
個人的には1人で黙々作業するよりも、チームで話し合いながら作業するほうが楽しいので、チームで工夫しながらより良い開発をおこなっていけるよう今後も試行錯誤を続けていきます。
採用中です
組織拡大！急成長中スタートアップでエンジニアリングマネージャーを募集！！ - 株式会社M&AクラウドのWebエンジニアの採用 - Wantedly
