モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか（前編）。モブプログラミングの生みの親が解説するその理由と効果とは？
今回は「モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか（前編）。モブプログラミングの生みの親が解説するその理由と効果とは？」についてご紹介します。
関連ワード （方針決定、機能強化、知恵等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
2人のプログラマが協力して同じコードに対してプログラミングを行う「ペアプログラミング」に対して、モブプログラミングは3人以上のチームメンバーが協力してプログラミングを行う方法です。
このモブプログラミングの生みの親であるWoody Zuill氏が、今年（2024年）1月に東京都内で行われたイベント「Regional Scrum Gathering Tokyo 2024」の基調講演「Software Teaming (Mob Programming) and the Power of Flow.」（ソフトウェアチーミングと「フロー」のチカラ）を行いました。
講演のなかでZuill氏は、なぜ一見すると手分けをして作業するよりも効率の悪そうなモブプログラミング（あるいはソフトウェアチーミング、チームプログラミング）が、生産性の高い開発手法であるのか、その理由である「フロー」とその効果について解説しています。
国内でも少しずつ知られるようになり、実践されつつあるモブプログラミングの背景にある考え方とは何なのか、その理解を深める基調講演となりました。
本記事ではその内容をダイジェストで紹介します。本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は前編です。
ソフトウェアチーミングと「フロー」のチカラ
Woody Zuill氏。
まずは「モブプログラミング」について手短に紹介しましょう。
「モブプログラミング」あるいは「ソフトウェアチーミング」など、どちらで呼んでもらっても構いませんが、それを簡単に説明するならばそれは、ブリリアントマインド（優秀）な人たちが、同じ時間に、同じ空間で、同じコンピューターを使って、同じ仕事に取り組んでいる、ということです。
これは馬鹿げたアイデアに聞こえるかもしれませんが、私たちにとっては非常に有効な手法でした。
モブプログラミングにルールはない。うまく一緒に仕事をすること
ここで強調しておきたいことは、モブプログラミングやソフトウェアチーミングにルールはない、ということです。
もし誰かがあなたのところに来て「それはソフトウェアチーミングではない。ウディが私たちに説明した通りのことをやっていないから、それはモブプログラミングではない」などと言ったとしても、それは間違っています。
私が持っているモブプログラミングの唯一のルールは、うまく一緒に仕事をすること、です。
それはお互いの意見を衝突させないという意味ではなく、意見の衝突を乗り越えながら仲良くやっていこう、という意味です。これ以外のルールはありません。
そして優秀な人たちが同じ場所に集まれば、これから取り組もうとしている仕事に必要な知識も技量もすべてそこに揃うことになります。全てがそこに揃っているのであれば、あとは仕事を開始して完了するまで、ふだんなら途切れ途切れで作業せざるを得ないようなこともなく、全員で取り組むことができるのです。
これが今日、これから話そうとしていることです。
モブプログラミングの実際の様子
この写真は2012年頃に撮影されたもので、私たちがモブプログラミングに取り組み始めたときのオリジナルメンバーの一部です。
私たちが微笑んでいるように見えるでしょう。タイムラプスカメラで撮影していたのですが、そこにはみんなが微笑んでいるように見える写真が何千枚もありました。このチームがうまく機能していたことは、そこからご想像いただけると思います。
いまはリモートでも同じことができるようになっています。パンデミック以後はこうしたやり方も増えました。
チーム全体でコミュニケーションが続く
こうしたモブプログラミングは、1人がコーディングしている様子を5人で見守っているわけではありません。そうではなく、5人が仕事をし、1人がその仕事をコンピュータにインプットしているのです。
例えるならば、キーボードの前に座っている人がドライバーで、彼が運転するタクシーにみんなが乗り込むようなものです。タクシーに乗ったら、行き先を告げますよね。「空港に行きたいんです」とか。あるいはもっと詳しく道順を指示する必要があるかもしれません。
これが基本的な考え方です。
この方法の素晴らしくパワフルなところは、チーム全体で仕事を通じてずっとコミュニケーションが行われている、というところです。何かコミュニケーションに問題がある場所があれば、そのことがすぐに分かります。これはこのやり方における大事なポイントの1つでしょう。
そして世界中でこのモブプログラミングは行われています。下記の写真はモブプログラミングのオリジナルの場所であるHunter Industriesです。
世界中のさまざまなチームでも実践されています。私はおそらく1000以上のチームをトレーニングしてきたと思います。数えたことはないので、もっと多いかもしれません。
この写真で紹介したすべての人たちを私がトレーニングしたわけではありません。もしもモブプログラミングがうまくいかないものであれば、これほど多くの人が実践してはいないと思います。
なぜ集まって仕事をするのか？
では、本題に入りましょう。
これはプログラミングのチームではなく、スペースシャトルのミッションの写真です。ここでもブリリアントマインド（優秀）な人たちが一同に会し、同じことを同じ時間に、同じ空間でやっています。
しかも、その中の何人かは宇宙空間にいるはずです。
この人たちの頭脳が揃わなければミッションは遂行できません。しかもそれぞれの席には役割が書いてあり、その席の担当者はミッション全体に注意を払いつつ、自分の役割に集中しているのです。
なぜ私たちはこのようにして仕事をするのでしょうか？
私たちや多くの人が、次のようなことに気づきました。
- 多くの知識が共有できる
- 絶え間なくコードと設計をレビューすること
- 多くの異なる視点が持てること
- 迅速なフィードバック
- 正しいことに集中できる
- 仕事におけるフローな状態を拡大できる。フローについては後で詳しく説明する
- キュー（順番待ち）をなくし、在庫（作ったが使われていない）を削減できる
- よりよいソリューションを実現できる
- より高い品質を実現できる
- みんなの知恵を合わせているので、より楽しくストレスが少なく、穏やかに働ける。
こうして私たちの仕事はずっとやりやすくなったのです。
このような働き方をしている理由はもう1つあります。
それは、私たちチームがそうすると決めたからです。これは本当に重要なことで、自己組織化、自主的な方針決定、自己マネジメントを試みているのです。
モブプログラミングは本当に生産性が高いのか？
ソフトウェアチーミングの話をすると、いつも「1台のコンピュータの周りに5人もいて、本当に生産性を高くできるのですか？」と聞かれます。
そしていつも私は「分かりません。それは重要なことですか？」と答えています。というのも、私は生産性が重要だとは全然思っていないのです。
それよりも重要なのは、このやり方でチームがきちんと機能していることでした。
私たちが気づいたのは次のようなことです。
私たちが別々に仕事をしているとき、チームの5人がそれぞれのブースで仕事をしています。そしてある時期が来たら、それらを組み合わせて仕事を終えるのです。以前の計測によると、これは2日がかりの仕事でした。
私はこの種類の計測が有益だと考えてはいないのですが、経営陣向けにこうしたものを示すことが必要でした。
その後、私たちが一箇所で仕事をするようになると、より多くの仕事を成し遂げることができるようになりました。
数字で示すとすれば、私たちは約10倍の量をこなしていたのです。
成果が増えただけではありません。
コードはよりきれいになり、ソリューションはよりユーザーが望むものになり、メンテナンスが容易になり、コードを読むのが容易になり、機能強化が容易になり、何かを取り除くのが容易になったのです。つまり、より高い品質を実現できたのです。
私がこの職場で働いていた3年半のあいだ、この方法で数十ものプロジェクトで仕事をしました。そしてその仕事によるアプリケーションで本番稼動中に報告されたバグは3つだけでした。
とても高い品質を実現できたのは、一箇所に集まって知恵を出し合った結果だと私は考えています。
ラッセル・アッコフによるシステムの定義を紹介しましょう。それは「システムとは部品の働きの総和ではなく、その相互作用によるプロダクトである」というものです。
つまり5人の仕事を単に組み合わせるのではなく、いかにうまく相互作用を引き出すかに注目すべきなのです。
これこそがアジャイル開発のすべてだと私は考えています。
≫続く：中編では、生産性を阻害していた要因を取り除くき、高い生産性を実現する「フロー」が解説されます。
関連記事
Regional Scrum Gathering Tokyo 2024では、下記の講演も行われています。
- ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
- ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）