ペアプロが嫌すぎて会社を退職した話

ペアプロ・モブプロアンケート結果発表 🎉

ペアプロに対するエンジニアの本音が分かります。こちらもオススメです。

はじめに

巷ではペアプロ、モブプロがホットワードになっており、あたかも開発生産性を向上する特効薬のように取り上げられている印象を受けます。一方、この記事では、ペアプロ、モブプロ開発のネガティブな部分を考え、私の経験から感じたペアプロ、モブプロのアンチパターンとその改善策をご紹介します。

どんなアンチパターンを踏んでいたのか？

• 勤務時間は100%ペアプロを実施（ソロプロ禁止）
• ソロプロは悪、ペアプロが最高というチームの雰囲気
• フロー効率を過度に重視する姿勢

どうなったか？

• ＋) 開発生産性およびデプロイ頻度は上がった
• ＋) 4keysなどの数値上の指標はすべてプラスになった
• －) エンジニアとしての楽しさ、個性が抑制された
• －) 精神的な負担が蓄積し、最終的には退職に至った

学び

• 長時間のペアプロは、マイクロマネジメントになること
• ペアプロ、ソロプロはそれぞれ適材適所で使い分けること
• 行き過ぎたペアプロは拒否する権利があること

目次

• 時系列
  • ペアプロ導入の経緯
  • ペアプロ導入期
  • ペアプロ機能期
  • ペアプロ反抗期
  • ペアプロ絶望期
• 何でそんなにペアプロが嫌いなの？
  • 他人に気を遣い人疲れする
  • 好みの問題で衝突し、結局どちらかが折れる
  • 30秒で将棋を指す
  • 自分のペースで学習や試行錯誤ができない
  • 相互監視の仕組みができ、自分のペースで休息できない
• 転職活動
• 新天地
• 現職ではどのようにペアプロを取り入れているか？
• 最後に
  • チームにペアプロを導入しようとしている皆様へ

時系列

はじめに、ペアプロが前職へ導入されてから自分が退職に至るまでの過程を時系列でお話します。ペアプロ導入後の期間は、「導入期」→「機能期」→「反抗期」→「絶望期」→退職 の順序で移り変わります。導入期から退職まで約1年間となります。

※ ソロプロ開発の時を100としています。自分のモチベーションが0になった時点が退職を決意した時点となります。

ペアプロ導入の経緯

これは前職のweb系自社開発企業のお話です。入社時から数年はソロプロメインで開発を実施していましたが開発チームの課題として下記のような問題がありました。

• 中途入社エンジニアが増加しており、業務知識のキャッチアップに時間がかかっている
• 技術的負債の経緯を知らないエンジニアがソースを触り、本番障害が増加した
• レビューでの手戻りが増え、mainブランチにマージするまでに数日かかっている
• ジュニア層のエンジニアが増え、エンジニアの教育に時間を使いたい

このような課題がある中で、前職でXPを経験していたメンバーがいました。その方の前職ではペアプロメインで開発することにより、開発体験および生産性が向上し、ペアプロの成功体験を持っている印象を受けました。その方の開発体験のヒアリングや、他社事例の調査により、開発チーム内で、「何やらペアプロが良いらしい」という流れが発生しました。

その結果、会社のマネジメント層から我々メンバーエンジニアに対し、「来月から全てペアプロで実施します。」という通達がありました。このとき私は「何か嫌だな」という気持ちはありましたが、ペアプロに好意的なメンバーが多く、私も強く反対できずとりあえずやってみるかという気持ちになりました。

結局、このときの「何か嫌だな」という気持ちは退職するまで消えませんでした...。

ペアプロ導入期

ペアプロ導入日から、開発の流れがガラッと変わりました。開発チームは必ず二人組でコーディングを強制されます。リモートの場合はWeb会議ツールをつなぎ、ヘッドホンを耳にかけて画面共有しながらコーディングを実施するようになりました。
最初はチームメンバーも混乱しており、中々コーディングが進みません。お互いの認識の擦り合わせや、ペアプロ開発への慣れの問題から、開発生産性はソロプロ開発をしていた時の半分にまで落ち込みました。
右利きの人が、急に左手で字を書き出したようなもどかしさがありました。

ペアプロ機能期

ペアプロ導入してから2ヶ月ほど経つとチームの生産性がソロプロと同じレベルに回復してきました。また、常に2人以上でソースコードを確認しているため、pull requestのレビューでの指摘事項や差し戻しがほとんど発生せず、pull requestのマージが早くなってきた印象がありました。チーム（特にジュニアメンバー）は、仕事がサクサク進むようになったと肯定的に捉えるメンバーが多く、会社としてはペアプロを続ける流れとなりました。

