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