Slide 1

Slide 1 text

エンジニアだけの スクラムチームを脱却する第⼀歩 Bill One Engineering Unit ⻄野 貴宏

Slide 2

Slide 2 text

写真が入ります ⻄野 貴宏 Sansan株式会社 技術本部 Bill One Engineering Unit 2022年 Sansan 新卒⼊社。 ⼊社以来 Web アプリケーション開発エンジニアとして Bill One の開発に携わっています。 チームでは⽇々の開発業務に加え、スクラムイベントの リードを中⼼に、開発フローの改善を⾏っています。 @takapiro_99

Slide 3

Slide 3 text

- Bill One の開発 - ATL としてスクラムイベントの運営 - スクラムの三本柱「透明性」「検査」「適応」 普段の業務

Slide 4

Slide 4 text

- 以前の開発フローについて - その開発フローで挙がった課題 - 開発フローを⾒直して「レビュー会」をチームで企画・開催してみた - 開催してみてのフィードバック - これからの展望 話すこと

Slide 5

Slide 5 text

今⽇する話は 急激に⼈が増えた後の この辺り

Slide 6

Slide 6 text

以前の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM

Slide 7

Slide 7 text

PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM 以前の開発フローにあった課題 この機能ではユーザーの 課題が解決していない…! 仕様や顧客理解が曖昧で 意思決定が遅くなりがち

Slide 8

Slide 8 text

PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM 以前の開発フローにあった課題 この機能ではユーザーの 課題が解決していない…! 仕様や顧客理解が曖昧で 意思決定が遅くなりがち ⼤きな⼿戻り 😢

Slide 9

Slide 9 text

- 開発したものを PdM・CS に⾒せたら思ってたのと違ってた - 関係者みんなで仕様を考えられていなかった - チーム内で、開発に関わる意思決定をしきれていなかった - 仕様の不明点は個別に PdM や CS に聞いて、それをチームに展開して、をする ので、意思決定が遅くもなっていた - そもそも PdM は忙しい 課題まとめ

Slide 10

Slide 10 text

レビュー会を開催し始めた - プロダクトを中⼼において「何を作るか?何を作ったか?」に焦点を 当てて開催 - エンジニア×デザイナー、エンジニア×CS の接点は個別にあったが、 改めて担当デザイナー・担当CS をチームのメンバーと捉え、 まとめて巻き込んだ

Slide 11

Slide 11 text

以前の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM

Slide 12

Slide 12 text

レビュー会 (毎週) 今の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM

Slide 13

Slide 13 text

- PBIレビュー - PBIに対してユーザー要望が満たせているか - デザインレビュー - デザインに対してUI/UXが問題ないか - インクリメントレビュー - エンジニアが開発した機能は要件を満たせているか レビュー会でやったこと・⽬的

Slide 14

Slide 14 text

- PBIレビュー:PBIに対してユーザー要望が満たせているか - 「解決したい課題」と「達成したい状況」にずれはなく、「必要な機能」があ ればそれは満たされるか確認する - レビューを通して機能の仕様について理解を深める - チーム全体で仕様の合意形成を図り、PdMにはそれを報告する流れをとれる状 態にする - 意思決定をPdMまで待たずにできる状態を⽬指したい レビュー会でやったこと・⽬的 ①

Slide 15

Slide 15 text

- デザインレビュー:デザインに対してUI/UXが問題ないか - PdL 以外もレビューすることで開発フェーズでの⼿戻りを減らす - 参加者が少ない・スコープが絞られていることでデザイナーに FB しやすい 場とする - チーム全体で納得感を持って進め、⼿戻りを減らす レビュー会でやったこと・⽬的 ②

Slide 16

Slide 16 text

- インクリメントレビュー:エンジニアが開発した機能は要件を満たせて いるか - リリース前レビューでは時間が限られており、⼤枠でしか説明できていない かもしれないので詳細に⾒せてレビューしてもらう - 要件を満たせているが +α で欲しい機能に関してはここで出して対応できる ものは対応し、難しいものはプロダクトバックログ化する レビュー会でやったこと・⽬的 ③

Slide 17

Slide 17 text

レビュー会をやってみて - エンジニア - ユーザーと近いCSと話しながら作れて、ユーザー視点のイメージがすごく湧いた - お互いにFBすることで⼀体感が出せて、いいものを作ろうという意識が⾼まった - 早い段階のFBが助かった、細かい表現の相談が勉強になった、ありがたかった - CS - 開発のスコープや仕様の認識合わせをしたことで、今後のリリース予定やオンボーディングの伝え⽅が 考えられた - ⼩規模にやることで発⾔しやすかった - 細かいレスポンスがあってよかった(先週出たFBが翌週には改善されている) - デザイナー - ⼀体感があった - スコープの認識合わせもできてよかった。 - 細かいところはレビュー内での指摘はできなかったので、Slackベースでのやりとりがもっとできたら よかったかな

Slide 18

Slide 18 text

Next - 規模が⼤きいPBIに対しては有効な施策だったが、⼩規模なPBIが続く 場合に関係者をどう巻き込んでいけるか - 他チームに展開してみる

Slide 19

Slide 19 text

まとめ - 「エンジニアだけのスクラムチーム」に、いくつか課題があった - ステークホルダーを巻き込んで「レビュー会」を開催した - 意思決定スピードが向上し、プロダクトの品質も向上した

Slide 20

Slide 20 text

No content