モブプロの利点と注意点を改めて考える：2つのチームの実践を踏まえて

カイポケフルリニューアルプロジェクトの2つのチームのモブプロ事情

「カイポケ」のフルリニューアルプロジェクトで開発を行っている soranakk とsetoh の所属しているそれぞれのチームでは、モブプログラミング(モブプロ)が盛んに行われています。今回はモブプロについて、良いところや注意しないといけないところ、工夫して改善しているところについて聞きました。

話し手の紹介

soranakk: プラットフォームチームに所属する元Androidエンジニア。Kotlinを使ったバックエンドやReactを使ったフロントエンド実装をしたりしている。モブプロは現職から盛んにやり始めた。
setoh: フロントエンドチームに所属する元Androidエンジニア。前職から5年以上モブプロの経験がある。soranakkとは新卒の会社時代の同期。

モブプロの良いところはなんですか？

soranakk

チームで共通認識が持てるのがいいなって思っています。例えば設計について一口にアーキテクチャといっても、その適用には濃淡があって、コーディング時にどのくらい厳密に適用するかには選択の余地があると思います。完全に厳密に適用する、言語仕様等で難しいところは変更することを許容する、やりすぎず細かいところは柔軟に変える、などなど。どれが正解ということはないですが、同じコードベース上では粒度を揃えておかないとメンテナンスが厳しいコードになります。それをモブプロで一緒にコーディングすることで肌感を揃えることができるのがいいと思います。

あとはコードの属人化の防止です。例えば新しい技術やライブラリを使うとき、ある機能の開発を担当した人だけが詳細な仕様を知っている、という状態がよくあります。こういうところをモブプロで行うことで、機能拡張やメンテナンスを当初の担当者だけではなくチーム全員で行うことができるようになります。

またチームビルディングの観点でもモブプロは有用で、コロナ禍のリモートワークの状況での貴重なコミュニケーションの機会になります。コーディングをしながらコードや機能の気になるところを話し合ったり、ワイワイとコミュニケーションしながら開発するのはとても楽しいです。

setoh

soranakkも言っているとおり、同僚と技術的な認識を合わせる場としても効率的だと思っています。自分がチームに入った際にはまだチームのコーディングガイドラインはまだ未完成だったのですが、オンボーディングも兼ねてモブプロをしているうちに色々な案が出てきました。モブプロを通して複数人で同じコードを実装しているのでガイドラインを書く際の前提となる認識が一致しており、ガイドライン化の必要性などを摺り合わせなくて良いので非常に楽でした。

それ以外では、オンボーディングの一環として使うのは実際に体験してみて良いと感じました。自分が所属するフロントエンドチームではオンボーディングの一環としてモブプロを取り入れており、自分がチームに入った後すぐにモブプロでコードを書き始めました。自分はエス・エム・エスに入社するまでフロントエンド開発は未経験だったので開発についていけるか非常に不安でしたが、理解が足りない点や実装の背景が気になる点をすぐに同僚に聞けたり、同僚の効率的な実装手順を見ることができて、とてもスムーズにキャッチアップができたと思っています。モブプロ中の雑談からVS CodeのオススメのExtensionsなどを知ることができたのもモブプロならではのメリットだと思います。

注意しないといけないところはありますか？

soranakk

実際にモブプロをしていて起こったことなのですが、新しい技術を触っていて詰まった場合に非効率になってしまうことがありました。知らない技術なので調べるだけでなく、動作させて試しながら探る、みたいなことをやりたくなった時に、モブプロで行うとドライバー役の一人しか出来ない、という状況になったりします。

あとは、前にモブプロでやった内容に近くてチームの誰がやっても同じになるよね、ぐらいの共通認識が持てている箇所をモブプロでやっても得られるものが少なくなってしまうなどが挙げられます。

setoh

自分は前職から5年以上モブプロをやっているので、割とアンチパターンを踏んできた方だと思います。よくある失敗はモブプロで情報を共有したことで満足してしまい、ドキュメント化を忘れてしまうことです。

過去の一番大きな失敗として、モブプロで実装した部分のPRは時間短縮のためにdescriptionを雑にして良いというルールを作ったこともあったのですが、後からチームに加わった人がPRの経緯が分からなくて困るということがありました。口頭での情報共有で満足せず、モブプロで決まった方針や経緯はしっかりと議事録やチームのルールとして明文化し、モブプロの場にいない人にも共有するという意識が必要だと思います。

モブプロのドライバーはしゃべりながら実装するので非常に疲れますし、ナビゲーターもコードを読みながら他人にコメントをしていくので頭を使うので疲れますし、達成感を感じます。でもその達成感の割にアウトプットや学んだことがあまりない場合も多い気がしています。達成感を抜きに考えて、しっかりとモブプロの目的を達成できているのかを考えるようにしています。ミーティングの基本に近いものがありますが、モブプロの前と後で目的を確認することなども有効かもしれません。

工夫しているところや改善しているところを教えてください！

soranakk

新しい技術についてモブプロをやる時に詰まった箇所が出てきたら、最初の数分は一緒に調査します。この時はドライバーの人は動作を試しながら探り、ナビゲーターの人はググったりして文献調査するという感じで役割分担しながら進めます。そして数分で解決出来なかった場合は、そこでモブプロを切り上げて個別に調べて、次回に持ち越しって感じにしています。また事前に詰まりそうなところの調査をしておいて、目処が立った状態でモブプロを開始するようにもしています(この文献にある方法でやれそう、みたいな感じで調査しておく)。

あとは共通認識が持てているとチームで認識した箇所についてはモブプロでは行わず、PRのレビューでコミュニケーションを取るようにしています。あるいは、どういう方針で実装するかの設計までをモブプロで行った後、実装は個別で行ってPRのレビューでコミュニケーションを取る、みたいな工夫も行っています。

setoh

ドキュメントを残すという点では色々試行錯誤をしました。モブプロが終わった後でやったこと・勉強になったこと・決まったルールなどをみんなで議事録を書いたこともありました。しっかりとしたドキュメントが残ったのは良かったのですが、負担になってしまいモブプロに気が乗らなくなってしまったりしました。現時点でのベストプラクティスとしては、書記担当を用意してモブプロ中に議事録を作るスタイルが良さそうに感じています。

前項でsoranakkも書いているとおり、効率性には気をつけています。4人でモブプロをすると1人でやる場合の4倍の工数を消化するので、それに見合う成果を出すためには何をすべきなのかという点はいつも考えています。モブプロの時間だけで工数に見合うアウトプットを出すのはなかなか難しいため、認識合わせや議論が起こりそうな実装など長期的に考えてチーム全体のパフォーマンスが上がるような内容をやるようにしています。

お互いの話を聞いてみての感想をお願いします！

soranakk

setohも書いている通り、モブプロの間に話した内容のドキュメント化は課題だと認識しています。

対策としてモブプロ中に一緒にドキュメント作成をするようにしたりなどをしていたのですが、書記担当を決めるというのも良さそうだと思いました。チームのモブプロに取り入れていきたいと思います。

setoh

soranakkの所属するチームはほぼ毎日モブプロを行っており、どんな点を意識しているのか気になっていたのですが、モブプロに対する大きな認識のずれはないということがブログ記事を通して改めて分かったのは良い知見でした。自分の所属するチームに最近入った同僚がいるので、コミュニケーションを目的としたモブプロを増やしてもいいのかなと思いました。