🥳

新チームにモブプロを導入してみた！

2024/02/17に公開

チーム開発

ペアプログラミング

モブプログラミング

idea

私は普段、Web系の自社開発企業でバックエンドエンジニアとして働いています。
先月末くらいに新チームが発足し、開発メンバーとして私が入ることになりました。

今回は、その新チームでモブプログラミングを導入してみたお話です。

導入経緯

話の発端は年明け前でした。
弊社の開発フェーズ上、ある機能を新チームとして開発する必要がでてきました。
そこで、私を含めた3️人（当初は2人だった）で新チームを発足し開発を行うことになりました。

私が今まで所属していたチームではスクラムを採用していました。
進め方は、個人がタスクを選択・実施し、
実施したタスクを他の人がチェックする方式で進めていました。

新しいチームでもこのままでいいかなあと思っていました。
ただ、私は次の3点に課題を感じていました。

タスクチェックに時間がかかる

以前のチームではタスクチェックをタスクを実施した人以外がチェックすることになっていました。
チェックをお願いする場合もありますが、基本的には手が空いている人や同じストーリーをやっている人が担当することが多く
どうしてもチェックが終わるまで時間がかかるケースがありました。

一人ひとりの進捗具合が把握しにくい

一人一つのタスクを担当しているため、タスクの進捗具合が見えにくくなりがちです。
透明化するために毎日デイリーを実施しています。

その時に
「後どれくらいかかりそうですか？」
「そうですね…。◯◯時間（日）でいけると思います。」

のような会話で終了するため、具体的にそのタスクの何割くらい終わっているのか把握できないことが多々ありました。
また、そのタスクが終わらないと次のタスクが着手できないようなパターンでは
上記で上げたチェックスピードも合わさり、進捗が遅れがちになります。

スキルの属人化が進む

タスクは簡単なものから特定の知識・技術が無いと時間がかかるものがあります。
例：特定のライブラリを使用する（Pythonならpandasや機械学習）、使ったこと無いサービス・APIを使う...
その場合、スプリント内に終わらせようとするとどうしても技術に長けている人が担当しがちです。

余裕があれば別の人が担当することもありますが
その場合は進捗に遅れが発生してしまう可能性が高いです。

結果、元々スキルがある（もしくは経験がある）人がそのタスクを主として担当することが増え
その人しかできない=属人化が進むことに繋がります。

スキルがある人も、そのタスクを進んでやりたいわけではない事もあり
そういった状況が続くとモチベーション低下につながります。

以上のことから、モブプロを導入することでこの課題を解決できるのでは無いかと思い
モブプロを導入してみることにしました。

導入してみた

ということで、とりあえずやってみる。
私が主体となってモブプロを導入してみることにしました。
導入にあたっては次の2点に取り組みました。

開発メンバーに合意を取る

まずは、新チームにアサインされるメンバー全員と打ち合わせをし
すべてのタスクをモブプロで進めることを話します。

先程挙げた個人でタスクを進めることの課題をあげ
これらの事を解消していきたい旨を強調して話しました。

モブプロは試してみる。一つのTryであるため
合わなかったり、課題感が大きければいつでもやめて良いということにしました。

モブプロの本・スライドを見て学習する

これは私が個人的にやったことです。
開発メンバーは私も含め全員モブプロを経験したことがありません。
（ペアプロはたまにあるかなあくらい）

そのため、まずモブプロとは何なのか。どう進めればよいのか
指針になりそうな資料を探して勉強しました。

具体的にはこちらのスライドを読みました。

スライドを作成された及部さんが解説として書かれている本もあったため
こちらも購入して概要を掴むことにしました。
https://amzn.asia/d/2ZXQt4n

モブプロ導入後の一日

モブプロを導入して、数週間経ちました。
一日のスケジュールも固まってきたため簡単に紹介したいと思います。

■ 9:00~9:15 本日やることの整理
今日進めるタスクをチーム全員で確認します。
私達はタスク管理にNotion
議論や振り返りにMiroを使用しています。
これらを画面共有しながらやることを洗い出します。

■ 9:15~9:30 輪読会
チームで輪読会を導入しています。
チーム全員で課題だと感じることに対して、それを解決できる本を探してきて読もうというTryから生まれたアクションです。
毎日15分で読み進められるところまで進めて、意見や感想を交わしながらまとめていきます。

■ 9:30~12:00 モブプロ
ここからはひたすらモブプロです。
私達は全員リモートワークのため、VsCodeのLive Shareを使ってモブプロを実現しています。
タイピストとモブの交代は10分としました（本に10分程度が良いと記載があったため）。
10分*人数分で回し、1ローテ終わったら15分ほど休憩をはさみます。

■ 13:00~16:30 モブプロ
会議や打ち合わせがなければ先程述べたローテを回してモブプロを進めます。
途中で認識合わせやフローの整理が必要になった場合は、コーティングを一度止め
Miroを使って全員で議論して合意を取ります。

■ 16:30~17:00 振り返り
モブプログラミング終了後に進捗の確認と今日のモブプロについての振り返りを行います。
振り返りは本で紹介されていたシンキングハットをモブプロ用に改変したものを使用しています。

◯事実と数字（白） 2分
今日完了できたこと、進んだことを列挙します。
具体的な数字を使うと良いです。
例：1ローテで◯◯の実装が完了した

◯肯定的感想（黄） 3分
モブプロを通しての肯定的感想を列挙します。
私達は話す順番は特に決めず、各々思ったことを話しながら付箋を貼り付けています。

◯批判的感想（黒） 3分
批判的感想を列挙します。
具体的解決策は言わず、不満に思ったことや課題に感じたことを話すだけにします。
問題解決法は次のステップ、みんなで出すことになっているからです。

