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

by freee

Slide 1

Slide 1 text

運⽤負荷削減に PdM‧エンジニア‧デザイナーが三位⼀体で取り組んだ話 osso, mihoi, kiba 2024年6⽉1⽇

Slide 2

Slide 2 text

2021年11月に中途入社し、入社以来ずっと外部サービス連携エンジニア。同期機能の運用負荷改善や体験改善に取り組んでいます。日本酒がとても好き。新卒5年目！カスタマーサクセス・セールス・サポート企画の経験を経て、現在は外部サービス連携の PdM。グラフィックデザインを作るのも好きです。  mihoi  外部サービス連携プロダクトマネージャー新卒4年⽬の関⻄在住プロダクトデザイナー。サービス連携のデザイナーを2年務めたあと、エンジニアに職種異動して今はfreee販売をつくっています。  kiba  元‧外部サービス連携プロダクトデザイナー osso  外部サービス連携エンジニア PdM PD Eng

Slide 3

Slide 3 text

　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ〜今後の展望〜⽬次

Slide 4

Slide 4 text

　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ〜今後の展望〜⽬次

Slide 5

Slide 5 text

コアエンジンチームとは？

Slide 6

Slide 6 text

⾦銭にまつわる業務データをfreeeに取り込むことで、時間が奪われる記録作業からユーザを解放する外部サービスの業務/経営データを収集&活⽤する機能の開発を担当するチーム

Slide 7

Slide 7 text

⾦銭にまつわる業務データをfreeeに取り込むことで、時間が奪われる記録作業からユーザを解放する外部サービスの業務/経営データを収集&活⽤する機能の開発を担当するチーム約 2,300のサービスと連携

Slide 8

Slide 8 text

連携先ごとに仕様が異なるため運⽤負荷がとても⼤きい

Slide 9

Slide 9 text

運⽤‧保守の主な対応内容問い合わせ対応メンテナンスサーバー監視不具合対応マニュアル作成

Slide 10

Slide 10 text

運⽤‧保守の主な対応内容問い合わせ対応メンテナンスサーバー監視不具合対応マニュアル作成価値を届け切るために削ってはならない発生させない・リードタイムを短くすることが価値に繋がる

Slide 11

Slide 11 text

運⽤‧保守の主な対応内容問い合わせ対応メンテナンスサーバー監視不具合対応マニュアル作成価値を届け切るために削ってはならない対応コストを下げて価値を最速で届けることに注力したい

Slide 12

Slide 12 text

今回のテーマ運⽤ ≒ 問い合わせ対応

Slide 13

Slide 13 text

freeeでの問い合わせ対応フロー仕様の質問や不具合をサポートに問い合わせる回答できるものは回答する調査が必要なものはエンジニアへ調査をしてサポートに回答するユーザーサポートエンジニア

Slide 14

Slide 14 text

freeeでの問い合わせ対応フロー仕様の質問や不具合をサポートに問い合わせる回答できるものは回答する調査が必要なものはエンジニアへ調査をしてサポートに回答するユーザーサポートエンジニア freee全体の問い合わせのうち約 15% （※直近2年間）

Slide 15

Slide 15 text

freeeでの問い合わせ対応フロー仕様の質問や不具合をサポートに問い合わせる回答できるものは回答する調査が必要なものはエンジニアへ調査をしてサポートに回答するユーザーサポートエンジニアサポートからの起票のうち約 48%

Slide 16

Slide 16 text

freeeでの問い合わせ対応フロー仕様の質問や不具合をサポートに問い合わせる回答できるものは回答する調査が必要なものはエンジニアへ調査をしてサポートに回答するユーザーサポートエンジニア数も多くとっても⼤変！！ユーザーに価値を届ける⾏動に注⼒できない！課題 =

Slide 17

Slide 17 text

　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ〜今後の展望〜⽬次

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

運⽤負荷改善の成果 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万

Slide 20

Slide 20 text

Slide 21

Slide 21 text

　⽬次 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ〜今後の展望〜

Slide 22

Slide 22 text

PdM PD Eng うまくいった理由

Slide 23

Slide 23 text

??? PdM PD Eng うまくいった理由

