Tweet
Tweet

Slide 1

Slide 1 text

急成長中こそ、王道を。 課題ドリブンで高速に改善を 回し続けた1年 Haruka Oguchi

Slide 2

Slide 2 text

小口 遥（おぐち はるか） @hogucc 株式会社エンペイ / エンジニア ● Sler企業にていくつかの製品開発を経験 ● 2021年5月〜 株式会社エンペイ 集金業務のキャッシュレス化/DX化を実現する Fintech×SaaSプラットフォームの「enpay（エンペ イ）」を開発しています 自己紹介

Slide 3

Slide 3 text

3 サービスについて

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5 プロダクトの価値 事業者側は業務の工数/心理的負担が圧倒的に減り、保護者は支払手段を自由に選べる

Slide 6

Slide 6 text

6

Slide 7

Slide 7 text

7 急成長中こそ、王道を。 課題ドリブンで高速に改善を 回し続けた1年

Slide 8

Slide 8 text

エンペイのエンジニア組織の変遷 　内製化へ CTO 兼 PM 業務委託 社員 業務委託 CTO 兼 PM ~2021/04 2021/05 ● スクラム開発の導入 ● 社員のみの開発チームを結成

Slide 9

Slide 9 text

この1年で起きた変化 ● PMのジョイン ● 社員の数が倍以上に ○ 1チームの規模感ではなくなってきた ● 新規プロダクトの構想が温まってきた

Slide 10

Slide 10 text

現在のエンペイのエンジニア組織 CTO 業務委託 PM enpay開発組織 PM 新規プロダクト開発組織 2022/06 現在

Slide 11

Slide 11 text

ユーザーが求める機能を提供す ることに注力
 ● Launch Darklyの導入
 ● 開発前段階で機能を見える化
 
 開発フローの改善活動を実 施
 ● ベロシティの計測
 ● PRレビューは最優先
 ● リソース効率からフロー効率へ
 
 1年でやってきたこと 2021/11頃〜2022/06現在 開発フロー改善期
 開発フロー安定期
 2021/5〜

Slide 12

Slide 12 text

12 今まで行った開発フローの改善活動

Slide 13

Slide 13 text

ベロシティの計測

Slide 14

Slide 14 text

開発者による問題点の発見・提起

Slide 15

Slide 15 text

PRレビューは最優先で 
 タスク間のコンテキストスイッチをなるべく減らすことが目的
 
 タスクA タスクB レビュー依頼 出したぞ レビューを待つ 間にタスクBを進 めよう レビューが返って きた！時間があい たから内容を思い 出さないと...😅

Slide 16

Slide 16 text

PRレビューは最優先で レビューが後になる or PRの内容の複雑さが高い ほど コンテキストスイッチがつらくなる

Slide 17

Slide 17 text

PRレビューは最優先で ● PRを出してから24時間以上マージされないPRが 減った ● PRが作成されてからレビューが返ってくるまでの 時間が短くなり、結果的にマージまでの時間が短く なった

Slide 18

Slide 18 text

PRレビューは最優先で とはいえやむを得ない事情でレビューが遅れることも ある... 逆にこれは優先して見て欲しい！という時も... そこはコミュニケーションでカバー

Slide 19

Slide 19 text

PRの複雑さへの対処 ● PRを細かく分割する ● レビュワーがdiffが多いと感じたときは レビュイーに対して分割してもらうよ うにお願いする

Slide 20

Slide 20 text

PRの複雑さへの対処 口頭でレビューする

Slide 21

Slide 21 text

プロダクトの勢いの低下 ● ベロシティの低下がベロシティのレポートグラフ から明らかに ● レトロスペクティブでも、なんかプロダクトの開 発スピード落ちてない？みたいなProblemが... 😨

Slide 22

Slide 22 text

プロダクトの勢いの低下 ● ある程度規模のある案件が複数並行で走り、それ ぞれの担当者が開発を進めていた ● どれも5割から6割の進捗でなかなかリリースまで 持っていけない状態が続いていた

Slide 23

Slide 23 text

リソース効率からフロー効率への切り替え 複数人で1つの案件に集中して開発を進め、その他の 案件はストップ 結果、終わりが見えなかった案件が完了

Slide 24

Slide 24 text

フロー効率がうまくいった要因 ● やることが細分化されていて案件のゴールまでの 残作業が明確だった ● 案件の内容が元々チーム内で共有されていた 参考: ● フロー効率性とリソース効率性について ○ https://www.slideshare.net/i2key/xpjug

Slide 25

Slide 25 text

25 ユーザーが求める機能を提供する ための取り組み

Slide 26

Slide 26 text

Launch DarklyのFeatureManagement機能を導入 ● Launch DarklyとはLaunch Darkly社が運営する 機能管理プラットフォーム ● ユーザーを限定して機能をリリースすることが可 能 if FeatureFlag.admin_user?(user) # FeatureFlagの値がtrueのときだけここに定義された機能が使える else ... end

Slide 27

Slide 27 text

Launch DarklyのFeatureManagement機能を導入 ● これからリリースする機能を一部のユーザーに先 行導入し、反応を見て改善 ● リリース後に大きな手戻りになることを防げる

Slide 28

Slide 28 text

開発前段階で機能を見える化 ユーザの課題を想定し、その解決策および画面デザ インをドキュメント化したものをユーザーに共有

Slide 29

Slide 29 text

29 まとめ

Slide 30

Slide 30 text

エンペイがこの1年でやってきたこと ● 開発フローの安定化 ○ ベロシティの観察・開発メンバーによるチームの 観察・定期的な振り返りをもとにフローを改善 ● ユーザーが求める機能を把握することに注力 ○ なるべく早い段階でユーザーが求める機能を把握

Slide 31

Slide 31 text

今後の課題 問題の抽出と解決策によって得られた効果を数値化 できていないという課題あり ● Four Keysの計測 ● ツールを導入したチームのパフォーマンスモニタ リング に今後取り組んでいこうと考えています

Slide 32

Slide 32 text

32 PR

Slide 33

Slide 33 text

絶賛採用中です！ ● プロダクトの成長を加速させるために 絶賛採用中です。 話を伺いたい方、是非お問い合わせください！ ● 採用サイト ○ https://www.enpay.co.jp/recruit/top

Slide 34

Slide 34 text

34 34 Thank you!