2021年6月26日に開催されたScrum Fest Osaka 2021 で発表した資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15410

1. ペアワークで持続的に
成長するチームになろう！
2021/06/26
Scrum Fest Osaka 2021
XP祭りトラック
NTTテクノクロス株式会社 中島進也

2. 自己紹介
• 中島進也（なかしょ @nakasho_dev ）
• 所属：NTTテクノクロス株式会社
デジタルトランスフォーメーション事業部
第二ビジネス事業ユニット
• 業務：MaaS関連のスマートフォンアプリ開発担当
• 趣味：
IT関連の勉強会（主にモバイル系 or アジャイル系）
技術コミュニティの運営スタッフ
eXtreme Programming Japan User Group（XPJUG） 2019〜
TDD BootCamp Online (TDDBC) 2020〜
Japan PlayFab User Group（JPFUG）2020〜
Japan Xamarin User Group（JXUG）2016〜
2
※本資料は私個人の意見であり、所属企業・部門見解を代表するものではありません。

3. Lean XPによる開発
参考：Pivotal Labsって一体なに？（https://medium.com/product-run/8d96000f2791）
3

4. LeanXP ではDeveloper以外もペアワーク
4
Product Manager 2名 Product Desginer 2名
・・・
Developer 2名〜8名
常にペア・常に同じ場所で作業

5. LeanXP ではDeveloper以外もペアワーク
5
Product Manager 2名 Product Desginer 2名
・・・
Developer 2名〜8名
常にペア・常に画面共有して作業

6. Developerのペアプロ
は分かるけど、
Product Managerと
Product Designerの
ペアワークってどう
いうものだろう？
6

7. まずはDeveloper(Dev)の
ペアプロの効果を考えよう
7

8. ペアプログラミングの7つの相乗的な方法(1/3)
• ペア間の交渉
分散認知により共同で最適の解決策に到達する
• ペアデバッグ
人に説明したり人と質疑応答することで、問題が解決したり大きな発見がある。
• ペア間の学習
知識・スキルだけでなく習慣や思考方法も学べる
学習効果を高めるためにはペアスワッピングが推奨されている
8
参考：ペアプログラミング―エンジニアとしての指南書(ピアソン・エデュケーション)

9. ペアプログラミングの7つの相乗的な方法(2/3)
• ペアプレッシャー
パートナーを失望させたくないから、熱心かつ懸命に取り組むようになる
共有する時間を貴重にし、お互いの時間を無駄にすることが無くなる
• ペアレビュー
アウトプットに対して同時にレビューを実施する
欠陥を早期に発見するほど修正のコストは少ない
9
参考：ペアプログラミング―エンジニアとしての指南書(ピアソン・エデュケーション)

10. ペアプログラミングの7つの相乗的な方(3/3)
• ペア間の勇気
パートナーに確認すると、一人で行う不安、ただ避けるか決して行わない
かもしれないことを、実行する勇気が生まれる
• ペア間の信頼
ペアは互いに信頼しあわなければならない
チームで培われた信頼はチームの成長に貢献する
10
参考：ペアプログラミング―エンジニアとしての指南書(ピアソン・エデュケーション)

11. この効果って、Developerのみ
に当てはまるわけじゃないよ
ね。
11

12. Product Manager(PM)のペアワーク
• 捨てる勇気
Leanの考えに従って、機能を捨てるには勇気がいる
ペアで話し合えば確信をもって捨てられる
• 能力の補完・学習
PMに求められていることは多い。ビジネス、テクノロジー、クリエイティ
ブのそれぞれの知見が必要である。
完璧なPMなどいない。ペアで補完しあって相乗効果を得る。
12

13. Product Designer(PD)のペアワーク
• PDに求められるのはArt(芸術)ではなくDesign（設計）
「もの」「こと」を意識したUI/UXのDesignが重要
個人の感性に依存しないため、ペアでのレビューやデバッグは有効
• 共感による仮説への確信
ユーザインタビューで仮説を検証する際は共感が重要
自分以外の誰かが同じ共感を持ってくれることで、仮説が正しい（誤って
いる）と確信できる
13

