今年で3回目となるラクスのアドベントカレンダー
ですが、とうとうトップバッターから解放されて気楽な7番手に収まりました。とある方面からはクレームがきそうですが 😜
はじめに
今年は新メンバーが加わった開発チームをスケールさせるために、大阪の楽楽精算開発チームではモブプロやペアプロに積極的に取り組んできました。
技術スキルだけでは足りない業務知識の理解や、明文化しきれていない開発ルールなど暗黙知の共有、意思決定やフィードバックループの短縮など、メリットとしてよく言われる様々な効果を体感することができました。モブプロの取り組みについては、先日のMeetupでもお話ししたので、もし興味があればそちらの資料を参照してください。
今日はどちらかというとペアプロを進める中で、当初想定していなかったにも関わらず、回を重ねるごとにメンバーの間で話に挙がるようになった「過程を見える化できる」メリットについてまとめます。モブプロでも同様の効果があると思いますが、自分のチームではペアプロ中にそういった意見が多かったため、ここではペアプロを前提としています 
実務的な側面
GitHub（ラクスではGitLab）とプルリクエストのおかげでコード、あるいはコードを中心とした周辺の成果物をレビューすることが当たり前になりました。しかし、中にはレビューしづらいものもあります。
- コードのconflictを解決してmasterにpushしたいが、レビューアーにはどこがconflictしてどう直したのかが分からない
- 新しいライブラリの調査結果を受けて導入可否を決定したいが、完成したサンプルコードからはハマりどころや使い心地が分かりづらい
- セキュリティテストの対象となる画面を修正の影響がある画面だけに絞り込みたいが、レビューアーにはどういう判断でどの画面を選択したか（選択肢しなかったか）が分からない
これらはいずれも結果だけをレビューするのが難しい類のタスクです。レビューできるようにするために、レビューイーはどういう根拠でどこをどう判断したかを細かくプルリクエストに記載することになります。あるいは、レビューアーが同じ作業をもう1度繰り返して結果を付き合わせる、といった本末転倒なことになりがちです。
しかし、もしペアプロをしていれば、最初から最後まで判断や修正の過程を2人の目で確認しながら進めることができます。conflictをどう解決したか、新しいライブラリを試すときにどこでつまったのか、そのすべての過程をレビューアーも体験しているので、改めてプルリクエストをレビューする必要がありません。レビューイーも長い時間をかけて、思考の過程を文書化する必要がないのです。
よく費用対効果のコンテキストでペアプロどうなの？という話になると、意思決定の速さや後戻りが減ること、学びの多さでペイできる／いやできない、みたいな議論になりがちですが、そもそもペアプロでないと逆に難しいタスクがあると気付けたのは大きな収穫でした。
教育的な側面
立場上、若手1メンバーに仕事をお願いしたり、仕事の内容で相談を受けたりすることが多くなりました。しかし、次のような難しさを感じています。
- 今ハマっている問題について解決方法をアドバイスすることはできるが、どうしてそのような状況になったのかまでは分かりづらい
- 期待していたものと違うアウトプットについて指摘することはできるが、いつから方向がずれていったのかまでは分かりづらい
- バグの切り分け方法やユニットテストの書き方を教えることはできるが、いざ自分の問題に適用してもらおうと思うとうまくできない
ペアプロをしていて気付いたのは、これらもやはり結果だけを見ていて、過程を見ることができていないからだということでした。
一緒にペアプロをしていれば、いつ何を考えてどのような方針で進めようとしていたのか、どのタイミングでの判断がまずくてつまずいたのか、という過程が見えるようになり、後からアドバイスするよりも的確なアドバイスをすることができます。また、単に考え方や手法を教えるのではなく、今実際に取り組んでいる問題に対してどう適用するかをより具体的に伝えることができます。
あとから「こういうふうに考えればよかったね」とか「こういう手法もあるよ」と教えるのではなく、今まさに「こっちに進もうとしているけど、こういう理由でこっちに進んだ方がいいよ」とか「ここではこういうふうに考えるとこの手法が使えるよ」とか、よりコンテキストを合わせて説明できるのです。
まとめ
われわれのソフトウェア開発は、いつの間にか分業を前提としていて、出来上がった結果だけをレビューしたり、結果だけから課題を想像してアドバイスしたり、ということが当たり前になっています。
しかし、実際にはその結果にいたるまでの連続的な "過程" こそが重要な場合があり、頑張ってあとから過程を説明するよりも、最初からペアプロで過程を見える化し、共有してしまった方が何倍も効果的な場合があると感じます。
もっとペアプロしていこう。
補足
どこかで聞いたことがあるなと思ったら、 @t_wada さんが同じようなことをすでに仰っていました。コンテキストが若干違いますが、結果よりも過程に価値を置いているという点で言わんとすることは同じだと思います。さすが先人の知恵は偉大です。
「結果」ではなく「過程」がリアルタイムに見れるからなのかな、と考えています。書籍やコードレビューで結果としてのコードは見えます。が、その前には設計判断や枝刈りが行われていて、それらをなぜ行い、いつ判断し、どんなテンポや順番でコードを書くかは見えません。
— Takuto Wada (@t_wada) February 3, 2017
書かれたコードだけでなく、書かなかったコードや、なぜそれを残さなかったかにも学びがあるんですよね。それらはペアプロのセッションでは全て見えますが、コミット時にはコメントに残れば良い方で、テンポや順番は既に失われています。
— Takuto Wada (@t_wada) February 3, 2017
明日は @RyoheiAdachi です。意外性があるからどんな記事がくるか全然読めない…
-
年齢が若いというよりは経験が浅いという意味で使っています。 ↩