ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話

ソフトウェア開発

2022/04/8 03:00

ペアプロを実務で導入したことによって、想定以上の効果が得られた体験についてまとめています。

※ 本記事は過去にQiitaで投稿した記事を転載したものです。

はじめに

この話は、弊社のとある新規プロジェクトの立ち上げで実際にペアプロを導入した話です。 プロジェクトでは初期メンバーとして私を含めた4人の開発者がアサインされました。過去のプロジェクトで比較的うまく機能していたアジャイルの導入や、ソフトウェアテスト・静的解析ツール等を徹底してコードの品質を担保するなど、アプリケーション開発する上での準備を入念に行いました。

そんな中、同じプロジェクトにアサインされた同期の@Takuan_Oishiiから

「今回は絶対にペアプロをやりたい。意地でもやらせてくれ。」

と、熱烈な提案を受けました。

ペアプロの提案を受けた時、以下の理由から正直言って僕は懐疑的で導入をためらっていました。

• 単純に手を動かす事ができる人間が減ってしまうのは非効率なのでは？
• 人と話をしながら集中力を持続することが可能なのか？
• 開発者の精神衛生を保つ意味しか無いのではないか？

しかし、同期の提案の中の以下の要素が決め手となり導入することを決定しました。

• 開発メンバーのうち半分は学生インターン生で、ペアプロで開発と育成を同時に進められるかもしれない
• 新規プロジェクトこそ、新しい取り組みがやりやすいという過去の経験知
• 「個人がコードに責任を持つのではなく、チームでコードの責任を持つ組織にするべき」という考えに心を打たれた

導入をすすめるにあたり、最低限以下の2つをモニタリングしてペアプロの実質的な効果を検証することにしました。

• 実質的にチームの生産性が高まるか
• ジュニアメンバーの育成に効果的か

タイトルがネタバレなのですが、結論としては上記2点双方に良い結果が出ました。正直、いい意味で予想に反しました。 以下、僕達がどのようにペアプロを導入し、どのような影響があったかを説明していきます。

そもそもペアプロとは

ペアプロとはペアプログラミングの略称で、2人のプログラマが1つのPCを前にして共同でプログラムを書いていく開発スタイルです。 ペアにはドライバとナビゲータという役割があります。

• ドライバ
  • 実際に手を動かしてコードを書く人
  • ナビゲータのサポートの元、プログラムを完成させることに集中する
  • 実装の細かい部分を考える
• ナビゲータ
  • ドライバが気持ちよくコードを書く事をサポートする人
  • ドライバが書いたコードを横から常にレビューする(コーディングスタイル、バグのチェック、コードの簡潔化の提言、etc)
  • プログラムを書く上での大局的な問題を考える

ペアプロでは、このドライバとナビゲータの役割を定期的にスイッチしながら開発を進捗させていきます。

ここではペアプロの詳細な説明は省きますが、ペアプロの基本的なやり方は上記のとおりです。

どのようにペアプロしていたのか

ペアの組み合わせ

導入したプロジェクトのメンバーは

社員2名(僕, 同期(@Takuan_Oishii)) インターン生2名

の合計4名の開発チームで、ペアのパターンは以下の3つでした。

• 社員×社員
• 社員×インターン生
• インターン生×インターン生

開発当初、社員とインターン生ではスキル・経験知共に差があったので

社員×インターン生

のパターンをメインで社員とインターン生の能力差を徐々に埋め、チャンスが有れば他の組み合わせでペアプロをしていました。

ペアの組み合せは毎日始業時に決めますが、ペアの作業が完了したタイミングで一度ペアは解散になります。 そして、可能であれば他のペアと組み合わせを交代して、なるべく組み合わせが膠着化しないようにしています。 ペアが膠着化すると、そのペアだけが知っている情報・経験が増大して仕事の属人化を引き起こす可能性が上がるからです。

ペアの着手するタスク

着手するタスクは、原則タスクに着手可能になったタイミングで決めます。裏を返すとどの開発タスクを誰が着手するかを決めていない事を意味します。

このやり方を選んだ理由は大きく分けると以下の2つです。

• そもそもいつどの組み合わせのペアになるかがわからない
• どの組み合わせのペアだったとしても、あらゆるタスクを完了することができるチームを長期的に作りたい

