Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

hbsnow
April 17, 2023

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

hbsnow

April 17, 2023
Tweet

More Decks by hbsnow

Other Decks in Technology

Transcript

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

    View Slide

  2. 2
    自己紹介
    高橋ゆうき
    クラスメソッド株式会社 CX事業本部Delivery部
    フロントエンドチーム チームリーダー
    @hbsnow

    View Slide

  3. 3
    今日話したいこと
    ● 今日自慢したい、2年以上続いているプロジェクトの簡
    単な説明
    ○ 起こっていた問題とその改善策
    ● 3人のお客さんのエンジニアとリモートのスクラムで併
    走している話
    ○ 開発をはじめてから1年程度のメンバー
    ○ 全員、それまでプログラミング未経験

    View Slide

  4. 4
    今日自慢したいあるプロジェクトの話
    ● 今日自慢したい、2年以上続いているプロジェクトの簡
    単な説明
    ○ 起こっていた問題とその改善策
    ● 3人のお客さんのエンジニアとリモートのスクラムで併
    走している話
    ○ 開発をはじめてから1年程度のメンバー
    ○ 全員、それまでプログラミング未経験

    View Slide

  5. 5
    今日自慢したいプロジェクトの参加履歴
    2020年
    9月
    参加期間1 参加期間2
    2021年
    1月
    2021年
    8月
    2022年
    10月
    現在
    ※要件定義の期間は含めていません

    View Slide

  6. 6
    最初からは参加できず
    ● 最初から参加していなかった(入社していなかった)
    ので、技術選定や設計にはかかわれていません。
    参加期間1 参加期間2
    2021年
    8月
    2022年
    10月
    現在
    2020年
    9月
    2021年
    1月

    View Slide

  7. 7
    入社後すぐにアサインされた
    ● 入社後プロジェクトに参加。このときは、割り当てら
    れたタスクをもくもくとこなすだけ。
    参加期間1 参加期間2
    2022年
    10月
    現在
    2020年
    9月
    2021年
    1月
    2021年
    8月

    View Slide

  8. 8
    長期の離脱期間
    ● 別プロジェクトに移動。長期の離脱期間が発生し、正
    式リリースもこの期間に行われました。
    参加期間1 参加期間2
    現在
    2020年
    9月
    2021年
    1月
    2021年
    8月
    2022年
    10月

    View Slide

  9. 9
    でもどり
    ● 別プロジェクトが終了したため、でもどり。
    (前回よりも期待されている雰囲気……!)
    参加期間1 参加期間2
    2020年
    9月
    2021年
    1月
    2021年
    8月
    2022年
    10月
    現在

    View Slide

  10. 10
    現在のプロジェクトの規模感
    ● フロントエンドエンジニア
    ○ 私
    ○ プロパー 1名
    ○ パートナー 1名(木金不在)
    ○ お客さんのエンジニア 3名
    ● バックエンドエンジニア 7名
    ● PO 2名・スクラムマスター 1名

    View Slide

  11. 11
    ざっくり特徴として
    ● プロジェクトの息が長いので、エンジニアの入れ替わ
    りが少なくない
    ○ 特にリードする立場のフロントエンジニアに
    入れ替わりが何度か発生してしまう
    ● Redux Sagaが使われていて、小規模でもシンプルでも
    ないアプリですがジュニアレベルのエンジニアが学習
    のために参加することもある

    View Slide

  12. 12
    結果、なにが起こったか
    ● 主要ないくつかのページでコードの特徴が異なる
    ○ 一部ページでは主要なロジックが1つのカスタムフック
    にまとめられ、カスタムフックがネストしていく状態
    ○ ReduxにレスポンスとUIの状態が別ファイルになって
    いたり、同じだったり
    ● Atomic Designのディレクトリ構成に秩序がない
    ● 散乱するつぎはぎのコピペコード

    View Slide

  13. 13
    そして
    バグの修正で新たなバグが誕生

    View Slide

  14. 14
    図解
    バグ修正PR
    バグ修正ででたバグ修正のPR
    バグ修正のバグ修正ででたバグ修正のPR

    View Slide

  15. 15
    リリースは1週間間隔、ときにhotfix
    バグ修正PR
    バグ修正ででたバグ修正のPR
    バグ修正のバグ修正ででたバグ修正のPR
    1スプリント
    1スプリント

    View Slide

  16. 16
    ただバグ修正できていなかっただけなのに進捗はでる
    バグ修正PR
    バグ修正ででたバグ修正のPR
    バグ修正のバグ修正ででたバグ修正のPR
    1スプリント
    1スプリント
    1pt
    1pt
    1pt

    View Slide

  17. 17
    なにをしたか
    ● 再発防止策の徹底
    ○ テストを必須にする
    ■ 難しいときはIssueに再発防止策検討のタスクを
    起票する
    ○ バグの原因を必ず記載する
    ○ バグ修正はモブプロで行う

    View Slide

  18. 18
    そもそもバグを減らしたい
    ● やる必要があるカイゼンタスクをもくもくと起票
    ○ 先述の問題の他にも……
    ■ React v18なのに型情報がReact v17
    ■ mswがインストールされてるのに起動しない
    ■ StrictModeが無効
    ○ ただ起票するだけでは後回しになってしまうの
    で、カイゼンタスクを必ずスプリント内に1つ以上
    含める

    View Slide

  19. 19
    なにをしなかったか(できなかったか)
    ● E2Eテスト
    ○ 過去それなりの工数をかけている形跡があった
    が、現状どれも動作していない現実
    ■ Cypress/Playwright/Autify
    ○ 簡単な正常系だけを用意しても……
    ○ スクラムイベントでアドホックテストをしている
    ○ 現状は雑にライブラリをアップデートとかも慎重
    にならざるを得ない状況なので、リソースがあれ
    ばもちろんやりたい

    View Slide

  20. 20
    併走する
    ● 今日自慢したい、2年以上続いているプロジェクトの簡
    単な説明
    ○ 起こっていた問題とその改善策
    ● お客さんのエンジニアとリモートのスクラムで併走し
    ている話
    ○ 開発をはじめてから1年程度のメンバー
    ○ 全員、これまでプログラミング未経験

    View Slide

  21. 21
    お客さんのエンジニアの参画時期
    2020年
    9月
    2021年
    1月
    2021年
    8月
    2022年
    10月
    現在
    2022年
    3月
    2022年
    11月
    2023年
    2月

    View Slide

  22. 22
    意識してやったこと
    ● 発言をしやすい雰囲気を作る
    ○ 質問をしやすい・意見をいいやすい
    ○ わからないことをわからないと言える
    ● お客さんの目標である、内製化ができるようになるこ
    とを極力支援できるように考えて行動する
    ○ タスクの割り振り
    ○ 何でも自分でやりすぎない

    View Slide

  23. 23
    質問しやすい雰囲気作り
    逆の立場になって考えてみると、
    雰囲気以前の話で、いきなりMeetやSlackのハドルで
    呼び出して質問なんてそもそもしにくい。

    View Slide

  24. 24
    Gather

    View Slide

  25. 25
    ゲーム感のあるバーチャルオフィス

    View Slide

  26. 26
    過去失敗した
    実はこの期間でもやっていたのですが、振り返ってみると
    あまりうまく運用できていませんでした。
    参加期間1 参加期間2
    2022年
    10月
    現在
    2020年
    9月
    2021年
    1月
    2021年
    8月

    View Slide

  27. 27
    なぜうまくいかなかったのか
    ● Gatherを使っているのにMeetのような運用になって
    いた
    ○ 用事があるときに、用事がある人だけを呼ぶ
    ○ 用件以外の会話があまり生まれない状況
    ○ 用事のある人しか呼ばないので、仮に雑談が発生し
    てもそれはチームというよりも個人間の会話にしか
    なっていなかった

    View Slide

  28. 28
    うまくいった運用を経験していた
    ● Gatherがうまく運用できていた案件ではGatherに自然
    と集まっていた
    ○ そこでは案件の話もするし、それ以外の雑談もする
    ○ よく知るメンバーなので、どんなときでも意見を言
    いやすい
    ○ なので困っているときには全力で助けたくなる

    View Slide

  29. 29
    このプロジェクトでもそうなりたい!
    ● 最初から自然に集まるというのは無理な話なので集ま
    る時間をつくった(15時-17時、カレンダーに登録)
    ○ ただし任意で、強制はしない
    ○ 誰も来なくても常に広いスペースにいる
    ■ 個々の席にいるだけだとあまり意味がないので
    ■ いつもいる人になる。誰もいないところに人は
    集まらない
    ○ 積極的に雑談もした
    ○ 誰もこなくても泣かない

    View Slide

  30. 30
    なった
    ● 15時から17時の時間には集まるようになった
    ○ この時間帯以外にも午後には人が集まる状態

    View Slide

  31. 31
    モブプロ

    View Slide

  32. 32
    参加必須にしています
    ● 火曜日の15時から17時はモブプロ
    ○ 基本フロントエンドメンバー全員参加

    View Slide

  33. 33
    目的
    ● 習熟度の向上
    ● 知識の平準化による属人化の解消
    ● レビューコストの低減

    View Slide

  34. 34
    ルール
    ● タイピスト1名(15分時間交代制)とモブからなる
    ● タイピストは基本的にモブから指示されていないこと
    を書き込むことはできない
    ● タイピストはモブの指示が不明瞭な場合は理解できる
    まで質問する
    ● お互いを信頼すること
    ○ いや、そうじゃなくて・・禁止

    View Slide

  35. 35
    VS CodeのLive Share便利
    ● VS CodeのLive Shareを使っています
    ○ 普段別のエディタを使っている人はつらいかも
    ○ Issue単位でホストの変更をしています
    ● 記録はNotionに残しています
    ○ 途中参加や作業が途中で終わったとき
    翌週何をしていたか忘れるため

    View Slide

  36. 36
    効果
    ● みんなの反応がとてもよく大好評
    ○ 自分自身もとても楽しめている
    ■ ドメイン知識は圧倒的にお客さんのエンジニア
    のほうが上なので、気付かされることも多い
    ● POやバックエンドメンバーも見学に来てくれている
    ● バグタスクを多めに消化しているので、ボードに溜
    まっていたバグタスクが減った

    View Slide

  37. 37
    以上になります。
    ありがとうございました。

    View Slide

  38. 38
    おまけ

    View Slide

  39. 39
    レビュー会

    View Slide

  40. 40
    カレンダーではレビュー会と書いてた
    ● 最初はみんなでPRレビューをする時間(過去形)
    ○ 時間は16:30からの30分で任意参加
    ○ 自分の作業に集中してしまうメンバーが多く、レ
    ビューが滞り気味だったので、全員でレビューをす
    る時間を作った
    ○ 自分の作業も大事だけど、レビューも大事
    ○ レビューがコードの品質よりも、動作確認作業に
    なっていそうなところが気になっていたので、全員
    で同じPRを同時にみると何か得るものがありそう
    かなと感じた

    View Slide

  41. 41
    結果、微妙でした
    ● 見て欲しいところを文字通り見てもらうだけの謎の会
    になった
    ○ レビュー会自体は微妙だったが、こういった時間を
    設けたことでチームのレビューにたいする意識は向
    上した気がする
    ○ いまもカレンダーだけは設定されていて、この時間
    になると「質問ないですか?」と私から声をかける
    時間になった

    View Slide