エンジニアだけのスクラムチームを脱却する第⼀歩

■イベント
ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み
https://sansan.connpass.com/event/292027/

■登壇概要
タイトル：エンジニアだけのスクラムチームを脱却する第⼀歩
登壇者：技術本部 Bill One Engineering Unit　⻄野 貴宏

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. エンジニアだけの スクラムチームを脱却する第⼀歩 Bill One Engineering Unit ⻄野 貴宏
2. 写真が入ります ⻄野 貴宏 Sansan株式会社 技術本部 Bill One Engineering Unit 2022年 Sansan 新卒⼊社。 ⼊社以来 Web アプリケーション開発エンジニアとして Bill One の開発に携わっています。 チームでは⽇々の開発業務に加え、スクラムイベントの リードを中⼼に、開発フローの改善を⾏っています。 ＠takapiro_99
3. - Bill One の開発 - ATL としてスクラムイベントの運営 - スクラムの三本柱「透明性」「検査」「適応」 普段の業務
4. - 以前の開発フローについて - その開発フローで挙がった課題 - 開発フローを⾒直して「レビュー会」をチームで企画・開催してみた - 開催してみてのフィードバック - これからの展望 話すこと
5. 今⽇する話は 急激に⼈が増えた後の この辺り
6. 以前の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM
7. PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM 以前の開発フローにあった課題 この機能ではユーザーの 課題が解決していない…！ 仕様や顧客理解が曖昧で 意思決定が遅くなりがち
8. PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM 以前の開発フローにあった課題 この機能ではユーザーの 課題が解決していない…！ 仕様や顧客理解が曖昧で 意思決定が遅くなりがち ⼤きな⼿戻り 😢
9. - 開発したものを PdM・CS に⾒せたら思ってたのと違ってた - 関係者みんなで仕様を考えられていなかった - チーム内で、開発に関わる意思決定をしきれていなかった - 仕様の不明点は個別に PdM や CS に聞いて、それをチームに展開して、をする ので、意思決定が遅くもなっていた - そもそも PdM は忙しい 課題まとめ
10. レビュー会を開催し始めた - プロダクトを中⼼において「何を作るか？何を作ったか？」に焦点を 当てて開催 - エンジニア×デザイナー、エンジニア×CS の接点は個別にあったが、 改めて担当デザイナー・担当CS をチームのメンバーと捉え、 まとめて巻き込んだ
11. 以前の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM
12. レビュー会 （毎週） 今の開発フロー PdM 仕様の策定 デザイナー 開発 デザイン リリース前 レビュー リリース 営業・CS エンジニア ユーザーの声 PBI化 営業・CS デザイナー PdM
13. - PBIレビュー - PBIに対してユーザー要望が満たせているか - デザインレビュー - デザインに対してUI/UXが問題ないか - インクリメントレビュー - エンジニアが開発した機能は要件を満たせているか レビュー会でやったこと・⽬的
14. - PBIレビュー：PBIに対してユーザー要望が満たせているか - 「解決したい課題」と「達成したい状況」にずれはなく、「必要な機能」があ ればそれは満たされるか確認する - レビューを通して機能の仕様について理解を深める - チーム全体で仕様の合意形成を図り、PdMにはそれを報告する流れをとれる状 態にする - 意思決定をPdMまで待たずにできる状態を⽬指したい レビュー会でやったこと・⽬的 ①
15. - デザインレビュー：デザインに対してUI/UXが問題ないか - PdL 以外もレビューすることで開発フェーズでの⼿戻りを減らす - 参加者が少ない・スコープが絞られていることでデザイナーに FB しやすい 場とする - チーム全体で納得感を持って進め、⼿戻りを減らす レビュー会でやったこと・⽬的 ②
16. - インクリメントレビュー：エンジニアが開発した機能は要件を満たせて いるか - リリース前レビューでは時間が限られており、⼤枠でしか説明できていない かもしれないので詳細に⾒せてレビューしてもらう - 要件を満たせているが +α で欲しい機能に関してはここで出して対応できる ものは対応し、難しいものはプロダクトバックログ化する レビュー会でやったこと・⽬的 ③
17. レビュー会をやってみて - エンジニア - ユーザーと近いCSと話しながら作れて、ユーザー視点のイメージがすごく湧いた - お互いにFBすることで⼀体感が出せて、いいものを作ろうという意識が⾼まった - 早い段階のFBが助かった、細かい表現の相談が勉強になった、ありがたかった - CS - 開発のスコープや仕様の認識合わせをしたことで、今後のリリース予定やオンボーディングの伝え⽅が 考えられた - ⼩規模にやることで発⾔しやすかった - 細かいレスポンスがあってよかった（先週出たFBが翌週には改善されている） - デザイナー - ⼀体感があった - スコープの認識合わせもできてよかった。 - 細かいところはレビュー内での指摘はできなかったので、Slackベースでのやりとりがもっとできたら よかったかな
18. Next - 規模が⼤きいPBIに対しては有効な施策だったが、⼩規模なPBIが続く 場合に関係者をどう巻き込んでいけるか - 他チームに展開してみる
19. まとめ - 「エンジニアだけのスクラムチーム」に、いくつか課題があった - ステークホルダーを巻き込んで「レビュー会」を開催した - 意思決定スピードが向上し、プロダクトの品質も向上した