ペアプロ反抗期

導入から半年くらい経過してもなお自分はペアプロへの苦手意識が消えませんでした。また、毎日ペアプロを強制される開発に精神的な疲労が溜まってきていました。ペアプロを続けることで、主に対人関係に対する気疲れが溜まるのです。

私は、業務時間中100%ペアプロするのが嫌いなので、何とかソロプロを復活させたいと考えていました。そこで、「一部の機能開発をソロプロで開発することで、リソース効率が上がるのでは？」とチームに提案し、2週間ほどソロプロの導入をお願いしました。チームがソロプロの良さに気づき、ペアプロ一辺倒な開発から脱出する目論見でした。
2週間後、ソロプロを復活させるか否かをチームが判断する時が来ました。ジャッジは、4Keysの値の良し悪しで決めるそうです。2週間ソロプロを導入したことによる生産性はどうなったでしょう？
なんと、部分的にソロプロを導入したことで、業務時間中100%ペアプロしたときよりも4keysの数値が悪化しているではありませんか！これにより、ソロプロを部分的に導入する案はチームに却下され、ペアプロを続けることになりました...。
客観的な数値を使ってペアプロを止めるという目論見が失敗したことで、私はとても絶望しました。

ペアプロ絶望期

ペアプロ反抗期に失敗し、半年ほど我慢しながらペアプロを続けていましたが、私は、そろそろ限界を感じていました。そんな折、プロジェクトに新しい言語を導入することになりました。これが私にトドメを刺します。
この言語は、私は未経験だったが、他のメンバーは経験がある言語であり、チーム内でのスキル差が大きくなりました。そうなるとペアプロでの私の発言量および思考量が大きく低下しました。私の言語に対する知識が少ないため、自分の発言は的外れのことが多く、相手の発言が正解という機会が多くなりました。それにより、徐々に自分の意見を発言できなくなり、「ペアプロでは相手の言った通りにコーディングする作業者」に成り下がりました。また業務時間中100%ペアプロしているため、ソロプロのようにおいそれと自己学習ができず、業務時間外も会社からの目標達成のための別のワークのため学習できないという状況に陥りました。学習できるのは土日しかないが、平日の精神的苦痛によりクタクタ、学習できずに次の週のペアプロに望むというループにハマり、徐々に精神を蝕まれていきました。

また、私にはチームのペアプロ文化に反対する力も説得力もありませんでした。ソロプロがしたいと言おうにも、4keysの指標では説明できず、かといって「ペアプロやりたくない」という主張も、一個人の感情に過ぎません。

• 私は、ペアプロでは常に相手に気を使って辛い。技術的な勉強もできなくて辛い。
• でも、自分が駄々をこねているようで強く言うことができない。
• けれど辛いのは変わらない。どうしよう...。

もう辞めるしかない...!

そうして心が折れた自分は前職を辞めました。

何でそんなにペアプロが嫌いなの？

ここで、自分が業務時間中に100%ペアプロすることで感じたデメリットをできるだけ言語化しようと思います。ペアプロには良い点もたくさんありますが、ペアプロの時間があまりにも長くなると、対人関係に起因したデメリットが大きくなるのです。私が感じたデメリットは下記の5点です。

他人に気を遣い人疲れする

あなたが運転する車に、あまり仲良くない人間を乗せて、ふたりきりで8時間ドライブをしてください。最初は世間話や当たり障りのない会話でごまかすことができるでしょう。しかし、人生の価値観や趣味などの深い話では価値観が合わないため、会話が続かず、次第に沈黙が多くなっていくでしょう。
ペアプロでも同じことが発生します。作業の端々で感じる「何か合わないな」を感じながらの作業。相手の顔色を伺いながらの発言。頭脳労働ではなく感情労働の割合が大きくなりました。

好みの問題で衝突し、結局どちらかが折れる

人間はそれぞれ異なる価値観を持っており、お互いに分かり合えない部分が必ずあります。ペアプロを続けると個人の好みの問題が顔を出してきます。例えば、

• 変数名はAがいい。いや、 Bがいい。
• リファクタはこのpull requestでやりきりたい、いや、別課題で良いでしょ。
• 単体テストはそこまで細かく書くの？ もっと省略してもいいでしょ。

このように大小様々な衝突が発生し、その場ですぐに解決しなければならないのです。枝葉末節な議論も多いのでダラダラと議論するわけにもいかず、結局どちらかが妥協するということがしばしば発生しました。表面的には問題が解消しましたが、妥協した方にはモヤモヤが残るんですよ。

