モブプログラミング入門📖
はじめに
本記事は書籍「Code with the Wisdom of the Crowd」の読書メモ的な内容です
読書時に出てきた用語・概念・疑問点をChatGPTに質問した結果で主に構成されます
ChatGPTの結果を使ってますが、内容的におかしい箇所は手動で修正・削除しています
この記事の解説動画
モブプログラミングとは
モブプログラミングとは、全てのチームメンバーが同時に同じタスクに取り組むソフトウェア開発手法の一つです。この手法では、一人のメンバー（ドライバー）がコードを直接書き、残りの全てのメンバー（ナビゲーター）が共同で問題解決を行い、ドライバーへ指示を出すという形をとります。チーム全員が同じ画面を見ながら、同じ時間を共有し、同じ問題を解決します。このプロセスはローテーションで進行し、定期的にドライバーの役割をメンバー間で交換します。
モブプログラミングの特徴
集団作業: モブプログラミングでは全員が一つのタスクに集中します。そのため、作業は非常に集中的で、個々のタスクがバラバラになることはありません。
一つのコンピュータで作業: モブプログラミングでは一つのコンピュータで作業を行います。そのため、複数のコンピュータで作業を同期させる必要がありません。
ローテーション: チームメンバーは定期的に役割をローテーションします。このため、全員がプロジェクト全体に関与することができ、多角的な視点で問題を考えることができます。
即時のフィードバック: モブプログラミングでは、問題が発生したときにその場でフィードバックと解決が行われます。これにより、問題が大きくなる前に解決できることが多いです。
知識の共有: モブプログラミングは、チーム内の知識の共有を促進します。各メンバーがタスクに直接関与することで、チーム全体の理解が深まります。
品質の向上: 一つのタスクに全員が関与することで、品質の高いコードが書かれやすいと言われています。それぞれの視点や専門知識が組み合わさることで、より優れた解決策が生まれやすいです。
学習の促進: 新しい技術や手法を学ぶ際、チーム全体で学習を共有することができます。また、経験豊富なメンバーから新人メンバーへの教育効果も期待できます。
ペアプログラミングとの違い
特性モブプログラミングペアプログラミング参加人数3人以上(通常)2人コード作成グループ全員で一つのコードを作成2人で一つのコードを作成ロールのローテーション頻繁に行う頻繁に行う学習効果高い(全員が全ての議論に参加)高い(2人で深く議論)生産性プロジェクト全体の視点での高い生産性単一タスクの完成速度は速い即時フィードバック全員からのフィードバックを得ることが可能相方からのフィードバックを得るナビゲータの数多数1人ドライバーの数1人1人
モブプログラミングの進め方
準備(約20分)
事前説明 (約10分): モブプログラミングに慣れていない場合は、モブプログラミングの目的ややり方、各ロールの意味等を説明します。既にモブプログラミングに慣れている場合は省略可能です。
問題の紹介(約10分): 今回チームで解く問題についての説明を行います。対象となる問題の目的や対象となるコードがどういった処理にあたるか等の認識を一致させます。
タイピスト順序決め (2分): ドライバー担当する順序を決定します。そこまで重要ではないのでじゃんけんなど任意の方法できめてください。
モビング (約1時間半(10分区切り)):
コーディング(10分) ドライバーはナビゲーターの指示に従ってコードを書きます。この間、ナビゲーターはドライバーが書いたコードについてフィードバックを提供し、改善点やエラーを指摘します。
ロールのローテーション (0分): コーディングセッションの終わりに、チームはロールをローテーションします。一般的には、ドライバーがナビゲーターに移り、新しいドライバーが選ばれます。
ふりかえり (20分): アジャイルの振り返りメソッドなどを用いて今回の作業をふりかえり、うまくいったこと、いかなかったこと、次回何を修正するか等を決めます。
タイピストが気を付けるべきこと
ナビゲーターの指示に従う: ナビゲーターからの指示や提案は重要です。タイピストはこれらの指示に従い、自分自身の意見や考えを抑制することが求められます。
明確なコミュニケーション: タイピストはナビゲーターからの指示が理解できない場合、すぐに問い合わせるべきです。混乱や誤解を避けるためにも、明確なコミュニケーションが重要です。
速度を適切に保つ: タイピングの速度が早すぎると、他のメンバーがついてこれなくなる可能性があります。反対に、遅すぎると進行が停滞します。適切なペースを維持することが大切です。
コードの可読性を保つ: タイピストはコードの可読性を常に考慮する必要があります。インデントやスペース、変数名など、他のメンバーが理解しやすいコードを書くことが重要です。
自身の役割を理解する: モブプログラミングではタイピストは「手」となり、ナビゲーターの思考をコードに変換する役割を果たします。タイピスト自身が解決策を考えるのではなく、ナビゲーターの指示を元にコーディングすることを理解することが求められます。
ハンズオフのスムーズな実行: ロールのローテーション時、タイピストはスムーズに自身の役割を次の人に引き継ぎます。これには、行っていた作業の状況を明確に伝えることも含まれます。
ツールや環境についての理解: タイピストは使用する開発ツールや環境について理解している必要があります。これにより、エラーの発生を避け、効率的なコーディングを実現します。
ナビゲーターが気を付けるべきこと
明確な指示: ナビゲーターはドライバーに対して明確な指示を提供する必要があります。指示が曖昧だと、ドライバーはその意図を理解しにくくなります。
積極的なコミュニケーション: ナビゲーターは他のナビゲーターやドライバーとの間で積極的なコミュニケーションを行い、意見や視点を共有することが重要です。
全体の視点を保つ: ナビゲーターはコードの特定の部分に固執するのではなく、全体的な視点を持つことが重要です。これにより、全体の目標や大局的な視野を保ちつつ、具体的なコーディングを進行できます。
ドライバーのペースを尊重する: ナビゲーターはドライバーのペースを尊重し、自分が理解していることを早く進めようとせず、全員が同じページにいることを確認する必要があります。
フィードバックと改善提案: ナビゲーターはドライバーが書いたコードに対して適切なフィードバックと改善提案を行う必要があります。これには、問題の指摘だけでなく、良いコードを認めるポジティブなフィードバックも含まれます。
コードの理解: ナビゲーターはドライバーが書いたコードを理解し、それが全体の目標にどのように寄与しているかを評価する必要があります。
次のドライバーへのスムーズな引き継ぎ: ナビゲーターはドライバーの役割を引き継ぐ際に、現在の状況を把握し、問題解決に対するアプローチを理解することが求められます。
モブプログラミングが向いている問題
複雑な問題: モブプログラミングは多くの視点を組み合わせて解決策を見つけるのに適しています。そのため、複雑な問題や未知の問題に対しては特に有用です。
新技術や新しいフレームワークの学習: 一つの問題に対して全員が集中することで、全員が新しい技術やフレームワークについて学ぶのに適しています。
コードの品質を上げる: ナビゲーター全員がドライバーのコードを見るため、コードレビューがリアルタイムで行われます。これにより、コードの品質を上げるのに有効です。
ナレッジシェアリング: チーム全員が同じコードベースを見て、一緒に考えることで、知識や経験が自然と共有されます。
モブプログラミングが向いていない問題
単純な問題: 単純かつ明確な解が既に存在する問題に対しては、モブプログラミングは時間を過剰に消費する可能性があります。
並列化可能なタスク: 複数の独立したタスクが存在し、これを並列に処理することで効率が上がる場合、モブプログラミングは不適切かもしれません。
極度に専門的な問題: 特定の高度な専門知識を必要とする問題では、専門家が単独で取り組む方が効率的な場合があります。
時間が非常に限られている場合: モブプログラミングは議論や合意形成の時間を必要とします。したがって、時間が非常に限られている場合には不向きかもしれません。
問題の解決策をだれもすぐに思い付かないとき
時にはすぐに良いアイデアが思いつかない場合があります。そんな時は以下の対策が考えられます
研究時間を設ける: チームメンバーが独自に問題について調査する時間を設けることで、新たな視点やアイデアを得ることができます。
専門家の意見を求める: 問題が特定の専門知識を必要とする場合は、その分野の専門家に意見を求めることも有効です。
一時的な休憩: 時には、少し離れて休憩を取ることで新たな視点を得られることがあります。一時的な休憩や他のタスクに取り組むことで、問題に対する新たな洞察を得ることができるかもしれません。
別の問題に取り組む: アイデアが思いつかない問題に立ち往生しているときは、一時的に他の問題に取り組むことも有効な戦略です。別の問題を解決することで、元の問題に対する新たな視点を得ることができる場合があります。
仮説を立てて試す: 最善の解決策が見つからない場合でも、何かしらの仮説を立てて試し、その結果から学ぶことも有効です。
モブプログラミングにおける人間関係の重要さ
モブプログラミングを行うチームは以下のような人間関係が理想です
尊重と信頼: 他のメンバーの意見やアイデアを尊重し、信頼することが重要です。これにより、安全な環境が形成され、全員が自由に意見を出せるようになります。
オープンなコミュニケーション: メンバー間でのオープンなコミュニケーションが必要です。問題点や意見を素直に表現し、他のメンバーの意見も受け入れることが求められます。
協調性: モブプログラミングは一人ではなく全員で行う作業であり、協調性が非常に重要となります。互いの意見を尊重し、共有することで一体感を持ちつつ効果的な解決策を見つけ出すことが大切です。
共感: メンバー間での共感も重要です。他のメンバーの視点を理解し、その感情や考えに共感することで、より深い理解と協力関係が生まれます。
Win-Winの思考: モブプログラミングは全員が勝つ（Win-Win）ことを目指すべきです。一人だけが解決策を押し通すのではなく、全員が納得できる解決策を見つけることが求められます。
フィードバックの受け入れ: メンバーからのフィードバックを受け入れ、改善につなげる能力が重要です。また、フィードバックは建設的であり、他人を尊重する態度を持って提供することが大切です。
集団思考(Groupthink)について
集団思考（Groupthink）は、一致団結を重視するあまりに、グループ内で批判的な意見や異なる視点が抑制され、誤ったまたは非効率的な意思決定につながる心理的な現象です。モブプログラミングのようなチームでの活動においては、集団思考は以下のような悪影響を及ぼす可能性があります。
誤った意思決定: 集団思考により、批判的な視点や異なる意見が抑制され、最善の解決策が見逃される可能性があります。
イノベーションの抑制: 新たな視点や創造的な解決策が抑制されると、革新的なアイデアの発生が阻害される可能性があります。
リスクの過小評価: 全員が同じ意見になることで、リスクや潜在的な問題が過小評価され、予期せぬ問題が生じる可能性があります。
集団思考を防ぐ対策
集団思考を防ぐためには以下のような対策が考えられます。これらはいずれも心理的安全性を確保するために行っていると考えて下さい。
意見の多様性: チームメンバーには自分の意見を自由に表現することを奨励し、多様な意見を尊重する文化を育てます。
匿名フィードバック: メンバーが自由に意見を述べられるよう、匿名でのフィードバックを許可することも有効な手段です。
批判的思考の奨励: 批判的思考を奨励し、全てのアイデアや提案が適切に評価・分析されることを確認します。
メンバーの個性(強み/弱み)
Strength Finder等の性格分析で各人の強み／弱みを把握することが可能ですが、モブプログラミングではこれらの情報を活かすことでより効率的に作業することが可能となります。
強みの活用: 各メンバーの強みを理解し、それを最大限に活用します。例えば、あるメンバーがコードの品質を確保することに特に優れていれば、そのメンバーの意見を重視する時間を設けたり、彼らにコードのレビューを任せるなどが考えられます。
弱みの補完: 同様に、メンバーの弱みも理解し、それを補う方法を見つけます。他のメンバーがその弱みを補える強みを持っている場合、その人をサポート役にするなどが有効です。
相互理解の深化: メンバー間で性格特性についてオープンに話し合い、相互理解を深めることが重要です。これにより、互いの強みと弱みを理解し、より効果的に協働することが可能になります。
メンバーの成長支援: メンバーが自分の弱みを克服し、新たな強みを身につけられるように支援します。これには、必要なスキルトレーニングや教育、メンターシップなどが含まれます。
フィードバックの活用: 定期的なフィードバックを通じて、メンバーの強みや弱み、成長の機会を識別します。このフィードバックは建設的で、成長と改善を促すものであるべきです。
オンボーディング時の注意点
新しいメンバーが参加する際は以下のような点に注意することで、スムーズにモブプログラミングに参加できるようになるのを支援できるとおもわれます。
オリエンテーション: 新メンバーがモブプログラミングのプロセスを理解するように、事前に彼らにモブプログラミングの概要と流れを説明します。
練習と模擬状況: 新メンバーがどのようにモブプログラミングを行うのかを理解するために、練習セッションや模擬状況を作成します。
快適な環境の確保: 新メンバーが快適に働ける環境を提供します。これには、適切なハードウェアとソフトウェア、十分な作業スペース、静かで集中できる環境などが含まれます。
オープンなコミュニケーション: 新メンバーが自由に質問や提案をできるよう、オープンなコミュニケーションを促します。既存のメンバーも新メンバーの意見や視点を尊重し、忍耐強くサポートします。
フィードバックの提供: 新メンバーがモブプログラミングのプロセスや動きに慣れるのを助けるために、定期的なフィードバックを提供します。また、新メンバーからもフィードバックを受け取ることで、彼らが直面している問題や改善のためのアイデアを理解できます。
チームビルディング: 新メンバーがチームの一部として受け入れられるように、チームビルディングの活動を行います。
モブプログラミングのアンチパターン
「エキスパート × ビギナー」の組み合わせ
エキスパートと初心者が一緒に作業する場合、いくつかの問題点が存在します
理解のギャップ: エキスパートと初心者の間には技術的な理解のギャップが存在します。エキスパートが持つ知識や経験を初心者がすぐに理解し、追いつくことは難しい場合があります。
進行速度の差: エキスパートは、より早く問題を解決できるかもしれませんが、初心者が追いつくのに時間がかかることがあります。これにより、全体の進行速度が遅くなる可能性があります。
意思決定の不平等: エキスパートの意見が優先され、初心者の意見が無視される可能性があります。これにより、初心者が参加意欲を失う恐れがあります。
これらに対する改善策としては以下のようなものが考えられます
ナビゲーターに徹する: エキスパートはナビゲーターに徹することでエキスパートがタイピングで暴走するのを防げます
相互教育: エキスパートは自分の知識を初心者に共有する役割を果たすべきです。逆に初心者の視点や疑問はエキスパートにとって新たな洞察をもたらすことがあります。
パティエンスと理解: モブプログラミングでは、全員が理解し、納得するまで進行しないことが重要です。エキスパートは、初心者が理解できるように説明する時間を持つ必要があります。
全員の意見を尊重: すべてのメンバーの意見を尊重し、共有することが大切です。初心者の視点や提案も有効であり、エキスパートも学ぶことができます。
サポートとフィードバック: エキスパートから初心者への定期的なフィードバックとサポートが重要です。これにより初心者は学習を加速し、エキスパートは教育的なスキルを向上させることができます。
[おまけ] 用語「strong style mobbing(ストロングスタイルモビング)」
"Strong-style"モブプログラミングは、一般的なモブプログラミングから派生した方法で、Woody Zuillによって提唱されました。通常のモブプログラミングとの最大の違いは、ナビゲーションのスタイルにあります。
通常のモブプログラミングでは、ドライバー（タイピスト）とナビゲーター（思考の指導者）がおり、ドライバーは自分の考えやアイデアもコードに反映できます。これは、ドライバーがナビゲーターの提案を聞きながらも、自身の判断に基づいて作業を進めることが可能であることを意味します。
一方、"Strong-style"モブプログラミングでは、「思考がなければ手を動かさない」という原則が採用されています。このスタイルでは、ドライバーは単にナビゲーターからの指示に従ってタイピングする役割を果たします。そのため、全てのアイデアや思考が明示的に言語化され、全員が共有しなければならないため、全員が同じ理解を持つことが強調されます。
また、"Strong-style"モブプログラミングでは、新しくアイデアを持った人がナビゲーターの役割を引き継ぐというルールもあります。これにより、アイデアや知識がチーム全体に共有され、全員が問題解決に参加することが奨励されます。
これらの差異からも分かるように、"Strong-style"モブプログラミングはより強く全体の共有と参加を重視しています。一方で、通常のモブプログラミングはドライバーの裁量も認めることで、より柔軟な進行が可能です。どちらのスタイルを選択するかは、チームの目的、個々のスキルレベル、問題の性質などによります。
リソース効率とフロー効率
概要
モブプログラミングと効率性の関係を理解するためには、"リソース効率"と"フロー効率"の二つの観点から考えることが重要です。
リソース効率は、リソース（この場合はプログラマー）が活動的に働いている時間の割合を指します。一般的には、個々のプログラマーが各自のタスクに集中している時間が長ければ長いほど、リソース効率は高くなります。
一方、フロー効率は、全体の作業流れのスムーズさを重視します。つまり、タスクが開始から終了までどれだけスムーズに進むか、タスクが待機状態にある時間が少なければ少ないほどフロー効率は高くなります。
モブプログラミングを採用すると、リソース効率の視点からは非効率的に見えるかもしれません。なぜなら、全員が同時に一つのタスクに集中するため、個々のプログラマーが各自のタスクに取り組む時間は減少します。
しかし、フロー効率の視点から見ると、モブプログラミングは非常に効率的なアプローチとなり得ます。全員が一つのタスクに集中するため、そのタスクは迅速に完了し、次のタスクに移行することができます。また、全員が同じコンテキストを共有しているため、コミュニケーションコストや誤解からくるリワークが減少します。
高速道路の例え
モブプログラミングとフロー効率、リソース効率を高速道路における車の流れに例えて考えると以下のように説明できます：
リソース効率は、高速道路上にいる車（リソース）がどれだけ走行しているか、つまり道路上にどれだけの車が存在し、それらが動いているかに相当します。これが高いということは、道路上に車が多く、かつそれらがみな走行しているということです。一見すると、車がたくさん走行していることは効率的に見えますが、それが逆に渋滞を引き起こし、全体の流れを阻害する可能性があります。
フロー効率は、一台の車が出発点から目的地までどれだけスムーズに進むことができるかに相当します。たとえば、道路に車が少なく、一台の車がスムーズに移動できる状況はフロー効率が高いと言えます。ただし、これは必ずしも道路を利用する全ての車（リソース）が動いているわけではないことを意味します。
モブプログラミングは、リソース効率の視点から見れば、高速道路に車が一台しかなく、その車が移動するのみという状況に似ています。つまり、一見するとリソース（車）が全体としてはあまり活用されていないように見えます。
しかし、フロー効率の視点からは、その一台の車がスムーズに高速道路を移動できることから、モブプログラミングは非常に効率的と言えます。複数の車（タスク）が一度に走行しようとすると、逆に渋滞（コンテキストスイッチやコミュニケーションの課題）が生じ、全体の流れ（タスクの進行）を遅らせる可能性があります。
リーン思考(特にWIP)との関係
モブプログラミングでは、チーム全体が一つのタスクに集中します。これは、WIPの観点から見ると、進行中の作業が一つに制限されることを意味します。この一つのタスクにチーム全員が集中することで、コンテキストスイッチングのコストが削減され、また問題が生じた場合も即座に対処できます。
これがフロー効率にどのように影響するかというと、WIPが少ないと、各タスクが開始から完了までスムーズに移動します。つまり、待ち時間が減少し、タスクのサイクル時間（開始から完了までの時間）が短縮されます。これにより、フロー効率が向上します。
一方、多くのタスクを並行して進めると、個々のタスクが完了するまでの時間は長くなりがちです。これは、各タスク間でのコンテキストスイッチング、問題の解決が遅れる、リソースの競合など、複数のタスクを同時に管理することの複雑さから来るものです。
[おまけ] 用語「ドレフェスモデル」
ドレフェスモデルは、スチュワート・ドレフェスとヒューバート・ドレフェスが提唱したスキル習得モデルで、人々が新しいスキルを学び、それを習熟する過程を表しています。このモデルは5段階で構成されています。
初級者(Stage 1: Novice):
スキルを初めて学びます。
明確なルールや手順に従って操作を行います。
コンテキストや抽象的な概念を理解するのは難しいです。
上級初級者(Stage 2: Advanced Beginner):
実際の経験を通じてスキルが改善します。
コンテキストによる差異を理解し始めますが、全体的な状況を判断するのは難しいです。
中級者(Stage 3: Competent):
より複雑なタスクを行うために必要なスキルを習得します。
問題を解決するためにどの情報が重要で、どのルールを適用すべきかを判断できます。
熟練者(Stage 4: Proficient):
経験を通じてスキルが洗練され、直感的な理解ができるようにな - ります。
状況全体を考慮し、以前の経験に基づいて問題を解決できます。
達人(Stage 5: Expert):
スキルが完全に内面化され、直感的かつ自動的に行動できます。
ルールやガイドラインを超えて、新しい解決策を見つけることができます。
この記事が気に入ったらサポートをしてみませんか？