お客さんのエンジニアとスクラムで 併走している話

Transcript

1. お客さんのエンジニアとスクラムで 併走している話 1
2. 2 自己紹介 高橋ゆうき クラスメソッド株式会社 CX事業本部Delivery部 フロントエンドチーム チームリーダー @hbsnow
3. 3 今日話したいこと • 今日自慢したい、2年以上続いているプロジェクトの簡 単な説明 ◦ 起こっていた問題とその改善策 • 3人のお客さんのエンジニアとリモートのスクラムで併 走している話 ◦ 開発をはじめてから1年程度のメンバー ◦ 全員、それまでプログラミング未経験
4. 4 今日自慢したいあるプロジェクトの話 • 今日自慢したい、2年以上続いているプロジェクトの簡 単な説明 ◦ 起こっていた問題とその改善策 • 3人のお客さんのエンジニアとリモートのスクラムで併 走している話 ◦ 開発をはじめてから1年程度のメンバー ◦ 全員、それまでプログラミング未経験
5. 5 今日自慢したいプロジェクトの参加履歴 2020年 9月 参加期間1 参加期間2 2021年 1月 2021年 8月 2022年 10月 現在 ※要件定義の期間は含めていません
6. 6 最初からは参加できず • 最初から参加していなかった（入社していなかった） ので、技術選定や設計にはかかわれていません。 参加期間1 参加期間2 2021年 8月 2022年 10月 現在 2020年 9月 2021年 1月
7. 7 入社後すぐにアサインされた • 入社後プロジェクトに参加。このときは、割り当てら れたタスクをもくもくとこなすだけ。 参加期間1 参加期間2 2022年 10月 現在 2020年 9月 2021年 1月 2021年 8月
8. 8 長期の離脱期間 • 別プロジェクトに移動。長期の離脱期間が発生し、正 式リリースもこの期間に行われました。 参加期間1 参加期間2 現在 2020年 9月 2021年 1月 2021年 8月 2022年 10月
9. 9 でもどり • 別プロジェクトが終了したため、でもどり。 （前回よりも期待されている雰囲気……！） 参加期間1 参加期間2 2020年 9月 2021年 1月 2021年 8月 2022年 10月 現在
10. 10 現在のプロジェクトの規模感 • フロントエンドエンジニア ◦ 私 ◦ プロパー 1名 ◦ パートナー 1名（木金不在） ◦ お客さんのエンジニア 3名 • バックエンドエンジニア 7名 • PO 2名・スクラムマスター 1名
11. 11 ざっくり特徴として • プロジェクトの息が長いので、エンジニアの入れ替わ りが少なくない ◦ 特にリードする立場のフロントエンジニアに 入れ替わりが何度か発生してしまう • Redux Sagaが使われていて、小規模でもシンプルでも ないアプリですがジュニアレベルのエンジニアが学習 のために参加することもある
12. 12 結果、なにが起こったか • 主要ないくつかのページでコードの特徴が異なる ◦ 一部ページでは主要なロジックが1つのカスタムフック にまとめられ、カスタムフックがネストしていく状態 ◦ ReduxにレスポンスとUIの状態が別ファイルになって いたり、同じだったり • Atomic Designのディレクトリ構成に秩序がない • 散乱するつぎはぎのコピペコード
13. 13 そして バグの修正で新たなバグが誕生
14. 14 図解 バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR
15. 15 リリースは1週間間隔、ときにhotfix バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR 1スプリント 1スプリント
16. 16 ただバグ修正できていなかっただけなのに進捗はでる バグ修正PR バグ修正ででたバグ修正のPR バグ修正のバグ修正ででたバグ修正のPR 1スプリント 1スプリント 1pt 1pt 1pt
17. 17 なにをしたか • 再発防止策の徹底 ◦ テストを必須にする ▪ 難しいときはIssueに再発防止策検討のタスクを 起票する ◦ バグの原因を必ず記載する ◦ バグ修正はモブプロで行う
18. 18 そもそもバグを減らしたい • やる必要があるカイゼンタスクをもくもくと起票 ◦ 先述の問題の他にも…… ▪ React v18なのに型情報がReact v17 ▪ mswがインストールされてるのに起動しない ▪ StrictModeが無効 ◦ ただ起票するだけでは後回しになってしまうの で、カイゼンタスクを必ずスプリント内に1つ以上 含める
19. 19 なにをしなかったか（できなかったか） • E2Eテスト ◦ 過去それなりの工数をかけている形跡があった が、現状どれも動作していない現実 ▪ Cypress/Playwright/Autify ◦ 簡単な正常系だけを用意しても…… ◦ スクラムイベントでアドホックテストをしている ◦ 現状は雑にライブラリをアップデートとかも慎重 にならざるを得ない状況なので、リソースがあれ ばもちろんやりたい
20. 20 併走する • 今日自慢したい、2年以上続いているプロジェクトの簡 単な説明 ◦ 起こっていた問題とその改善策 • お客さんのエンジニアとリモートのスクラムで併走し ている話 ◦ 開発をはじめてから1年程度のメンバー ◦ 全員、これまでプログラミング未経験
21. 21 お客さんのエンジニアの参画時期 2020年 9月 2021年 1月 2021年 8月 2022年 10月 現在 2022年 3月 2022年 11月 2023年 2月
22. 22 意識してやったこと • 発言をしやすい雰囲気を作る ◦ 質問をしやすい・意見をいいやすい ◦ わからないことをわからないと言える • お客さんの目標である、内製化ができるようになるこ とを極力支援できるように考えて行動する ◦ タスクの割り振り ◦ 何でも自分でやりすぎない
23. 23 質問しやすい雰囲気作り 逆の立場になって考えてみると、 雰囲気以前の話で、いきなりMeetやSlackのハドルで 呼び出して質問なんてそもそもしにくい。
24. 24 Gather
25. 25 ゲーム感のあるバーチャルオフィス
26. 26 過去失敗した 実はこの期間でもやっていたのですが、振り返ってみると あまりうまく運用できていませんでした。 参加期間1 参加期間2 2022年 10月 現在 2020年 9月 2021年 1月 2021年 8月
27. 27 なぜうまくいかなかったのか • Gatherを使っているのにMeetのような運用になって いた ◦ 用事があるときに、用事がある人だけを呼ぶ ◦ 用件以外の会話があまり生まれない状況 ◦ 用事のある人しか呼ばないので、仮に雑談が発生し てもそれはチームというよりも個人間の会話にしか なっていなかった
28. 28 うまくいった運用を経験していた • Gatherがうまく運用できていた案件ではGatherに自然 と集まっていた ◦ そこでは案件の話もするし、それ以外の雑談もする ◦ よく知るメンバーなので、どんなときでも意見を言 いやすい ◦ なので困っているときには全力で助けたくなる
29. 29 このプロジェクトでもそうなりたい！ • 最初から自然に集まるというのは無理な話なので集ま る時間をつくった（15時-17時、カレンダーに登録） ◦ ただし任意で、強制はしない ◦ 誰も来なくても常に広いスペースにいる ▪ 個々の席にいるだけだとあまり意味がないので ▪ いつもいる人になる。誰もいないところに人は 集まらない ◦ 積極的に雑談もした ◦ 誰もこなくても泣かない
30. 30 なった • 15時から17時の時間には集まるようになった ◦ この時間帯以外にも午後には人が集まる状態
31. 31 モブプロ
32. 32 参加必須にしています • 火曜日の15時から17時はモブプロ ◦ 基本フロントエンドメンバー全員参加
33. 33 目的 • 習熟度の向上 • 知識の平準化による属人化の解消 • レビューコストの低減
34. 34 ルール • タイピスト1名（15分時間交代制）とモブからなる • タイピストは基本的にモブから指示されていないこと を書き込むことはできない • タイピストはモブの指示が不明瞭な場合は理解できる まで質問する • お互いを信頼すること ◦ いや、そうじゃなくて・・禁止
35. 35 VS CodeのLive Share便利 • VS CodeのLive Shareを使っています ◦ 普段別のエディタを使っている人はつらいかも ◦ Issue単位でホストの変更をしています • 記録はNotionに残しています ◦ 途中参加や作業が途中で終わったとき 翌週何をしていたか忘れるため
36. 36 効果 • みんなの反応がとてもよく大好評 ◦ 自分自身もとても楽しめている ▪ ドメイン知識は圧倒的にお客さんのエンジニア のほうが上なので、気付かされることも多い • POやバックエンドメンバーも見学に来てくれている • バグタスクを多めに消化しているので、ボードに溜 まっていたバグタスクが減った
37. 37 以上になります。 ありがとうございました。
38. 38 おまけ
39. 39 レビュー会
40. 40 カレンダーではレビュー会と書いてた • 最初はみんなでPRレビューをする時間（過去形） ◦ 時間は16:30からの30分で任意参加 ◦ 自分の作業に集中してしまうメンバーが多く、レ ビューが滞り気味だったので、全員でレビューをす る時間を作った ◦ 自分の作業も大事だけど、レビューも大事 ◦ レビューがコードの品質よりも、動作確認作業に なっていそうなところが気になっていたので、全員 で同じPRを同時にみると何か得るものがありそう かなと感じた
41. 41 結果、微妙でした • 見て欲しいところを文字通り見てもらうだけの謎の会 になった ◦ レビュー会自体は微妙だったが、こういった時間を 設けたことでチームのレビューにたいする意識は向 上した気がする ◦ いまもカレンダーだけは設定されていて、この時間 になると「質問ないですか？」と私から声をかける 時間になった