キャリトレ事業部の松岡(@little_hand_s)です。

最近モブプロ、ペアプロがブームですよね。キャリトレチームでも2018年8月にスクラムを導入するにあたり、本格的にモブプロを導入しました。

「キャリトレ」は2022年12月21日をもってサービス終了しました。

(私のチームでは、モブかペアについては、現時点ではあまり意識的に区別をしていません。目的やタスクの分担状況を考慮しながらメンバー構成を都度検討しています。)

現時点の結論として、 モブプロは目的をきちんと持って行えばとても良いプラクティス! と思っています。

逆に言うと、モブプロを導入する前には
「なぜモブプロを導入したいのか?」を言語化することが重要 だと考えます。

そうしないと、「そもそも何でモブプロやってるんだけ?」と迷子になってしまったり、 モブでやる必要ない時に柔軟にソロワークにする、と言った判断ができなくなってしまうからです。

この記事では、一般に言われていることに加え、実体験を通じて感じたモブプロのメリットをご紹介します。
プロジェクトの課題感と照らし合わせ、目的を定義するための一助となればと思います。

言葉の定義

この記事では、「モブプロ」と言いつつ開発に関する作業全般(要件定義、設計、テストなど)を指しています。 モブワーク、ペアワークというのが適切ですが通りがいいのでここではモブプロと呼称しています。

モブプロのメリット

メリットとしては以下のようなものがあります。(書き出して見ると、結構な数ですね。笑)

1
2
3
4
5
6
7
8
1. レビュー&指摘対応の手戻り工数を大幅に減らせる
2. 分担によって発生する作業が減らせる
3. コードの品質が向上する
4. 難しい問題に取り組みやすくなる
5. 作業時間、フロー状態になっている時間の増加
6. 個人の知見のシェア
7. 知識がない分野でも取り組みやすくなる
8. 開発者同士のリレーション構築

メリット1: レビュー&指摘対応の手戻り工数を大幅に減らせる

以下図で説明します。

review_vs_pair

コンテキストスイッチというのは、一つの作業から別の作業を行う際に、前に何を行なっていたか思い出すのに時間がかかり、効率が悪くなる現象を指します。 Gerald WeinbergはQuality Software Management: Systems Thinkingの中で、 2つのプロジェクトを兼務するとコンテキストスイッチのために全体の20%効率が落ちると言っています。(参考リンク)

「工数削減!」というのはシンプルでわかりやすいので、私が人にモブプロを勧める時にはこの話を一番にするようにしています。 (この例だけでいうと、レビュアー/レビュイーという形のペアプロ導入からお勧めする場合になります)

メリット2: 分担によって発生する作業が減らせる

タスクの分担等のは一見効率的ですが、実は 分担の前後で「分担の計画」や「同期するための作業」が発生 しています。
これも以下の図でをみていただければと思います。

pair_design

これらの時間は普段無意識に食っていることが多いので、 作業時間を計測してみると「こんなに時間かかってたのか!」となることがあります。

そのようにして問題意識を顕在化させると、自然と最初からモブでやる方がいいよね、となったりします。

メリット3: コードの品質が向上する

複数人の知見が反映されるので、品質が向上しやすくなります。

mistake

もちろんレビューでもこの効果はありますが、レビューだと対象コードが多すぎる場合は細かいミスが見つけにくかったり、 ある程度作業が進んでからだと根本的な指摘がしにくかったり、といったレビューでは拾いきれない問題も解消できる傾向があります。

また、声に出すことによって、複雑さやおかしな挙動について明確に意識するようになるので、それらを解決しようとするきっかけを増やす効果もあります。

メリット4: 難しい問題に取り組みやすくなる

難しい問題に取り組むというのはどうしても気が重くなります。
個人で取り掛かろうとすると、必要以上に大きなプレッシャーを個人が背負うことになりがちです。

問題に対してチームで取り組むことで、「個人で抱える問題」から「チームで対応する問題」となり、個人にかかるプレッシャーを軽減し、純粋に問題に向き合うことができます。 結果的に、問題に積極的に取り組むことができます。

メリット5: 作業時間、フロー状態になっている時間の増加

個人で作業していると、ついSlackに回答したり、調査から横道に逸れたネットサーフィンをしてしまたり、ということが発生してしまいますが、 チームで議論をしながらプログラミングすると自然とそのような時間がなくなるので、単純に作業に向き合っている時間が増加します。

また、それだけではなく、「フロー状態」、つまり何かに完全に没頭して集中している時間を増やす効果があると言われています。 (参考:モブプログラミングと「フロー」)