その為、場合によっては特定の機能の開発を、タスクを細かく分解した上でペアを交代してすすめることもあります。 短期的にはペア交代のオーバヘッドで生産性は落ちますが、機能開発における知識と経験がチーム内で自然にシェアされるので、その後新しい機能を開発する際にどのペアの組み合わせでも可能な状態をキープでき、トータルでプラスになると判断してこのやり方を進めています。

ただし、プログラマのモチベーションや学習意欲を尊重するため、どうしてもこの機能を自分が作りたい！という場合は着手予約宣言して良いことにしています。プログラマ自身がやる気を燃やせなくなるルールにするのは本末転倒なので。

また、タスクを選定する基準は以下の2点です。

• タスクの優先順位
• タスクの重さ

全てのタスクには、優先順位がざっくり振られていて、基本的に上から順番に着手します。 そして、同じ優先度のタスクの中でも、なるべくその日のうちに完了できそうな重さのタスクを選定します。これは、仕掛り作業を次の日に持ち越してしまうことでペアの組み合わせの柔軟性が下がることを防ぐためです。 仮にどのタスクも重すぎてその日のうちに終わらない場合は、その日のうちに終わる粒度にタスクを細分化することで解決しています。

また、非常に重要な機能の設計や新しい技術の導入をする場合は、設計だけチームメンバー全員で実施して、開発をすすめる上で可能な限りメンバー間の知識差が無くなるようにしています。

ペアプロによるチームの生産性への影響

チームの生産性の指標は、アジャイル開発を導入していることもあり、ストーリーポイント消化の平均ベロシティで計測することにしました。ストーリーポイントの細かい説明は割愛しますが、タスクの大きさを見積もる際に絶対的な大きさで見積もるのではなく、タスク同士の相対的な大きさに着目する見積もり手法です(ex: BはAよりも3倍ぐらい大きなタスクだからポイントを3にしよう)。

以下が、ペアプロを導入したプロジェクトと過去のプロジェクトでのチーム平均ベロシティの比較です。 (過去のプロジェクトのタスクと比較してストーリーポイントは見積もり直し、平均ベロシティはチームメンバーの人数比に対応して公平に計算しています)

項目	ペアプロ導入プロジェクト	過去プロジェクト
ベロシティ	22.0	18.8
比率(過去を100%)	117%	100%

ペアプロを導入したことで、過去のプロジェクトと比較してもベロシティが大きく向上したことがわかります。

メンバーが違うことによってそもそもチームの生産性が違うから比較の意味が無いでしょ！という意見もあると思いますが、過去のプロジェクトは全員が社員だったのに対し、ペアプロを導入したプロジェクトは半分がフルタイムではない学生インターン生だったことを考慮すると、むしろ不利な状況の中で優位な結果を出したことにもなりますし、両方のプロジェクトにいた自分としては体感的にも明らかにベロシティが速いことを実感できました。

ペアプロによるジュニアメンバー育成への影響

ペアプロを通してインターン生の育成にどのような影響を与えたかを、2パターンのペアの組み合わせで説明します。

社員×インターン

このパターンは非常わかりやすく、かつ意図通りの結果になりました。 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習でも紹介されている様に、成長を阻害する悪い習慣を早い段階で察知でき、良い習慣を目の前で実践して教えることができます。

ペアプロ導入前は、ジュニアメンバーから飛んでくるPullRequestをレビューしながら鬼の形相でコメントをしていましたが、そのコードを書くに至るまでのプロセスの情報が抜け落ちていたため、なぜアウトプットの方向がずれるのか？なぜこの設計をしたのか？という原因を特定して、適切なフィードバックをすることが難しかったのです。

しかしペアプロをしていると、上記の様な課題は大幅に軽減されます。 ペアで作業をしながら、ジュニアメンバーが理解できていない時は雰囲気や行動で即座に判断でき、そしてその原因をその場で確認することができるからです。

また弊社のインターン生は、社員とのペアプロをやった後で、以下の様なプロセスで知識を定着するサイクルを回しているので覚えも速く、日に日にできることが増えていく実感を社員・インターン生双方が感じ取っています。

• その日のペアプロで学んだことをメモにまとめる
• とくにわからなかった部分を公式ドキュメントを読み込んでまとめを作る
• そのまとめをペアをしていた社員にレビューしてもらい、正しく理解しているかをチェックする

