• Home
• コーポレートブログ
• ペアプロ・モブプロをやってみた話

今週のブログの担当、石川です。3月になり、いよいよ春だなあと思うのと同時に、花粉の恐怖を感じています。

今回のブログでは、社内でシステム開発をする中で行なっている、ペアプログラミングやモブプログラミングについて、実際にやってみて感じたことなどを書こうと思います。



ペアプロ、モブプロとは？？

ペアプログラミング

2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法。実際にキーボードを操作してコードを書く人を「ドライバー」、もう1人を「ナビゲーター」と呼び、ドライバーの書いたコードを横からレビューしていったり、改善案を出したりする。

モブプログラミング

ペアプログラミングと似ている。2人でなく、チーム全体(もしくは複数人)でプログラミングをすること。



モブプロ・ペアプロにトライした理由

出退勤管理システムを開発するプロジェクトの中で、システムの完成以外にチームメンバーの技術的成長を目標として挙げていました。今回はチームの中で知識・技術を共有するためにも、積極的にモブプロ・ペアプロをやってみることにしました。

実際にやってみて

ドライバー

• 入社したばかりの頃はペアプロをしても指示されたことを書くだけで、理解できないところを突っ込んで質問できなかった
  慣れてくると自分から手を動かしたり話し合いもできる様になってきた。
• スペルミスなどをしてもすぐに気づいてもらえるという安心感がある
• 一人でコードを書いている時よりも、コードの読みやすさ・綺麗さを意識することができる
  その場で人に読まれるコードなので、自分一人の時よりも綺麗に書くことをより意識できました。また、実際にその場で「〜〜〜した方がもっと読みやすくなって良いのでは？」というようなアドバイスをもらうこともでき、「綺麗なコード」という考え方を身につけやすかったような気がします。
• 画面をいかにオペレーターに見やすくするかというのが難しい
  複数人で一つの画面を見るので、「ちょっと見えないので大きくしてください」となることが何度かありました。文字を大きくしたり、Macのマグネット(Magnet マグネット)というアプリケーションなどを利用して適宜ウィンドウサイズを変えたりと、見やすい画面を作るように気をつけています。
• ドライバーは自分のパソコンを利用しないと環境の違いで疲れる
  以前社外の勉強会でペアプロをした時は、OSやキーバインド、エディターなどの違いに戸惑って、大変でした。

ナビゲーター

• 説明することにより理解が深まる
  「これはこういう理由でこう書いたほうがいいと思う」というように口に出して説明することで、より理解が深まることが多かったです。 物事を順序立てて説明するのがあまり上手ではないので、説明の練習にもなっています。
• どのタイミングで誤りを指摘するべきか難しい
  これをやろう、と言って実際にコードを書いている時に誤字などに突っ込むと流れを絶ってしまうということに最近気がつきました。 できるだけ作業や会話を止めないタイミングで指摘するように気をつけようとしています。
• 一気にいろんなことを言いすぎるとドライバーがパンクしてしまう
  「どのタイミングで誤りを指摘するべきか難しい」にも関連しますが、あれもこれもと言い過ぎてしまうとドライバーさんがいっぱいいっぱいになってしまいます。どこまで深く説明すべきか、という判断も少しずつ上手になっていけたらと思います。また、きついような言い方だとドライバーの気も滅入ってしまいそうなので、できる限り指摘の仕方には気をつけています。
• モブプログラミング(複数人)の時は、気づいたら置いていかれてしまうことも
  ペアプログラミングの時と違って複数人なので、一人が抜けていても成り立ちます。そのため、思ったことや疑問に思ったことはある程度口に出して、共有するようにしています。あえてメインの流れから外れて別のことについて調べておくというのも複数人であることの有効活用という感じで、良いと思います。
• 他の人の効率の良いコードの書き方やデバッグ方法などを見ることができる
• 作業の切り替えを忘れることが多かった
  作業の切り替えをしっかりと行わなければドライバーの人がとても疲れてしまうので、適度な休憩と交代は意識してやっていこうと思います。

その他

• チームの中で会話の機会が増え、問題意識などを共有しやすくなった
• チーム全体でやる場合、仕様を決めながらコードを書いたりすることができた
• 会話をしながら作業をしていくので、集中力が続きやすい
• 「やったー」と声を出してハイタッチは、社内だと照れ臭くて難しい

また、こんなこともありました。



挙げられたProbrem	ドライバーから操作(マウス)を奪ってしまうことがしばしば…
それに対するTry	マウスを遠ざけるという荒療治

「ちょっと貸して」が必ずしも悪いわけではない(むしろ言葉で伝えにくい時は実際に動かした方が早い)とは思いますが、頻度が高かったのでこのように対策をしました。



こうして、実際に複数人で作業をしてみて、課題だと感じた点は改善しながらプロジェクトを進めています。

一緒にペアプロなどを行なった社員の感想も聞いて見たところ、「色んなプログラムの書き方を学べる」「不安な部分を確認しながら進められる(聞きやすい)」とのことでした。ただ、ナビゲーターから「ああ書いて、こう書いて」と指示を受けながらコードを書く場合は、その時点ではどういう動きをするのかわからないまま書いてしまうこともあったとのことで、もう少しナビゲーターの誘導の仕方も考えなければと思いました。

各々がコードを書くよりは書ける量も少ないとは思いますが、全員の同意を伴って進むことで手戻りが少なくなったり、ある程度のレビューはその時点で済ませられたりという点もあるのでそこまで大きな違いはないような気がしています。また、その分コードのクオリティが高くなったり、効率よくコーディングを学べたりといった良い点がそれを補って余るほどにあると感じています。

人の書いたコードを本人もしくは別の人に説明する

話が逸れてしまうのですが、ペアプロ・モブプロ以外にも、プロジェクトの中で「人の書いたコード(プルリクエスト)を本人もしくは別の人に説明する」ということも試して見ました。

説明する側

• 面白かったのが、プルリクエストを確認して「良いと思います！」とコメントした後なのに、それを声に出して説明してみると「何でこうなってるんだろう？」と疑問がポンポンとでてくること。
• 「人の書いたコード」から「自分たちのコード」という気持ちになってくる
• コードリーディングについてアドバイスがもらえる(「こうやってコードを追っていくとわかりやすい」等)
• 間違った捉え方をしている時には本人からすぐに訂正が入る(勘違いしたままにならずに済む)

説明される側(書いた側)

• この書き方って人から見るとわかりづらいんだな、ということがわかる
• 1からコードを読み直せる
• しっかりと伝えられていなかった実装の意図なども共有できる

これも結構面白かったので、今度またやって見たいと思っています。

今後



• 少し前に話題になったteletypeやVisual Studio Live Shareなどを使ってリアルタイムで同時コーディングしてみたい(どんな感じになるのか興味があります)
• ペアプロ・モブプロをもう少し勉強して、より良い形で開発を進めたい
• もう少し大人数のモブプログラミングを経験してみたい

今後も開発の中で様々なことに挑戦して、より良い形で開発を進めていきたいです。