30秒で将棋を指す

ペアプロの大きな問題として、「自分のペースでじっくり思考できない」点が挙げられます。会話しながらのコーディングなので、作業者が無言のまま、自分が調べたい内容のGoogle検索の画面だけを投影することができません。必然的に30秒に1回は何か発言しないといけません。この症状を私は「NHK将棋杯」と名付けました。

将棋で例えると、ソロプロは名人戦。ペアプロはNHK将棋杯です。名人戦は一人あたりの持ち時間が9時間もあり、一手を指すのにじっくり考えることができます。必要であれば自由に離席することもできます。一方で、NHK将棋杯の場合の持ち時間は20分間で、持ち時間が切れると、なんと1手を30秒で打たなければなりません。

ペアプロ中に長考しようにも、頭の中で、

• 「10秒」
• 「20秒」
• 「1, 2, 3, 4, 5, ...」

という秒読みが聞こえるではありませんか。
うわあああああ。

というわけで、自分が今知ってるやり方でとりあえずコードを書くしかなく、ペアに指摘されるのがストレスでした。（ゆっくり調べれば分かるのに、悔しい。）

自分のペースで学習や試行錯誤ができない

これは、ペアプロの「頻繁なフィードバック」の悪い作用となります。ペアプロをするとペアから頻繁なフィードバックをうけるため、寄り道することが難しくなります。よって、基本的に自分の知っている知識で何とかすることが多くなります。

いきなりですが、下記の定積分を解いてください。
$$
\int_0^\pi (\tan\theta - 1)\cos\theta d\theta
$$

正解は、2 です。
あなたが受験生だとして、答えだけ教えられて実力が付くと思いますか？

途中式はこちら

※ このように自分で実際に解かないと、積分のやり方は身につかないはず

受験数学の勉強では、答えだけを暗記しても意味がなく、手を動かして自分なりの正解を書いた後、模範解答を見て、復習するというプロセスが必要です。プログラミングの習得も似たようなプロセスが必要で、分からない概念が出たら、自分なりに試行錯誤しながらコンパイルエラーを潰し、概念を理解する時間が必要です。

※ 個人的に、Typescriptのinfer, extendsあたりの習得が受験数学のたとえに近かったです。

type MyReturnType<T> = T extends (...args: any[]) => infer R ? R : never;

ソロプロでは一人でコーディングできるので、試行錯誤しながら自分なりの正解を書き、pull requestでレビュアーに模範解答を書いてもらうことが可能です。このように、試行錯誤、模範解答、復習のサイクルを自分に適したスピードで行うことができます。

一方ペアプロの場合、実装に詰まったら即座に正解が与えられ、その通りに書き直す事で次に進みます。一見するとペアプロの方が良さそうに見えますが、そうではありません。ペアプロではコーディングによる失敗経験が減るため、正解だけ知っている状態になります。自分一人で考え抜く力がつかないため、受験を暗記だけで乗り切ろうとする人と同じになります。ちょっとひねった応用問題が出てくると途端に解けなくなるのです。

結局、自己学習と試行錯誤の経験値は、ソロプロが勝ります。

相互監視の仕組みができ、自分のペースで休息できない

ソロプロで開発しているとき、私は必要に応じて15分昼寝するとか、散歩で気分転換をしていました。決してサボることが目的ではなく、自分のパフォーマンスが落ちてきたら、細かく休んでパフォーマンスを維持するためです。

一方で、ペアプロは常に画面投影&音声でのやり取りが必須です。これは、ペア同士でお互いを監視している状態と同じです。トイレに行くときも一声かけなければいけません。さらに業務時間中100%ペアプロの場合は、お昼休憩の時間も合わせないと行けないし、昼寝がしたいとも言えません。これはかなりのストレスでした。

上記の理由から、業務時間中100%のペアプロはマイクロマネジメントであると感じました。

ただし、管理する側（会社）からするとこれはメリットです。ペアプロは無料の監視ツール になるため、社員のサボりを防止できますね。

ここまで、ペアプロのネガティブな面を書いてきました。ここからは前職を退職後、現職での取り組みを書きます。

転職活動

前職を退職し、自分の心はとても晴れやかな気持ちになりました。今までペアプロで抑圧されていた反動からか、自宅で個人開発に没頭しました。しばらく仕事のことは忘れてソロプロでWebアプリを個人開発していました。

コードを書いていくにつれ、「自分で自由にコードが書けるってこんなに幸せなんだな！」と感激しました。

