Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ペアプロという選択肢
Search
nerusan
February 08, 2023
Programming
0
820
ペアプロという選択肢
ペアプロのメリット・デメリットをまとめました
nerusan
February 08, 2023
Tweet
Share
More Decks by nerusan
See All by nerusan
Git・Git-Flowについて
nerusan_main
0
770
Other Decks in Programming
See All in Programming
The Cutting Edge Of Versioning (LambdaConf 2024)
chriskrycho
0
250
TypeScriptの型とパフォーマンス (TSKaigi 2024)
ypresto
14
5.1k
Long journey of Ruby standard library RubyKaigi 2024
andpad
2
280
TypeScript 関数型スタイルでバックエンド開発のリアル
naoya
49
16k
Embedding it into Ruby code
soutaro
2
410
Amazon Aurora Serverless v2が意外と高かった話と、AWS Database Migration Serviceの話
satoshi256kbyte
1
110
Escolhendo (ou não) o melhor ORM para o seu projeto
andreiacsilva
1
160
RustでAWS Lambda functionをいい感じに書く
taiki45
2
160
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
13
4.4k
教えて!スクラムコーチ品質とスピードのバランスはどうすりゃいいの?
pinboro
0
150
JavaScript Closure
asoluka
0
2k
GoでParserを書く
karupanerura
3
440
Featured
See All Featured
How to Ace a Technical Interview
jacobian
273
22k
Producing Creativity
orderedlist
PRO
338
39k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Docker and Python
trallard
35
2.7k
Making the Leap to Tech Lead
cromwellryan
125
8.6k
Building Your Own Lightsaber
phodgson
100
5.7k
Into the Great Unknown - MozCon
thekraken
15
1.1k
Infographics Made Easy
chrislema
238
18k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
8
3.5k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
A Tale of Four Properties
chriscoyier
153
22k
Transcript
ペアプロという選択肢 @nerusan
目次 1. 背景 2. 提案 3. 効果 2
目次 1. 背景 2. 提案 3. 効果 3
背景:現状の開発課題 • 作った人が退職しており修正に時間がかかる • ドキュメントがない、間違っている、古い • コードが複雑で何か書いているかわからない • 誰かが休むと仕事が止まる •
キャリアチェンジしにくい(フロントからバックなど) 4 属人化により運用が大変
背景:ありたい姿 人の移動を前提とした開発体制 • 急な人の入れ替わりが発生しても 問題なく開発可能 ◦ キャリアチェンジ ◦ 転職 ◦
休暇 5 フロントエンド React/CSS/TS バックエンド Go/SQL/REST
背景:課題 とりあえず動くものを早くお客様に届けることが評価される文化を変え ることが大事 • 運用をあまり考えていない個人任せの開発スタイル • とりあえず動くものを早くお客様に届けることが評価される文化 • シンプルより多機能(一部顧客しか利用しない機能)が良いとされる 6
技術力に対して月のリリースが多 くて作るので手一杯... 人が足りず、スケジュールも間に 合わない... 企画 開発
目次 1. 背景 2. 提案 3. 効果 7
提案:アジャイル開発の登場 短いサイクルで繰り返し開発することで素早く開発する手法 • XP(エクストリームプログラミング) ◦ 変更への対応力を高めた手法 ◦ テスト駆動開発 ◦ ペアプログラミング/モブプログラミング
• スクラム ◦ スケジューリングや進捗を重視する手法 ◦ デイリースクラム ◦ スプリントプランニング 8
提案:アジャイルが解決すること 長期運用を見据えた開発が可能 9 https://udemy.benesse.co.jp/development/system/agile.html
提案:ペアプログラミングの提案 1つのエディターを共有して2人でコードを実装する アジャイル開発とともに採用されることが多い 2人以上で行うことはモブプログラミングともいう 10 ドライバー コードを書く人 ナビゲーター ドライバーを補佐
提案:具体的なやり方:設計 設計とテスト作成もペアで行い、抜け漏れを防ぐ ペアの組み合わせ • バックエンド1名、フロント1名 ←人員不足も解消できる • バック2名 • フロント2名
11
提案:具体的なやり方:実装 • ドライバー ◦ 主導的にコードを書く • ナビゲーター ◦ ドライバーの補佐 ◦
ドライバー行き詰まったら一緒に考える ◦ リファクタの指示 ◦ 仕様書確認・更新 • 1時間おきまたはキリの良いタイミングで交代 12
提案:具体的なやり方:フロント1名バック1名の場合 13 設計 バック実装 フロント実装 テスト ペアで詳細設計 Swagger作成 DB設計 画面設計
ペアプロ Swagger・仕様書 をもとに実装 ペアプロ Swagger・仕様書 を元に実装
目次 1. 背景 2. 提案 3. 効果 14
効果:メリット • キャリアチェンジしやすい ◦ フロント、バックどちらもチャレンジしやすい環境 ◦ 一方の人員不足を解消できる • 人の出入り容易 ◦
新しい人は入りやすいし、転職しやすい ◦ 採用に繋がる • 相互確認でミスを防止 ◦ コード及びサービス品質向上 • リモートによるコミュニケーション不足の解消 ◦ 相談しやすいので効率にも繋がる • エディターの使い方、コマンド操作も学べる 15
効果:デメリット • 工数が増える ◦ 毎月のリリースを少し調整する必要がある • 対立が起きると効率が下がる ◦ 実装方法の違いで争う可能性がある •
自身のペースでできない ◦ 一人でやる方が効率的な人にとって不向き 16
効果:デメリットに対する考え • 工数が増える →トラブル対応が全員可能 →技術的ナレッジ形成 →長期的にみて効率化につながる • 毎月のリリースを調整(減らす)する必要がある →代わりに品質活動に時間を当てているので今後の拡張性、品質が良くなる →スウォーミングを導入するなどで改善
17
効果:工数 Laurie Williamsのペアプロ効果に対する研究[1]によると、ペアプロによって 工数が2倍になるのではなく 15%増、バグの数は15%減 プログラムの正確性は15%向上し、最終的な成果としては、 15%から 60%の効率向上があるとされている [1] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
18
提案:採用している会社 メルカリ 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
提案:採用している会社 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
提案:サイボウズの事例1 • 基本モブプロ • 参加人数2~4人 • ドライバー ◦ ナビゲーターに説明しつつ自主的 にどんどん記述
◦ 行き詰まったらナビゲータと解決 に向けて調査 • ナビゲーター ◦ ドライバーの意図を読み取り、リ ファクタの指示などしたりする ◦ つまづいた点、参考になった点な どメモに残す(ナレッジ形成) 21 https://blog.cybozu.io/entry/2022/04/14/170000
提案:サイボウズの事例2 ソロプロとモブプロを両立したスウォーミング 22 https://blog.cybozu.io/entry/2022/06/08/141944
提案:サイボウズでの事例2 23 優先度の高いタス ク担当者をキャプ テン 優先度 高
提案:サイボウズの事例2 キャプテンから招集がかかれば、メンバーは作業を止めて、 モブプログラミングを行い早急解決に努める 24