モブプログラミングは諸刃の剣

背景

モブプログラミングとは, 3 人以上が 1 つのコンピュータで 1 つのタスクを行うプログラミング手法のこと.
僕が所属するチームでは, 1 年半ほど様々な形でモブプログラミングを利用している.

この１ヶ月ほど, チームで プロダクトバックログのタスクを全てモブプロにする という試作が行われた.
そこで様々な試行錯誤による学びが多かったのと, 本などにはなかった僕の中で一番辛い部分もわかったので整理する.

僕が所属するチームとは？

僕が所属するチームができたのは, 2022 年の 11 月頃.
できた当初からチームで持つプロダクトバックログを WIP1 にしたりと, 最初からフロー効率を重視していた.

チームができて早い段階から, プロダクトバックログの開発開始時にモブプロで interface だけ認識合わせのために実装するということを行なっていた.

なぜ全てのタスクをモブプロにしたのか？

今年の始めにチームの大半の人が別のチームに移動することになり, メンバーも半分近くになってしまった.
また, 半分のメンバーが開発経験 2 年未満の方になり, チーム編成前と同じ開発方法だとうまくいかないことも多くなった.

interface 認識合わせ以外でもモブプロをやっていこうという話は上がっていたが, 意識だけでは難しく都度課題に上がっていた.
チームで色々話し合った結果, 全タスク強制モブプロを試してみようという結論になった.

どんなことをやったのか？

まず, 全てのタスクをモブプロにするようにすることと同時に, 毎週木曜日に「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」の読書会を行い, 取り入れるべきものは取り入れたり, 感想を言いながら進めていった.

最初は本に忠実に従い, 10 分ごとに交代をしたり, 毎日午前中はモブ時間として時間を確保したり, モブプロごとに 20 分の振り返りも行なった.

最初はぎこちなかったが, 回数を重ねるごとに振り返りで出た改善の効果が出始めて, 練度が上がっていくのを感じた.

IDEA の Code With Me を使っていたが, 各々で設定したショートカットが使えないなど辛い面が多く, 本のルールに違反しつつも個人の IDEA を使うようにした.
また, Google Meets を使っていたのだが, 毎回画面共有をすると切り替えに時間がかかってしまうので, 一番最初に全員 IDEA の画面共有を行い, タイピストの画面を全員が固定する形にした.

モブが複数人いると進みが悪かったので, モブリーダーという人を立てるようにして, 基本的にはモブリーダーが指示を出し, タイピストがその指示に従うようにした.
モブリーダー以外のモブの人をモブモブと呼び, モブモブはモブリーダーが正しい方向に進んでいるのかを確認したり, 設計意図を質問したりする役割とした.
また, モブリーダーとタイピストの組み合わせは, なるべく開発経験が長い人と短い人になるようにもしていた.

進行状況が見えづらかったり, モブリーダーごとの進め方の差異が出て辛いこともあったので, 基本 TDD を意識するような形にし, モブの開始時にテストファイルを作り, テストファイルの先頭に TODO リストを書き出すことから始めるようにした.
これによりチームでの進捗状況が見えるようになり, モブリーダーも上から TODO を終わらせていけば良いので, 進め方の差異も少なくなった.

タイピストごとに本筋ではないことに時間が取られることも多かったので, モブプロ開始時にラジオ体操という時間を作り, 全員 Google 認証/Docker や DB 立ち上げ/テスト実行して build cache を作るなどの作業を行う時間を作った.

モブ時間の確保ができなくて, チーム開発が思うように進まないことがあったので, 週末にモブ作戦会議という MTG を設置して, 次週のモブプロ時間を確保することもした.

練度が上がったことで, 15 分交代にしたり, 振り返りを行わないという判断も行うようになった.

何が辛かったのか？

長くなってしまったが, これが本題.
結論を言うと, 同棲と同じような辛さ があるのだと思った.
(同棲した経験はないんですが, 一緒にいる時間が長くて一人の時間が欲しい. 嫌な部分も見ることになったとかよく聞くので笑)

モブプログラミングを導入してからは, 技術的スキルはあまり重視せず, どういう価値を提供できるか, ほかのメンバーとうまくやっていける感じがするかを重視するようになった.

マーク・パール. モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプロの一番の課題は技術力の差だと思っていたが, 本にも書いてある通り一番の課題は人間関係だとわかった.

