ペアプロという選択肢

ペアプロのメリット・デメリットをまとめました

Transcript

1. ペアプロという選択肢 @nerusan
2. 目次 1. 背景 2. 提案 3. 効果 2
3. 目次 1. 背景 2. 提案 3. 効果 3
4. 背景：現状の開発課題 • 作った人が退職しており修正に時間がかかる • ドキュメントがない、間違っている、古い • コードが複雑で何か書いているかわからない • 誰かが休むと仕事が止まる • キャリアチェンジしにくい（フロントからバックなど） 4 属人化により運用が大変
5. 背景：ありたい姿 人の移動を前提とした開発体制 • 急な人の入れ替わりが発生しても 問題なく開発可能 ◦ キャリアチェンジ ◦ 転職 ◦ 休暇 5 フロントエンド React/CSS/TS バックエンド Go/SQL/REST
6. 背景：課題 とりあえず動くものを早くお客様に届けることが評価される文化を変え ることが大事 • 運用をあまり考えていない個人任せの開発スタイル • とりあえず動くものを早くお客様に届けることが評価される文化 • シンプルより多機能(一部顧客しか利用しない機能)が良いとされる 6 技術力に対して月のリリースが多 くて作るので手一杯... 人が足りず、スケジュールも間に 合わない... 企画 開発
7. 目次 1. 背景 2. 提案 3. 効果 7
8. 提案：アジャイル開発の登場 短いサイクルで繰り返し開発することで素早く開発する手法 • XP（エクストリームプログラミング） ◦ 変更への対応力を高めた手法 ◦ テスト駆動開発 ◦ ペアプログラミング/モブプログラミング • スクラム ◦ スケジューリングや進捗を重視する手法 ◦ デイリースクラム ◦ スプリントプランニング 8
9. 提案：アジャイルが解決すること 長期運用を見据えた開発が可能 9 https://udemy.benesse.co.jp/development/system/agile.html
10. 提案：ペアプログラミングの提案 1つのエディターを共有して2人でコードを実装する アジャイル開発とともに採用されることが多い ２人以上で行うことはモブプログラミングともいう 10 ドライバー コードを書く人 ナビゲーター ドライバーを補佐
11. 提案：具体的なやり方：設計 設計とテスト作成もペアで行い、抜け漏れを防ぐ ペアの組み合わせ • バックエンド１名、フロント１名 ←人員不足も解消できる • バック２名 • フロント２名 11
12. 提案：具体的なやり方：実装 • ドライバー ◦ 主導的にコードを書く • ナビゲーター ◦ ドライバーの補佐 ◦ ドライバー行き詰まったら一緒に考える ◦ リファクタの指示 ◦ 仕様書確認・更新 • 1時間おきまたはキリの良いタイミングで交代 12
13. 提案：具体的なやり方：フロント１名バック１名の場合 13 設計 バック実装 フロント実装 テスト ペアで詳細設計 Swagger作成 DB設計 画面設計 ペアプロ Swagger・仕様書 をもとに実装 ペアプロ Swagger・仕様書 を元に実装
14. 目次 1. 背景 2. 提案 3. 効果 14
15. 効果：メリット • キャリアチェンジしやすい ◦ フロント、バックどちらもチャレンジしやすい環境 ◦ 一方の人員不足を解消できる • 人の出入り容易 ◦ 新しい人は入りやすいし、転職しやすい ◦ 採用に繋がる • 相互確認でミスを防止 ◦ コード及びサービス品質向上 • リモートによるコミュニケーション不足の解消 ◦ 相談しやすいので効率にも繋がる • エディターの使い方、コマンド操作も学べる 15
16. 効果：デメリット • 工数が増える ◦ 毎月のリリースを少し調整する必要がある • 対立が起きると効率が下がる ◦ 実装方法の違いで争う可能性がある • 自身のペースでできない ◦ 一人でやる方が効率的な人にとって不向き 16
17. 効果：デメリットに対する考え • 工数が増える →トラブル対応が全員可能 →技術的ナレッジ形成 →長期的にみて効率化につながる • 毎月のリリースを調整（減らす）する必要がある →代わりに品質活動に時間を当てているので今後の拡張性、品質が良くなる →スウォーミングを導入するなどで改善 17
18. 効果：工数 Laurie Williamsのペアプロ効果に対する研究[1]によると、ペアプロによって 工数が2倍になるのではなく 15%増、バグの数は15%減 プログラムの正確性は15%向上し、最終的な成果としては、 15%から 60%の効率向上があるとされている [1] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF 18
19. 提案：採用している会社 メルカリ https://engineering.mercari.com/blog/entry/2018-06-27-100628/ サイボウズ https://blog.cybozu.io/entry/2022/06/08/141944 https://blog.cybozu.io/entry/2022/04/14/170000 LayerX https://tech.layerx.co.jp/entry/2021/04/09/090000 Yahoo https://about.yahoo.co.jp/hr/linotice/20180925.html 19
20. 提案：採用している会社 ZOZO https://techblog.zozo.com/entry/remote-pairprogramming グロービス https://note.com/globis_engineers/n/n739a36da3893 クラスメソッド https://dev.classmethod.jp/articles/try-remote-pair-programming/ ホワイトプラス https://style.wh-plus.co.jp/enginners-development-style-b/ 20
21. 提案：サイボウズの事例１ • 基本モブプロ • 参加人数2~4人 • ドライバー ◦ ナビゲーターに説明しつつ自主的 にどんどん記述 ◦ 行き詰まったらナビゲータと解決 に向けて調査 • ナビゲーター ◦ ドライバーの意図を読み取り、リ ファクタの指示などしたりする ◦ つまづいた点、参考になった点な どメモに残す（ナレッジ形成） 21 https://blog.cybozu.io/entry/2022/04/14/170000
22. 提案：サイボウズの事例２ ソロプロとモブプロを両立したスウォーミング 22 https://blog.cybozu.io/entry/2022/06/08/141944
23. 提案：サイボウズでの事例２ 23 優先度の高いタス ク担当者をキャプ テン 優先度 高
24. 提案：サイボウズの事例２ キャプテンから招集がかかれば、メンバーは作業を止めて、 モブプログラミングを行い早急解決に努める 24