◯建設的な問題解決法 5分
批判的感想から思いつく問題解決法を出します。
相手の解決法は批判せず、思いつく限りアイディアを出し合います。

◯軌道修正すべきことの決定 3分
問題解決法から軌道修正すべきことを一つだけ決定します。
一つだけに絞るのは、Tryが多すぎると優先順位付けが難しくなるからです。
チームで最も直したいことを一つ選び、明日のモブプロへつなげます。

導入してみた感想

実際に導入してみてどうだったか。
メリット3つ、デメリット2つで整理しました。

メリット1: タスクの開始から終了までワンストップになった

モブプロは全員で一つのタスクに取組みます。
開発はもちろんのこと、調査タスクや議論も全員で行います。
その結果、タスクのチェック工程が不要になりました。
全員でタスクをやっているので、その場でチェックすることになるからです。

これはフロー効率が良い状態といえます。

タスクの開始から終了まで、川の流れのように止まることなく進められます。
個人で進めていたときに感じていた「タスクチェックに時間がかかる」や「進捗具合が不明」が透明化されたことになります。

一人でタスクを進めるのとどちらが早いか。
感覚ですが、ストーリーに関わる全てのタスクを完了させる時間はほぼ一緒だと思います。

全員が知見・技術に長けているチームなら個人で進めるのが早いと思いますが
そうではない場合は、モブプロのほうが早く終わることもあるかなあという感想です。

タスクの進捗具合を確認する必要がなくなったので
私達のチームではデイリーを廃止しました。

メリット2: 技術共有がしやすい

モブプロを導入してから技術や知見の共有がしやすくなりました。
例えばVsCodeのショトカ。画面共有をしながら作業をしているため
どんな風にコーティングしているかが分かります。
使ったことのないショトカを使っている人がいれば、今どうやったのとすぐ聞けて、教える側も教わる側もWinWinの関係を築けます。

使ったことのないライブラリ・開発生産性が上がる拡張機能など…
何気ない会話から知見共有がしやすい環境になったため、属人化という課題をクリアできている感覚があります。

メリット3: 新しいことにチャレンジしやすい

私達は基本どんなタスクも全員で進めます。
課題に感じることがあったり、試したいことがあればいつでも発言するチャンスがあります。
輪読会・TDDなんかはメンバーからやりたいという声があったためTryとして取り組むことになりました。

常に全員がいる=合意が取れる環境が整っている状態は良いなと感じている日々です。

デメリット1: 発言力が大きい人に意見が集約されがち

タイピストはナビゲーターが指示した通りに実装します。
人数によってはナビゲーターが複数人いる場合があります。
複数人だと、どうしても発言力がある人（意見をすぐ伝えられる人）の声が大きくなりがちです。

ここは対策する必要があります。
私達はナビゲーターとモブのロールを分け、ナビゲーターは原則一人。モブはナビゲーターから相談を受けるまで見守る
ことにして全員が発言する機会を設けることにしました。

デメリット2: 短期的効率の悪さを感じる

モブプロをしていると
あー。ここ一人で出来たら直ぐ実装できるんだよなあ…
と思う瞬間があります。

モブプロはフロー効率は良いですが、リソース効率（何かしら手を動かしている状態）は悪いので
特に手を沢山動かしたい人は効率が悪いと感じるときが多いと思いました。

ここの解決は難しく、長期的に見たら属人性が解除されて効率が良くなる話をして我慢する形になるのかなあと思っています。
一応、私達は一人でやっても問題なさそうなタスクがあれば
それをタスク化させ、モブが取り組むようにして手を動かす機会を増やすようにしています。
（これが正解かは分かりません…）

導入時の注意

この記事を読んでもし導入したいと思った方は次の3点に気をつけると良いと思います

メンバー全員と合意を取る

まずは、開発メンバー全員とモブプロで進めたいと話をする必要があります。
私達のように新チーム発足時なら比較的導入が簡単だと思います。
既チームで導入するときは、この実装はとか、このタスクはモブプロでやってみるといった
段階的に進めると合意が取れやすくなると思います。

まとめると

なぜ導入したいのか（解決したい目的）
どのタスクで導入するのか
誰がやるのか（メンバーが多いときはグループを分けてやるとかの工夫が必要）

について合意が取れると導入が楽になると思います。

タイピスト交換の時間を守る

モブの役割を時間で交代するのが基本ですが時間厳守しましょう。
ここまで実装したら交代しますかあ。
みたいなノリで進めたことがありましたが、モブプロしている感がなく意味ないなと思いました…。

時間厳守にすると、この時間内にここまで実装したいというタイピストとナビゲーターの連携が働き
実装に集中することができます。

特に沢山手を動かしたい人は時間制限という規約が大きくプラスに働くと思います。

最初のうちは毎日振り返りを実施する

モブプロを導入して、数日は毎日振り返りをすると良いと思います。
メンバーがどう思っているのか、肯定的感想と批判的感想をもらいながら続けるべきか判断できます。

軌道修正も早めにできるので、モブプロが安定するまでは続けると良さそうです。

毎日振り返りをすることで、意見をいうチャンスが増えるので
透明性が上がるメリットもあります。

まとめ

今回はモブプロをチームに導入してみた話をしました。
私達は一人もモブプロを経験したことがない状態からのスタートでした。
全く経験がなくても、基本方針さえ守れればモブプロは開始できます。

モブプロを試してみたい方がいればTDDyyχがおすすめです。
あるお題をTDDとモブプロで進めるイベントになっています。
私も参加してみましたが、初めての人とでもモブプロを通じて交流でき、良いイベントだと思いました。

ぜひ皆さんのチームに導入してみてはいかがでしょうか。

最後まで読んでくださり、ありがとうございました！