技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った

Misoca開発チームの黒曜(@kokuyouwind)です。
先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。

流しの技術フェローに教わったペアプロのコツ

先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。
今回はkakutaniさんから教わった内容のまとめと、教わったことを意識してペアプロをして感じたことなどをまとめていきたいと思います。

f:id:kokuyouwind:20170215153602j:plain

スループットをあげるためのペアプロ

最初に、大事なこととして「ペアプロは監視やOJTではない」ということを強調されました。
つまり、片方が作業しているのを他方が監視しているだけ、あるいは学ぶために見ているだけではペアプロではない、ということです。

逆にペアプロの目的として、「スループットを上げること」が重要だという話をされました。
タスクは完了させてユーザーに届いてこそ価値があるので、2人で並行して作業し仕掛りを増やすよりも、1つずつのタスクを確実に完了させてスループットを上げていくべきです。
このために、ひとまとまりのコードを書き終えてからコードレビューに進むのではなく、書かれたコードを片っ端からコードレビューしていくことで、コードレビューでのコミュニケーションコストや手戻りを減らすためのプラクティスがペアプロだ、ということです。
他にも「一緒に作業していることで継続的に引き継ぎやTipsの共有がなされる」といった話もありましたが、個人的には継続的コードレビューという考え方が面白く、ペアプロの考え方が変わった気がします。

ペアプロの持ち物

f:id:kokuyouwind:20170216111210j:plain

ペアプロの際、以下のようなものを準備しておくと良いそうです。

水や飴

ペアプロ中はしゃべりっぱなしになります。これは非常に喉が乾くので、水などの飲み物や飴を用意し、いつでも喉を潤せるようにしておきます。

紙とペン

セッション開始時のやることリストを書いたり、考えを図で書いたりできるよう、紙とペンを用意しておきます。
これはさっと書き込めればiPadやWeb上のツールなどでも良いそうです。

デカいディスプレイ

大きめのディスプレイがあると、二人で一緒に画面を見やすくなります。

その他

1台のマシンを2人で使うと、場所の交代が面倒だったりキー配列の違いで思った通りに打てなかったりします。
こういった場合にScreenheroを使うと、それぞれのマウスとキーボードを使って同じ画面を操作できるため便利です。

また、今回は実践していませんが、ペアプロした際のコードのauthorがそのペアが共同で書いたことを明確にするために、専用の名前を用意するというプラクティスも紹介されました。 有名なものではCarlhudaやtomhuda、 kakutaniさんの身近な例ではursmhbryなどがあるそうです。

ペアプロの進め方

f:id:kokuyouwind:20170216111311j:plain

ペアプロの際、主に実装する方をドライバー(Driver)、もう一方をナビゲーター(Navigator)といいます。
基本はドライバーの実装作業をナビゲーターが見ながら適宜コメントをしていくことになりますが、以下のような点に気をつけたほうがよいと勧められました。

セッションでやることをリストにする

実装作業に入る前に、今回のセッションでやることをノートなどにまとめ、ドライバーとナビゲーターで合意します。
これにより、ドライバーとナビゲーターでゴールの認識を合わせることができ、また作業漏れも防ぐことができます。

ドライバーは「やろうとしていること」を話し続ける

ドライバーが実装する際には、「どういう意図でなにをしようとしているか」を話し続けます。
これをすることで、

  • ナビゲーターにどういう意図で作業をしているのかが伝わる
  • 実装が進む前にナビゲーターからよりよい方法の提案や懸念点の提示などができる

といった効果があります。 実際にやってみると、事前に想像していた以上に喉が乾きます。 ペアプロを体験した他のメンバーからも、「冗談抜きで、水、だいじ」という感想が寄せられました。

f:id:kakutani:20170217091447p:plain

操作権を頻繁に譲り合う

ナビゲーターがアドバイスをする際、typoの修正など簡単なもの以外では、なるべくドライバーがキーボードやマウスの操作権を譲ってあげるとよい、という指摘を受けました。
これは、指示を出して何かをしてもらうよりも直接操作したほうが早いのですが、「ナビゲーター側が操作権を要求する」よりも「ドライバー側から操作を譲る」ほうが心理的な抵抗感が少なく望ましい、という内容でした。
また同様に、ナビゲーターがドライバーの作業を止める際の合言葉を決めておくと、自分から割り込むことへの心理的障壁を下げられる、という話もされました。

ペアプロしてみた感想

ここまでの内容を意識して何度かセッションをしてみたところ、「ドライバーがやろうとしていることを話し続ける」というプラクティスで早めに軌道修正ができるようになり、手戻りが減って効率よく実装が進むようになりました。
まだきちんと計測できていませんが、主観としては手戻りや詰まることが減ったことで、チームとしての出力も上がっているのではないかと思います。

リモートでのペアプログラミングも試してみましたが、こちらもScreenheroでの画面共有を使ってスムーズに行うことができました。
ただしペアプロの画面だけを映してしまうと相手の顔が見えず、コミュニケーションが少ししづらい場面がありました。

このあたりは並行してGoogle hangoutsを映したり、Pragmatic Bookshelfの『Remote Pairing』を参考にしながら色々試してみたいと思います。

まとめ

ペアプロの際、今回紹介したことを意識しながらやると密度が非常にあがりました。

kakutaniさんのペアプロは、10年以上前に双人亭らい音師匠(@t_wada)から稽古をつけてもらった経験を基礎として独自研究を重ねたものだそうです。双人亭一門のkakutani流のペアプロ、オススメです。

ペアプロの他の流派の考えかたについては、結城浩さんのyukiwikiのペアプログラミングのやりかたの記事や、書籍では残念ながら現在は入手困難ですが『ペアプログラミング―エンジニアとしての指南書』を参考にすると良いそうです。

Misocaではペアプロでスループットを上げたいエンジニアを募集しています！

2/22に東京で行われる「名古屋ITベンチャーNight」へ行きますので、ペアプロの話やMisocaの話や技術書典2の話(おやおや?)をしたい方はぜひお越し下さい。