チームでモブプログラミングを経験して得られたもの / Hatena Engineer Seminar #30

Hatena Engineer Seminar #30 チーム開発編

Transcript

1. チームでモブプログラミング を経験して得られたもの id:mds_boy 2024/06/27 Hatena Engineer Seminar #30 1
2. 自己紹介 2 • id:mds_boy • 2023年入社 • Webアプリケーションエンジニア • Mackerelチーム所属
3. 話すこと 3 • 当初の課題感 • モブプログラミングとは • モブプログラミングの実施 • まとめ
4. 4 当初の課題感
5. 前提：開発体制 5 • Mackerelの、とある新機能の開発チーム ◦ アプリケーションエンジニア3~4人 ▪ うち2人は（当時）入社数ヶ月以内 ◦ 基本的にフルリモート ◦ 細かい仕様は作りながら決めていく
6. 課題感 6 • 開発が思うように進まない ◦ 手が止まる要因 ▪ コードベースへの慣れ ▪ 仕様の理解、不確定な部分 → モブプログラミング、やってみよう！
7. 7 モブプログラミングとは？
8. モブプログラミングとは？ 8 • 3人以上の人々が1台のコンピューター の前に座って協力しながら問題を解決 していくこと[1] ◦ モブプロ、モビングなどと略される チームでプログラミングを しているイラスト [1] Mark Pearl (2018). Code with the Wisdom of the Crowd: Get Better Together with Mob Programming. Pragmatic Bookshelf. (マーク・パール 長尾高弘 (2019) モブプログラミング・ベストプラクティスソフトウェアの品質と 生産性をチームで高める)
9. モブプログラミングにおける役割 9 • ドライバー（タイピスト）👦 • ナビゲーター（モブ）👧👨🧑
10. モブプログラミングにおける役割 10 • ドライバー（タイピスト）👦 ◦ 1台のコンピューターに入力、操作をする人 ▪ ドライバーの操作する画面をみんなで見ることになる ◦ 同時に1人だけ
11. モブプログラミングにおける役割 11 • ナビゲーター（モブ）👧👨🧑 ◦ ドライバーに指示を出したり、自分の考えを共有する人 ◦ 基本的に、直接は入力を行わない ◦ ドライバー以外全員
12. 12 モブプログラミングの実施
13. 導入前の期待 13 • メンバー間で知識の共有が進むこと ◦ コードベース、仕様など ◦ いわゆるスキルトランスファー • 一定のペースで作業が進むこと ◦ 全員が一つのタスクに取り組むことになる
14. どうやったか 14 • ドライバーが画面を共有 ◦ ナビゲーターはその画面を見て会話する ◦ ドライバーは交代制 • VSCodeのLive Shareなども活用 ◦ ナビゲーターが手元でソースコードを見られる
15. どうだったか 15 • 不定期で「モブプロのふりかえり」を行い、 確認した ◦ いわゆる Good, Keep, Problem, Try
16. ふりかえり 16 • Good：事前の期待通りの効果が得られた ◦ メンバーのコードベースへの理解が進んだ ◦ 作業も一定のペースで進めることができた
17. ふりかえり 17 • Good：事前の期待以外の効果も得られた ◦ 実装、仕様の考慮漏れに気付きやすい ◦ 会話、議論の機会が増える ◦ 仕掛かり（WIP）タスクが減る
18. ふりかえり 18 • 実装、仕様の考慮漏れに気付きやすい ◦ コードレビュー前に気付ける ▪ レビュー前にレビューが行われているようなもの ◦ 仕様についての疑問が気軽に交わされる
19. ふりかえり 19 • 会話、議論の機会が増える ◦ 他のメンバーのことを知る ◦ 他のメンバーの「問題解決のための思考法」を知る ◦ 便利tipsを知れる ▪ 人の作業をまじまじ見ることはなかなかない
20. ふりかえり 20 • 仕掛かり（WIP）タスクが減る ◦ フロー効率を重視した開発 ◦ 現在進行中のタスクが1つだけになる ▪ 状況がわかりやすい ◦ タスク同士の依存関係による待ち、競合が起こらない
21. ふりかえり 21 • Problem ◦ 交代のタイミングが難しい ◦ 疲れやすい ◦ ドライバーの手が止まってしまう ◦ 会話だけで完結すると、テキストに残りづらい ◦ 個人のタスクを進める時間が取りにくい ◦ 比較的容易なタスクでも、全員の時間を使ってしまう → Try を出す
22. ふりかえり 22 • Problem → Try (1/2) ◦ 交代のタイミングが難しい ▪ → 交代を幅のある時間制に ◦ 疲れやすい ▪ → 交代時に休憩を挟む ◦ ドライバーの手が止まってしまう ▪ → 今何をしようとしているか、何を考えているか、意識して 声に出してもらう（実況スキル）
23. ふりかえり 23 • Problem → Try (2/2) ◦ 会話だけで完結すると、テキストに残りづらい ▪ → 意識してテキストに残す • 声を上げるのもナビゲーターの仕事 ◦ 個人の時間が取りにくい ▪ → モブプロをする時間帯を決める ⇨ 取り組み方の工夫で、ある程度問題を解消
24. 残った Problem 24 • Problem ◦ 交代のタイミングが難しい ◦ 疲れやすい ◦ ドライバーの手が止まってしまう ◦ 会話だけで完結すると、テキストに残りづらい ◦ 個人のタスクを進める時間が取りにくい ◦ 比較的容易なタスクでも、全員の時間を使ってしまう ▪ モブプロの性質上の問題 ▪ メンバーにスキルがつくにつれ、この場面が増える
25. モブプロの向き不向き 25 • 状況により向き不向きはある • 向いていそうな状況 ◦ その領域に自信がないメンバーがいるとき ◦ 仕様に不確定な部分が多くあるとき ◦ タスクを分割して並行に進めにくいとき ▪ プロジェクトの動き始めなど
26. 26 モブプログラミングを 経験してみて
27. 現在 27 • メインは分担作業 ◦ メンバーのコードベース理解も進んだため • 場面によって、モブプロも活用 ◦ メンバーの慣れていない領域に触れるとき ▪ タスクの一連の流れを全員で体感 ◦ 困っている状況の相談、解決 ▪ 今の状況を説明するスキルが役立つ
28. まとめ：モブプロを経験して得られたもの 28 • メンバーのコードベース理解が進んだ • メンバーのことをより知ることができた ◦ 会話しながら開発を進めたことで • モブプロという強い選択肢を得ることができた ◦ 向いている状況もわかった