フロントエンドエンジニアが顧客エンジニアとスクラムで伴走している話

Transcript

1. フロントエンドエンジニアが 顧客エンジニアとスクラムで伴走するために やっていること 1 クラスメソッド株式会社　高橋ゆうき 2023.08.04 クラスメソッドの最新開発ノウハウを学ぶ勉強会 〜エンジニア編〜
2. 2 自己紹介 高橋ゆうき クラスメソッド株式会社 CX事業本部Delivery部 フロントエンドチーム チームリーダー @hbsnow
3. 3 アジェンダ 1. 私がかかわっているプロジェクトのかんたんな説明 2. Gather 3. モブプロ 4. ペアプロ 5. Github Copilot Chat
4. 4 規模感 • フロントエンドエンジニア 6名 ◦ 私 ◦ プロパー 1名 ◦ パートナー 1名（木金不在） ◦ お客さんのエンジニア 3名 • バックエンドエンジニア 7名 • PO 2名・スクラムマスター 1名
5. 5 特徴 • プロジェクトの息が長い（3年以上たつ）ので、エンジニ アの入れ替わりが少なくない ◦ 特にリードする立場のフロントエンジニアに 入れ替わりが何度か発生してしまう • Redux Sagaが使われていて、小規模でもシンプルでもな いアプリですがジュニアレベルのエンジニアが学習のた めに参加することもある • デザイナー？いません
6. 6 特徴 その2 • スプリントは1週間 ◦ お盆休み、年末年始など例外で2週間になることも • スクラムイベントは水曜日 ◦ 10:30から昼休憩を挟んで16:30まで ▪ デプロイ作業があると…… ◦ ファシリテーションは全員ローテーション • スクラムオブスクラム ◦ 機能ではなく、バックエンドとフロントエンドで分か れている
7. 7 お客さんのエンジニアの参画時期 2020年 9月 2021年 1月 2021年 8月 2022年 10月 現在 2022年 3月 2022年 11月 2023年 2月
8. 8 意識してやったこと • 発言をしやすい雰囲気を作る ◦ 質問をしやすい・意見をいいやすい • お客さんの目標である、内製化ができるようになるこ とを極力支援できるように考えて行動する ◦ 何でも自分でやりすぎない
9. 9 質問しやすい雰囲気作り 逆の立場になって考えてみると、 雰囲気以前の話で、いきなりMeetやSlackのハドルで 呼び出して質問なんてそもそもしにくい。
10. 10 Gather
11. 11 ゲーム感のあるバーチャルオフィス
12. 12 うまくいかなかったプロジェクトでは…… • Gatherを使っているのにMeetのような運用になってい た ◦ 用事があるときに、用事がある人だけを呼ぶ ◦ 用件以外の会話があまり生まれない状況 ◦ 用事のある人しか呼ばないので、仮に雑談が発生し てもそれはチームというよりも個人間の会話にしか なっていなかった
13. 13 うまくいってたプロジェクトでは…… • Gatherがうまく運用できていた案件ではGatherに自然 と集まっていた ◦ そこでは案件の話もするし、それ以外の雑談もする ◦ よく知るメンバーなので、どんなときでも意見を言 いやすい
14. 14 このプロジェクトでもそうなりたい！ • 最初から自然に集まるというのは無理な話なので集まる時 間をつくった（15時-17時、カレンダーに登録） ◦ ただし任意で、強制はしない ◦ 誰も来なくても常に広いスペースにいる ▪ 個々の席にいるだけだとあまり意味がないので ▪ いつもいる人になる。誰もいないところに人はこな い ◦ 積極的に雑談もした ◦ 誰もこなくても泣かない
15. 15 モブプロ
16. 16 任意参加で週1の開催 • タイピスト1名（15分時間交代制）とモブからなる • タイピストは基本的にモブから指示されていないことを書 き込むことはできない • タイピストはモブの指示が不明瞭な場合は理解できるまで 質問する • お互いを信頼すること ◦ いや、そうじゃなくて・・禁止
17. 17 使う道具はこれだけ • VS CodeのLive Shareを使っています ◦ 普段別のエディタを使っている人はつらいかも • 記録はNotionに残しています ◦ 途中参加や作業が途中で終わったとき 翌週何をしていたか忘れるため • 場所はさきほど紹介したGather
18. 18 目的 • 習熟度の向上 • 知識の平準化による属人化の解消 • レビューコストの低減 • バグのバグ修正をやめたい
19. 19 特徴の振り返り • プロジェクトの息が長い（3年以上たつ）ので、エンジニ アの入れ替わりが少なくない ◦ 特にリードする立場のフロントエンジニアに 入れ替わりが何度か発生してしまう • Redux Sagaが使われていて、小規模でもシンプルでもな いアプリですがジュニアレベルのエンジニアが学習のた めに参加することもある • デザイナー？いません
20. 20 結果 • 主要ないくつかのページでコードの特徴が異なる • 散乱するつぎはぎのコピペコード • そもそも共通化すべきでないコードの共通化
21. 21 そして バグの修正で新たなバグが誕生
22. 22 よくわかる図解 バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR
23. 23 リリースは1週間間隔、ときにhotfix バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR 1スプリント 1スプリント
24. 24 ただバグ修正できていなかっただけなのに進捗はでる バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR 1スプリント 1スプリント 1pt 1pt 1pt
25. 25 ちょっと待った
26. 26 そもそもレビューで防げない？ 防げませんでした。根本の原因は今でもわかりませんが • 再現手順で再現せず、受け入れ条件を満たしていれば 問題ないのでApproveしやすいから？ ◦ それぞれ全員が自分の考える修正と異なる修正方法 でなくてもいいと思っていた ◦ 気になったくらいではコメントしない ▪ コメントだと修正圧が強いから？
27. 27 ラベルをつけるようにした 参考: コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話 https://zenn.dev/hacobell_dev/articles/code-review-comment-prefix
28. 28 とはいってもモブプロでは継続してバグ修正をしています • 複雑なバグ修正は後回しにされがち ◦ アサインでとったはいいけど、わからなくて戻す • バグ修正で既存の仕様調整が必要なものもあり、POが いてチーム全員の意見が確実に揃う安心感 • 間違った修正方針を取った場合、すぐに指摘がもらえ る
29. 29 ペアプロ
30. 30 ペアプロするタスク 30 • スプリントゴールになっている ◦ またはスプリントゴールでなくても優先度が高い • 難易度が高い ◦ 属人性が高くなってしまっている場所
31. 31 ペアプロする前のスプリントゴール 1. リファインメントでスプリント内でやるタスクを 決める 2. スプリントゴールを決める 3. アサインを決める • ここでスプリントゴールの担当者が決まる
32. 32 なにがおこったか 見積もりに失敗していた 難易度の高い スプリントゴールの担当者
33. 33 なぜこんなことに…… • 本来協力してやるべきスプリントゴールを担当者 にすべて任せっきりになっていた ◦ 難易度が高いタスクでは仕様調整が入る場合も 少なくない ◦ 調整した結果、実装都合でできないことも • 協力していた部分はレビューの優先のみ
34. 34 ペアプロ前のスプリントゴールの課題 • リファインメントでだしきれなかった仕様調整不足 があったとき、1人で難易度の高いスプリントゴー ルのタスクを抱えることは重圧になる ◦ リファインメントですべての仕様をだしきるこ とは不可能 • 負荷がチームで分散されない状態
35. 35 ペアプロによって解決したこと • CMのエンジニア+顧客エンジニアのペアを極力組む ようにしているため、CMのエンジニアがよりユー ザー目線をもった業務知識をもつエンジニアと協業 でき、よりよいプロダクトを作れる！ • 属人化の解消 • ペアなので心強い ◦ スプリントゴールの担当になっても休みやすい ◦ すぐ質問できる
36. 36 レンジャー
37. 37 レンジャーとは • 永和システムマネジメント社のAGILE STUDIOリ モート見学で知りました ◦ チーム内でさらにチームを作り、そのスプリン ト内はその組み合わせですべてのタスクを行う ◦ 組み合わせはスプリントごとでシャッフルする 見学先: スタジオ見学 | Agile Studio https://www.agile-studio.jp/tour
38. 38 こんなイメージ
39. 39 やりませんでした • やりませんでした、というよりもやれませんでした ◦ 別会社という壁 ▪ 始業時間の違い ▪ 社内業務 ◦ ペアでできる時間が限られてしまう
40. 40 ぼくたちはひとりじゃない・・・！ GitHub Copilot Chat
41. 41 Github Copilotのみでは正直物足りなかった • コメントはすべてというわけではないが、いい感じ に補足してくれる • 説明を書くとコードを書いてくれはする…… ◦ が、コード上のコメントアウトで指示をだすの で使いにくい
42. 42 zundoko() ここでEnterを押して……
43. 43 1回で全部出してほしいし、テストコードもほしいな…… •
44. 44 そうCopilot Chatならね
45. 45 解説もしてくれる、ありがとう！
46. 46 テストコードも聞くだけで
47. 47 コードの説明も対話式
48. 48 選択するだけでもオッケー ただしこの場合、すべて英語に なるので、メインのチャット ボックスで「以降はすべて日本 語で」などの指示をあらかじめ しておく必要があります
49. 49 とはいえ完璧ではない • とはいってもビジネスロジックゴリゴリみたいなと ころでうまくいくかというと、いまのところはそこ まででもない • ただ、わからないときに気軽に質問できる相手とし てとても優秀
50. 50 おわり ありがとうございました