14. Product ManagerとProduct Designerのペア
• PMとPDはペアで作業することが多い
• Discovery & Framing
問題発見⇒価値探求⇒問題解決までの一連の検証プロセス
• ビジネス視点だけではユーザに受け入れられない
ソリューションだけでなくユーザ体験を意識した視点が必要
• ユーザインタビュー
ビジネスとユーザ体験の両方の観点でユーザを理解できる
14

15. Product DesignerとDeveloperのペア
• モバイル, Web, Desktop等で最適な体験を提供するには各プラット
フォームの知識は必須
Material Design（Google）
Human Interface Guidelines（Apple）
Fluent Design System（Microsoft）
• DevとペアすることでPDは各プラットフォームの特徴をつかみや
すくなる
• PDとペアすることでDevはアプリのコンセプトデザインへの理解
が深まる
15

16. Product ManagerとDeveloperのペア
• 運用者側のUser Storyなどはシステムの運用を知っているDevとペ
アになることで抜け漏れが防げる
とくにエラー系のStoryはシステムが分かっていないとStoryが書けない
• 外部サービスとの連携の際、一緒にAPIを叩いて実現イメージを膨
らませる
• チームのダッシュボードのカスタマイズを一緒にやることで、チー
ムメンバ全体で共有したくなるダッシュボードを構築
• Devはドメイン知識を深めたうえでの技術提案ができるようになる
16

17. ペアワークで持続的に
成長するチームになろう！
今までは
こちらの話
17

18. ペアワークで持続的に
成長するチームになろう！
これからは
こちらの話

19. 持続することへの阻害要因（1/4）
• 特定のドメイン知識を持っているメンバーの突然の休暇・離脱
ペアワークによりバス係数を上げる
気軽に休暇等が取れないチームは生産性が低い印象
19

20. 持続することへの阻害要因（2/4）
• チームに永続的に貢献できる優秀なメンバーが採用できない
そんなメンバーは現れない
短期でもチームに良い文化を持ち込んでくれればと割り切ると採用しやす
い
短期でもペアワークにより、その文化を定着させやすい
20

21. 持続することへの阻害要因（3/4）
• PM、PDがユーザインタビュー等で不在時にDevがコミュニケー
ション取れない
ペアであれば片方はDevとのコミュニケーションを優先できる
MVPでなくMVFで作るには密なコミュニケーションが必須
21
ルームB ルームA
割り込んで質問・
確認できる

22. 持続することへの阻害要因（4/4）
• チームをスケールできない
ペアであれば二つのチームにスケールできる
22

23. ペアワークへの課題（1/2）
• 業績評価
個人での成果が分かりづらい
チームメンバからの評価を参考にマネージャが判断するなどの工夫が必要
• ペアワークについての上層部の理解
一つのことについて倍の工数をかけるのか疑問視される
ペアワークの方が学習効果も高く、品質も上がるというデータを見せる
バス係数が低いことのリスクを訴える
23

24. ペアワークへの課題（2/2）
• ペアで複数のプロダクトを押し付けられる
大抵の人はそんな器用じゃないし破綻する
一つのプロダクトに集中すべき
• フルタイムのペアワークに不向きな人がいる
常にコミュニケーションを取り続けるのは疲れる
最初のうちは慣れている人が休憩をコマ目に促そう
どうしても合わなければメンバから外す選択も
24

25. まとめ
• ペアワークはとても大事
• ペアワークにより学習効果を高め、品質も上げよう
• メンバーが流動的になってもプロダクト開発が止まらないよ
うにペアワークをしてバス係数を上げよう
• プロダクトが大きくなったときにチームがスケールできるよ
うにペアワークしよう
• バランスチームを作り最高のアジャイル開発を
25

26. ご清聴ありがとうございました。
26
なかしょ（中島 進也）
@nakasho_dev