モブプログラミングは、なぜ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.」（ソフトウェアチーミングと「フロー」のチカラ）を行いました。
本記事ではその内容をダイジェストで紹介します。本記事ではその内容をダイジェストで紹介します。本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は中編です。
では、一緒に働く人を別々にしたら生産性は高まるのか？
「1台のコンピュータの周りに5人もいて、本当に生産性を高くできるのですか？」という質問に戻りましょう。
ソフトウェア開発において1人でできる仕事というのは、今となっては存在しません。私がプログラミングを始めた頃もそうでした。
だから私たちの仕事はすべて、複数の人間が必要です。その仕事を分割し、バラバラにして各人に振り分けているのです。
私の立場としては、先ほどの質問をひっくり返して、質問した人とは逆の視点から質問する必要があるのです。
つまり、「一緒に働くべき人たちを別々にして、どうやって生産性を上げられるのすか？」ということなのです。
それぞれが逆の2つの質問は、どちらが優れているということはありません。正しい質問とは何なのかを学ばせてくれるプロセスなのです。
「モブプログラミングが一人でプログラミングをするよりも優れていることを証明する研究はありますか？」と聞かれることもあります。私は逆にこう考えます「別々に働く方が一緒に働くよりも優れていると証明する研究はあるのだろうか？」と。
いずれの研究であれ、まったく同じ研究になるのですが。
生産性を妨げている要因は何か？
では、次にどのような別の質問をすべきなのでしょうか。「何が私たちの仕事の効率性を妨げているのか？」という質問は役に立つでしょう。
私は今まで、いろんな人を相手に1000回はこの質問をしてきました。その答えの一部をここに集めてあります。
「雑音が多すぎる」という答えがある一方で、「静かすぎる」という答えもあります。このペアは私のお気に入りです。
私にとって仕事の効率性を妨げている大きな要因は、ワークフローの中断、コンテキストの切り替え、注意散漫、次にすべきことが分からない、マルチタスキング、依存関係による待ちの発生、異なるタイムゾーン、要件の不明さなどなどです。
ところが、ソフトウェアチーミングを始めた途端に、これらの問題の多くが消え去っていったのです。
これは単に私たちがそのことに気づいただけであり、いずれかの証明になるわけではありませんが。たしかにそうでした。
待ち時間は大きな無駄である
そうして消え去った問題の1つ、私が「クエシチョンキュータイム」（質問の順番待ち時間）と呼んでいる問題について紹介しましょう。
質問の順番待ち時間とは、質問に対する答えを得るために待たなければならない時間のことです。私たちの仕事を妨げている要因の1つでした。
質問してから答えを得るまでに待ち時間が発生することはすごく一般的なことですが、仕事において、待ち時間は無駄な時間です。
そして、この待ち時間は「無駄」として測定可能です。
下記は仕事をしている時間と、その中の待ち時間をグラフ化したものです。緑の線は仕事をして付加価値を生んでいる時間帯で、赤い線は待ち時間なので付加価値を生んでいません。
話を単純化して、仕事をしていると1日に8つの質問が発生するとして、その待ち時間がそれぞれ1時間だったとき、10分だったとき、2分だったとき、そして0分だったときを図にしてみました。
もし待ち時間が1回当たり1時間なら1日のうちの半分を失っています。10分だとしたら、1日で1時間を失います。
しかし待ち時間がゼロなら、私たちは1日中効率的に仕事ができるのです。
ではどうすればいいのでしょうか？
例えばマルチタスクが考えられます。待ち時間にほかの仕事を進めるために別の仕事をするのです。すると別の仕事に取りかかることができ、在庫を増やすことになります。
これによって仕事は忙しくなるように見えますが、着手した仕事のうち納品されていないもの、すなわち在庫が増えることになります。
在庫とは、まだ価値を届けられていないもので、これも無駄の一種です。つまり無駄を解決するために別の無駄を作ることになるわけで、これでは解決になりません。
モブプログラミングを始めたら問題が消え去った
私たちはこの問題をどうやって解決したのでしょうか？ 解決したのではなく、消えてしまったのです。
ソフトウェアチーミングのメンバーへの質問であれば、その場でメンバーが答えてくれるので、順番待ちの時間はゼロなのです。
ただしチームメンバー以外への質問が生じた場合には、待ち時間が発生します。プロダクトオーナーへの質問が生じたとき、私たちはチームメンバーは開発者だけでは完成しないのだと気がつきました。
その当時はプロダクトオーナー、ソフトウェアテスト担当、データベース担当、デプロイ担当のグループがそれぞれあり、私たちの仕事を待っていました。
そこで私たちは、開発者だけではチームが完結しないことに気づいたのです。
つまり私たちには、彼らすべてのブリリアントマインドを集合させることが必要であり、質問の順番待ち時間をなくすことが理想的で、できる限りそれを実現したいと考えました。
プロダクトオーナーがその場で質問に答えてくれるのであれば、彼ららの仕事は開発中のシステムの中にすぐに取り込まれていくのです。
このことに気づいたとき、チームメンバーの一人がこう言いました「私たちがやろうとしていることは、一連の『フロー』のようなものだ」と。
これがこの話の中で最も重要なこと、つまり「フロー」です。
フローとは、何かに完全に集中しているとき
フローという言葉は、ミハイ・チクセントミハイという人が作った造語です。
彼は1970年代にこの言葉を作りました。フローとは何かに完全に没頭しているとき、何かに完全に集中しているときに陥ることができる状態であり、それによって私たちはある種の卓越性を達成することができます。
ゾーンに入っていると言ってもいいでしょう。プログラマーにとって別の言い方をすれば、集中し、多くのことを成し遂げ、自分の仕事に自信を持ち、その結果に満足しているということです。
フローで仕事をしているように見える人たちの写真を見つけたので、ご覧ください。
これはとても有名なコンピュータのイノベーション空間だった、ゼロックスのPARCにいる人たち。
次の写真は私のお気に入りです。
この手術にはそれぞれが自分の技術や能力を備えた10人の医者が参加しました。1944年に12歳の患者に対して行われた非常に有名な手術です。長時間を要した手術で、おそらくは何度となく手術の準備と練習を事前に繰り返したはずです。
チームにもフローがある
「チームフロー」という研究が行われていたことも見つけました。
そこには集団的野心、共通の目標、個人的目標の一致、高いスキルの統合、オープンなコミュニケーション、心理的安全性、一体感。相互の信頼、そして全体的な集中があります。これらができればチームフローができるのです。
製造業において無駄をなくす「リーンフロー」
そしてもう1つの「フロー」として、私が「リーンフロー」と呼んでいるものについても話をしましょう。
リーンフローは製造業の考え方から来ています。
基本的な考え方はとても単純です。誰かが注文しない限り、何も製造しない。製造は1つずつ完成させ、最初から最後まで可能な限り途中の順番待ち（キュー）や在庫が発生しないように製造するのです。
そこで私が問いたいのは、「ソフトウェア開発でこれを達成できるか？」ということです。
このテーマに関する良い本を見つけました。
この本の著者ドナルド・ライナーセン氏は次のように書いています。「順番待ち（キュー）は、製品開発における経済的無駄の大半の根本原因である」と。
ソフトウェア開発でもリーンフローを実現する
製造業のリーンフローと同じように、ソフトウェア開発においてフローを定義するとすれば、最初のストーリーやアイデアがそれぞれ、可能な限り行列待ちや在庫なく、開発の最初から最後まで流れていくものだ、と言えるでしょう。
最後まで、というのは、ちゃんと動くソフトウェアになる、ということです。
アジャイルソフトウェア開発宣言には、動くソフトウェアについての定義がありますが、私自身はそれを、QAのテストに合格した地追う意味ではなく、それを使うべき人々にとって意図したとおりに動いている、という意味だとしています。
そのためには、これまで見てきたような無駄、つまり行列待ち（キュー）や在庫だけでなく、仕事の割り込みやコンテキストの切り替え、マルチタスクなどたくさんのものをなくしていくことになるのです。
そこでこの円環の図をお見せしましょう。アジャイル開発の図です。
私たちはプロセスのどの位置であっても学習を行い、そして次のプロセスに進みます。これをいかに短期間にできるでしょうか？
この1回ずつの「価値における、小さく手軽な試み」（Small inexpensive attempt at Value）という言い方は気に入っています。これこそ方向性を決めるための私たちの知恵です。
これが出来たときがフローを実現できたときだと思います。
これを妨げる大きな要因となっているのが、行列待ち、作業待ち、在庫なのです。
私は、1時間もかからずに試せるようなことを、わざわざ1日かけて議論するようなチームで働いたことがありました。しかし議論しているだけでは結果は得られません。実際に試してみることで、やるべきことが見えてくるのです。
何かを作り上げなければ、行動を起こすために必要な学習は得られません。
ソフトウェアチーミングはフローを最適化する
私たちはリーンフローを達成することで、これが「1台のコンピューターに5人で効率的に作業するにはどうしたらいいか？」という疑問に対する答えなのかもしれない、と気づき始めました。
ソフトウェアチーミングでは、一体何を最適化しようとしているのでしょうか？
もうお分かりでしょう。仕事のフローを最適化しようとしているのです。
それは、個人のアウトプットを最適化するよりもずっと重要なことです。
私が長年働いてきたほとんどの職場では、個人のアウトプットを測定し、誰もが自分の仕事を最大限にこなせるように最適化していました。
しかし私たちがやろうとしているのは、各人の力を最大限に引き出せるような環境を作ろうとしていることです。
≫続く：後編では、モブプログラミングは生産性が高いのか？ という質問の答えと理由の解説、そして会場からの質問に答えます。
関連記事
Regional Scrum Gathering Tokyo 2024では、下記の講演も行われています。
- ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
- ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）