この記事は、NTTテクノクロス Advent Calendar 2020の21日目です。
NTTテクノクロス エンタープライズ事業部の中島です。
普段はコンシューマ向けモバイルアプリをアジャイルで開発しています。
はじめに
私のいるプロダクトチームではLeanXPというアジャイルな開発手法を採用しており、その手法ではペアワークを必須としています。本記事ではそのペアワークについて扱います。
LeanXPによる開発
LeanXPとはPivotal Labs が実践している開発手法です。1
LeanXPには３つのロールがあります。このロールで一つのプロダクトチームを構成します。
- Product Manager
- 「このプロダクトを作ることで、ビジネス上の成果が生まれるか？」（Lean Startup）
- Product Designer
- 「ユーザーはこのプロダクトに価値を見出すか？」（User-centered design）
- Developer
- 「このプロダクトを最も技術的にシンプルに実現させるにはどうしたらいいか？」(Extreame Programming)
LeanXPではDeveloper以外でもペアワークが必須です。
同じ場所での作業が推奨ですが、ニューノーマルの時代ではリモートで画面共有してペアワークします。
Developerによるペアプログラミングは分かるけど、Product ManagerとProduct Designerもペアワークが必須なの？ と思った方もいらっしゃるかもしれません。
では、まずはDeveloperのペアプログラミングについて考えてみましょう。
ペアプログラミングの7つの相乗的な方法
ピアソン・エデュケーションから発刊された『ペアプログラミング―エンジニアとしての指南書』2の第3章のペアプログラミングの7つの相乗的な方法を挙げてペアプログラミングについて考えてみましょう。
- ペアプレッシャー
- パートナーを失望させたくないから、熱心かつ懸命に取り組むようになる
- 共有する時間を貴重にし、お互いの時間を無駄にすることが無くなる
ペアでいると相手を意識して、ついボーっとしてしまうというようなことや、ブラウザでIT系ニュースサイトを巡ったりということはできないですよね。
相手の時間も共有して消費しているんだ、という意識が無駄を省く行動に向かわせます。
- ペア間の交渉
- 分散認知により共同で最適の解決策に到達する
1人1人違うスキルや知識を持っています。
お互いで選択肢を提案しあいより良い解決方法にたどりつけます。
- ペア間の勇気
- パートナーに確認すると、一人で行う不安、ただ避けるか決して行わないかもしれないことを、実行する勇気が生まれる
自分の仕様の理解が正しいかコードが正しいか時には不安になることもあるでしょう。
先ほどのペアプレッシャーでも述べた通り、相手の時間を無駄にしたくないという思いも働き、積極的に自分が知らないということを認め、相手に伝えることができます。知らないことを認める勇気を持つことでお互いの能力を把握し、自分たちが今の能力でできる最高のアウトプット、アウトカムはどういうものなのか、を考えることができます。
- ペアレビュー
- アウトプットに対して同時にレビューを実施する
- 欠陥を早期に発見するほど修正のコストは少ない
近年では多くの企業がコードレビューを取り入れていると思います。
開発者がプルリクエストをしてレビュアーがレビュー後マージするような開発ではないでしょうか。
ペアプログラミングでは常にペアであり、一人が書いたコードはもう一人がレビューしています。
つまり常にレビューが同時に実施されているのです。開発者とレビュアーが別々にいる場合よりも、より早く欠陥に気づけます。それにより修正コストも少なくなります。
- ペアデバッグ
- 人に説明したり人と質疑応答することで、問題が解決したり大きな発見がある。
デバッグで詰まったときに、他のメンバに助けを求めて事象を説明し、その説明をするだけで自己解決できた経験はありませんか。人に伝えようと整理することで解決方法が浮かぶことは良くありますよね。ペアでデバッグしていると常にそのような状態を作れます。
- ペア間の学習
- 知識・スキルだけでなく習慣や思考方法も学べる
- 学習効果を高めるためにはペアスワッピングが推奨されている
初心者でもベテランでも様々な経験をしているはずです。そこにはお互いに持っていないプロダクトに関する知識、スキル、観点などが必ずあるはずです。それらをペア間で補完しあい、お互いが学習することができます。
私のいるプロダクトチームではペアを毎日変えてペアの相手から学びを得ています。
- ペア間の信頼
- ペアは互いに信頼しあわなければならない
- チームで培われた信頼はチームの成長に貢献する
ペアで業務を円滑に進めるにはお互いをリスペクトして信頼する必要があります。
それはペアだけでなくチームでも必要です。心理的安全性の高いチームを目指していきましょう。
ペアプログラミングの7つの相乗的な方法を振り返って
さて、ペアプログラミングの7つの相乗的な方法を振り返ってみると、Developerのみに当てはまるものではないですよね。
では、Product ManagerとProduct Degisnerにも当てはめた例を考えてみましょう。
Product Manager でのペアの効果
- 捨てる勇気
Leanの考えに従って無駄を省くには機能を捨てる勇気も必要です。
今までリサーチしてきた稼働、途中まで実装した稼働を思い返し、一人では本当に捨てて良いものか決定できないこともあるでしょう。
ペアで話し合えばその不安も和らぎ、確信をもって捨てられるのではないでしょうか。
もちろん、DesignerやDeveloperと話しても不安は和らぐでしょう。
ですが、同じProduct Managerとしてビジネスの視点に最も重きを置いたメンバーと話すことが一番効果的だと考えます。
- 能力の補完・学習
PMに求められていることは非常に多いです。
ビジネスに関しての視点に重きを置くとはいえ、テクノロジー、クリエイティブのそれぞれの知見が必要です。
完璧な人などいません。同じ立場のペアで補完しあって相乗効果を得たいです。
Product Designer でのペアの効果
- PDに求められるのはArt(芸術)ではなくDesign（設計）
最近はようやく変わってきた気もしますが、デザイナーを募集するとアーティストが応募してきます。
面談では『自分は〇〇のHPでこのような絵を描いてきた』など、自身の創造性をアピールしてきます。
創造性があること自体は良いことですが、自身をアーティストと思っている人は思い込みが強い印象です。
ユーザリサーチで仮説検証していない課題やアイデアは全て思い込みです。（極論）
Product Designerに求められるのは徹底的なユーザリサーチにより仮説を検証していくことです。
それは論理的な積み重ねであり、Developerのペアプロと同様に、ペアでの分散認知やレビューは有効です。
- 共感による仮説への確信
自己満足で独りよがりな感性は不要ですが、ユーザに共感できる感性は非常に重要です。
とくにユーザインタビュー時はユーザ自身が気づいていないペインに気付く共感力があるとインタビューの効率が上がります。
しかし共感とは曖昧であって一人だと正しいか不安になります。自分以外の誰かが同じ共感を持ってくれることで、仮説が正しい（誤っている）と確信できます。
- Developerとのペアワーク
DeveloperとペアワークすることでAndroidやiOSの仕組みについて知識が増えます。Developerが嫌がるような無茶なDesignの要求が減ります。（なくなりはしません）
どうですか？ Product ManagerもProduct Designerもペアワークをした方が良いと思いませんか？
では、次にチームが持続的に成長するために、なぜペアが必要かを考えてみましょう。
持続することへの阻害要因
- 特定のドメイン知識を持っているメンバーの突然の休暇・離脱
『バス係数(バスカウント)』という言葉はご存知でしょうか。
チームメンバーが何人バスにはねられたらプロダクト開発が失敗するかというものです。
プロダクトに関して、あるメンバーのみ知っているというのはとても危険です。
そのメンバーが離職したり、転勤になるリスクは常にあります。職業選択は労働者の自由です。アハハン。
バス係数を上げるためにペアワークは非常に有効です。
例えばAndroidアプリ、iOSアプリ、APIサーバを一つのチームで開発しているとき、昨日はAndroid/Kotlin、今日はiOS/Swift、明日はSpringBoot/Kotlinなど毎日違うペアで開発して、全員がプロダクトの全ての箇所を触れるようにすることで、誰が抜けても大丈夫なようにするのが理想です。
また、バス係数が1のところを担当しているメンバーは休むとそこの開発が進まないというプレッシャーがあるかもしれません。個人的な印象ではありますが、気軽に休みが取れないチームはモチベーションは低く生産性も低くなりがちと考えます。
- チームに永続的に貢献できる優秀なメンバーが採用できない
そんな願望は捨ててください。そんなメンバーは現れません。
短期でもチームに良い文化を持ち込んでくれればと割り切ると採用しやすいと考えます。
優秀な人がチームにいてくれるのは短期でもペアワークにより、そのスキル・能力・文化を定着させやすいです。
- Product Manager、 Product Designer不在時に開発が止まる
User Storyに問題が発覚した際にProduct Managerが打ち合わせ、Product Managerがユーザインタビューで不在時でコミュニケーション取れないなんてことはありませんでしたか。
そんなとき、手を付けられないStoryを横に置き、優先度がそれよりも低いStoryに手を付けてしまうということはありませんでしたか。
ペアであれば片方はDeveloperとのコミュニケーションを優先でき、開発に無駄が発生しません。
- チームをスケールできない
Productを成長させたくないチームはないと思います。
Productの成長に従いチームの規模が大きくなり、スケールしたくなってもProduct Manager、 Product Designerが一人だけだと、今まで培ってきたチームの文化を新しいチームに継承できません。
ペアワークをしていれば、同じ文化を持った状態で二つのチームにスケールできます。
ペアワークへの課題
- 業績評価
常にペアワークしていると個人での成果が分かりづらいです。
チームメンバからの評価を参考にマネージャが判断するなどの工夫が必要だと考えます。
- ペアワークについての上層部の理解
一つのことについて倍の工数をかけるのかと疑問視されることもあるでしょう。
しかしペアワークの方が学習効果も高く、品質も上がるというデータは今ではネット上にもたくさんあります。
バス係数が低いことでProductが継続できないリスクも踏まえて上層部を説得しましょう。
- ペアで複数のプロダクトを押し付けられる
ペアワークは認めるけど一つのプロダクトに稼働を書けるのはもったいないから３つのプロダクトを任せよう、なんてことがあった会社さんもいるようです。
ですが大抵の人はそんな器用じゃないし破綻しました。
一つのプロダクトに集中すべきです。
まとめ
- ペアワークはとても大事
- ペアワークにより学習効果を高め、品質も上げよう
- メンバーが流動的になってもプロダクト開発が止まらないようにペアワークをしてバス係数を上げよう
- プロダクトが大きくなったときにチームがスケールできるようにペアワークしよう
- バランスチームを作り最高のアジャイル開発を
おわりに
ここまで読んでいただいてありがとうございます。
今回の記事でペアワークを始めたいと思っていただけると幸いです。
明日は、NTTテクノクロス Advent Calendar 2020の22日目、watanyさんにバトンタッチします。