モブでやる必要ない時に柔軟にソロワークにする、と言った判断ができなくなってしまうからです。この記事では、一般に言われていることに加え、実体験を通じて感じたモブプロのメリットをご紹介します。プロジェクトの課題感と照らし合わせ、目的を定義するための一助となればと思います。言葉の定義この記事では、「モブプロ」と言いつつ開発に関する作業全般(要件定義、設計、テストなど)を指しています。モブワーク、ペアワークというのが適切ですが通りがいいのでここではモブプロと呼称しています。モブプロのメリットメリットとしては以下のようなものがあります。(書き出して見ると、結構な数ですね。レビュー&指摘対応の手戻り工数を大幅に減らせる以下図で説明します。コンテキストスイッチというのは、一つの作業から別の作業を行う際に、前に何を行なっていたか思い出すのに時間がかかり、効率が悪くなる現象を指します。2つのプロジェクトを兼務するとコンテキストスイッチのために全体の20%効率が落ちると言っています。(参考リンク)「工数削減!」というのはシンプルでわかりやすいので、私が人にモブプロを勧める時にはこの話を一番にするようにしています。これも以下の図でをみていただければと思います。作業時間を計測してみると「こんなに時間かかってたのか!」となることがあります。そのようにして問題意識を顕在化させると、自然と最初からモブでやる方がいいよね、となったりします。コードの品質が向上する複数人の知見が反映されるので、品質が向上しやすくなります。ある程度作業が進んでからだと根本的な指摘がしにくかったり、といったレビューでは拾いきれない問題も解消できる傾向があります。声に出すことによって、複雑さやおかしな挙動について明確に意識するようになるので、それらを解決しようとするきっかけを増やす効果もあります。難しい問題に取り組みやすくなる難しい問題に取り組むというのはどうしても気が重くなります。個人で取り掛かろうとすると、必要以上に大きなプレッシャーを個人が背負うことになりがちです。問題に対してチームで取り組むことで、「個人で抱える問題」から「チームで対応する問題」となり、個人にかかるプレッシャーを軽減し、純粋に問題に向き合うことができます。結果的に、問題に積極的に取り組むことができます。チームで議論をしながらプログラミングすると自然とそのような時間がなくなるので、単純に作業に向き合っている時間が増加します。それだけではなく、「フロー状態」、つまり何かに完全に没頭して集中している時間を増やす効果があると言われています。(参考:モブプログラミングと「フロー」)実際モブプロをすると夕方にはかなりの疲労感があることを感じますが、個人作業に比べてそれだけ集中していたということを実感できます。個人の知見のシェア開発者が持っている暗黙知をシェアすることができます。対象は様々で、業務知識、開発ツールの効率の良い使い方、開発自体の進め方や考え方などです。いうことが発生します。一緒に作業をすると、それらの暗黙知を会話や作業を通じてシェアすることができます。業務知識などについては属人化リスクを低減するのに役立ちます。開発のベストプラクティスとしては、ログの追い方、テストの書き方、細かいところではIntelliJのショートカットなどを作業を通じて知る、などがあります。知識や作業が属人化しないことにより、気軽に休暇を取りやすくなったり、メンバーが離任してもプロジェクトから知識が欠落しなくなる、というメリットもあります。着手するのはなかなかハードルが高く、効率もすぐに上がりにくいです。いう場合、フロントが得意な人とモブプロをしながら徐々に覚えていくと、アウトプットを出しながら自然に学習することができます。これはチームに新規ジョインした開発者を迎える場合にも、同じことが言えます。開発者同士のリレーション構築モブプロをすると、必然的にコミュニケーション力が圧倒的に増えます。設計や実装の議論を通じて、成功/失敗の経験を共有することにより、自然とリレーションが構築されます。何か作業を終えた時に「やったね!」と一緒に喜ぶ体験は、単純にとても楽しいものです。レビューという「見る側/見られる側」という関係と、同じ目線で課題に向かっていう関係というのは、実際体験してみるとかなり違うと思います。導入時に発生しうる課題メリットに並べて、導入時に発生しうる課題もご紹介します。課題に関しては、実施したチームの特性によって様々に異なるものが発生すると思います。そのため、一般的にこうというよりは、あくまで経験上の主観的なものを述べたいと思います。継続的改善プロセスが必要モブプロ導入時にはかなり実験的要素が含まれており、最初からベストな形にはたどり着かないでしょう。そのため、継続的に現状を振り返り、進め方を改善していく、というプロセスがセットで行われることが必要になると思います。モブ/ソロの使い分けは悩ましい「レビューの手戻り工数、分担作業のオーバーヘッドを減らせるので結果的に効率的になる」と書きました。それでもやはり個別に作業した方が効率が良いことは生まれます。個人で色々手を動かさないと腹落ちしない、といった学習上の課題も発生します。いう場合に、モブ/ソロの使い分けの判断は常に迷います。現時点の結論としては、やはり目的を意識して、それに照らし合わせてどちらが良いかを判断するのが良いと思っています。あとでレビューをしてもほぼ手戻りしなさそうであればソロ、そうでなければモブ、といったようなことです。全ての人に向いているわけではないコミュニケーションスタイルや、仕事の進め方としてどうしても個人で作業をする方が好き!という人はいます。いう人には強制をしない方が良いと思います。複数ある手段の一つとして持っておき、トライアンドエラーの中で良さそうであれば継続する、というぐらいのスタンスが良いと思っています。まとめモブプロの目的の候補としてのメリットと、発生しうる課題の例を整理してみました。モブプロは常に効果を発揮する銀の弾丸ではありません。上記のような目的を考えた時に、チームの状況的に特に必要とならなければ、「モブプロをしないということが適切」ということになります。モブプロ自体はとても楽しいものだと思います。サーバーサイドエンジニア。