Slide 1
Slide 1 text
ペアプロに納得感がなかった話
2024年11月7日
木村 昂史
Slide 2
Slide 2 text
2
経歴
ソフトウェア開発者としてSIerでの開発経験を経て、2020年に独
立。2023年に株式会社コドモンにジョイン。現在はEMとして複数
チームを兼務。5歳と2歳のパパ。
自己紹介
木村 昂史 きむら たかふみ
2023.11 コドモンに開発エンジニアとして入社
2023.12 プロダクト開発チームのEMになる
Slide 3
Slide 3 text
3
● ペアプロをすることで起きたマインドセットの変化
今日話すこと
Slide 4
Slide 4 text
4
● 具体的なペアプロのやりかた
● 実務上のペアプロの恩恵
今日話さないこと
Slide 5
Slide 5 text
5
2人1組でプログラミングをする
ソフトウェア開発手法
(3人以上でモブプロ)
ペアプロとは
Slide 6
Slide 6 text
6
● フロー効率が上がる
● 知識の循環が速い
● 学習効率アップ
ペアプロのメリット
● 属人化を防げる
● 設計品質の向上
● レビューコストの減少
Slide 7
Slide 7 text
7
● 自分で調べて解決できる
● チームメンバー (先輩など)の工数を奪わない
● 1人で全部できる人になりたい
誰もがエンジニア未経験だったあの頃...
Slide 8
Slide 8 text
8
一人称で開発可能です
Slide 9
Slide 9 text
9
一人称で開発可能です
● 一人称で開発可能な人材
● 一人称で仕事ができる人
● 現在の案件は一人称で開発をしております
Slide 10
Slide 10 text
10
他人に頼るのはプロじゃない
他人に頼るのはプロじゃない。
なぜなら一人称で開発が可能な人材でなければならないから。
己の力のみで問題を解決してこそ一人前の (プロ)プログラマー だ！
Slide 11
Slide 11 text
11
自力で解決できないことは恥である
他人に教えることはあっても、他人から教わることは自分の弱みを見せるこ
とになる。
わかったフリをして業務後にキャッチアップしてこそプロフェッショナルであ
る！
Slide 12
Slide 12 text
12
自分の評価はチームの中での定量評価で決まる
Aさんは5つチケットを消化して、 Bさんは8つ消化。7つの自分は Aさん以上Bさん以下だな。
仕事は責務をきっちり分割して、分析可能な数値として戦闘力が見えていた方が優劣を判断しやすい。
それぞれが決められた責務の中でベストを尽くすべき！
ペアで作業したら個人の成果が不透明になるから評価 (成果をアピール )しにくくなるぞ ...！
Slide 13
Slide 13 text
13
何かと闘っていたあの頃...
Slide 14
Slide 14 text
14
皆さんも、多かれ少なかれ
そんな時期がありませんでしたか？
何かと闘っていたあの頃...
Slide 15
Slide 15 text
15
自立したい気持ち > チームとしての成果
何かと闘っていたあの頃...
Slide 16
Slide 16 text
16
自立したい気持ち > チームとしての成果
↓
個人としての成果 > チームとしての成果
何かと闘っていたあの頃...
Slide 17
Slide 17 text
17
実際にペアプロをして起きた変化
Slide 18
Slide 18 text
18
タスクベースでの個人の成果が曖昧になる
Slide 19
Slide 19 text
19
タスクベースでの個人の成果が曖昧になる
● チームとして成果を上げよう
→ そのために自分に何ができるか
Slide 20
Slide 20 text
20
タスクベースでの個人の成果が曖昧になる
● 個人としての評価は定量評価ではなく、チームからの評価によって決める
→ ペアプロをしていく中でのイニシアチブや協力姿勢によってアピール
Slide 21
Slide 21 text
21
● フロー効率が上がる
● 知識の循環が速い
● 学習効率アップ
ペアプロのメリット
● 属人化を防げる
● 設計品質の向上
● レビューコストの減少
Slide 22
Slide 22 text
22
● フロー効率が上がる
● 知識の循環が速い
● 学習効率アップ
ペアプロのメリット
● 属人化を防げる
● 設計品質の向上
● レビューコストの減少
● マインドセットの軸足が個人からチームに移る
Slide 23
Slide 23 text
23
他人に頼るのはプロじゃない
他人に頼るのはプロじゃない。
なぜなら一人称で開発が可能な人材でなければならないから。
己の力のみで問題を解決してこそ一人前の (プロ)プログラマー だ！
Slide 24
Slide 24 text
24
🙆チームの成果を上げるために積極的に人を頼る🙆
1人で考えるよりも聞いてしまった方が早く正解に辿り着く確率が高い
（聞くコストはほぼゼロと言って良い）
→周囲を巻き込み早く問題を解決してこそ一人前の (チーム)プログラマー だ！
Slide 25
Slide 25 text
25
自力で解決できないことは恥である
他人に教えることはあっても、他人から教わることは自分の弱みを見せるこ
とになる。
わかったフリをして業務後にキャッチアップしてこそプロフェッショナルであ
る！
Slide 26
Slide 26 text
26
🙆自力で解決できないことはチームの伸び代🙆
自力で解決できない問題がある
→チームとして知識を循環させた方が属人化が起きない
→自力で解決できるように周囲がサポートする
→学習効率が高い
→チームの伸び代としてチームで対処する！
Slide 27
Slide 27 text
27
自分の評価はチームの中での定量評価で決まる
Aさんは5つチケットを消化して、 Bさんは8つ消化。7つの自分は Aさん以上Bさん以下だな。
仕事は責務をきっちり分割して、分析可能な数値として戦闘力が見えていた方が優劣を判断しやすい。
それぞれが決められた責務の中でベストを尽くすべき！
ペアで作業したら個人の成果が不透明になるから評価 (成果をアピール )しにくくなるぞ ...！
Slide 28
Slide 28 text
28
🙆自分の評価はチームへの貢献で決まる🙆
タスクベースでの定量評価ではなく
ペアプロをしていく中でのイニシアチブや協力姿勢によって評価する
Slide 29
Slide 29 text
29
● フロー効率が上がる
● 知識の循環が速い
● 学習効率アップ
ペアプロのメリット
● 属人化を防げる
● 設計品質の向上
● レビューコストの減少
● マインドセットの軸足が個人からチームに移る
Slide 30
Slide 30 text
30
● 個人としてスキルを上げていこう /自立していきたという姿勢はとても大切
● チームとしての成果を追い求めることも大切
● ペアプロはチームに軸足を置いて日々の業務に取り組むきっかけとなる
まとめ