インターン×インターン

一方、社員×インターンの組み合わせばかりだと、自立したプログラマに育成するのは難しいと思います。 社員×インターンのペアでは、社員がインターン生に対して一方的にインプット・指示する時間が多くなりがちで、自発的に思考して行動することを経験しにくいからです。

先日読んで大変感銘を受けた、 一つ上のチームメンバーのそだてかたによると、

SL理論 (Situational Leadership)というメンバーの能力とモチベーションに応じて発揮すべきリーダーシップを表したモデルが存在し、S1->S2->S3->S4という順番で育っていくことが望ましいとされています。

(参考 : http://www.earthship-c.com/leadership/situational-leadership-theory.html)

この図でいうS1->S2までは社員×インターンの組み合わせで十分に効果的な育成ができますが、S2->S3->S4の育成には向いていないという事が直感的にわかります。

ここで、S2->S3の育成に効果的なアプローチがインターン×インターンのペアプロだと感じています。

インターン×インターンの理想的なペアプロの流れは、以下のとおりです。

1. ペアで着手するタスクを決める
2. インターン生同士で、タスクの要件詰めやTODOの整理を行いGithubのIssueにまとめる
3. 社員に声をかけてレビューを受ける
4. 社員のレビューを通過した後に、立てたTODOにもとづいてタスクを完了させる

別にこれペアプロじゃなくても良くないか？と思う方もいると思いますが、インターン×インターンが非常に効果的に働く要素が一つあります。それは、自分の意見や考えを相手に発信するというハードルが大きく下がる事です。

ジュニアメンバーの中には、自分よりも経験や知識が豊富な相手に対して自分の意見や考えを伝えることに抵抗や恐怖心を持つ人もいます。もしこれが仮にペアプロではなく、インターン生が個人でタスクを推進するケースに置き換えた場合、心理ハードルが邪魔をしてなかなか前に進めない可能性があります。 S2->S3に移行するためには、自律的な発言・行動量を増やすことが必要となり、インターン×インターンのペアプロはこの遷移ハードルを下げます。

事実、試しにインターン×インターンのペアを一日やってもらった後に、社員×インターンのペアを組んでみたら、以前と比較して格段に自分の意見を言ってくれるようになり、僕がドライバーの時に

「あ、そこ違います。こうしないと駄目です。」

と、社員のミスを指摘してくれるようになりました。頼もしい。

後にそのインターン生に聞いてみたら

「インターン生同士で自分の考えを言うのは凄く言いやすく楽しくて、社員とのペアプロをする時も同じような感覚でペアプロしてみたら意外とちゃんと発言できました」

という答えが帰ってきました。この心理ハードルは馬鹿にできないし、おもったよりもシンプルな方法で解決できる可能性があるということをインターン×インターンのペアプロをやってみて学びました。

さらに、S2->S3に遷移したのち、インターン生から

「イテレーション内で1つでもいいから自分ひとりで全部タスクを完了させてみたいです」

という提案ももらい、インターン×インターンのペアプロによって、S3->S4への遷移の足がかりになる環境を作る事もできることがわかりました。

ペアプロを導入してみて

ペアプロを導入して、いいことづくめだったプロジェクトですが、それはペアプロという仕組みが素晴らしかったという事もありますが、「個人がコードに責任を持つのではなく、チームでコードの責任を持つ組織にするべき」という考えを基本哲学として、「あの人しかできない仕事」を無くし、社員・インターン生の差を徹底的に無くしていくという取り組みが産んだ結果なのかもしれないと思いました。

思うと、ペアプロ懐疑派だった時の自分の考えは、個人の力を過信して他者の力をあまり信頼していない心から来た考えだったのかもしれません。

終わりに

新しい開発スタイルの導入は楽しくも有り、周りを巻き込む必要があるためとてもエネルギーのいる行為です。少しでも導入の成功確率を高めるには、信頼関係を強固に築いたメンバー達同士で、小さくトライしていく事が重要だと思います。実質的な成果を示すことで、他者を巻き込んで組織全体に浸透させていく事ができると私は考えておりますので、今後は弊社の他のプロジェクトでもトライしてもらえる様に、引き続きこのペアプロの実質的な成果を作り続けようと思っています。