Help us understand the problem. What is going on with this article?

ペアプロで "過程" を見える化する

More than 1 year has passed since last update.

今年で3回目となるラクスのアドベントカレンダー :christmas_tree: ですが、とうとうトップバッターから解放されて気楽な7番手に収まりました。とある方面からはクレームがきそうですが 😜

はじめに

今年は新メンバーが加わった開発チームをスケールさせるために、大阪の楽楽精算開発チームではモブプロやペアプロに積極的に取り組んできました。

技術スキルだけでは足りない業務知識の理解や、明文化しきれていない開発ルールなど暗黙知の共有、意思決定やフィードバックループの短縮など、メリットとしてよく言われる様々な効果を体感することができました。モブプロの取り組みについては、先日のMeetupでもお話ししたので、もし興味があればそちらの資料を参照してください。

今日はどちらかというとペアプロを進める中で、当初想定していなかったにも関わらず、回を重ねるごとにメンバーの間で話に挙がるようになった「過程を見える化できる」メリットについてまとめます。モブプロでも同様の効果があると思いますが、自分のチームではペアプロ中にそういった意見が多かったため、ここではペアプロを前提としています :two_men_holding_hands:

実務的な側面

GitHub(ラクスではGitLab)とプルリクエストのおかげでコード、あるいはコードを中心とした周辺の成果物をレビューすることが当たり前になりました。しかし、中にはレビューしづらいものもあります。

  • コードのconflictを解決してmasterにpushしたいが、レビューアーにはどこがconflictしてどう直したのかが分からない
  • 新しいライブラリの調査結果を受けて導入可否を決定したいが、完成したサンプルコードからはハマりどころや使い心地が分かりづらい
  • セキュリティテストの対象となる画面を修正の影響がある画面だけに絞り込みたいが、レビューアーにはどういう判断でどの画面を選択したか(選択肢しなかったか)が分からない

これらはいずれも結果だけをレビューするのが難しい類のタスクです。レビューできるようにするために、レビューイーはどういう根拠でどこをどう判断したかを細かくプルリクエストに記載することになります。あるいは、レビューアーが同じ作業をもう1度繰り返して結果を付き合わせる、といった本末転倒なことになりがちです。

しかし、もしペアプロをしていれば、最初から最後まで判断や修正の過程を2人の目で確認しながら進めることができます。conflictをどう解決したか、新しいライブラリを試すときにどこでつまったのか、そのすべての過程をレビューアーも体験しているので、改めてプルリクエストをレビューする必要がありません。レビューイーも長い時間をかけて、思考の過程を文書化する必要がないのです。

よく費用対効果のコンテキストでペアプロどうなの?という話になると、意思決定の速さや後戻りが減ること、学びの多さでペイできる/いやできない、みたいな議論になりがちですが、そもそもペアプロでないと逆に難しいタスクがあると気付けたのは大きな収穫でした。

教育的な側面

立場上、若手1メンバーに仕事をお願いしたり、仕事の内容で相談を受けたりすることが多くなりました。しかし、次のような難しさを感じています。

  • 今ハマっている問題について解決方法をアドバイスすることはできるが、どうしてそのような状況になったのかまでは分かりづらい
  • 期待していたものと違うアウトプットについて指摘することはできるが、いつから方向がずれていったのかまでは分かりづらい
  • バグの切り分け方法やユニットテストの書き方を教えることはできるが、いざ自分の問題に適用してもらおうと思うとうまくできない

ペアプロをしていて気付いたのは、これらもやはり結果だけを見ていて、過程を見ることができていないからだということでした。

一緒にペアプロをしていれば、いつ何を考えてどのような方針で進めようとしていたのか、どのタイミングでの判断がまずくてつまずいたのか、という過程が見えるようになり、後からアドバイスするよりも的確なアドバイスをすることができます。また、単に考え方や手法を教えるのではなく、今実際に取り組んでいる問題に対してどう適用するかをより具体的に伝えることができます。

あとから「こういうふうに考えればよかったね」とか「こういう手法もあるよ」と教えるのではなく、今まさに「こっちに進もうとしているけど、こういう理由でこっちに進んだ方がいいよ」とか「ここではこういうふうに考えるとこの手法が使えるよ」とか、よりコンテキストを合わせて説明できるのです。

まとめ

われわれのソフトウェア開発は、いつの間にか分業を前提としていて、出来上がった結果だけをレビューしたり、結果だけから課題を想像してアドバイスしたり、ということが当たり前になっています。

しかし、実際にはその結果にいたるまでの連続的な "過程" こそが重要な場合があり、頑張ってあとから過程を説明するよりも、最初からペアプロで過程を見える化し、共有してしまった方が何倍も効果的な場合があると感じます。

もっとペアプロしていこう。

補足

どこかで聞いたことがあるなと思ったら、 @t_wada さんが同じようなことをすでに仰っていました。コンテキストが若干違いますが、結果よりも過程に価値を置いているという点で言わんとすることは同じだと思います。さすが先人の知恵は偉大です。

明日は @RyoheiAdachi です。意外性があるからどんな記事がくるか全然読めない…


  1. 年齢が若いというよりは経験が浅いという意味で使っています。 

oohira
rakus
「IT技術で中小企業を強くします!」というミッションを掲げ、中小企業の業務効率化に貢献する複数のクラウドサービスを提供しているIT企業です。「楽楽精算」「メールディーラー」など、国内トップシェアを誇る複数のサービスを開発し、累計導入社数は5万社を超えています。次の時代の"楽"を創るための、まだ見ぬサービスや機能を生み出す取り組みは、今日も続いています。
https://www.rakus.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした