この記事を書くきっかけとしては、
「ペアプロする事で、属人化を排除出来る！」
という話が仕事の中でありまして、
で、属人化解消問題は昔から個人的にも課題だと思っていましたので、
考えるのに丁度良いと思い、今回書いてみる事にしました。
結論としては、
「ペアプロによる効果が無いとは思わないし、取り組む事は良いと思うけど、幾つか注意点があると思うし、あと短期間じゃ排除出来そうにない属人化している部分もあるよね」
って感じですね。
■目次
１．ペアプロ導入で上手くいった話
２．ペアプロで苦しんだ話
３．ペアプロの実践を通じて、個人的に気になっている点
４．ペア間でのスキル差を埋める為のコツ
５．まとめ
まず、仕事中に教えていただいた、以下リンクの記事を見てみたいと思います。
ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話 #アジャイル - Qiita
https://qiita.com/YudaiTsukamoto/items/06b426f4dbee268d5035
まず、気になった点としては以下。
ペアの組み合せは毎日始業時に決めますが、ペアの作業が完了したタイミングで一度ペアは解散になります。
そして、可能であれば他のペアと組み合わせを交代して、なるべく組み合わせが膠着化しないようにしています。
ペアが膠着化すると、そのペアだけが知っている情報・経験が増大して仕事の属人化を引き起こす可能性が上がるからです。
上記ですが、「ペアを解散する前（AさんとBさんによる、ペアAとする）に行っていた作業（タスクAとする）」と、
「ペア解散後にペアを替えて（AさんとCさんによる、ペアBとする）行った作業（タスクBとする）」があるわけですよね。
なので、人別に行ったタスクを整理すると以下かと。
Aさん：BさんとペアでタスクAを行い、CさんとペアでタスクBを行った
Bさん：AさんとペアでタスクAを行った
Cさん：AさんとペアでタスクBを行った
で、タスクAとBは別のタスクなわけですから、そのタスクの消化に必要な情報や経験も異なる可能性があるわけで、
「BさんはタスクBについては知らない」し「CさんはタスクAについては知らない」と。
これで、属人化が排除されたんですかね？
まあ、「必要な情報や経験が同じタスク同士だった」ら排除されたかもしれないですし、
僕の解釈が間違っているかもですが、まずそれが疑問ですね。
短期的にはペア交代のオーバヘッドで生産性は落ちますが、機能開発における知識と経験がチーム内で自然にシェアされるので、その後新しい機能を開発する際にどのペアの組み合わせでも可能な状態をキープ
この「自然にシェアされる」って所に、
やっていて疑問を感じる事が多かったんですよね。
確かに、シェアはされるんです。
ただ、シェアされても、実際に作業をする時にスムーズにいく場合とそうでない場合があった印象ですね。
シェアの定義がポイントな気がしているんですが、
「シェア→話を聞いただけ」って定義の場合、
「以前に、せめて似た作業ぐらいはやった事がないと、シェアされてもその後スムーズに対応出来ないのでは？」と。
例えば、フロントエンドにはSQLは出てこない（基本的には）わけですが、
SQLの内容と実行する話をシェアして、フロントの方（で且つ、SQLは全然知らない人）はすぐにその作業を出来るものなんでしょうかね。
逆に、バックエンドの人は、最近（でもないが）フロントエンドにはソースをビルドする作業があるのですが、
ビルドする情報をシェアされて、その後スムーズに対応が出来るかと。
人によってはここで、「フルスタックエンジニアを考えるなら上記ぐらいは」となって、それ自体は否定はしないですが、
フルスタックを志向する中でフロントもバックエンドもやると、時間的にどうしても特定のスキルが深堀れず、
専門的知識やスキルが求められた時に厳しくなるので、その点を踏まえて志向するなら良いと思いますね。
少し話が逸れましたが、「シェアされてその後すぐ出来る」のは、
最低でもその作業における知識と経験が既にあるのが前提にあるんじゃないかと思いますね。
どうも、上記の記事ですと「シェアされた知識を低スキル側が吸収出来ているのが前提となっている」様に思いましたので。
記事に対するツッコミは以上ですが、
ただ、上記の疑問や懸念があったからといって、
じゃあペアプロが上手くいかないかというと、
別にそうは思わないですね。
なんでかっていうと、最近よく思うんですけど、
「書かれていない前提だったり情報」次第で、
成功・失敗が左右されると思ってまして。
上記の記事の場合だと、インターン生といってもかなりスキルの高い人なのかもしれなく、
それなら上手くいくかもしれないなとか。
本でよく見る「こうすれば上手くいく」とかの話も同じで、
だから、「書いてある通りやってるのに、上手くいかない」という事が起きると。
ってうのがあるので、上記の記事の話は「上手くいったケース」だったんだろうと。
次に、失敗したというわけではない様ですが、タイトルの通りペアプロで苦しんだ話ですね。
苦しいペアプロに苦しむ話｜Kohei Sakamoto
https://note.com/skmtko/n/n23d65aa3ddbe
ペア同士のスキル差、知識差が大きすぎる
最初に断ると、この要素だけでは特に問題ではなかったかもしれないです。
「ペア同士のスキル差、知識差が大きすぎるけど、ペア内に差があることをちゃんと認めれきれてなくて、ペアの動きに反映できてなかった」がここで言いたい苦しみかもしれないです。
これが、今回記事にしたかった事のテーマの一つですね。
で、スキル差がある時の問題として、
初心者の方がプレッシャーやできないことをとても感じてつらいと感じたり
熟練者側も教育・指導的な負担が大きくてつらい
上記は、まぁあってもおかしくないですよね。
で、上記は当事者の感想ですが、指標的な話として、
「ペアプロした場合の生産性と、熟練者側がソロでやった場合の生産性が逆転（前者の方が高くなる）するのに、どれくらいの期間がかかるか？」
が、と～～～っても気になっています。
だって、凄く大事な部分じゃないですかコレ。
最初の記事にも、
「短期的にはペア交代のオーバヘッドで生産性は落ちますが」
と書いている通り、最初はソロの方が作業は捗るわけじゃないですか。
でも、途中からペアの方が良くなると。
でも、その「途中」っていつ頃？って辺りが気になるんですよね。
スキルアップって、１年や２年で天井になるわけじゃなく、
知識によっては５年も１０年もかかったりすると。
なので、場合によっては「途中が３年後」だった場合、
それまでの３年間は、「エンジニアによって生産性が１０倍違う」とかの話の通り、
「難易度が高いタスクがあった時、熟練者の人なら２日で終わるが、初心者の人なら２０日かかる」
って話の熟練者の時間が、「ペアプロにおける伝授などによる生産性の低下で奪われ」て、
熟練者がどんどん捌いていたタスクの消化が遅くなると。
別に、伝授するなって話じゃないんですよというか、
むしろ業界的にはもっと伝授した方が良いんじゃないですかねって思ってますが、
ただ、特にスキル差のあるペアの場合、こういう問題もあるかなと思いますね。
なので、メンバー構成的にどうしてもスキル差の大きいペアにしなければいけないってケースもあるかと思うので、
それは仕方ない部分もあるかとは思いますが、
ただ、少なくとも上記の様な側面の考慮は必要かと思いますね。
個人的に思うのは、現状に対して
・作業を消化する時間
・知識やスキルを伝授する時間
というのを分けて行っていくか、
分けないにしても、「ここまでは伝授する時間で、ここからは作業を消化する時間」
という決めを設けて、状況を可視化するのが大切と思いますね。
ソロを増やしてみる
実際にやるべきことがシンプルでかっちり固まっている系のタスクだったり、ちょっと時間をとって探索する系の調査タスクだったりソロで進める方が結果的にもよかった
うん、「常に」ペアでやるっていうのに疑問を感じているんですよね。
で、以下がある。
他には、今はペアプロの選択肢の他にバディプログラミング的なものも実施してみている。レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス に載っているらしい。それを少しカスタマイズしたやり方で、バディ（二人組）でタスクの初めにお互いのやることを確認→分散してそれぞれ並行作業→一定時間（1hくらい）経ったら合流して報告し合うみたいな進め方
名称は始めて知りましたけど、これは実際にやってましたね。
分散してやるのは実装よりは調査の方が適していると思いますけど。
ここは、記事の引用ではなく自分で書きます。
（１）ペアプロで属人性が排除出来る？
上記でも少し書いた様に、「習得する知識の難易度と時間」「本人の意向と得意・不得意」次第だとは思いますけど、
特に「時間」の部分がボトルネックになるんじゃないかと思いますね。
人によって、習得までにかかる時間が変わるわけですし、
なので、本人の現状のスキルと習得したい知識の意向のヒアリングが大事なんじゃないかと。
あと、属人性を排除するのに必要なのは「自分の知識や経験を、他人に伝える事」なわけで、
それはペアプロ以外の方法（ペアという形ではなく、単純に伝えたり、あとドキュメントに残したり）もあるので、
ペアプロに拘る必要性はないのではとも思いますね。
（２）ペアを頻繁に交代する事の是非
時々見かける「ペアを１時間でどんどん交代していく」という話なんですが、
目的として「チームメンバー全員への知識の共有による、属人性の排除」があると。
ただコレ、「ペアが頻繁に交代するので、コミュニケーションコストが高くなる」というのと、
かなり↑に書いた「知識のシェア問題」をより強く考える必要があると思いますね。
属人性の排除についてなんですが、「Aさんが不在で、属人化していて困った」というのが問題と考えれば、
２人か多くても３人で充分じゃないですかね。２人か３人「全員不在」になる確率ってどのくらいですかね？
退職して２→１人になった？じゃあまた、２人にする様に動けばよいんじゃないですかね。
どうも、この話の多分前提として、
「全員が同じスキルセットを持っている」というのがあるんじゃないかと思うんですが、
我々は人間であってロボットじゃないので、
キャリア・年齢・性別・性格・趣味・嗜好などが全然違うわけですよね。
ただ、だからといって本人の自由に好き勝手にやってもらっても、
属人化しちゃう部分が出てきたりすると（他人に伝えたり、ドキュメント書くのが得意じゃなかったり好きじゃないエンジニアもいますよね？）。
なので、それに気を付けつつも、でも本人のポテンシャルを最大限に発揮する為に大事な事を考える事が必要なのではと。
話が逸れますが、この辺「個人主義 VS チーム主義」の様な構図になっている感じもしましたね。
この辺は、目的や状況によるとしか言いようがないんですけどねぇ。
（３）このタスクの消化は、ソロだと出来ないので、ペアプロで補う
これは、いわゆる低スキル人材を何人集めても、
「医療行為は出来ない or 絶品料理は作れない or 高品質なITシステムは作れない」
みたいな話と一緒に感じますね。
ITシステムの話なら、例えば以下の様な「品質」じゃないですかね。
・異常系に対する対応が十分か？
・速度やメモリ不足に対する対応が十分か？
・脆弱性に対する対応が十分か？
・仕様変更や追加に対しての修正にかかる時間への意識
あるいは、最近の本なら以下の書籍も。
人が増えても速くならない ～変化を抱擁せよ～
https://www.amazon.co.jp/dp/4297135655
このシチュエーションでのポイントは、
「目的が、目先の作業時間を早くしたりするのではなく、教育である」
という側面が強くなるって事だと思いますね。
なので、そこが明確になっていれば良いと思うんですが、
果たしてどうでしょうかね。
「教育をすることによって、作業時間が早くなる」
のは、勿論そういう一面もあるとは思いますが、
でも、「すぐに」早くなりますかっていうのがポイントかなと。
長年仕事やっていて自分でも他人でも最近思うのは、
「スキルって、"すぐに"上がるとは限らないんだな」
ですね。
特に苦手分野なら、尚更かなと。
勿論、そのやり方で上手くいっているなら、別に止める必要はないと思いますけど、
そうでないのなら、ちょっと立ち止まって考えた方が良いんじゃないですかね。
ここからはまた、記事の言及に戻って、
で、以下の記事が良かったなと思いましたので、こちらにも言及します。
知識差-スキル差を埋めるためのペアプロ＋αのコツ(1)
https://twop.agile.esm.co.jp/bridge-gap-of-pairprogramming-part1-b1e97f452e4a
大前提：HRT原則を守ってパートナーと接することができる
関数型、オブジェクト指向、ユニットテスト、リファクタリングなどの基礎知識を有する
画像の部分のテキストなので引用が難しいのですが、
「基礎知識を有する」と書かれていて、
それが「ソロで作業が出来る」と必ずしもイコールではないと思いますが、
でも一定以上のスキルを求めているのは確かに感じますね。
教育目的のペアプロといえど、最低限の知識がないと言葉も発せられず指も動かずコードも書けません。教育をペアプロだけに頼る必要はありません。
ペアプロに拘る必要はないというのは、ここにもありますね。
あと、普通に良い記事なので、何も言及する事がないですね（笑）
知識差−スキル差を埋めるためのペアプロ＋αのコツ(2)
https://twop.agile.esm.co.jp/bridge-gap-of-pairprogramming-part2-cde572d24d9c
サイドバイサイドプログラミング
長いので引用しませんが
これが一番気になったんですよね。
というより、これまでのキャリアで散々この形式でやっていたんですけど（笑）
でも、本文に書かれている通り地味なんでしょうねって事で、
あまり話題に上がらないんですかね。
あと、中途半端感があるので、メリデメもハッキリしないのもありますかね。
あと、リモートだと若干工夫が必要な気もしないでもないですが、
ソロでやるにしてもペアでやるにしても、
このぐらいの距離感でやるのもアリなのではとは思いますけどね。
好みだけなら、僕はこれをベースに状況に応じてペアを組んだりソロになったりが一番好きですね。
色々と書いてきましたが、短文でまとめるなら以下の様な感じですかね。
・スキル差のあるペアの場合は、高スキル側の生産性低下による影響や低スキル側の習得確認が充分か気を付ける
・属人化を防ぐ為に知識を共有する人数が多くなればなるほど、コミュニケーションコストが増す事に気を付ける
・ペアプロの目的が、作業時間を早めたりする事なのか、教育目的なのかなど、ペアを組む前に明確にしておく
・ペアプロが有効に働くかは、タスクの難易度と担当するペアの組み合わせが重要
あと、ありきたりですけど、ペアプロも銀の弾丸ではないというか、
どの技術や手法でも、目的や状況に応じた実践が大切で、
「こういう状況や課題を抱えている時には、この技術や手法は有効だよ」
って事がポイントじゃないかと思いますね。
