モブ作業をやってみて、よかったと感じた6つのこと
つい最近、モブ作業をやってみて大きな効果を実感できたので、これを機に書き残しておきます。
モブ開発（モブ作業・モブプログラミング）とは
厳密な定義は見つけられませんでしたが、英語のWikipediaにMob Programmingの項目があります。
本記事では「モブ〜」や「ペア〜」について、以下の意味で使用します。
- モブ開発：開発に関するタスク全般を、チームメンバー全員（3人〜5人）で行うこと
- モブ作業：何らかのタスクをチームメンバー全員（3人〜5人）で行うこと
- モブプログラミング：コーディングをチームメンバー全員（3人〜5人）で行うこと
- ペア作業：何らかのタスクを2人で行うこと
- ペアプログラミング：コーディングを2人で行うこと
モブ作業をやってみたきっかけ
現在稼働しているCI環境についてうまく動作しないケースがあるため、その改善を行うときにモブ作業をやってみました。 そもそも、CI環境が改善されずに放置されていたことには、以下の事情があります。
- CI環境を構築した人は、既にチームにいない
- CI環境の構成について、ドキュメントは残されていない
- CI環境の評価環境がないので、環境を破壊してしまうのが怖くて触りづらい
- CIのツールについて、1人で使いこなせるほど詳しい（or覚えている）人がいない
一言でまとめると「誰もCIの現状構成やツールについて十分には理解できておらず、セーフティーネットもないので、怖くて触れない」という状況でした。しかしCIのツール自体は一般的なものを使用していますし、メンバー全員で1〜2時間程度かければ改善できるのでは、と思ったのでモブ作業を試してみました。
その結果としては非常に効果的で、CI環境をトラブルなく改善することができました。
この経験を通じて、モブ開発（モブ作業、モブプログラミング）の可能性を肌で感じられたので、よかったことをまとめてみます。
モブ作業をやってみてよかったこと
モブ作業の効果として実感したことは、以下の6個です。
- 常に情報共有・レビューができ、生産性と品質が上がる
- 並行作業の効率が上がる
- 効率的な方法を学ぶ機会が増える
- 気が散ることを防ぎ、集中力が持続する
- チームメンバーの知識を結集できる
- メンバーが不在でもタスクを続行しやすくなる
以下、順にまとめていきます。
常に情報共有・レビューができ、生産性と品質が上がる
CI環境を触っている間、メンバー間では「この設定項目がわからないね」「これ、多分こういう機能なんじゃないかな」「ここを変更すればよいのでは？」「こうやって検証すればよくない？」といったやりとりが発生しましたが、このやり取りを通じて情報共有とレビューが実現できていると感じました。
もし1人で作業していたら、具体的な変更内容だけを後から情報共有してもほとんど伝わらないでしょうし、変更内容の妥当性をレビューしてもらうことも困難だったでしょう。そして情報共有に30分〜1時間かかってしまうのならモブ作業で進めてもトータルでかかる時間には大差ありませんし、モブ作業のほうが調査や作業工程まで詳細にレビューできる分だけ品質は高いということになります。
また、モブ開発においても同様の効果は期待できそうだと感じました。
例えば、設計レビューやコードレビューには思った以上に多くの時間がかかります。「なぜこのような設計にしたのか」を口頭で補足説明しなければ伝わらないことも多いですし、コードレビューについてもプルリクだけで完結できないことはよくあります。また、レビューでの指摘事項が軽微なものであればよいのですが、根本的な欠陥が見つかった場合には設計のやり直しが必要になるなど、大きな後戻りとなることもあります。
他にも、影響調査などの工程においてはその結果や結論だけを見てレビューすることは難しく、「どのように調査を進めたか」というプロセスを含めてレビューすることが重要になります。
以上のことを踏まえると、開発においてもモブで行ったほうが結果的に効率的で、品質も高くなると感じました。また、メンバーが随時指摘できることは後戻りを最小限に抑えることにも繋がります。
そもそも「言語で伝えられる情報は限られている」ということを考えても、「モブ作業によって生産性と品質担保を両立する」というのは非常に合理的なのかもしれません。
並行作業の効率が上がる
CI環境の調査中、分からない項目や用語がでてきましたが、メンバーで手分けして調べることができました。
個人作業の場合は一つ一つ調べる必要がありますが、モブ作業では1人が調べた内容を全員に共有すれば済むので、非常に効率的であると感じられました。
モブ開発においても同様のことが期待できそうだと感じました。
例えばコーディングを行う場合、1人で進める場合は「設計資料を見ながらコーディングを進める」ことになりますが、2人以上ではドライバーの人がコーディングに集中し、他の人は設計資料を読み返しながら指示を出すことができます。
このようにモブ作業の人数だけ操作端末を増えることで並行作業が可能となり、開発途中の調査にかかるリードタイム短縮に繋がりそうだと感じました。
効率的な方法を学ぶ機会が増える
CI環境を触っているときに、一部のメンバーが「こんな画面があったんだ」という反応をしていました。
効率的な方法を知っていれば一瞬で終わる作業であっても、その方法を知らなければ非効率な状況はずっと続きます。
そのため、他人のやり方から効率的な方法を学ぶ機会が増えることは、非常に有益であると感じました。
モブ開発においても同様のことが挙げられます。
例えば、開発環境の機能やショートカットキーです。開発環境の機能やショートカットキーは知っているだけで生産性向上に直結するので、他人から学ぶ機会を増やせることは中長期的に見てもプラスに働きます。
また、新卒の人やエンジニア見習いレベルの人は、具体的な作業をどのように進めていけばよいのか、確立するまでに時間がかかります。 これらの人にとっても、他人のやり方を見て覚えることのできるモブ開発は、早期戦力化に向けて大きな効果が期待できます。
気が散ることを防ぎ、集中力が持続する
モブ作業のほうが、個人作業よりも半強制的に集中力を持続できると感じました。
メンバーとの意見交換や議論そのものが刺激になりますし、途中で集中力や思考力が低下してきても会話によって引き戻されます。そのため、モブ作業で進めること自体がパフォーマンスをキープする上で効果的であると感じました。
また、個人作業していると作業途中に飛んできたメールやチャットに反応してしまったり、ふと思い出したタスクに着手してしまうこともあります。しかしモブ作業であれば途中でよそごとを始めてしまうことも防止できるので、集中力をキープすることに繋がります。
チームメンバーの知識を結集できる
CI環境およびその現状構成について、完全に理解している人はおらず、それを記したドキュメントもありませんでした。
そもそも、年月が経過し、メンバーが加入・離脱を繰り返すにつれて、メンバーのシステムやアプリに対する理解は断片的になっていきます。その結果「有識者もいないが、ドキュメントも存在しない」という状況が起こり得ます。
しかしこのような状況においても全員の知識を結集すれば、おおよそ全体像を掴むことができ、改善につなげることができました。
この経験を経て、モブ作業はドキュメントが不十分な既存機能のドキュメント化を進めていく上でも活用できそうだと感じました。 誰も体系的に理解できていない機能については、ドキュメントを整備しようと思っても各々が「自分は完璧なドキュメントなんて作れないしな…」と考えがちですが、モブ作業であれば断片的な知識を結集し、必要に応じてコードの読み合わせも行えば、心理的なハードルを下げつつ効率的にドキュメント化が進められそうだと感じました。
メンバーが不在でもタスクを続行しやすくなる
モブ開発は、途中でメンバーが不在となる場合にも効果が期待できそうだと感じました。
今回は1〜2時間程度の作業だったので、途中でメンバーが不在になることはありませんでした。
しかし1日や1週間などの単位で見れば、打ち合わせ・病欠・年休などの理由でメンバーが一時的に不在になることは少なくありません。
ペア作業やペアプログラミングであれば、どちらか片方が不在になっただけで続行不可能になります。 しかしモブ作業やモブプログラミングでは、3人以上いれば1人離脱しても複数人での作業を続行できるため、一部のメンバー不在による影響を受けづらくなります。 したがって、モブ開発のほうが不測の事態やトラブルの発生に強く、計画通りに動きやすいというメリットがありそうです。
まとめ
モブ作業をやってみてよかったと感じられたことをまとめました。
一部、ペア作業やペアプログラミングの効果と重複する箇所もありますが、モブ作業ならではの発見もありました。特に、チーム内でノウハウを共有できたり、勉強会のような効果を実感できたことは、特に大きな発見でした。
モブプログラミングの定量的な効果は定かではありませんが1、情報共有のコミュニケーションコスト削減、勉強会のような効果を兼ねられることなどを考えると、肌感覚では生産性が上がっていることを実感しました。 チームメンバーが「モブ作業って効率悪くない？？」と感じるようになったら、それはノウハウ共有が十分に進んだということであり、個人作業やペア作業に切り替えてもよいのだろうと感じました。
今後は開発においてもモブ開発を積極的に取り入れていこうと思います。