モブプロを続けて見えてきた課題とその解決策

こちらの記事はカケハシ Advent Calendar 2024 の 17日目の記事になります。

こんにちは。 AI在庫管理開発チームのエンジニアの大村です。

私たちの開発チームでは、素早く顧客に価値を提供するための手段としてモブプログラミングやペアプログラミング（以下、モブプロ）を積極的に実施しています。私自身もチームの開発手法に関心があり、昨年のAdvent Calendarでは『フロー効率重視開発のすすめ』という記事を書きました。その中で、モブプロが開発のフロー効率を高める上で効果的であるという話をしました。

あれから一年が経ち、チームの状況が変化する中で見えてきたモブプロの課題と、自身の考えの変化について書いていきます。

開発状況の変化

昨年の時点では機能開発体制はフロントエンドとバックエンドに分かれており、私はフロントエンドエンジニアと一緒にモブプロを実施していました。

ただ、エンジニアが状況に応じて柔軟に機能開発をしたり視野を広げるために、職能横断でフロントエンドもバックエンドも関係なく開発を進められるようにしたいという思いはありました。

そんな中、周囲の状況の変化に伴って数ヶ月前からバックエンド領域の開発の比重が非常に高くなりました。それまで主にフロントエンドの開発をしていた私も、良い機会が巡ってきたと思いバックエンドの開発に携わることとなりました。

直面した課題

バックエンド開発経験の少なかった私は、バックエンド経験豊富なメンバーに引っ張ってもらう状況が続きました。

そのような状況の中でも、素早く価値提供するためにモブプロは効果的だというのが私含めチームの考えであったため、モブプロを継続して実施しました。

しかし、フロントエンドエンジニアのみで行っていたモブプロの時とは異なり、バックエンド領域の知識が足りず開発スピードや品質の向上に対して自分はあまり寄与できていないのではと感じるようになりました。

同時に「このままモブプロを続けることが本当にチームとして効率の良い開発のやり方なのか？」という問いも生まれ、それに対する明確な回答を持っていませんでした。

起きた変化からチームのフェーズを考える

以前に行っていたフロントエンドエンジニアのみのモブプロ（職能別）と、現在の職能横断でのモブプロ（職能横断）の違いを考えてみました。

職能別のモブプロ実施時は、基本的な開発の流れや利用している技術の使い方を理解しており、実装や設計において注意すべき点やテストすべき点はどこかの認識が揃っていました。そのため、実装からレビューまでを素早く進めることに集中できていたと感じます。

一方、職能横断のモブプロにおいて私は開発の流れを掴むことで手一杯でした。テストを書く場合にもどのテストをどれくらい書けばいいのか？ということがわかりませんでした。

もちろん、有識者がいると問題は解決し開発は進むのですが、不足している知識や観点を有識者が補って進んでいる状態と言えます。

このことから、全員が開発に必要な知識を獲得することで次の段階に進み、そこからはメンバーそれぞれがチームのために知識を出し合うことができる状態になると考えました。

ただし品質を犠牲にすることはできないので、求められる品質を満たす開発ができてはじめて全員が開発効率の向上にフォーカスできると考えています。

これらを踏まえ、モブプロを実施するチームの状態は以下の3つのフェーズに分けました。

フェーズ1：全員が開発に必要な知識を獲得する
フェーズ2：全員で成果物の品質を保証できる
フェーズ3：全員で開発効率を高め合う

各フェーズにおけるモブプロの効果

このように分類した時、モブプロの効果もフェーズによって変わってくることがわかります。

フェーズ1における効果

プロダクトのドメイン知識やチームの普段の開発の流れなどを実際に手を動かしながら共有できる
背景情報を共有して知識レベルを揃えることで、着手してからコードを書き始めるまでの時間を短くできる

フェーズ2における効果

複数人で開発することで「目」が増え、個人では見落としていた問題を発見できるようになる
テストやリファクタリングなど一手間がかかるが品質向上に寄与する活動が自然と開発に組み込まれる

フェーズ3における効果

実装時に全員の知識を出し合って問題解決できる
実装の背景を共有しているためレビューのコストを下げられる（※このあたりの内容は昨年投稿した記事にも記載しているので。興味がある方はご参照ください）

昨年時点の開発体制では、フロントエンドエンジニア同士で開発していたためメンバー間の知識の差が少なく、品質に対する共通認識も形成されおり、フェーズ3に近い状態だったと言えます。その時には開発効率を高めることに自然に意識が向いていました。

数ヶ月前の開発体制では、バックエンド開発が中心でメンバー間で知識量に差が生じたため、開発の土台を作るフェーズ1の段階でした。この段階では知識共有が重要であり、モブプロは知識共有の効率を高めることに効果を発揮していました。

もともとの「このままモブプロを続けることが本当にチームとして効率の良い開発のやり方なのか？」という問いに対しては、「今のフェーズでは知識レベルを揃えるために効果的な手法だと考えている。チーム全体で開発効率を高め合うことはできていないが、フェーズが進むことでその効果も期待できる」と答えられます。

私たちのチームの取り組み

取り組む開発内容によっては、全員でパフォーマンスに関する議論をしたり、テストやリファクタリングを自然と実践できる状態になっていたりと、フェーズ3の「全員で開発効率を高め合う」に近い状態で進めることもできるようになりました。

最後に、私たちのチームがフェーズ1からフェーズ2へ、そして次のフェーズ3へ進むためにモブプロの中で取り入れてきた活動を紹介します。

モブプロの役割を明確にする (フェーズ1 → フェーズ2)

ドライバーとナビゲーターを必ず設定するようにしました。ドライバーはナビゲーターが指示したとおりに手を動かすことに専念し、指示の内容が理解できない場合は理解できるまで質問するようにしています。

これにより、ドライバーはインプットを即座にアウトプットする行為を繰り返すことになり、知識定着の効率が高くなると感じます。上記の理由から、メンバーが後からモブに合流した場合には、まずそのメンバーがドライバーを担当することが多いです。

交代を徹底する (フェーズ1 → フェーズ2)

時間になったら交代することを徹底しました。

ドライバーは知識獲得の効果が高いと考えているため、そのポジションを全員が体験できるのがメリットだと感じています。また、理解が追いついていないメンバーに気付くこともでき、その場で知識共有する機会も得られます。

さらに、上記の効果を得られる機会を増やすため、交代の間隔を短くする取り組みも行っています。私たちの場合は15分交代からスタートし、慣れてきたら徐々に短くして10分交代をおおよその目安にしています。

交代を促すためにモブタイマーを設定し、素早く交代できるようにVSCodeのLive Share機能を活用するなど、支援ツールも活用しています。

ワーキングアグリーメントを決めて全員で守る (フェーズ2 → フェーズ3)

チームが良いと思った開発プラクティスを全員が横並びで実践できるようにワーキングアグリーメントとして明文化しています。

たとえば、私たちのチームではテスト駆動開発を行っており、「テストから始めよ！」をワーキングアグリーメントとしています。うっかり実装のコードを先に書き始めそうになった時には、他のメンバーが「テストから始めよ！」と促すため、良いプラクティスが習慣化されていきました。

休憩を取る (フェーズ2 → フェーズ3)

開発で予想外に時間がかかる原因の1つとして「行き詰まること」が挙げられます。モブの交代の合間に休憩を取ることで、いったん落ち着いて方針を見直し、軌道修正する機会を作ることを意識しています。また、コンテキストがリセットされるため、コードを改めて見直したときに複雑になっていることに気づきやすくなる効果もあると感じています。

このことも「1時間モブしたら5分以上休もう！」というワーキングアグリーメントとしてチームで合意しています。