この記事の初出は、Software Design 2023年6月号です。

はじめに

前回と前々回でペアプログラミング(以下、ペアプロ)とモブプログラミング(以下、モブプロ)の魅力を伝えてきました。
そこで今回は、私のチームでのペアプロ・モブプロのやり方を紹介します。
執筆時点での私のペアプロ・モブプロ歴は4年です。

今回紹介するノウハウの特徴は「メンバーが楽しく成長する事」を重視している点です。
ペアプロ・モブプロは、楽しく成長するために有効な手段なので、本稿が少しでもその役に立てば幸いです。

なお、ペアプロとモププロは異なる特性がありますが、この記事では共通のノウハウを説明する便宜上、まとめています。
用語について、本稿ではキーボードを操作する人を「ドライバー」、それ以外の人を「ナビゲーター」と記します。

ペアプロ・モブプロをするタイミング

まず、ペアプロ・モブプロをどういうタスクや進め方でやるかのノウハウをいくつか紹介します。

前提として、1人でタスクを進める事を私のチームでは「ソロ」と呼んでいます。
ソロでやるか、ペアプロ・モブプロでやるかは、タスクの内容に合わせて決めます。
そのために、全員がペアプロ・モブプロに適したタスクとそうでないタスクの特性をよく理解しておく事が必要です。

重要な特性は、ペアプロ・モブプロは「対応方針が複数あり、手戻りが発生しやすいタスク」に効果が高い事です。
逆に、「対応方針が決まっており、手戻りがあまり発生しない作業的なタスク」には不向きです。

上記の特性からペアプロ・モブプロは、プログラミングだけでなく、プロジェクトの計画を作成したり、報告資料を作ったりなど、様々なタスクで効果的なため、幅広く活用します。

ちなみに、私のチームでは朝会で、どのタスクをペアプロ・モブプロするのか、誰が参加してやるのかを決めることが多いです。
その後、予定より早くタスクが終わった場合は、柔軟に次のタスクをソロでやるかペアプロ・モブプロでやるかを判断して進めます。

モブプロの人数

モブプロは、3人～4人でやることが多いです。
人数が多くなるほど、一人当たりの発言機会が減り、それが一定以下になると楽しさが少しずつ減る傾向を感じました。
経験的には5人くらいで、その傾向が出始めたので、私のチームでは4人以下を推奨しています(ここはチームの特性により変わると思います)。
例外として、メンバー間での知識共有や育成を主目的としてモブプロをする場合は、5人以上でも実施します。

リモートと出社が混在の場合

モブプロ時に、1人でもリモートワークで参加なら、参加者全員が個別のマシンで参加します。
よくないのは、出社していて近くの席にいるメンバー同士で盛り上がって、リモートワークで参加している人が疎外感を受ける事です。

なお、これは、モブプロだけでなく、他のすべての会議にも言える事です。
そのため、私のチームでは、基本的に出社していても会議には個別のマシンから参加しています。

ペアプロ・モブプロの出入り

ペアプロ・モブプロでやることになったタスクを進める際に、そのタスクが完了まで何時間もかかるタスクであれば、他の会議の都合などで全員がそろわない時間帯が発生することはよくあります。その場合は、都合がつく人だけで進めます。
例えば、3人でモブプロするタスクについて、最初は3人でモブプロを始めて、途中で2人が抜けている間は1人でそのタスクを進め、2人が帰ってきたら、その間の進捗を共有してから3人でモブプロを再開します。

開始時にタスクの認識合わせ

ここからは、ペアプロ・モブプロの実施中のノウハウを紹介します。

ペアプロ・モブプロ開始時に、参加者全員で以下を共有することが大切です。

• タスクの目的・ゴール

• 残りの作業と進める順序

特に、目的・ゴールの共有は重要です。
例えば、タスクの目的が「試作を作って顧客にデモしてフィードバックを得る事」と思っている人と「リリースするために不具合のないプログラムを作る事」と思っている人では、作業の進め方の考え方が異なります。
それが異なると、議論に無駄な時間がかかります。
残りの作業と進める順序の共有については、これからどういう進め方をするのか、皆で見通しを立てるために行います。
人は見通しが立たない状況下では不安になりやすいため、見通しを立てた方が気持ちよく進められます。

とにかく考えている事を話す

ペアプロ・モブプロに慣れていないうちは、ナビゲーターがどう指示すべきか詰まった時などに、黙ってしまう事があります。
そうなるとドライバーは、何に悩んでいるか分からず指示待ちになってしまうため、そうならないように、自分が何に悩んでどう考えているかを話しましょう。

悩んでいる内容を話せば、それが皆に共有され、議論して結論を出せます。
一人の頭の中で考えるより、人に説明して問題を言語化した方が、問題が整理される上に、他の人からの意見ももらえるので効率的ですし、黙って考えるより楽しいです。

また、熟練者の場合は、どう考えてどう判断するのか、その思考プロセスが言語化される事は、それを聞いている他メンバーの学びになります。そのため、結論だけでなくその導出過程の考えを話す事は大きな価値があります。

判断の理由を必ず言語化する

複数の選択肢の中から、1つを選ぶという判断をした場合、なぜその判断をしたのか、必ず言語化します。
理由は、その判断が妥当かどうかを皆で確認するためと、メンバーの成長のためです。
メンバーの成長については、以下に詳細を説明します。

開発経験の少ないメンバーがソロで作業した場合の手戻り原因の1つは「なんとなく判断してしまう」ことです(「どうしてそうしたの？」と聞くと「なんとなくです」と答えが返ってくる状況のことですね)。
例えば、ソロでやる時に以下の内容をなんとなく判断した結果、レビューで手戻ることが過去に何度もありました。

• クラスおよびメソッドの分割方針

• クラス、メソッド、プロパティなどの命名

• メソッド内の処理順序、処理内容

• 技術課題の解決方法

この「なんとなく判断してしまう」という問題は、ペアプロ・モブプロで「判断の理由を必ず言語化する」を徹底する事で解消されます。
「ここはXXXの理由で、YYYを使いましょう」のように判断の理由と共に指摘することを、ペアプロ・モブプロの習慣として浸透させることで、皆が自ら判断理由を述べるようになります。
そういうペアプロ・モブプロを何度も経験すると、ソロで作業する時に「なんとなく判断してしまう」という事は無くなります。

達成できた時は喜ぶ

ペアプロ・モブプロをやる意義として、一番大きいのは「楽しい事」です。
楽しいと凄く集中して効率が上がるため、楽しい事はとても重要です。
プログラムで動くものができた時など、何かの達成時には「やったー！」と皆で喜びましょう。

ドライバーの交代タイミング

これはチームの特性によって適切なタイミングは異なると思いますが、私のチームでは1時間くらいで10分の休憩を取り、そのタイミングでのドライバー交代を推奨しています。
もっと頻繁にドライバー交代する方法を試した事もありますが、集中している時に交代が入るのが水を差すように感じて、私のチームには合いませんでした。

続きは次回に

他にも、ペアプロ・モブプロ実施中にどんな発言をすると良いかのノウハウや、事前にチーム全員が理解しておくと良い事があるので、それらを次回に紹介します。

はてなブックマークへの登録はこちらです

連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