はじめに
これまで私は、Slerでソロプログラミングを6年ほど、アジャイル開発でペアプログラミングを1年ほど、モブプログラミング（フルモブ）を3週間ほど行いました。その結果、フルモブって最高じゃん！ってなったので、「そんなこと言ってもフルモブってさ…」ってよく聞く質問に答える形でフルモブの良さを伝えます！！
「フルモブってなんなん？」
フルモブとは、チーム全員でのモブプログラミングのみで開発を進める開発体制のことです。（wikipediaにあるかなって思ったらなかったので、勝手に定義しておきます）
「フルモブって効率悪くない？」
よくソロやペアと対比した際に聞かれる質問だと思います。この質問はある意味正しいですが、ある意味正しくはありません。それはどういうことかというと、質問にある「効率」が、なに効率を指しているかがポイントになるからです。
効率といっても様々な効率があり、その効率の中でも、システム開発の現場で主に注目される効率には「リソース効率」と「フロー効率」があります。
リソース効率とは、その名の通り「人員などのリソースが遊び無く稼働している」ことを重視して考える効率性のことです。稼働率の高さを主眼において考えることとも言えます。
フロー効率性とは「価値を届けるまでのリードタイム」を重視して考える効率性のことです。ある機能（価値）をできるだけ早く届けることを主眼において考えることとも言えます。届けるまでの時間（リードタイム）が短くなるほど、フロー効率が良いという言い方をします。
両者の効率の違いをスーパーマーケットの会計待ちののレジで例えてみます。
会計待ちのお客さんが長いレジは、遊びなくレジが稼働しているので、とてもリソース効率が良い状態です。しかし、お客さん1人の待ち時間は長くなってしまうので、フロー効率は悪い状態です。
逆に、各レジ会計しているお客さんのみで全くお客さんが待っていないレジは、すぐに遊びができてしまうので、リソース効率が悪い状態ですが、フロー効率は良い状態です。
会計待ちのお客さんがたくさんいるレジ
リソース効率が良い
レジの稼働率が高く、遊びがない
フロー効率が悪い
お客さん1人1人の待ち時間長い
会計待ちのお客さんいないレジ
フロー効率が良い
お客さんの待ち時間が短い、無い
リソース効率が悪い
稼働率が低く、レジに遊びができる
では、どちらの効率を重視する方が良いのでしょうか？
近年のシステム開発の現場では、稼働効率を上げ新機能の開発コストを下げることよりも、顧客にできるだけ早く新機能を届けることが、重視される傾向にあると思います。コストを下げるよりもスピードを優先した方が結果として大きな利益を生む場合が多いからです。
リソース効率は、大人数が関わる大規模なシステム開発に向いている考え方ですが、フロー効率は、小規模でスピードを優先し、変化に柔軟に対応できるようリリースし続ける、アジャイル的な開発に向いている考え方だと思います。
詳しくはとても読みやすく素晴らしい参考記事さまを読んでください！
「でも結局別れた方が早いでしょ？」
ここまで、フロー効率を重視するフルモブの方が価値を届けるスピードが早いと言ってきましたが、フルモブしているチームで開発した場合と、技術レベルの高いスペシャリストひとりが担当した場合、開発時間を比べるとそこまで大きな差が出ないかもしれません。（属人化や、長期的目線の話はここでは置いておきます）
しかし、フルモブでは開発作業時間以外の時間が削減されるので、チームで開発している限り、トータルの作業時間はより短いものになると思います。
フルモブで削減される時間
- レビュー
- レビューする時間
- レビューのフィードバックをもらう時間
- レビュー待ちの時間
- 質問
- 質問する時間
- 質問を受ける時間
- 質問できるか伺う時間
- 管理・会議
- 各メンバーの進捗管理（会議、報告等）
- 各メンバーへのタスク振り分け
- 情報共有が目的の会議（進捗管理以外）
- （Gitを使っていれば）ブランチ管理
- その他
- 分からないとひとりで悩んでいる時間
では、これらの削減時間を試算してみましょう！
前提条件
- チームは5人、能力はバラバラで属人化も進んでいる
- レビューの発生頻度は、各人1週間に1回1時間かけている、2人からもらう
- 進捗管理は1日1回30分
- 情報共有目的の会議が1日1回30分
- タスクの振り分けの会議が1週間に1回1時間
- 各人、質問をする・受ける時間1日0.5時間
- 計算期間を1ヶ月とする
レビュー時間：5人×2人×4週 = 40時間
進捗管理：0.5時間×5人×4週 = 10時間
情報共有会議：0.5時間×5人×5日×4週 = 50時間
タスク振り分け：1時間×4週 = 4時間
質問：5人×1時間×4週 = 20時間
合計：124時間 → 約15日分（1日8時間として）
かなり控えめに見積もったつもりですが、1ヶ月フルモブで開発すると、15日分の開発作業外時間が浮くことになります。
また、レビューによる修正時間、レビュー待ちの時間、ひとりで悩んでいる時間などを含んでいないので、実際はこれよりも多くの時間が浮くことになると思います。
これらの時間が無くなること、何より悩んだり考える数が減ることがイイですよね。
「いやでも敢えてフルモブする必要もないんだよね…」
ここまでフルモブの悪いイメージを良くすることを話してきましたが、フルモブのマイナスイメージを無くしたところで、わざわざ開発体制を変えてまですることなのか？と言われると、する価値があると答えます。フルモブをすることで自然と享受できるメリットがたくさんあります。
フルモブによって享受できるメリット
- コードの共同所有
- 全員LGTM状態
- 共有範囲がチーム全員
- 学びの情報源がチーム全員
- 言語化・図式化して説明する機会が増える
- 2人休んでも、会社を辞めてもなんとかなる
フルモブでは、チームの全コードを全員で担当することになるので、自然と共同所有状態になり、自然と全員からレビューされている状態になります。
わざわざプルリクを飛ばす手間がありませんし、コードを書いた背景まで理解しているので、レビューの質も向上します。
プルリクでのレビューでは汲み取り辛い仕様上バグ、指摘点がコードの書き方に寄ってしまっていて、レビューが障害発生率の減少に繋がらないなど、思い当たるところはないでしょうか？
また、タスクや知識が属人化することもないので、タスク進行中のメンバーの病欠、キーマンの突然の辞職などがあっても問題なく業務を進行することができます。苦い思いをしたことのある人も多いのではないですか？
最後に
ここまで思いだけでお伝えしてきましたが、フルモブめっちゃイイです。とはいえ、チームの状況、開発の規模、メンバーの特性などで、フルモブに向いているチーム、向いてないチームがあると思います。ぜひ、やったことのない方は、実験と思ってまずは1週間試しにやってみてはいかがでしょうか？
※実験する際は参考の書籍を一読してから実施することをオススメします。