Slide 24

Slide 24 text

mihoiはどう思う？

Slide 25

Slide 25 text

mihoiの⼯夫したこと ● ユーザーさん⾃⾝で⾔語化してくださった問い合わせにこそ、つまずきが詰まっている ● 実際時間はすごいかかる！300件くらいを2営業⽇分くらい使って読み込んだりもした ● もともとユーザー対応組織にいたので、その肌感も思い出した（武器を活かす）問い合わせは宝箱！愚直に問い合わせをたくさん読み込んだ 1

Slide 26

Slide 26 text

mihoiの⼯夫したこと約2年間で100本くらい書いてたデザイナー/エンジニアに意図が伝わりやすかった（よね？） ● 「なぜやるか‧どういう価値を届けたいか」をステークホルダーに伝えることは、PdM の外しちゃならん責務だと思っている ● そのために必要なら、クエリも書くしモックも書いた⾃分がやらなくていいことも、ときにはやってみた 2

Slide 27

Slide 27 text

mihoiの⼯夫したこと ● 性格的に⼈に迷惑をかけちゃう...のマインドで任せられない節があったが、捨てた ● 「スピード感」を考えたときに、１番最短かつ最⼤の価値を出せる⼿段を取ろうと思ったら、⾃然とお任せするようになっていった ● みんなも任せられるようなチーム感を、率先して作っていった（つもり！）勇気を持って！めっちゃメンバーにお任せした 3 この仕様、体験と合わせて考えた⽅が良さそうだから kiba-chanよろぴく〜シンプルにこれ開発が打ち⼿考えたほうがエラー⾃体なくなるくね？あてくしいまパツってます！！〇〇だったら開発/デザイナーが検討しても良さそうなんで頼んでいいすか？！

Slide 28

Slide 28 text

● 愚直に問い合わせを⾒る ● ⾃分がやらなくていい事も時にはやった ● めっちゃ任せたうまくいった理由 PdM PD Eng

Slide 29

Slide 29 text

● 愚直に問い合わせを⾒る ● ⾃分がやらなくていい事も時にはやった ● めっちゃ任せたうまくいった理由 ??? PdM PD Eng

Slide 30

Slide 30 text

kibachanはどう思う？

Slide 31

Slide 31 text

kibachanの⼯夫したことプロトタイプを素早く作る 1 UIの変更だけで解決しない 2 めっちゃ巻き込んだし、めっちゃ任せた 3

Slide 32

Slide 32 text

プロトタイプを素早く作る 1

Slide 33

Slide 33 text

プロトタイプを素早く作る 1 ﬁgmaでサクッとプロトタイプ作ってシュッと共有

Slide 34

Slide 34 text

● エンジニア/PdM/デザイナーの職種の間には当然、前提知識のギャップがある。 ○ 特にエンジニアリング周りの知識のギャップが⼤きい ● 具体的な画⾯を作って共有することで、知識や認識のギャップが埋まりやすくなる。結果、議論が深まりやすいプロトタイプを素早く作る 1

Slide 35

Slide 35 text

UIの変更だけで解決しない 2

Slide 36

Slide 36 text

UIの変更だけで解決しない 2 ⼀旦それでパッとプロトタイプ作ってみますーこういうUIで解決できるんじゃないか？

Slide 37

Slide 37 text

UIの変更だけで解決しない 2 ⼀旦それでパッとプロトタイプ作ってみますーこういうUIで解決できるんじゃないか？想定よりも条件が複雑になって、操作が難しいUIが爆誕

Slide 38

Slide 38 text

UIの変更だけで解決しない 2 やっぱり０から考え直した⽅がいいんちゃう？そもそもユーザーの操作をなくせないかな？⼀旦それでパッとプロトタイプ作ってみますーこういうUIで解決できるんじゃないか？

Slide 39

Slide 39 text

UIの変更だけで解決しない 2 やっぱり０から考え直した⽅がいいんちゃう？そもそもユーザーの操作をなくせないかな？⼀旦それでパッとプロトタイプ作ってみますーこういうUIで解決できるんじゃないか？結果、裏側のロジックを変更して、極⼒ユーザーさんに操作をさせない⽅針で進めた

