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

Transcript

1. 運⽤負荷削減に PdM‧エンジニア‧デザイナーが 三位⼀体で取り組んだ話 osso, mihoi, kiba 2024年6⽉1⽇
2. 2021年11月に中途入社し、 入社以来ずっと外部サービス 連携エンジニア。同期機能の 運用負荷改善や体験改善に 取り組んでいます。日本酒が とても好き。 新卒5年目！カスタマーサ クセス・セールス・サポート 企画の経験を経て、現在は 外部サービス連携の PdM。グラフィックデザイン を作るのも好きです。
 mihoi
 外部サービス連携プロダクトマネージャー 新卒4年⽬の関⻄在住プロ ダクトデザイナー。サービ ス連携のデザイナーを2年 務めたあと、エンジニアに 職種異動して今はfreee販 売をつくっています。
 kiba
 元‧外部サービス連携プロダクトデザイナー osso
 外部サービス連携エンジニア PdM PD Eng
3. 　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ 〜今後の展望〜 ⽬次
4. 　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ 〜今後の展望〜 ⽬次
5. コアエンジンチームとは？
6. ⾦銭にまつわる業務データをfreeeに取り込むことで、時間が奪われる記録作業からユーザを解放する 外部サービスの業務/経営データを 収集&活⽤する機能の開発を担当するチーム
7. ⾦銭にまつわる業務データをfreeeに取り込むことで、時間が奪われる記録作業からユーザを解放する 外部サービスの業務/経営データを 収集&活⽤する機能の開発を担当するチーム 約 2,300の サービスと連携
8. 連携先ごとに仕様が異なるため 運⽤負荷がとても⼤きい
9. 運⽤‧保守の主な対応内容 問い合わせ対応 メンテナンス サーバー監視 不具合対応 マニュアル作成
10. 運⽤‧保守の主な対応内容 問い合わせ対応 メンテナンス サーバー監視 不具合対応 マニュアル作成 価値を届け切るために 削ってはならない 発生させない・リードタイムを 短くすることが価値に繋がる
11. 運⽤‧保守の主な対応内容 問い合わせ対応 メンテナンス サーバー監視 不具合対応 マニュアル作成 価値を届け切るために 削ってはならない 対応コストを下げて 価値を最速で届けることに注力したい
12. 今回のテーマ 運⽤ ≒ 問い合わせ対応
13. freeeでの問い合わせ対応フロー 仕様の質問や不具合を サポートに問い合わせる 回答できるものは回答する 調査が必要なものはエンジニアへ 調査をしてサポートに回答する ユーザー サポート エンジニア
14. freeeでの問い合わせ対応フロー 仕様の質問や不具合を サポートに問い合わせる 回答できるものは回答する 調査が必要なものはエンジニアへ 調査をしてサポートに回答する ユーザー サポート エンジニア freee全体の 問い合わせのうち 約 15% （※直近2年間）
15. freeeでの問い合わせ対応フロー 仕様の質問や不具合を サポートに問い合わせる 回答できるものは回答する 調査が必要なものはエンジニアへ 調査をしてサポートに回答する ユーザー サポート エンジニア サポートからの 起票のうち 約 48%
16. freeeでの問い合わせ対応フロー 仕様の質問や不具合を サポートに問い合わせる 回答できるものは回答する 調査が必要なものはエンジニアへ 調査をしてサポートに回答する ユーザー サポート エンジニア 数も多くとっても⼤変！！ ユーザーに価値を届ける⾏動に 注⼒できない！ 課題 =
17. 　 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ 〜今後の展望〜 ⽬次
18. 運⽤負荷改善の成果 1年⽬の成果 2年⽬の成果 ユーザー サポート エンジニア ユーザー サポート エンジニア 1ヶ⽉あたりの問い合わせ数は 約 267件の削減 （※2021年,2022年の繁忙期の⽐較） 1ヶ⽉あたりの起票数は  約 259件の削減 回答までの時間は 平均 22.5時間の短縮 （※2022年,2023年の繁忙期の⽐較）
19. 運⽤負荷改善の成果 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万
20. 運⽤負荷改善の成果 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万 ユーザー数が増えているにも関わらず 問い合わせ数を減らすことができ 価値を届ける開発に使える時間が増えた！！
21. 　 ⽬次 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ 〜今後の展望〜
22. PdM PD Eng うまくいった理由
23. ??? PdM PD Eng うまくいった理由
24. mihoiは どう思う？
25. mihoiの⼯夫したこと • ユーザーさん⾃⾝で⾔語化してくださった問い合わせにこそ、つまずきが詰まっている • 実際時間はすごいかかる！300件くらいを2営業⽇分くらい使って読み込んだりもした • もともとユーザー対応組織にいたので、その肌感も思い出した（武器を活かす）   問い合わせは宝箱！愚直に問い合わせをたくさん読み込んだ 1
26. mihoiの⼯夫したこと 約2年間で100本くらい書いてた デザイナー/エンジニアに 意図が伝わりやすかった（よね？） • 「なぜやるか‧どういう価値を届けたいか」をステークホルダーに伝えることは、PdM の外しちゃならん責務だと思っている • そのために必要なら、クエリも書くしモックも書いた   ⾃分がやらなくていいことも、ときにはやってみた 2
27. mihoiの⼯夫したこと • 性格的に⼈に迷惑をかけちゃう...のマインドで任せられない節があったが、捨てた • 「スピード感」を考えたときに、１番最短 かつ 最⼤の価値を出せる⼿段を取ろうと 思ったら、⾃然とお任せするようになっていった • みんなも任せられるようなチーム感を、率先して作っていった（つもり！）   勇気を持って！めっちゃメンバーにお任せした 3 この仕様、体験と合わせて 考えた⽅が良さそうだから kiba-chanよろぴく〜 シンプルにこれ開発が 打ち⼿考えたほうが エラー⾃体なくなるくね？ あてくしいまパツってます！！ 〇〇だったら開発/デザイナーが 検討しても良さそうなんで 頼んでいいすか？！
28. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 PdM PD Eng
29. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 ??? PdM PD Eng
30. kibachanは どう思う？
31. kibachanの⼯夫したこと   プロトタイプを素早く作る 1   UIの変更だけで解決しない 2   めっちゃ巻き込んだし、めっちゃ任せた 3
32.   プロトタイプを素早く作る 1
33.   プロトタイプを素早く作る 1 figmaでサクッとプロトタイプ作ってシュッと共有
34. • エンジニア/PdM/デザイナーの職種の間には当然、前提知識のギャップがあ る。 ◦ 特にエンジニアリング周りの知識のギャップが⼤きい • 具体的な画⾯を作って共有することで、知識や認識のギャップが埋まりやす くなる。結果、議論が深まりやすい   プロトタイプを素早く作る 1
35.   UIの変更だけで解決しない 2
36.   UIの変更だけで解決しない 2 ⼀旦それでパッと プロトタイプ作ってみ ますー こういうUIで解決でき るんじゃないか？
37.   UIの変更だけで解決しない 2 ⼀旦それでパッと プロトタイプ作ってみ ますー こういうUIで解決でき るんじゃないか？ 想定よりも条件が複雑になって、 操作が難しいUIが爆誕
38.   UIの変更だけで解決しない 2 やっぱり０から考え直し た⽅がいいんちゃう？ そもそもユーザーの操作 をなくせないかな？ ⼀旦それでパッと プロトタイプ作ってみ ますー こういうUIで解決でき るんじゃないか？
39.   UIの変更だけで解決しない 2 やっぱり０から考え直し た⽅がいいんちゃう？ そもそもユーザーの操作 をなくせないかな？ ⼀旦それでパッと プロトタイプ作ってみ ますー こういうUIで解決でき るんじゃないか？ 結果、裏側のロジックを変更して、 極⼒ユーザーさんに操作をさせない⽅針で進めた
40.   UIの変更だけで解決しない 2 • 学び① ◦ ⼀度作ったプロトタイプに縛られすぎないようにする • 学び② ◦ 「そもそも操作をなくせないか」を⼀番最初に考える
41.   UIで解決することにこだわらない 2 freeeのような業務アプリだと 『使いやすくて迷いにくいUI』より 『そもそもユーザーの操作が不要(⾃動)』な⽅が 優れた体験である場合が多い
42.   めっちゃ巻き込んだし、めっちゃ任せた 3
43.   めっちゃ巻き込んだし、めっちゃ任せた 3 Engが画⾯をデザイン/実装して、 PDはUIレビューをする Engが企画書を作って、 チームでブラッシュアップしていく
44.   めっちゃ巻き込んだし、めっちゃ任せた 3 • 「ユーザー体験の品質を担保する」ことがPDの役割 ◦ より素早く質⾼く担保できるなら、だれが導線設計や画⾯デザインしてもいい • 職種関係なくユーザー解像度が⾼いチームだったので任せられた ◦ 全員がユーザー価値⽬線で議論できる ◦ エンジニアもインタビューやユーザビリティテストに参加してる
45. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 • プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた PdM PD Eng
46. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 • プロトタイプを素早 く作る • UIで解決することに こだわらない • めっちゃ任せた ??? PdM PD Eng
47. ossoは どう思う？
48. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   ？？？ 2   ？？？ 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
49. ①定量‧定性で徹底的にデータを集める この事象に出会った ユーザーの何割が 問い合わせるの？ これに関する 問い合わせって ⽉にどのくらい 来ているの？ このタイプの 問い合わせって 平均何時間で 回答できているの？ それが改善されたら エラーはどれくらい 減るの？
50. ①定量‧定性で徹底的にデータを集める この事象に出会った ユーザーの何割が 問い合わせるの？ これに関する 問い合わせって ⽉にどのくらい 来ているの？ このタイプの 問い合わせって 平均何時間で 回答できているの？ それが改善されたら エラーはどれくらい 減るの？ これらのデータをもって 全員が納得したうえで施策を進めている
51. ①定量‧定性で徹底的にデータを集める ユーザー サポート エンジニア ユーザーからの問い合わせと そのときに発⽣しているエラーを 紐づけられるように サポートも巻き込んで仕組みを構築 感覚的に多い＝分析対象を絞る ⼼理的に負荷の⼤きい対応を優先 CSV出⼒したデータをもとに GASをゴリゴリ書くことも…
52. ①定量‧定性で徹底的にデータを集める ユーザー サポート エンジニア ユーザーからの問い合わせと そのときに発⽣しているエラーを 紐づけられるように サポートも巻き込んで仕組みを構築 感覚的に多い＝分析対象を絞る ⼼理的に負荷の⼤きい対応を優先 CSV出⼒したデータをもとに GASをゴリゴリ書くことも… データが取れないなら連携する仕組みを構築する スマートに取れないデータは 愚直に取り出す 数字に現れないデータも 考慮に含める
53. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2   ？？？ 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
54. ②インパクトとコストのバランスを考える ⾒込みの試算だと インパクトに対して コスト⼤きくない？ ⽬標に対して 現在地点は ここだけど⼤丈夫？
55. ②インパクトとコストのバランスを考える 施策案⼀覧にインパクトとコストもざっくり記⼊ 優先順位を考える段階では試算を正確に出すことに拘りすぎない
56. ②インパクトとコストのバランスを考える 起票数削減⽬標と⾒込みインパクト削減数 必達⽬標 ムーンショット⽬標 リリース済み施策の起票数削減⾒込み数 バランスが取れている状態 = ⽬標に対して 達成⽔準であること
57. ②インパクトとコストのバランスを考える 先⾏指標 （⽬標を達成できそうか） リリースした施策の 削減⾒込みインパクト 遅⾏指標 （⽬標を達成しているか） すでに発⽣した 運⽤負荷
58. ②インパクトとコストのバランスを考える 先⾏指標 （⽬標を達成できそうか） リリースした施策の 削減⾒込みインパクト 遅⾏指標 （⽬標を達成しているか） 実際に来ている 年間の問い合わせ 先⾏指標 （⽬標を達成できそうか） 計画を⽴てる 遅⾏指標 （⽬標を達成しているか） ⽬標を修正する この2つの指標をそれぞれ意識して ⽬標と計画をアップデートする
59. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2   めっちゃ任せた 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は仕組みだけ作って任せちゃう • PDがデザインシステムを使って画⾯を実装してくれるので、実装を任せちゃう • PdM/PDにEng事情の仕様もある程度理解してもらったうえで施策案を考えてもらう
60. ③めっちゃ任せた 他の業務に追われていることも‧‧‧！？ そんなときは思い切ってお任せさせてもらってました
61. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
62. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
63. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解 エンジニアに任せたくなるような 複雑なクエリを書ける
64. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
65. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解 実装中に出てきた疑問は 直接githubでレビュー依頼
66. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解 もはやFigmaも作らず 実装してもらう
67. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
68. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
69. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解
70. ③めっちゃ任せた • インパクト試算出し • 効果測定 • ドメインの理解 • PRレビュー • フロントの実装 • ドメインの理解 勉強会を行い モデル名や テーブル名だけでなく コードの話も共有 エンジニアと 同じ言葉で会話 してくれるため 認識のずれが 起きない安心感
71. • 議論は基本的に数字ベース。客観的事実で意思決定を進める • 定性データも⼤事！数字に現れづらい⼼理的な運⽤負荷は優先順位に反映 • データが取れないなら連携する仕組みを構築する   定量‧定性で徹底的にデータを集める 1   インパクトとコストのバランスを考える 2   めっちゃ任せた 3 • 掛けるコストに⾒合うインパクトが出せる施策から実施する • インパクト試算/コスト試算⾃体にもインパクトとコストのバランスを • 先⾏指標と遅⾏指標を意識し⽬標と計画をアップデート • PdMにインパクト試算や効果測定は任せちゃう • PDにレビューも実装も直接任せちゃう • PdM/PDに深いドメイン知識を持って企画をしてもらう
72. 　 ⽬次 01 コアエンジンチームとは 02 運⽤の課題とその改善の成果 03 成果の理由 04 まとめ 〜今後の展望〜
73. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 • プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた • 定性‧定量でデータ を集める • インパクトとコスト のバランス • めっちゃ任せた PdM PD Eng
74. • 愚直に問い合わせを ⾒る • ⾃分がやらなくてい い事も時にはやった • めっちゃ任せた うまくいった理由 • プロトタイプを素早 く作る • UIの変更だけで解決 しない • めっちゃ任せた • 定性‧定量でデータ を集める • インパクトとコスト のバランス • めっちゃ任せた PdM PD Eng
75. なぜ任せられたか？ マジ価値を届ける 最速の⼿段はなに？ を全員が常に考えていた ロールとしての領域に 責任は持っていながら できるところはできる ⼈がやれば良い ⼼理的安全性爆⾼ めっちゃ任せられた
76. 今後の展望 次年度のMissionは... Churn改善!! = 利⽤し続けてもらう価値を 技術で届ける! Churnは半年〜1年後に ようやく結果が⾒える難しい領域... その分、運⽤負荷削減のノウハウは活きてくる！
77. 今後の展望 次年度のMissionは... Churn改善!! = 利⽤し続けてもらう価値を 技術で届ける! Churnは半年〜1年後に ようやく結果が⾒える難しい領域... その分、運⽤負荷削減のノウハウは活きてくる！ やってくぞ〜！！ （kiba-chanも新チームでengがんばれ！！）