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

越境チャレンジの現在地 〜Epic大臣制度の今〜

越境チャレンジの現在地 〜Epic大臣制度の今〜

Scrum Fest Osaka 2022の登壇資料です。

https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16960

Dd5c63951803a69272ac7a6aaa59401d?s=128

sakai.yusuke

June 18, 2022
Tweet

Other Decks in Technology

Transcript

  1. 越境チャレンジの現在地 〜Epic大臣制度の今〜 2022.06.18 / Scrum Fest Osaka 2022 Day2 /

    スポンサーセッション2
  2. 今日お話すること

  3. 今日お話すること • 昨年、@okeicalm からお話させてもらった、 Epic大臣という役割を始めたチームのその後 ◦ Scrum Fest Osaka 2021

    - エピック大臣から始める LeSSの導入 • Epic大臣というロールを導入して 1年、何が起こって、どう乗り越えていったのか、をお話します
  4. 目次 1. 自己紹介 / 会社・チームの紹介 2. Epic大臣とは? a. 誕生の背景 b.

    役割 3. Epic大臣が登場して、しばらく後の世界 a. 状況 b. 問題と改善 4. ふりかえり
  5. 自己紹介

  6. 自己紹介 堺 祐輔(@yukke3duck) マネーフォワード 関西開発拠点所属 マネーフォワード クラウド会計Plus "初の"専任のスクラムマスター 経歴 インフラエンジニアや DB管理をやりながら、

    2018年、某ECサイトで、スクラムに出会い 2019年、某人材サービスで、スクラム導入にトライ 2021年11月、現職に至る
  7. 会社紹介

  8. 社名 株式会社マネーフォワード 設立 2012年5月 上場市場 東京証券取引所 プライム市場 【証券コード:3994】 本社所在地 東京都港区芝浦3-1-21

    msb Tamachi 田町ステーションタワーS 21F
  9. MISSION お金を前へ。人生をもっと前へ。 VISION すべての人の「お金のプラットフォーム」になる。 VALUE User Focus, Technology Driven, Fairness

    CULTURE Speed, Pride, Teamwork, Respect, Fun
  10. BtoC、BtoBに限らず、数多くのサービス、プロダクトを提供しています。 POINT

  11. 関西開発拠点について

  12. 関西開発拠点のコンセプト ユーザーのためになることを、まずやってみる。
 そこから失敗も成功もすべて受け止めて、前に進み続ける。
 最初の一歩を自ら踏み出す事を最も大事にしよう。


  13. チームについて

  14. BtoC、BtoBに限らず、数多くのサービス、プロダクトを提供しています。 POINT

  15. チーム • LeSSを採用 • 機能開発を主にしつつ、保守運用も行うチーム • ディスカバリーを行うチーム ◦ プロダクトオーナー( PO)

    ◦ アソシエイトPdM ▪ POのサポート ◦ デザイナー • Devチーム ◦ エンジニア ▪ Epic毎に、各Devチームから1名ずつがEpic大臣を務める ◦ フィーチャーチームで、独立して PBIを実現する能力をもっている • スクラムマスター
  16. None
  17. プロセス Sprint planning 1 Sprint planning 2 Sprint Sprint ・・・

    Sprint Review Retrospective Overall Retrospective Product Backlog Refinement 1week
  18. Epic? • ユーザーに提供したい価値の一番大きな単位 • プロダクトバックログアイテムの、一番粗い単位 • Epicは詳細化され、分割されて UserStoryが生まれる • スプリントで実際に開発する

    PBIになるのは、UserStory
  19. Epic大臣とは?

  20. サービスローンチまで • プロダクトオーナーの役割 ◦ Epicの優先順位づけを行う ◦ Epicの明確化とUserStoryへの分割 ◦ UserStoryの受入条件の検討とチケット化 ◦

    実装されたPBIのレビュー ◦ バーンダウンチャートによる Epicの開発進捗の可視化 ◦ ステークホルダーとの交渉・対話
  21. サービスローンチまで • ステークホルダーとの交渉・対話の時間は小さく、プロダクトオーナーがチームのために使える時間が 確保できていた • ドメイン知識のあるエンジニアがいて、プロダクトオーナーの代わりにドメインに関するフォローができた • エンジニアの人数もそこまで多くなかった

  22. サービスローンチ後 • ステークホルダーやユーザーとの対話の時間が増え、プロダクトオーナーがチームのために使える時 間が減少 • エンジニアは増え、複数チーム体制に • ドメインに詳しかったエンジニアが退職・・・ その結果、プロダクトオーナーがボトルネックになり アジリティが上がらない状況になってしまった

  23. 最初の一歩 • わかりやすくプロダクトオーナーの負担を減らそう、ということでエンジニアが Storyのチケットを起票し、 受入基準など必要事項を記載するタスクをエンジニアで実施することに • しかし、当たり前の話だがチケットにこれらを記載するためには Why, Whatについてプロダクトオーナー と知識レベルが揃っている必要がある

  24. Epic大臣の誕生 • Epic大臣として、これまでエンジニアが参加していなかったディスカバリーのプロセスに合流 ◦ ユーザーインタビュー ◦ ユーザーストーリーマッピング ◦ MVPの決定 ◦

    ストーリー分割 • プロダクトオーナーと知識レベルがある程度揃い、自律して動ける状態になっていった
  25. Epic大臣の誕生 • Storyの明確化をエンジニアが実施するため、プロダクトバックログリファインメントにもエンジニアが持 ちこむようになった • Epicの全体像が見えているため、設計方針の叩き台を作ってからチームで合意形成をする、というプロ セスが生まれた • リリースに関する手順の確認や、他チームとの調整などのリリースマネージャも行うことに Epic大臣が開発をリードする存在に!

  26. Epic単位での開発の進め方 杉浦さんの資料パクる Epic大臣が関わる範囲

  27. Epic大臣 is • プロダクトオーナーと並走して Epicの明確化を行う • 具体的には ◦ UserStoryの分割とPBIの準備 ◦

    リファインメントの実施 ◦ バーンダウンチャートなどによる状況の可視化 ◦ リリースマネージャ、など • 実装も行う • 希望すれば誰でもチャレンジできる ◦ Epic毎に挙手
  28. Epic大臣によって • プロダクトオーナーが Storyチケットの準備などを実施しなくてもスクラムが回るプロセスが確立されて、 プロダクトオーナーがユーザーペインやペインを解消する優先順位を考えることに時間をかけられるよ うになった • Epic大臣にドメイン知識が注入され、プロダクトオーナーのみに質問が集中する状態を緩和できた • 副次的な効果として、

    Epic大臣を担当したエンジニアがプロダクトマネジメント・プロジェクトマネジメント のスキルを身につけるきっかけとなった
  29. Epic大臣が誕生して しばらく後の世界

  30. 状況 • Epicのディスカバリーが終わり、実装が始まった頃の話 • そのEpicは、強い締切があるわけではない • しかし、ロードマップを考えると、リリースしたい時期がある程度決まっている • ロードマップとリリース予定時期は、販売戦略の検討材料の1つになっている なのに

    • 今、どこまで出来ているのかも分からない し、そもそもやりたいことの 全体感もわからない • 毎スプリント、たくさん仕掛りが発生 し、スプリントゴールが達成できない • 次のスプリントに入れたい PBIがプランニングの前日にリファインメントされる 自転車操業状態
  31. 何が起こっていた? • 採用・異動で、入社1年未満のエンジニアが大半になった • PBIをDoneにするために、他チームが必要なプロセスがある Devチームができていた • Epicと平行して、システム改善の PBIもやっていた •

    Epic大臣の知見の分断 • Epic大臣の時間が足りない • さらにPOが忙しくなった
  32. 採用・異動で、入社1年未満のエンジニアが大半になった • エンジニア採用が進んだ • 拠点内で新しいプロダクトを開発するために、メンバーを暖簾分け • 結果として、人数は増えたが、入社1年未満のエンジニアが大半という状況に • プロダクト立ち上げ期のメンバーがいなくなることで、アーキテクチャの背景を知るエンジニアが減った •

    さらにEpic大臣によりドメイン知識を身につけたエンジニアの多くもいなくなった • プロセスの断絶・形骸化 • 在籍期間の長いエンジニアへの負荷集中 • 諸々の背景を知らないことによる判断ミスや遅れ
  33. PBIをDoneにするために、他チームが必要なプロセスがあるDevチームができ ていた • 入社1年未満だったり、エンジニア歴自体が短いエンジニアだけで構成されたチームができていた • 足りない知見を補うために、他の Devチームへのコードレビューが必須のプロセスになっていた • コードレビューでのフィードバックが多く、また設計方針に関わるような指摘も多々 •

    Pull Requestの単位が大きいことで、レビュアー側も負担に
  34. Epicと平行して、システム改善のPBIもやっていた • 溜まった技術負債の大きな返済 • 将来のための仕込み • それなりのリソースを使っていた • スイッチングコストの多発 •

    既存コードを知るエンジニアの手をとりがちになった
  35. Epic大臣の知見の分断 • Epic大臣のやるべきことや期待値の言語化が不十分だった • ドキュメント化されたものも、共有が不十分だった • 過去にEpic大臣を担当したエンジニアの異動 • 本人や周りとの期待値の齟齬 •

    Epic大臣で判断できないことが多々 • プロジェクトマネジメントなどが後手に回った
  36. Epic大臣の時間が足りない • ディスカバリープロセスの MTGや、他プロダクトとの連携のための MTGなどに参加していた • 一方で、実装も行っていた • Epic大臣の負荷が高い状態が継続 •

    PBIをリファインメントできる状態にすることがギリギリになっていて、スプリントで実施したい PBIが、プラ ンニングの前日か当日に READYになる
  37. さらにPOが忙しくなった • プロダクトの成長に伴い、社内の他プロダクトの連携が密に • 他プロダクトのプロダクトマネージャー( 10人以上!)との連携 • レビュー・相談・質問の時間確保が難しくなり、 PO起因のリードタイムが増えた

  38. 改善だ!

  39. 現在地とゴール地点を知る • 粗くでも全体感を知るため、粗々リファインメントの実施 • 受入条件や分割など深堀りはおいて、分かっている範囲の WhyとWhatだけで、PBIに見積もりを付け る場 • ポイントの総数とベロシティから、バーンアップチャートを作り、大体の完了目安がわかるようになった •

    そして、リリースしたい時期には数ヶ月レベルで間に合わないことが顕に …
  40. • Epic大臣を、エンジニアとして、実装に集中できる状態にする • 組織的&職種的に、 POと距離が近づいたことにより、密にコミュニケーションをとれるようになり、判断 速度up • EMとアソシエイトPdMの密連携による、技術的課題の早期発見 Epic大臣の交代 •

    エンジニア2名→アソシエイトPdM+EMの体制 • POからアソシエイトPdM、レビューや各種判断などの権限委譲
  41. プランニングとデイリースクラムの見直し • 方針が共有され、レビューでの「そもそも」なところへのフィードバックが減った • スプリントバックログの粒度が細かくなったことで、 Pull Requestも小さくなり、レビュアーの負担も低減 • アソシエイトPdMがデイリースクラムに参加することで、リスクや疑問にすぐに対応できるように •

    プランニング ◦ 懸念点の洗い出し、十分な議論の上で、粒度を細かくしてスプリントバックログを作成 ◦ 必要に応じて、他チームも含めて実施 • デイリースクラム ◦ アソシエイトPdMも参加
  42. すべてのDevチームが自走できる状態へ • 仕掛りを作らない、確実に Doneにできるリズムを体感 • ドメイン知識やコードの背景の知見を獲得 • 自走できているDevチームがスプリントゴールに集中できる状態へ • 自走が難しかったチームの、プランニングでとる

    PBIを意識的に減らした • 問合せやアラート対応を集約
  43. 優先順位の見直し • 改善に手を取られがちだった、既存コードを知るエンジニアのリソースが使えるように • 改善とEpicの優先順位を明確にした • Epicを優先し、改善を一時的に止める決断

  44. スケジュールとスコープの調整 • POからステークホルダーへ、正直な、状況と今後の見通しの説明 • 新Epic大臣2人によるプロダクトバックログの見直しと整理 ◦ 実装済のストーリーと未実装のストーリーを整理 ◦ 未実装ストーリーの書き直し ◦

    ストーリーの要不要の見極め • ステークホルダーに、状況とロードマップへの影響を理解してもらい、心理的不安が低下 • プロダクトバックログが整理されたことで、今やるべきこととゴール地点が明確に
  45. 他にも • アジャイルコーチに、 UserStoryについて説明してもらい、改めて UserStoryの書き方や、それで伝えた いことをインプットしなおした • バリューストリームマッピングを行い、ボトルネックになっている箇所を探した • RSGT2022のセッション録画で、現状の打破のヒントになりそうなものの試聴会をやった

    などなど
  46. 改善の結果、、、

  47. 無事リリースできました🎉 • なんやかんやあったものの、無事リリース 🎉 • リリース後、大きな不具合もなし!!

  48. ふりかえってみて • スケジュールの着地地点は、当初のバーンアップチャートと大きく変わらなかった ◦ 最終的に、PBIは増えたり減ったりして、粗々で見積もったとき+ αくらいの見積もり • 品質や速度の担保のために、一部のメンバーにかなりの負荷をかけた ◦ Epic大臣

    ◦ 比較的在籍歴の長いエンジニア
  49. ふりかえってみて • 自分たちの状況が良くないことがわかった ◦ 問題点が、チーム全員がわかる形で明らかになり、色んな場で議論するきっかけになった ◦ その結果、たくさんの改善されたし、その勢いが続いている • アソシエイトPdMが、ドメイン周りを急速にキャッチアップすることで、大躍進 •

    ユーザーにいいものを早く届けたいという「 UserFocus」と、そのためにやれることをやってみようという 「Give it a try!」の気持ちがたくさん見えた 決して上手にはコケられなかったけど、その分、コケる前よりいいチームになった
  50. これから

  51. Epic大臣の今後 • エンジニアの中では、「今後もやりたい!」という声が多かった • エンジニアがディスカバリーに参加する、という越境は続く • PO・PdMとエンジニアの架け橋として、今後の在り方を模索中

  52. さらなる越境チャレンジ • Devチーム単独で、PO以外のすべてのロールを揃える • みんなで受入条件を作るリファインメント • メンバーのドメイン知識獲得のため、経理部出身者からメンバーへの経理業務体験会 • etc

  53. 最後に

  54. We are hiring! マネーフォワードでは一緒に働く仲間を募集中です! 一緒に、Give it a try!しましょう!! 全国 大阪

    京都
  55. We are hiring! 関西開発拠点の専任スクラムマスターも募集中!! マネーフォワードでは一緒に働く仲間を募集中です! 一緒に、Give it a try!しましょう!!

  56. ご静聴ありがとうございました!!