モブプロのススメ
モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（できれば4〜5人くらいが望ましい）でやるものです。
モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというものです。
この記事では、モブプロのススメということで効能について解説し、次の記事では具体的な方法について解説します。もともとは株式会社マツリカの社内ドキュメントに書いたものを、記事にまとめなおしました。
なぜモブプロ？
ソロ作業は個人がタスクと戦うスタイルです。それに対してモブプロでは、チームが問題そのものと戦うチーム戦です。
大変さは人数分の一。楽しさは人数倍
モブプロでは複数人で一つの成果物を作るため、効率が悪いようにみえますが、これは効率をどのレベルで捉えるという問題があります。
ここでいう「効率」は、より正確には「リソース効率」が悪いと言います。ある一人の作業者の時間をリソースとみなして、個人の能力や時間を最大限活かしてタスクをこなす効率のことです。
ペアプロやモブプロにおける効率はリソース効率とは異なる視座、個々人ではなくチームで考えるべきです。チーム全体の成果物を生み出す効率のことで、これを「フロー効率」と呼びます。
プログラミングでコミュニケーションコストの占める割合は大きい
プログラミングの工程では、コミュニケーションが少なくない割合を占めます。
チームのコミュニケーションでプログラミングを行うモブプロが、リソース効率は落ちてもフロー効率が上がる理由は、その少なくない割合のコミュニケーションを効率化するためです。
もちろんこれは成果物・作業及び作業者の性質によって異なります。誰がやっても同じになるような単純作業や定形作業のように、コミュニケーションの余地がない場合、フロー効率がリソース効率を上回ることはありません。
モブプロラミングはさらに、モブプロ参加メンバーの習熟度を上げるため、その後のリソース効率を上げることもできます。
属人性の解決
一般的にプログラミングでは調査が多いとはされていますが、属人性の度合いと、アーキテクチャによって比率は変わります。
ベンチャーのプロダクトなどは、スピード優先や限られたリソースで開発するため属人性が高まるため、長くなればなるほど調査タスクの比率は高めになります。
よくRailsで作られたベンチャープロダクトのメンテナンス性が落ちるのはこういった理由です。
モブプロの利点1つには、この属人性の問題を解決できることがあります。
ドキュメントを残せばいいのでは？
ドキュメントは、ベンダー仕様書のようなものなどは特にそうですが、メンテナンスコストを支払って、適切にメンテナンスしなければ、即座に負債と化すため、よほど無駄に人材が余っていなければ割に合いません。
ドキュメントを残すというのは意外に大変なものです。漏れがあるかもしれません。
モブプロでは、形式知だけでなく、暗黙知も得られるという大きなメリットがありますし、モブプロをやりながらドキュメントを少しずつ残していくことも可能です。このとき残すべきドキュメントは仕様書という形ではなく、粒度の小さいものです。
技術的知見を共有できる
たとえば、デバッグテクニックや、調査のコツ、ノウハウなど、個々人の持つ技術的な知見の共有にも役立つため、モブ参加メンバーの技術力アップに繋がります。
新規メンバーのオンボーディングに役立つ
当然、新規メンバーのオンボーディングにも役立ちます。
コードレビューの負荷を下げられる
モブプログラミングではプログラミングをしながら、コードレビューをすでにやっているのと同じなので、レビュー負荷を最小限に抑えることが可能です。
ハマりづらくなる
一人でタスクをこなしているとハマることがあります。特に集中力の高い人が調査系タスクをするととくにハマってしまう傾向があります。
モブプロでは、ハマる可能性は圧倒的に低くなるでしょう。
コミュニケーションコストの低減ができる
ここまで述べた通り、プログラミング開発ではコミュニケーションコストとの戦いになります。
人月の神話などで語られている通り、人をいっぱい投入すればプロダクト開発効率化やクォリティ向上するわけではありません。むしろ人が増えればコミュニケーションコストの増大により効率及びクォリティは悪化しがちです。
コミュニケーションコストは一般的に人数に比例して累乗的に増えると言われています。
モブプログラミングではコミュニケーションをしながら行うため、コミュニケーションコストを気にする必要性が減ります。
コミュニケーション欲求を満たせる
リモートワークやなんやかんやで、コミュニケーションに飢えてる人が増えてる今の時代だからこそ、コミュニケーションができるモブプロはオススメです。
モブプロではプログラマ以外も参加できる
デザイナーやプロダクトオーナー、テスターも参加することで、仕様の齟齬を防げます。
個人 vs タスク を、チーム vs 問題に変える
エンジニアがやるべきことは問題の解決（新規機能開発なども含めた広い概念）です。そのため、個人がタスクと立ち向かうことは本質的ではなくて、チームで問題を解決できればそれが望ましいはずです。
モブプログラミングやその他の手法では、チームで問題そのものを解決するというスタンスに変更できます。
やってみた感想
実際に社内でモブプロをしてみた感想としては、
・ きっちりモブプロとしてハマると面白い
・ 意外に疲れる（二時間くらいやるとヘトヘトになる）
・ コミュニケーション欲求が多少でも満たせるので、今の時代に合ってる
といったところでしょうか。
やりかた
筆者が実際にモブプロをやってみて得た知見を元に次の記事では、モブプロを成立させるためのやり方について解説します。
この記事が気に入ったらサポートをしてみませんか？