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

運用負荷削減にPdM・エンジニア・デザイナーが三位一体で取り組んだ話 / A story ab...

freee
June 06, 2024
2.2k

運用負荷削減にPdM・エンジニア・デザイナーが三位一体で取り組んだ話 / A story about the trinity of PdM, engineers, and designers working together to reduce the operational burden

freee

June 06, 2024
Tweet

More Decks by freee

Transcript

  1. 2021年11月に中途入社し、 入社以来ずっと外部サービス 連携エンジニア。同期機能の 運用負荷改善や体験改善に 取り組んでいます。日本酒が とても好き。 新卒5年目!カスタマーサ クセス・セールス・サポート 企画の経験を経て、現在は 外部サービス連携の

    PdM。グラフィックデザイン を作るのも好きです。
 mihoi
 外部サービス連携プロダクトマネージャー 新卒4年⽬の関⻄在住プロ ダクトデザイナー。サービ ス連携のデザイナーを2年 務めたあと、エンジニアに 職種異動して今はfreee販 売をつくっています。
 kiba
 元‧外部サービス連携プロダクトデザイナー osso
 外部サービス連携エンジニア PdM PD Eng
  2. 運⽤負荷改善の成果 1年⽬の成果 2年⽬の成果 ユーザー サポート エンジニア ユーザー サポート エンジニア 1ヶ⽉あたりの問い合わせ数は

    約 267件の削減 (※2021年,2022年の繁忙期の⽐較) 1ヶ⽉あたりの起票数は  約 259件の削減 回答までの時間は 平均 22.5時間の短縮 (※2022年,2023年の繁忙期の⽐較)
  3. 運⽤負荷改善の成果 1年⽬の成果 2年⽬の成果 ユーザー サポート エンジニア ユーザー サポート エンジニア 1ヶ⽉あたりの問い合わせ数は

    約 267件の削減 (※2021年,2022年の繁忙期の⽐較) 1ヶ⽉あたりの起票数は  約 259件の削減 回答までの時間は 平均 22.5時間の短縮 (※2022年,2023年の繁忙期の⽐較) 2019年 6月期 2020年 6月期 2017年 6月期 2018年 6月期 2021年 6月期 有料課⾦ユーザー 企業数(件) 有料課⾦ユーザー企業数(1)は 毎年 約 1.2倍 8.3万 12.1万 22.4万 29.3万 16万 2022年 6月期 2023年 6月期 37.9万 45.1万 ※(1) 2023年9⽉末時点。有料課⾦ユーザー企業数には個⼈事業主を含むまたfreeeグループ全体で集計。 2024年 6月期 54.3万
  4. 運⽤負荷改善の成果 1年⽬の成果 2年⽬の成果 ユーザー サポート エンジニア ユーザー サポート エンジニア 1ヶ⽉あたりの問い合わせ数は

    約 267件の削減 (※2021年,2022年の繁忙期の⽐較) 1ヶ⽉あたりの起票数は  約 259件の削減 回答までの時間は 平均 22.5時間の短縮 (※2022年,2023年の繁忙期の⽐較) 2019年 6月期 2020年 6月期 2017年 6月期 2018年 6月期 2021年 6月期 有料課⾦ユーザー 企業数(件) 有料課⾦ユーザー企業数(1)は 毎年 約 1.2倍 8.3万 12.1万 22.4万 29.3万 16万 2022年 6月期 2023年 6月期 37.9万 45.1万 ※(1) 2023年9⽉末時点。有料課⾦ユーザー企業数には個⼈事業主を含むまたfreeeグループ全体で集計。 2024年 6月期 54.3万 ユーザー数が増えているにも関わらず 問い合わせ数を減らすことができ 価値を届ける開発に使える時間が増えた!!
  5. mihoiの⼯夫したこと • 性格的に⼈に迷惑をかけちゃう...のマインドで任せられない節があったが、捨てた • 「スピード感」を考えたときに、1番最短 かつ 最⼤の価値を出せる⼿段を取ろうと 思ったら、⾃然とお任せするようになっていった • みんなも任せられるようなチーム感を、率先して作っていった(つもり!)

      勇気を持って!めっちゃメンバーにお任せした 3 この仕様、体験と合わせて 考えた⽅が良さそうだから kiba-chanよろぴく〜 シンプルにこれ開発が 打ち⼿考えたほうが エラー⾃体なくなるくね? あてくしいまパツってます!! 〇〇だったら開発/デザイナーが 検討しても良さそうなんで 頼んでいいすか?!
  6. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 •

    プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた PdM PD Eng
  7. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 •

    プロトタイプを素早 く作る • UIで解決することに こだわらない • めっちゃ任せた ??? PdM PD Eng
  8. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事!数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   ??? 2

      ??? 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
  9. ①定量‧定性で徹底的にデータを集める この事象に出会った ユーザーの何割が 問い合わせるの? これに関する 問い合わせって ⽉にどのくらい 来ているの? このタイプの 問い合わせって

    平均何時間で 回答できているの? それが改善されたら エラーはどれくらい 減るの? これらのデータをもって 全員が納得したうえで施策を進めている
  10. ①定量‧定性で徹底的にデータを集める ユーザー サポート エンジニア ユーザーからの問い合わせと そのときに発⽣しているエラーを 紐づけられるように サポートも巻き込んで仕組みを構築 感覚的に多い=分析対象を絞る ⼼理的に負荷の⼤きい対応を優先

    CSV出⼒したデータをもとに GASをゴリゴリ書くことも… データが取れないなら連携する仕組みを構築する スマートに取れないデータは 愚直に取り出す 数字に現れないデータも 考慮に含める
  11. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事!数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2

      ??? 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
  12. ②インパクトとコストのバランスを考える 先⾏指標 (⽬標を達成できそうか) リリースした施策の 削減⾒込みインパクト 遅⾏指標 (⽬標を達成しているか) 実際に来ている 年間の問い合わせ 先⾏指標

    (⽬標を達成できそうか) 計画を⽴てる 遅⾏指標 (⽬標を達成しているか) ⽬標を修正する この2つの指標をそれぞれ意識して ⽬標と計画をアップデートする
  13. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事!数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2

      めっちゃ任せた 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
  14. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー •

    フロントの実装 • ドメインの理解 エンジニアに任せたくなるような 複雑なクエリを書ける
  15. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー •

    フロントの実装 • ドメインの理解 実装中に出てきた疑問は 直接githubでレビュー依頼
  16. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー •

    フロントの実装 • ドメインの理解 もはやFigmaも作らず 実装してもらう
  17. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー •

    フロントの実装 • ドメインの理解 勉強会を行い モデル名や テーブル名だけでなく コードの話も共有 エンジニアと 同じ言葉で会話 してくれるため 認識のずれが 起きない安心感
  18. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事!数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2

      めっちゃ任せた 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は任せちゃう • PDにレビューも実装も直接任せちゃう • PdM/PDに深いドメイン知識を持って企画をしてもらう
  19. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 •

    プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた • 定性‧定量でデータ を集める • インパクトとコスト のバランス • めっちゃ任せた PdM PD Eng
  20. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 •

    プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた • 定性‧定量でデータ を集める • インパクトとコスト のバランス • めっちゃ任せた PdM PD Eng