モブプロは開発していて悩む部分をすぐに相談することができるのは, とても良いところだと思う.
自分は変数名を考えるのが苦手だったりするので, それをチームメンバーにフォローしてもらえるのはありがたいし,
モブプロで自分の開発する上での弱みを見せることになるのも理解していた.

寧ろ, 技術的な弱みを見せてメンバーに弱みをフォローしてもらうことで開発速度を上げるのがモブプロの目的の一つだと思っていた.
僕の一番の発見は技術的な弱み以上に人間的な弱みもチームの人に見せることになること.

僕が所属するチームの場合, 全てのタスクをモブプロでやっているため 1 日のほとんどを一緒に過ごすことになる.
今までは認識合わせが必要な時だけ MTG をして, それ以外の時間は自分の世界に引きこもって開発することができる.
「このタスクが終わるまで頑張ったらコーヒー休憩しよう」
「テンションの上がる音楽を聴いてコーディングしよう」
みたいなことはできなくなってしまう.

みんな社会人なので, 厚さは違えど仮面を被っている.
ずっと一緒にいることになるので, それも剥がれていき, 人間性の弱みも見せなければいけなくなる.

眠くなってイライラしてしまう時だってある.
腹が減ってイライラしてしまう時だってある.
やる気が出ない日だってある.
頭がうまく回らない日だってある.
プロジェクトがうまくいってなくてイライラしてしまう時だってある.

そんな時でも距離を置くことはできず, 一緒に仕事をしなければいけない.
チームの人は何とも思っていないかもしれないが, 自分の発言や行動を後悔する夜は断然多くなった.

良かった点・感想

このままだとモブプロをしないほうが良いと思われてしまうかもしれないので, 良かった点も書いておく.
実際やってみて, 良かった点のほうが多い.

当たり前だが, PR 作成からマージまでは早くなる.
早くレビューしてくれないかな？レビューで今更そこを指摘してくる？みたいなことはなくなる.

チーム内で知識共有は自動的にされるし, 技術的な伸び代や深掘りポイントも見つけやすく, 指摘されやすくなった.

• テストから書くのか
• IDEA にこんな機能があるのか
• こういう意図で名前付けや関数の配置をしているのか
• プログラミング言語として、ここら辺の知識が足りないのではないか

など, 個人で開発していると共有できない知識が共有できるようになった.

以外だったのは, チームの一日のベロシティがほぼ変わらなかったこと.
チームが縮小してから, 1 つのプロだくバックログは今まで通り, 1 つのプロダクトバックログは全モブプロなのでサンプル数は少ないが, チーム編成直後と比べてもベロシティはほぼ変わらなかった.

僕はプロダクトバックログの開発が順調に進んでいることを仕事の優先順位として一番に考えているので, 良くも悪くもプロダクトバックログの開発ばかりしてしまう.
しかし, モブプロを強制にしたことでモブプロ開発時間以外は, 開発がちょっと遅れていてもプロダクトバックログの開発に時間を避けない.
その結果, 組織全体としてやったほうが良い改善やプロダクトへのフィードバックをちゃんと眺めるなど, プロダクトバックログ開発以外にやったほうが良いことにもコンスタントに時間を使えるようになった.

混乱期を乗り越えた分, 親近感が増し, 周囲の人々との理解が深まっている.

マーク・パール. モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

チームとして確実に成長している実感もある.
一部モブプロをやっていた時より, さらにチーム力が高まっている感覚がある.

チームとして動くことが多くなるので, 良くも悪くも平等になっていく.
上記にも記載した通り, プロダクトバックログにかける時間も同じ, タスクの難易度もばらつきがなくなり, 得られる知見も平等になる.

最後に

モブプロは周りの理解を得ることができてる かつ チーム全員に HRT がある場合は, とても良い開発手法だと思う.

しかし, モブプロ参加者の相性がかなり重要となるため, 相性が良くないとチームとして崩壊する可能性もある点は本当に注意が必要だと感じた.
（こんな人間性が極悪の僕も受け入れてくれるチームの人々には感謝しかない）

そのため, モブプロを導入する際はチームとしてある程度の信頼関係がある状態で導入する必要だし, モブプロの量を増やす際にも注意が必要である.

素晴らしい開発手法だが, 少しでもモブプロを導入するというのは チームが崩壊する可能性もあるという覚悟 は必要だと感じた.

ハッピーモビング！

マーク・パール. モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める