実際モブプロをすると夕方にはかなりの疲労感があることを感じますが、個人作業に比べてそれだけ集中していたということを実感できます。

メリット6: 個人の知見のシェア

開発者が持っている暗黙知をシェアすることができます。
対象は様々で、業務知識、開発ツールの効率の良い使い方、開発自体の進め方や考え方などです。

こう言った知識はドキュメント化してシェアしようとするとなかなか工数が大きくて進まなかったり、ドキュメントから抜け落ちて十分に伝わらなかったり、 ということが発生します。一緒に作業をすると、それらの暗黙知を会話や作業を通じてシェアすることができます。

業務知識などについては属人化リスクを低減するのに役立ちます。
開発のベストプラクティスとしては、ログの追い方、テストの書き方、細かいところではIntelliJのショートカットなどを作業を通じて知る、などがあります。

また、知識や作業が属人化しないことにより、気軽に休暇を取りやすくなったり、メンバーが離任してもプロジェクトから知識が欠落しなくなる、というメリットもあります。

メリット7: 知識がない分野でも取り組みやすくなる

例えばサーバーサイドエンジニアでモダンなフロントは詳しくないような場合、「今週はフロント作業も担当してみようかな」 と着手するのはなかなかハードルが高く、効率もすぐに上がりにくいです。

こういう場合、フロントが得意な人とモブプロをしながら徐々に覚えていくと、アウトプットを出しながら自然に学習することができます。 これはチームに新規ジョインした開発者を迎える場合にも、同じことが言えます。

メリット8: 開発者同士のリレーション構築

モブプロをすると、必然的にコミュニケーション力が圧倒的に増えます。

設計や実装の議論を通じて、成功/失敗の経験を共有することにより、自然とリレーションが構築されます。 何か作業を終えた時に「やったね!」と一緒に喜ぶ体験は、単純にとても楽しいものです。

レビューという「見る側/見られる側」という関係と、同じ目線で課題に向かっていう関係というのは、実際体験してみるとかなり違うと思います。

導入時に発生しうる課題

メリットに並べて、導入時に発生しうる課題もご紹介します。

課題に関しては、実施したチームの特性によって様々に異なるものが発生すると思います。
そのため、一般的にこうというよりは、あくまで経験上の主観的なものを述べたいと思います。

1
2
3
1. 継続的改善プロセスが必要
2. モブ/ソロの使い分けは悩ましい  
3. 全ての人に向いているわけではない

課題1: 継続的改善プロセスが必要

モブプロ導入時にはかなり実験的要素が含まれており、最初からベストな形にはたどり着かないでしょう。 そのため、継続的に現状を振り返り、進め方を改善していく、というプロセスがセットで行われることが必要になると思います。

課題2: モブ/ソロの使い分けは悩ましい

「レビューの手戻り工数、分担作業のオーバーヘッドを減らせるので結果的に効率的になる」と書きました。 しかし、それでもやはり個別に作業した方が効率が良いことは生まれます。

また、個人で色々手を動かさないと腹落ちしない、といった学習上の課題も発生します。

こういう場合に、モブ/ソロの使い分けの判断は常に迷います。

現時点の結論としては、やはり目的を意識して、それに照らし合わせてどちらが良いかを判断するのが良いと思っています。 例えば、あとでレビューをしてもほぼ手戻りしなさそうであればソロ、そうでなければモブ、といったようなことです。

課題3: 全ての人に向いているわけではない

コミュニケーションスタイルや、仕事の進め方としてどうしても個人で作業をする方が好き!という人はいます。 そういう人には強制をしない方が良いと思います。

あくまで複数ある手段の一つとして持っておき、トライアンドエラーの中で良さそうであれば継続する、というぐらいのスタンスが良いと思っています。

まとめ

モブプロの目的の候補としてのメリットと、発生しうる課題の例を整理してみました。

モブプロは常に効果を発揮する銀の弾丸ではありません。 上記のような目的を考えた時に、チームの状況的に特に必要とならなければ、「モブプロをしないということが適切」ということになります。

モブプロ自体はとても楽しいものだと思います。ぜひ目的を持って楽しいモブプロライフをお送りください!

参考資料

The Benefits and Pitfalls of Pair Programming in the Workplace
What is Pair Programming? Advantages, Challenges, Tutorials & More

松岡 幸一郎
松岡 幸一郎

主にサーバーサイドエンジニア。DDD布教活動中。