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

はじめに

前回に引き続き、私のチームで実践している「メンバーが楽しく成長すること」を重視したペアプログラミングとモブプログラミング(以降、ペアプロ、モブプロ)のやり方を紹介します。

熟練者は発言を促す

熟練者と初級者の組み合わせなどでスキルに差がある場合に、スキルの低い側が開発に貢献する発言を思いつかず、あまりしゃべらなくなってしまう事があります。
そうならないようにするために、スキルの高い側がフォローします。
一例を以下に示します。

• 「ここはなぜXXXの処理が必要だと思います？」と理解度を確認するための質問をしたり、「ここはXXXとYYYの2つの選択肢があるけど、どっちが良いと思います？」と判断を委ねたりして、発言を促す

• 質問に答えた後に、「今、質問に答えるために説明したおかげで、なぜこの処理が必要なのか、自分でもはっきり理解できました、ありがとう」のように、相手の質問が自分の成長になったという事を伝える

• ソロでやると一人でもんもんと悩んでしまう場合があるが、人と話しながらやると問題が整理されて効率的に進められる旨を伝えて、話を聞いてもらうだけでも意味がある事を伝る

このように些細な発言でも貢献になるという認識を相手にもってもらい、発言のハードルを下げて、楽しくペアプロ・モブプロができるようにします。

積極的に質問する

逆に、スキルが低い側は、ペアプロ・モブプロを成長の機会と捉え、積極的に質問しましょう。
熟練者の設計の考え方、開発ツールの使い方など、様々な知見を得るチャンスです。
そして、能動的なアクションをして得た知見は記憶に残りやすいです。
例えば、以下のような理由を確認する質問は、とても効果的です。
「なぜXXXの処理をする必要があるのでしょうか？」
「YYYという実現方法もありますが、なぜZZZを選んだのでしょうか？」

また、このような質問は、回答した人にもメリットがあります。
つまり、質問に回答した人は「人に説明する」というアウトプットを通して成長できるのです。
技術記事を書いている人なら誰しも経験があると思いますが、「なんとなく分かっている事」を記事に書こうとするとなかなかできないものです。
「人に説明する」ためには、自分なりの解釈を言語化する必要があり、それを行う事でやっと、その対象について深く理解できます。
だから些細な思い付きの質問であっても、それを回答する事がきっかけで新たな学びを得られる事は多くあります。

要するに、質問する方もされる方も成長できるので、積極的に質問しましょう。

知識が少ない人こそドライバー

基本的にドライバーとナビゲーターは定期的に交代しますが、対象のドメインに対する知識や経験が少ない人は、優先的にドライバーになることを推奨します。

理由は、その状態でナビゲーターになると、理解が追いつかないまま作業が進んでしまう事があるからです。
ペアプロ・モブプロは、理解不足の人が理解して成長するという狙いもあるため、理解不足のまま進めてしまっては、その効果が半減してしまいます。

従って、知識が少ない人が優先してドライバーになり、理解していないと作業を進められない状況を作り、分からない所を質問しながら手を動かすことで着実に理解してもらいます。
この時、熟練者がドライバーをやるのと比較すると、一時的に開発速度は低下しますが、これは必要な時間です。
短期的には開発遅延というマイナス面があっても、チーム全体の開発速度が上がるほうが長期的には有益であるため、ナビゲーターは全力でドライバーの成長をサポートしましょう。

熟練者は自分の弱みを見せる

ペアプロ・モブプロの最中に分からない事があって質問したくても、「分からない」と発言するのは弱みを見せるように感じて、言うのをためらってしまう事があると思います。
「分からない」と発言するのは、意外と勇気が必要なのです。
「分からない」と安心して言えるように、チームの皆がお互いに気兼ねなく弱みを見せられる環境を作る事は重要です。

その点で、熟練者が自分の弱みを見せることは効果的です。
熟練者でも分からない事があると素直に弱みを見せてくれると分かれば、他のメンバーも「分からない」と発言しやすくなります。

発言することに価値があることを共有

ここからは、ペアプロ・モブプロを効果的に活用するために、事前に皆で理解しておくと良い事を紹介します。

会議や打ち合わせにおいて、気付いた事や思った事を発言するのは、チームにとって価値があるという認識を浸透させて発言のハードルを下げ、新人でも気軽に意見しやすい環境を作ることが大切です。
そのために、私のチームでは、日頃からメンバーが主体的に発言しやすくなる取り組みをしています。
詳細は、本連載の第2回『メンバー間で活発に議論する朝会にしよう』の以下の記事を参照ください。

ペアプロ・モブプロをやる方が良い時の兆候

ソロで進めた結果、次のような事が起きたなら、それはおそらくペアプロ・モブプロをやる方が良いです。

• 何件かの問題を解消するために多くの時間がかかったが、リーダーからすると「聞いてくれればすぐに解決できたのに」という問題だった

• 設計書やソースコードのレビューにて、そもそも設計方針が不適であるなど、レビュアーの想定と乖離した成果になっていた

• レビュー指摘の修正後にレビュアーが確認したところ、類似の問題が修正されていない、意図通りに直っていないなど差し戻しが多い

このような事態が起きるのは、そのタスクに対する考え方が理解しきれていないからかもしれないので、熟練者を含めてペアプロ・モブプロをして考え方を理解した方が良いと思います。

ソロのタスクも一時的にペアプロ・モブプロを活用

ソロでやると決めたタスクでも、一時的にペアプロ・モブプロをやる方が良い時があります。
例えば次のような時は、柔軟にペアプロ・モブプロを活用しましょう。

• タスクの開始時に、目的とゴールの認識を合わせ、どの方針で進めるかを決定した後、必要があれば最初の30分くらいペアプロをする。

• 難しい技術課題が見つかり、その技術課題を解決する時だけ、ペアプロ・モブプロをする。

レビューは別途行う

そのタスクのレビュアーが、ずっとペアプロ・モブプロにナビゲーターとして参加していたとしても、レビューは別途行います。

理由は、レビューで確認すべき観点と、ナビゲーターの時に確認すべき観点は、異なる点もあるからです。
例えば、プログラミングで既存のメソッドの挙動を変更した際に、そのメソッドを利用する全ての既存機能がデグレードしていないかという確認は、コードを書いた瞬間よりもレビュー時にまとめて行う方が効率的なので、私のチームはそうしています。

ただ、レビューとペアプロ・モブプロで、共通する確認観点もあるので、レビュアーがペアプロ・モブプロに参加していた場合、レビューは短時間で終わります。

ルールとして守るのでなく楽しくやる事が大切

今回の内容はルールではなく、あくまでお勧めのやり方です。
ルールとして守るのでなく、楽しくやるためのノウハウとして活用してもらいたいと思います。
ペアプロ・モブプロは、楽しく成長するために、とても有効な手段なので、この記事が少しでもその役に立てば幸いです。

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

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

前回の記事はこちら↓