1. はじめに
本稿は、ペアプログラミングとモブプログラミング（以降、ペアプロ・モブプロと表記）について、私のチームでのガイドラインを紹介します。執筆時点でのペアプロ・モブプロ歴は4年です。
私のチームは若手が多く、「ハピネスチームビルディング」という皆が主体的に楽しく成長しながら開発するという取り組みをしているため、「メンバーが楽しく成長する事」を重視している点が、普通のやり方と少し異なります。
ハピネスチームビルディングの詳細は、ITエンジニア向け月刊誌「Software Design」で連載してますので、そのWeb公開版の以下を参照ください。
ハピネスチームビルディング連載記事一覧
ペアプロ・モブプロは、楽しく成長するために、とても有効な手段なので、この記事が少しでもその役に立てば幸いです。
なお、ペアプロとモププロは異なる特性がありますが、この記事では共通のガイドラインを説明する便宜上、まとめています。用語について、キーボードを操作する人を「ドライバー」、それ以外の人を「ナビゲーター」と呼びます。
2. ペアプロ・モブプロ実施前のガイド
2.1 ペアプロ・モブプロをするタイミング
前提として、ペアプロ・モブプロに対して、1人で進める事を「ソロ」と呼んでいます。
ソロでやるか、ペアプロ・モブプロでやるかは、仕事に合わせて決めます。
そのために、全員がペアプロ・モブプロに適したタスクとそうでないタスクの特性をよく理解しておく事が必要です。
重要な特性は、ペアプロ・モブプロは「対応方針が複数あり、手戻りが発生しやすいタスク」に効果が高い事です。逆に、「対応方針が決まっており、手戻りがあまり発生しない作業的なタスク」には不向きです。
詳細は以下の記事を参照ください。
ペアプロ・モブプロでメンバーが驚くほど成長した話
上記の特性からペアプロ・モブプロは、プログラミングだけでなく、プロジェクトの計画を作成したり、報告資料を作ったりなど、様々なタスクで効果的なので、そういうタスクで幅広く活用します。
（プログラミングに限定したタスクではないため、厳密には ペアワーク・モブワーク と呼ぶのが適切かもしれませんが、本稿では以降もペアプロ・モブプロと呼びます）
ちなみに、私のチームでは朝会で、誰がどのタスクをペアプロ・モブプロするのか決める事が多いです。その後、予定より早くタスクが終わった場合は、柔軟に次のタスクをソロでやるかペアプロ・モブプロでやるかを判断して進めます。
2.2 ペアプロ・モブプロの出入り
ペアプロ・モブプロでやるとなったタスクに対して、他の会議の都合などで全員が揃わない時間はよくあります。その場合は、都合がつく人だけで進めます。
例えば、3人でモブプロするタスクについて、最初は3人でモブプロを始めて、途中で2人が抜けている間は1人でそのタスクを進め、2人が帰ってきたら、その間の進捗を共有して3人でモブプロを再開する、という感じです。
2.3 オフラインとオンライン混在の場合
モブプロ時に、1人でもオンライン参加なら、参加者全員が個別のマシンで参加します。
よくないのは、オフラインで近くにいるメンバー同士で盛り上がって、オンラインで参加している人が疎外感を受ける事です。
なお、これは、モブプロだけでなく、他のすべての会議にも言える事です。
そのため、私のチームでは、基本的にオフライン時でも参加者は個別のマシンで会議に参加しています。
2.4 モブプロの人数
モブプロは、3人～4人を推奨します。
(育成が主目的の場合はそれ以上の人数でもやります)
人数が多くなるほど、一人当たりの発言割合が減り、それが一定以下になると楽しさが少しずつ減る傾向があります。
経験的には5人くらいで、その傾向が出始めたので、4人以下を推奨としています。
3. ペアプロ・モブプロ実施中のガイド
3.1 開始時にタスクの認識合わせ
ペアプロ・モブプロ開始時に、参加者全員で以下を共有します。
- タスクの目的・ゴール
- 残りの作業と進める順序
特に、目的・ゴールの共有は重要です。例えば、タスクの目的が「試作を作って顧客にデモしてフィードバックを得る事」と思っている人と「リリースするために不具合のないプログラムを作る事」と思っている人では、作業の優先順などの考え方が大きく異なります。そのため、これがずれていると、議論に無駄な時間がかかります。
残りの作業と進める順序の共有については、これからどういう進め方をするのか、皆で見通しを立てるために行います。人は見通しが立たない状況下では不安になりやすいので、精神衛生上も見通しを立てた方が気持ちよく進められます。
3.2 指示が出来なくても考えている事を話す
ペアプロ・モブプロに慣れていないうちは、ナビゲーターがどう指示すべきか詰まった時などに、黙ってしまう事があります。
そうなるとドライバーは、何に悩んでいるか分からず指示待ちになってしまうので、そうならないように、自分が何に悩んでどう考えているかを話しましょう。
悩んでいる内容を話せば、それを共有して皆で議論して結論を出す事ができます。
一人の頭の中で考えるより、人に説明して問題を言語化した方が、問題が整理される上に、他の人からの意見ももらえるので効率的ですし、黙って考えるより楽しいです。
また、熟練者の場合は、どう考えてどう判断するのか、その思考プロセスが言語化される事は、それを聞いている他メンバーに大きな学びになるので、メンバーの成長という意味でも価値があります。
3.3 判断の理由を必ず言語化する
複数の選択肢の中から、1つを選ぶという判断をした場合、なぜその判断をしたのか、必ず言語化します。
理由は、その判断が妥当かどうかを皆で確認するためと、メンバーの成長のためです。
メンバーの成長については、以下に詳細を説明します。
開発経験の少ないメンバーがソロで作業した場合の手戻り原因の1つは「なんとなく判断してしまう」です。
「どうしてそうしたの？」と聞くと「なんとなくです」と答える状況のことです。
例えば、ソロでやる時に以下の内容をなんとなく判断した結果、レビューで手戻ることが過去に何度もありました。
- クラスおよびメソッドの分割方針
- クラス、メソッド、プロパティなどの命名
- メソッド内の処理順序、処理内容
- 技術課題の解決方法
この「なんとなく判断してしまう」という問題は、ペアプロ・モブプロで「判断の理由を必ず言語化する」を徹底する事で解消されます。
「ここはXXXの理由で、YYYを使いましょう」のように判断の理由を必ず言語化することを、ペアプロ・モブプロの習慣として浸透させる事で、皆が判断理由の言語化をやるようになります。
そういうペアプロ・モブプロを何度も経験すると、ソロで作業する時に「なんとなく判断してしまう」という事は無くなります。
3.4 コーチングプログラミング
ペアプロ・モブプロをやる際に、熟練者と初級者の組み合わせのように、技術的にアドバンテージを持つ人とそうでない人が組むことは多いです。
その際には、「育成」も重要になります。
そこで私のチームでは、答えを教えるのでなく質問する事で、自分なりに考えて自分で答えにたどり着いてもらう方法として「コーチングプログラミング」と名付けた方法を実践しています(名前にプログラミングと付いていますが、プログラミング以外にも仕様検討や計画検討など、様々なシーンで活用します)。
私はこれまで十数人の若手育成の経験がありますが、コーチングプログラミングをやらない時と比べてやった時の方が成長速度が格段に速いと感じています。
そしてなにより、メンバーが「質問をもとに自分でひらめいて答えにたどり着くと、達成感があって楽しい」と言っているので、楽しく開発する上でも良い効果があります。
詳しい実施手順は以下を参照ください。
3.5 スキルの高い側は発言を促す
熟練者と初級者の組み合わせのようにスキルに差がある場合に、スキルの低い側の人が開発に貢献する発言を思いつかず、あまりしゃべらなくなってしまう事があります。
そうならないようにするために、スキルの高い側がフォローします。
具体例を以下に示します。
- 「ここはなぜXXXの処理が必要か分かる？」と理解度を確認するための質問をしたり、「ここはXXXとYYYの2つの選択肢があるけど、どっちが良いと思う？」と判断を委ねたりして、発言を促します。
- 回答してもらった後に「その通り！バッチリ！」などのポジティブフィードバックを繰り返します。
- 分からない事を質問されて回答した後に、「今、質問に回答するために説明したおかげで、なぜこの処理が必要なのか、自分でもはっきり理解できたよ、ありがとう」のように、相手の質問が自分の成長になったという事を伝えます。
- ソロでやると「あーでもない、こーでもない」と考えがまとまりにくいけど、人に説明しながら進めた方が最適な手順で効率的に進められている旨を伝えます。
上記は一例ですが、このように些細な発言でも貢献できているという認識を相手にもってもらい、発言のハードルを下げて、楽しくペアプロ・モブプロができるようにします。
3.6 スキルの低い側は積極的に質問する
逆に、スキルが低い側の人は、ペアプロ・モブプロを成長の機会と捉え、積極的に質問しましょう。
エレガントなコーディングや設計の考え方、開発ツールの使い方にいたるまで、自分よりスキルの高い人から様々な知見を自分のものにできるチャンスです。
「質問する」という能動的なアクションを行って得た知見の方が記憶に残りやすいので、質問した方がより成長できます。
例えば、以下のような理由を確認する質問は、とても効果的です。
「なぜXXXの処理をする必要があるのでしょうか？」
「YYYという実現方法もあると思うのですが、なぜZZZの方法を選んだのでしょうか？」
また、上記のような質問は、回答した人にもメリットがあります。
質問に回答した人は「人に説明する」というアウトプットを通して成長できます。
技術記事を書いている人なら誰しも経験があると思いますが、「なんとなく分かっている事」を記事に書こうとするとなかなかできない事があります。記事に書くなどで「人に説明する」ためには、自分なりに解釈した言語化が必要で、それを行う事でやっと、その対象について深く理解できます。些細な思い付きの質問であっても、それを回答する事がきっかけで新たな学びを得られる事は多くあります。質問が成長を促進しているのです。
つまり、質問する方も質問される方も成長できるので、積極的に質問しましょう。
3.7 達成できた時は喜ぶ
ペアプロ・モブプロをやる意義として、一番大きいのは「楽しい事」です。
楽しいと凄く集中して効率が上がるので、楽しい事はとても重要です。
プログラムで動くものができた時など、何かの達成時には「やったー！」と皆で喜びましょう。
楽しくモブプロをやる時の会話例は、以下の記事を参照ください。
3.8 ドライバーの交代タイミング
1時間ごとに10分の休憩を取る事を推奨し、そのタイミングでのドライバー交代を推奨します。
(もっと頻繁にドライバー交代をする方法を試した事もありますが、集中してノっている時に交代する事が多く、私のチームメンバーには頻繁に交代する方法は合いませんでした)
なお、休憩タイミングを決めておかないと、集中し過ぎて2時間くらい続けてしまうことがあります。時々ならまだしも、それが続くのは、しんどいので適度に休憩しましょう。
(ちなみに私のチームでは1時間ごとに10分の休憩を推奨していますが、実際に取る休憩の頻度はそれより少ないです)
3.9 知識が少ない人が優先してドライバーになる
基本的にドライバーとナビゲーターは交代しながらやりますが、経験が乏しかったり対象のドメインに対する知識が少ない人は、優先的にドライバーになることを推奨します。
理由は、そういう状態でナビゲーターになると、分かった気になって作業が進んでしまう事があるからです。ペアプロ・モブプロは、分かっていない人が分かるように成長するという効果と狙いがあるため、分かった気になって、実はよく分かっていなかったとなると、その効果が半減してしまいます。
だから、知識が少ない人が優先してドライバーになることで、理解していないと作業を進めることができない状況を作り、分からない所を質問しながら手を動かすことで着実に理解してもらいます。
この時、熟練者がドライバーをやるのと比較すると、一時的に開発速度は低下しますが、これは必要な時間です。
刹那的な開発速度よりも、長期的にチーム全体の開発速度が上がった方が有益であるため、ナビゲーターは全力でドライバーの成長をサポートしましょう。
4. ペアプロ・モブプロを効果的に活用するために皆で理解しておく事
4.1 発言する事がチームにとって価値があると理解する
会議や打ち合わせにおいて、気付いた事や思った事を発言する事は、チームにとって価値があるという事を浸透させて発言のハードルを下げ、新人でも気軽に意見が言える環境を作ることが大切です。
そのために、日頃から、私のチームでは、メンバーが活発に議論できるような取り組みをしています。
詳細は以下を参照ください。
4.2 レビューで大量の指摘が出る原因はレビューアにもあると理解する
レビューで大量の指摘が発生し、その指摘修正で大きな手戻りがある場合、その原因はレビューアにもあるという共通認識をチームで持ちます。
その上で、自分がレビューアをする場合に、レビューイ(成果を作る担当者)の経験が不十分ならペアプロで考え方を身に着けてもらうなどのフォローをします。
(成果が出来上がるまでレビューアが何もフォローせず、レビューで指摘がたくさん出たらレビューイの責任とするのは良くないので、そのようにならないように気を付けるということです)
詳細は以下の記事を参照ください。
4.3 ペアプロ・モブプロをやった方が良い時の兆候
ソロで作業を進めた結果、次のような事が起きた場合は、おそらくペアプロ・モブプロをやった方が良い兆候と言えます。
- 何件もの問題にハマって、それを解消するために多くの時間がかかったが、リーダーからするとそれは聞いてくれればすぐに解決できたのにという問題だった
- 設計やソースコードのレビューにて、そもそも設計方針が不適であるなど、レビューアの想定と大きくずれた成果になっていた
- レビューの指摘を修正し、レビューアが確認した結果、類似の問題が横展開して修正されていないとか、意図通りに直っていないなどの差し戻しが多い
これが起きるという事は、おそらく、その作業に対する考え方の理解が足りない可能性があるので、熟練者を含めてペアプロ・モブプロすることで、それを理解する事を推奨します。
4.4 ソロのタスクも一時的にペアプロ・モブプロを活用
ソロでやると決まったタスクであっても、一時的にペアプロ・モブプロをやった方が良い時はあります。その際には、柔軟にペアプロ・モブプロを活用しましょう。
以下はその例です。
- タスクの開始時。そのタスクの目的とゴールの認識を合わせ、どの方針で進めるかを決定し、必要あれば最初の30分くらいペアプロする。
- 難しい技術課題が見つかった時。その技術課題を解決する時だけ、ペアプロ・モブプロする。
4.5 レビューは別途行う
ペアプロ・モブプロでプログラミングしたコードであっても、レビューは別途行います。
そのタスクのレビューアが、ずっとペアプロ・モブプロにナビゲーターとして参加していたとしても同様です。
理由は、レビューで確認すべき観点と、ナビゲーターの時に確認すべき観点は、異なる点もあるからです。
例えば、プログラミングで既存のメソッドの挙動を変更した際に、そのメソッドを利用する全ての既存機能がデグレードしていないかという確認は、コードを書いた瞬間でなく、プルリクエストを送る前のレビュー時にまとめて確認した方が効率的なので、そうしています。
ただ、レビューとペアプロ・モブプロで、共通の確認観点もあるので、レビューアがペアプロ・モブプロに参加していた場合、レビューは短時間で終わります。
4.6 熟練者は自分の弱みを見せる
ペアプロ・モブプロの最中に分からない事があって質問したくても、「分からない」と発言する事は弱みを見せるように感じて、言うのをためらってしまう事があると思います。
「分からない」と発言するためには、意外と勇気が必要なのです。
そのため 「分からない」と安心して言えるように、チームの皆がお互いに気兼ねなく弱みを見せられる環境を作る事は重要です。
その点で、チームの中での熟練者が自分の弱みを見せることは効果的です。
熟練者であっても分からない事があるなどで自分の弱みを見せてくれると分かれば、他のメンバーも「分からない」という発言がしやすくなります。
4.7 厳密なルールに従うのでなく楽しくやる事が大切
ここまでの内容はルールではなく「そうした方がいい」という推奨事項です。
また、「そうしない方がいい」という行動を制限するようなルールがあると窮屈に感じて「楽しくやる」という点がおそろかになるため、あえてガイドに入れていない事がいくつかあります。
例えば、「ドライバーはナビゲーターの指示に従い、自分の意思で勝手に動かない」というやり方もありますが、それは私のチームではやっていません。
理由は、ドライバーが何か思いついた時に「あっ、思いついたんだけど、こんな感じにするのはどう？」と言って、自分の意思で勝手に動いた方が楽しいからです。
他にも、「ナビゲーターは、ドライバーの間違いに気づいても、自分で気付くまで数秒待つ」や「ナビゲーターは細かい指示を出しすぎない」というやり方もありますが、私のチームではどちらもやっていません。
理由は、発言を制限するよりも、自由に発言できた方が楽しいからです。
5. ペアプロ・モブプロ環境
私のチームでは、以下の環境で実施します(基本はリモート環境で実施します)。
- ZoomでカメラをONにして画面共有する
- ナビゲーターは共有画面に対して、Zoomの注釈ツールで画面に書き込んで指示する
- 各自が2台以上のディスプレイを用意し、ナビゲーターは共有された画面を見ながら、作業中の課題について自分の手元でも調べられるようにする
- 1日の中で会議やペアプロ・モブプロの比重が多いので、疲労軽減のためにスピーカーフォンを推奨する
- 利用するZoomのURLを固定にして、メンバーの出入りが容易にできるようにする
リモートワーク環境については、皆で楽しくできるようにするために、他にも取り組んでいる事が色々あるので、詳細は以下の記事を参照ください。
まとめ
ペアプロ・モブプロは、楽しく成長するために、とても有効な手段なので、この記事が少しでもその役に立てば幸いです。
私は、エンジニアリングマネージャーとして「ハピネスチームビルディング」というテーマで、チームの皆で主体的に楽しく成長するための知見を毎月発信しています。
この記事と同時に、毎朝15分の勉強会で若手の行動が驚くほど改善した話の記事も公開したので、合わせて読んでもらえると嬉しいです。
Twitterでも役立つ情報を発信していますのでフォローしてくれると嬉しいです → @kojimadev