Slide 40

Slide 40 text

UIの変更だけで解決しない 2 ● 学び① ○ ⼀度作ったプロトタイプに縛られすぎないようにする ● 学び② ○ 「そもそも操作をなくせないか」を⼀番最初に考える

Slide 41

Slide 41 text

UIで解決することにこだわらない 2 freeeのような業務アプリだと『使いやすくて迷いにくいUI』より『そもそもユーザーの操作が不要(⾃動)』な⽅が優れた体験である場合が多い

Slide 42

Slide 42 text

めっちゃ巻き込んだし、めっちゃ任せた 3

Slide 43

Slide 43 text

めっちゃ巻き込んだし、めっちゃ任せた 3 Engが画⾯をデザイン/実装して、 PDはUIレビューをする Engが企画書を作って、チームでブラッシュアップしていく

Slide 44

Slide 44 text

めっちゃ巻き込んだし、めっちゃ任せた 3 ● 「ユーザー体験の品質を担保する」ことがPDの役割 ○ より素早く質⾼く担保できるなら、だれが導線設計や画⾯デザインしてもいい ● 職種関係なくユーザー解像度が⾼いチームだったので任せられた ○ 全員がユーザー価値⽬線で議論できる ○ エンジニアもインタビューやユーザビリティテストに参加してる

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

● 愚直に問い合わせを⾒る ● ⾃分がやらなくていい事も時にはやった ● めっちゃ任せたうまくいった理由 ● プロトタイプを素早く作る ● UIで解決することにこだわらない ● めっちゃ任せた ??? PdM PD Eng

Slide 47

Slide 47 text

ossoはどう思う？

Slide 48

Slide 48 text

● 議論は基本的に数字ベース。客観的事実で意思決定を進める ● 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 ● データが取れないなら連携する仕組みを構築する定量‧定性で徹底的にデータを集める 1 ？？？ 2 ？？？ 3 ● 掛けるコストに⾒合うインパクトが出せる施策から実施する ● インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを ● 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート ● PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう ● PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう ● PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう

Slide 49

Slide 49 text

①定量‧定性で徹底的にデータを集めるこの事象に出会ったユーザーの何割が問い合わせるの？これに関する問い合わせって⽉にどのくらい来ているの？このタイプの問い合わせって平均何時間で回答できているの？それが改善されたらエラーはどれくらい減るの？

Slide 50

Slide 50 text

①定量‧定性で徹底的にデータを集めるこの事象に出会ったユーザーの何割が問い合わせるの？これに関する問い合わせって⽉にどのくらい来ているの？このタイプの問い合わせって平均何時間で回答できているの？それが改善されたらエラーはどれくらい減るの？これらのデータをもって全員が納得したうえで施策を進めている

Slide 51

Slide 51 text

①定量‧定性で徹底的にデータを集めるユーザーサポートエンジニアユーザーからの問い合わせとそのときに発⽣しているエラーを紐づけられるようにサポートも巻き込んで仕組みを構築感覚的に多い＝分析対象を絞る⼼理的に負荷の⼤きい対応を優先 CSV出⼒したデータをもとに GASをゴリゴリ書くことも…

Slide 52

Slide 52 text

①定量‧定性で徹底的にデータを集めるユーザーサポートエンジニアユーザーからの問い合わせとそのときに発⽣しているエラーを紐づけられるようにサポートも巻き込んで仕組みを構築感覚的に多い＝分析対象を絞る⼼理的に負荷の⼤きい対応を優先 CSV出⼒したデータをもとに GASをゴリゴリ書くことも… データが取れないなら連携する仕組みを構築するスマートに取れないデータは愚直に取り出す数字に現れないデータも考慮に含める

Slide 53

Slide 53 text

● 議論は基本的に数字ベース。客観的事実で意思決定を進める ● 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 ● データが取れないなら連携する仕組みを構築する定量‧定性で徹底的にデータを集める 1 インパクトとコストのバランスを考える 2 ？？？ 3 ● 掛けるコストに⾒合うインパクトが出せる施策から実施する ● インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを ● 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート ● PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう ● PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう ● PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう

Slide 54

Slide 54 text

②インパクトとコストのバランスを考える⾒込みの試算だとインパクトに対してコスト⼤きくない？⽬標に対して現在地点はここだけど⼤丈夫？

Slide 55

Slide 55 text

②インパクトとコストのバランスを考える施策案⼀覧にインパクトとコストもざっくり記⼊優先順位を考える段階では試算を正確に出すことに拘りすぎない

Slide 56

Slide 56 text

②インパクトとコストのバランスを考える起票数削減⽬標と⾒込みインパクト削減数必達⽬標ムーンショット⽬標リリース済み施策の起票数削減⾒込み数バランスが取れている状態 = ⽬標に対して達成⽔準であること

Slide 57

Slide 57 text

②インパクトとコストのバランスを考える先⾏指標（⽬標を達成できそうか）リリースした施策の削減⾒込みインパクト遅⾏指標（⽬標を達成しているか）すでに発⽣した運⽤負荷

Slide 58

Slide 58 text

②インパクトとコストのバランスを考える先⾏指標（⽬標を達成できそうか）リリースした施策の削減⾒込みインパクト遅⾏指標（⽬標を達成しているか）実際に来ている年間の問い合わせ先⾏指標（⽬標を達成できそうか）計画を⽴てる遅⾏指標（⽬標を達成しているか）⽬標を修正するこの2つの指標をそれぞれ意識して⽬標と計画をアップデートする

Slide 59

Slide 59 text

● 議論は基本的に数字ベース。客観的事実で意思決定を進める ● 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 ● データが取れないなら連携する仕組みを構築する定量‧定性で徹底的にデータを集める 1 インパクトとコストのバランスを考える 2 めっちゃ任せた 3 ● 掛けるコストに⾒合うインパクトが出せる施策から実施する ● インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを ● 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート ● PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう ● PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう ● PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう

Slide 60

Slide 60 text

③めっちゃ任せた他の業務に追われていることも‧‧‧！？そんなときは思い切ってお任せさせてもらってました

Slide 61

Slide 61 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 62

Slide 62 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 68

Slide 68 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 69

Slide 69 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解

Slide 70

Slide 70 text

③めっちゃ任せた ● インパクト試算出し ● 効果測定 ● ドメインの理解 ● PRレビュー ● フロントの実装 ● ドメインの理解勉強会を行いモデル名やテーブル名だけでなくコードの話も共有エンジニアと同じ言葉で会話してくれるため認識のずれが起きない安心感

Slide 71

Slide 71 text

● 議論は基本的に数字ベース。客観的事実で意思決定を進める ● 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 ● データが取れないなら連携する仕組みを構築する定量‧定性で徹底的にデータを集める 1 インパクトとコストのバランスを考える 2 めっちゃ任せた 3 ● 掛けるコストに⾒合うインパクトが出せる施策から実施する ● インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを ● 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート ● PdMにインパクト試算や効果測定は任せちゃう ● PDにレビューも実装も直接任せちゃう ● PdM/PDに深いドメイン知識を持って企画をしてもらう

Slide 72

Slide 72 text

　⽬次 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ〜今後の展望〜

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Slide 75

Slide 75 text

なぜ任せられたか？マジ価値を届ける最速の⼿段はなに？を全員が常に考えていたロールとしての領域に責任は持っていながらできるところはできる⼈がやれば良い⼼理的安全性爆⾼めっちゃ任せられた

Slide 76

Slide 76 text

今後の展望次年度のMissionは... Churn改善!! = 利⽤し続けてもらう価値を技術で届ける! Churnは半年〜1年後にようやく結果が⾒える難しい領域... その分、運⽤負荷削減のノウハウは活きてくる！

Slide 77

Slide 77 text

今後の展望次年度のMissionは... Churn改善!! = 利⽤し続けてもらう価値を技術で届ける! Churnは半年〜1年後にようやく結果が⾒える難しい領域... その分、運⽤負荷削減のノウハウは活きてくる！やってくぞ〜！！（kiba-chanも新チームでengがんばれ！！）

Slide 78

Slide 78 text

No content