この個人開発は、自分の心を癒やしてくれ、エンジニアの楽しさ、また自分のスキルへの自信を取り戻すことができました。

ここまでの経験を踏まえて、次の職場選びは非常に慎重に行いました。また、転職面接においても、退職の経緯を包み隠さず話し、ソロプロメインで開発できるかを確認しました。

入社が決まった会社は、
・自社開発であること
・アジャイル開発であること
・ソロプロメインで開発できること（ペアプロの失敗談も面接で会話し、その話に対し理解があること）
という好条件での会社でした。

また、前職の経験を踏まえて、スクラムマスターとしてオファーをいただきました。

新天地

入社した会社では、自社開発のWebアプリ開発のチームにアサインされました。チームは、デザイナー、POを含めて8人くらいの規模であり、業務委託、正社員半々くらいの会社でした。そこでは、ペアプロの文化は0で、各人がカンバンベースで開発するスタイルでした。前職と全く逆です。

チームの課題としては、

• チャットベースでのコミュニケーションがメインで、テキストでのラリーが何往復もある
• pull requestが数千行程度の大きさに膨れる場合があり、レビュアーが苦労する。また、レビューの手戻りが大きい

といった点が目につきました。

現職ではどのようにペアプロを取り入れているか？

前職とは異なり、コミュニケーションの頻度や密度が低いため、開発効率が悪い点が課題と考えました。そこで、スポットでのペアプロを導入する形としました。ペアプロに踏み切るのは、下記のようなタイミングです。

• PRのレビューで2往復しそうになったらペアプロする
• コード製造時に、30%作ったらペアプロでフィードバックをもらう
• デイリースクラムでペアプロ希望のメンバーがいたら、スポットでやる

ペアプロの指針としては、あくまでも 「だれかが必要としたときだけやる。」 ことを重視しました。またペアプロの時間も1日1時間程度に抑えることで、コミュニケーションの負担が増えないように工夫しています。この取り組みにより、ソロプロメインで開発しつつ必要であればペアプロを選択できるという発想がチームに生まれました。

ただしペアプロだけでは、手戻りが大きいという課題を消すには不十分です。そこでチームが取り組むタスクのサイズを1日以内の大きさに細分化して、Sprint Backlogに入れることにしました。事前のBacklog RefinementやSprint Planningなどでメンバーが会話する時間は増えることになりましたが、Sprint期間中のタスクサイズを小さくできるようになったため、下記の効果が得られました。

1つ目はデイリーで異常を検知しやすくなったことです。例えば、2日間「進行中」になっているタスクは当初の見積もりと異なり何らかのトラブルが発生していると分かるため、作業者が申告しなくても、デイリーの司会者が異常を指摘しアクションを取ることができます。

2つ目は一日以内のタスクサイズで課題を切ることで、必然的にpull requestのサイズを小さくできるようになった点です。理論上、一日に一回はpull requestができるためメンバーの進捗が把握しやすく、前述のスポットでのペアプロと合わせることで、実装からマージまでがスムーズに流れるようになりました。

この経験から、業務時間中に100%ペアプロをする必要はなく、他の手段と組み合わせることでソロプロ主体でも効率的な開発ができることが分かりました。また、ソロプロ主体としているので、ペアプロメインで開発する際の対人ストレスが少ないのも良い点です。

最後に

私個人の意見ですが、ペアプロはマイクロマネジメントの一種であり、劇薬であると考えています。ペアプロは各メンバーの仕事のやり方を強く拘束してしまうため、多用するとメンバーの離職や意欲の低下につながると考えています。一方で、手戻りの軽減や認識合わせといった良い点もあるため、スポットでペアプロ・モブプロを導入するくらいがちょうどよいと感じています。

私は、転職によって異なる文化の組織を経験しました。そのうえで前職のBadポイントを一つ上げるならば、ソロプロは悪、ペアプロが最高という二元論的な発想だと考えています。結局どんな手法もお互いに良い点・悪い点があるのだから、ゼロヒャクで導入するのではなく、ちゃんとカスタマイズしながら導入すべきだと思います。

チームにペアプロを導入しようとしている皆様へ

何となく良さそうだと思って、ペアプロをチームへ導入しようとしている皆様。メンバーの性格や感情も十分にチェックしてください。数値上、チームの生産性が上がったと思って放置していると、内部からチームは壊れていきますよ？

ペアプロ・モブプロアンケート結果発表 🎉

ペアプロに対するエンジニアの本音が分かります。こちらもオススメです！

筆者のX

参考URL

• NHK杯戦　羽生善治vs中川大輔