ペアプロを導入しようと決意した話

Adways Advent Calendar 2017 16日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2017


社内サービスや社内システムを開発している組織のエンジニアリングマネージャーをさせていただいている山口です。

今回は、ペアプロを導入しようと決意した背景を共有させていただきます。

きっかけ


発端は、Joy, Inc.を読んだことです。
※本書の説明は省略させて頂きますが、非常に良い本ですのでオススメです!

この本を読んだ山口は、メンローイノベーションズのような組織を作りたいと思いました。

どうやって、作っていくのか。

ここでキーとなるのが、Joy, Inc. に出てくるペア作業です。

ペア作業はいままで見たなかでも最高のマネジメントツールだということだ。ペア作業により、従来あったたくさんの問題を解消できるようになる。ペア作業は学習システムを育む。また人間関係の構築、知識の塔の除去、新メンバーの立ち上げにも寄与し、生産性の問題を洗い出す役にも立つ。

よし、ペア作業やろう。

開発組織のペア作業といえば?ペアプロ。

ならば、ペアプロを導入だ!

どうせやるのであれば、抜本的に行こう!

よって、案件の開発は必ずペアプロで行うことにするぞ!

と決意したのです。

とはいえ


一般的にいいと言われているペアプロですが、パッションだけで導入するわけにもいかないので調査と検証を行いました。

まずは、ペアプロのメリットとデメリットを調べました。

ペアプロのメリット

調べてみると以下のようなメリットがあることがわかりました。

  • 属人化の軽減
  • レベル差の軽減、レベルの向上
    • レベルとは、技術レベル、PJや業務理解など
  • コミュニケーションの増加による、チーム感の向上
  • レビューコストの軽減
    • 常にレビューが行われている状態となるので、レビューを無くせる可能性も!
  • 新しいチャレンジのやりやすさ向上
  • メリハリのある開発

ペアプロのデメリット

中長期で見るとデメリットはない、もしくは無くせると思っています。 が、短期的にはありそうです。

働き方の変化が強制される

ソロでの開発では、その時の気分によってのんびり働いたり、キビキビ働いたりということが選べますが、
ペアでの開発では、一定の時間一定のペースで開発することが求められます。

また、弊社は出勤時間を個人の裁量で自由に選べる1という制度があるのですが、
ペアプロを導入すると、少なくともペアで出勤時間をある程度揃える必要があると考えています。

これらの問題は、乱暴な話かもしれませんが働き方に対する慣習に依るところが大きいと考えているので、
続けていくことでデメリットとして感じなくなるのではないかと思います。

生産性が低下する

これはよく言われていることでもありますし、直感的にも同意する方が多いのではないかと思います。

1つのタスクにかける人日だけを見たときには、中長期で見ても生産性は下がってしまうとは思います。

しかし、開発チーム全体として見たときの生産性を見ると、前述したメリットを享受することにより、
生産性は大きな問題にならないと考えています。

どうやって導入していくか


当たり前ですが、開発チームの外と内、それぞれに取り組みを理解して頂く必要があります。

開発チームの外に対して

正直な話、必勝の策はないと思っています。

メリットは実際にやってみても短期的には分かりづらいものとなるので、抵抗される可能性が高いです。

自分の場合は、各PJの責任者と開発部本部長が説得対象となります。

各PJの責任者

一部のPJの責任者には理解して頂くことが出来ました。

(残りはまだ取り組みを説明できていないです。)

PJの責任者も、開発チーム側に属人化の問題があることを問題だと考えており、
それが解消されるのであれば、やってもいいよ。という形でした。

ありがたいことです。

開発部の本部長

開発チームの生産性など自分と同じ責任を持つ立場だからこそ、納得していただくまで時間がかかるかなと思っていました。

しかし、既にペアプロのメリットなどを理解されていて、

「なぜ、今までやらなかったんでしょうね?」という発言が返ってくるぐらい歓迎されてしまいました。

いい上司を持ったなと思ったタイミングでした。

開発チームの中に対して

メンバー全員と個別にランチに行く時間を設けているので、殆どのメンバーにはそのタイミングで思いとメリット・デメリットを語りました。

みな、賛同してくれペアプロの取り組みも、自主的に進めてくれるなど積極的な行動をしてもらえました。

この行動はほんとに嬉しく、ペアプロを導入していきたいとより強く思うきっかけになりました。

少しだけ実践してみて


前述の通り、自主的にペアプロをやってみてくれたチームがありました。

そこから出てきたフィードバックとなります。

良かったこと

  • テストコードを書くノウハウが共有された
  • プロジェクトの既存機能の仕様などが共有された
  • コミュニケーションが活発に行われた
    • どのように実装すると品質があがるだろうか?
    • 納期と品質どこまでを追求するのか、妥協点をどこに置くか
    • 気軽に質疑応答が出来るようになった
    • 雑談が増え、新しいメンバーがより馴染んだ

課題

  • ペアプロの時間があまり取れなかった
    • 弊社の出勤時間を自由に選べる制度なども影響
  • 働き方に差があると、どちらかの働き方に寄ってしまう

まとめ

ペアプロの価値は、事前調査と実践で感じることが出来ました。

しかし、課題もありました。

今回の課題は、チームとしてどのような働き方をし、どのような結果を出すのか という点でチーム内の合意がないこと起因しそうです。

当たり前ではありますが、ペアプロを導入すればより良い組織になるというわけではなく、
組織の改善も同時に行い続ける必要があることがハッキリとわかったのです。

そして、自分の来年の目標が決まりました。

来年の目標

組織を改善しながらペアプロを導入するぞ!!!

参考記事

ペアプログラミングに関する調査報告

難易度は? 効果は? 実践して初めて分かった「ペアプログラミング」の実際


  1. 8時〜12時の間であればいつ出社してもOK。事前に出社時間を共有する必要もなし。