freeeカードで経理を爆速で開発できたワケ / How we were able to develop accounting with freee cards at a blazing speed

Transcript

1. freeeカードで経理を爆速で 開発できたワケ him0 tsuyuki taro 2024年6⽉1⽇
2. 2017年4月 新卒入社
 2023年まで会計を開発
 2024年からは支出管理 リードエンジニア
 2 him0
 ⽀出管理 エンジニア マネージャー 2022 freeeにjoin
 2016 mikatus株式会社
 8年ほど会計畑でプロダ クトデザイナーをしていま す
 tsuyuki
 ⽀出管理 デザイナー 2018年4月 新卒入社
 2022年までカスタマーサクセス
 2023年からfreee支出管理 PdM
 taro
 ⽀出管理 PdM 去年の発表

3. 　 「freeeカードで経理」という機能を題材に 企画、開発、運⽤ それぞれのフェーズで取った 開発速度を上げるためのアクションを紹介します この発表でお伝えしたいこと • チームの開発プロセスを⾔語化する‧⾒直すきっかけ • 普段使っているサービスの裏側を想像するきっかけ こんな取り組みもある！技術もある！そんな発信が増えると嬉しいです X なら #freee技術の⽇ でお願いします
4. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
5. 　 爆速っていうけど、開発速度ってなんだっけ？ ⼿早くできた、少ない⼯数でできた！ なんだか、良いことの様に聞こえるけど、⼿放しでよろこべる？ 進んだ距離 かかった時間 速度 XXX速度を抽象化してみると 「何らかの効果」を「単位時間」あたりどれだけ出しているかと⾔い換えられる プロダクト開発における「何らかの効果」を定義しないと開発速度は扱えない
6. 　 短期間の開発で、ユーザ体験の良いものができた → よいこと 短期間の開発だけど、ユーザ体験の良くないものができた → よくなさそう 開発速度を定義する たくさんの⼈が関わって、1億円のビジネスインパクトが作る → よいこと 少数精鋭短期決戦で、1億円のビジネスインパクトが作る → もっとよいこと プロダクトの価値 プロジェクトに使う時間 開発速度 機能・非機能 問わず 価値が高いほどよい 少ない人数で意思決定 ができる方が良い 手数が少ない 手段がよい の総和 などなど... ※帰納的なので絶対ではない ポジティブな効果
7. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
8. 　 2023年12⽉に freeeカードで経理 をリリース 法人クレジットカードを日々の支払いに利用してもらう機能 機能としては以前から提供してきたが、制度の変化に合わせて刷新
9. 　 開発のきっかけは2023年インボイス制度 取引先がインボイス制度適格請求書発行事業者か否かで税率が変化 経理処理において領収書の保存がほぼ必須化した 領収書は「簡易インボイス」「適格簡易請求書」 領収書なのに請求書という... インボイス制度の概要｜国税庁 より
10. 　 freee会計 Before インボイス制度 法人カードの利用は利用明細だけあれば経理処理できた 経理 取引登録 利用明細 自動同期 利用明細 取引 カードの利用 freeeカード 従業員 利用明細
11. 　 After インボイス制度 従業員から領収書を受け取って電子化して保存する必要ができた 従業員は会計のアカウントを持ってないと電子化する口がない カードの利用 freee会計 freeeカード 領収書 アップロード 取引登録 領収書 業務が増えた 領収書の提出 従業員 経理 利用明細 取引 利用明細 自動同期 利用明細
12. 　 インボイス制度の施⾏に合わせて領収書回収をリリース カード利用を検知してメールやslackで領収書提出を催促 従業員が領収書を提出できる仕組みを構築
13. 　 freeeカード 領収書回収機能で実現できたこと 従業員が領収書を経理担当者に手渡しするフローは廃止できた 領収書が電子化される前に廃棄されてしまう状況は回避できた 従業員 freee会計 通知 カードの利用 領収書 アップロード 領収書 利用明細 取引 経理 取引登録 利用明細 自動同期 領収書 自動同期 領収書 利用明細
14. 　 freeeカード 領収書回収機能でまだ解決できなかった問題 freee会計に利用明細と領収書の関連付けの情報が渡せない 関連付けの情報をfreee会計の画面上で確認するUIがない 従業員 通知 カードの利用 関連付け 確認 領収書 アップロード 利用明細 自動同期 領収書 自動同期 経理 必要な情報は揃ったけど 管理は大変 領収書 利用明細 自動で経理 ファイルボックス
15. 　 freeeカード freeeカードで経理でこうなった 従業員 通知 カードの利用 領収書 アップロード 利用明細 自動同期 領収書 自動同期 同期の仕組みを刷新、利用明細と領収書を関連付けて会計に同期 freee会計上にクレジットカードの経理に特化した画面を作成 経理 利用状況が追いやすい ちゃんと領収書あるね 領収書 利用明細
16. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
17. 　 各ロールで役割・責任を分担するか
 PdM, Eng, デザイナー, QA, ...
18. 　 各ロールで役割・責任を分担するか
 チームによる違い PMの腕の⾒せ所 阿吽の呼吸でしょ そこは経験だよ
19. 　 freeeカード 領収書回収機能でまだ解決できなかった問題 従業員 通知 カードの利用 関連付け 確認 領収書 アップロード 利用明細 自動同期 領収書 自動同期 経理 領収書 利用明細 自動で経理 ファイルボックス 経理の人が関連付けを確認しつつ、経理作業を行うUIを 会計上に何らかの形で実現する必要があった
20. 　 実現⽅法は2つ   「⾃動で経理」でいいやん PMとしての最初の思考 自動で経理 新規の UI OR ユーザーも既存画⾯に慣れているし、これをイメージするだろうな… UIも既にあるから、PDも考える必要はないだろうし… 実装も裏側で関連付けやってあげるだけだから、おそらく軽いな…
21. 　 開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか？今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」 PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか？めちゃくちゃ⼤変だけどやる価値あるんです か？」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ
22. 　 開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか？今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」 PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか？めちゃくちゃ⼤変だけどやる価値あるんです か？」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ 「ちょっと待った！」
23. 　 👳「画面のこと、言い過ぎだよ」

24. 　 責任領域に対する考え⽅ PdMが決める領域 （解決する課題、業務） Engが決める領域 （実装） デザイナーが決める領域 （UIデザイン） 重なる領域は意識合わせが必要な領域、重なりがない部分はそれぞれで意思決定できる
25. 　 デザイナーが決める領域 （UIデザイン） PdMが決める領域 （解決する課題、業務） Engが決める領域 （実装） 「"自動で経理"にクレカ領収書機能を付けたい」 責任領域に対する考え⽅ これくらい 言及している デザインシステムとの 兼ね合い 既存の負債との 兼ね合い Eng や デザイナーが意思決定すべき領域まで⾔及していた
26. 　 責任領域に対する考え⽅ 責任領域を踏み越える判断 分からないことが増える PdMが決める領域 （解決する課題、業務） Engが決める領域 （実装） • 想定していないデメリットや問題 • そもそも決められない • 納得感の薄い「決め」 デザイナーが決める領域 （UIデザイン） 「"自動で経理"にクレカ領収書機能を付けたい」 これくらい 言及している
27. 　 PdMが決める領域 （解決する課題、業務） Engが決める領域 （実装） デザイナーが決める領域 （UIデザイン） 責任領域に対する考え⽅ ここを率先して言及 本来 PdM が率先すべき領域はどこか 👳それが「業務の要求」だよ
28. 　 各役割の責任が明確に • 責任領域のなかは⾃分で決める • 領域が被る部分は情報を持ち寄り担 当者の間で議論する 責任領域に対する考え⽅ PdMが決める領域 （解決する課題、業務） Engが決める領域 （実装） デザイナーが決める領域 （UIデザイン） ここを率先して言及 議論で扱う変数を減らして スピード感と納得感のある意思決定
29. 　 要求はこう変わった 「"自動で経理"にクレカ領収書機能を付けたい」 画面（機能・UI）を制約しない 業務（なにができるべきか） を定義 Before After
30. 　 どの様に開発速度につながったのか 各担当者の責任範囲を明らかにしてそれぞれのメンバーが意思決 定できる状態にした それぞれのメンバーが責任領域で価値が⾼い⼿段を選べる 責任領域の判断に集中し、短い時間で意思決定できる 各ロールが クリエイティビティを発揮 価値が増大 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和 責任範囲を分割することで 素早い意思決定
31. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
32. 　 実はfreeeカードで経理は、一度一覧画面が
 大きく変わっている
 
 

33. Before
 After

34. 　 大量の明細と領収書を
 一覧で一気に登録できるUI
 
 インボイス対応から
 もっと価値を出せるUIに できないか
 という議論 カード利用をもっと
 伸ばしたいという狙いと利 用明細の
 量も増える見込み
 ECサイトやWeb広告など
 一部の費用のみで想定から
 もっと経費で使うような
 広い利用の需要が見えた
 経費精算をカードに
 置き換えるニーズが
 リサーチで明らかに

35. 　 Before
 After
 明細情報の取捨選択を爆速で議論 皆の知⾒を合わせて項⽬を削る意思決定を短期間で素早く⾏った
36. 内容を
 • カードの利用明細
 • 領収書のOCR
 • ユーザ定義のルール
 で補完
 内容を確認
 登録ボタンを押すだけ
 経理処理が完了
 作りきって完成した体験
 チームの知識が集結して
 以前のUIより入力が減少
 高速で処理できるUIが実 現できた

37. 　 ⼀覧画⾯での登録数 半分以上のユーザーが補完を
 生かした一覧からの登録を
 利用している
 こだわったUIが
 ユーザーさんに届いたこと

38. 　 どの様に開発速度につながったのか • 企画の段階よりもリリースに向けてより価値がある機能を追求 • チームメンバーのカード ✖ 会計の業務理解の知識を活かして思い切ったUI変更 UIの⼿戻りにならないぎりぎりのタイミングまで価値を追求 チームとしてドメイン知識を⾼めておき意思決定したものを即座に作り込む 実際に新しい⼀覧画⾯のUIの80%くらいまでは2週間かからず詰められた 未来の価値に合わせ 価値増加 素早い意思決定 手数はそのまま プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
39. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
40. 　 freee会計 freeeカード 開発に関わるチームが複数、どう分担する？ カードの開発チームがインボイス対応に取り組み始めた 会計チームはすでに走っているプロジェクトがある状態だった カード開発チーム 会計開発チーム インボイス対応が 必要になったから作りたい と言われても今走っている プロジェクトがあるで 遡ることインボイス対応の必要性が⾒えてきたタイミング
41. 　 freee会計 freeeカード カードチームで設計に取り組み始めたが ドメイン知識がないので意思決定ができない 会計開発Tがカード開発Tの作業を止める形になってしまった カード開発チーム 会計のこと全然わからん 設計できない 会計チームはアドバイスだけという形で関わるという話でプロジェクトを始めた 会計開発チーム この設計は やめて欲しい
42. 　 カードチームで設計に取り組み始めたが カード 開発チーム 会計 開発チーム 10月 11月 12月 9月 既存プロジェクトA インボイス対応の見積もり カード開発チームだけでは10⽉の制度施⾏に間に合わないかも 着地が 見えない 既存は作りきりたい 設計は気をつけて欲しい カード開発Tは設計を会計開発Tに確認&締め切りが厳しい板挟み 会計開発Tの既存開発に影響を出す案が話始められた インボイス制度 会計のプロジェクト止めて みんなで対応したほうがいいかも 両立は無理じゃ
43. 　 このままではまずいので課題を分解 課題：クレジットカードを⽤いた経理のインボイス対応 1. 従業員による領収書の提出（領収書回収） 2. 領収書と利⽤明細を関連付けた経理業務（freeeカードで経理） カード 開発チーム 会計 開発チーム 10月 11月 12月 9月 既存プロジェクトA 領収書回収 インボイス制度 クレカ&領収書のPub/Sub 経理業務（freeeカードで経理） 会計の開発を完全にオミット カード開発Tは必達要素が自身のドメインに閉じて意思決定できる 会計の領域は会計開発Tが集中して設計開発できるように要件を整理 データさえあれば 後から処理できる 10月に欲しい
44. 　 freee会計 freeeカード リリースの分離とサービスの構成 領収書 利用明細 利用明細 自動同期 領収書 自動同期 取引 領収書 利用明細 カード開発チーム 会計開発チーム Kinesis Data Streams を用いた Pub/Sub Pub/Sub の Messageを Protocol Buffersで定義 プロダクト上で採用実績もあり こっちの設計はまかせろ！ Protocol Buffer によるスキーマ駆動 設計の担当領域がチームの開発領域内に収まり、速度アップ
45. 　 スキーマ駆動の Pub/Sub の連携の恩恵 会計開発T は freeeカードで経理の準備として スキーマ定義をもとにMock機能を作成 freee会計 取引 領収書 利用明細 会計開発チーム 利用明細 自動同期 領収書 自動同期 お互いの開発のタイミングを意識することなく開発が自走 スキーマが決まっているので絶対にうまく合流できる安心感
46. 　 どの様に開発速度につながったのか • 機能の分離によりそれぞれのチームが詳しい領域の開発に集中 • スキーマ駆動開発による開発の並列化、影響範囲の制御 エンジニアメンバーのリソース効率の上昇 Mockなどの今後の開発に繋がる⾮機能も実現 開発の独立化 調整コストの削減 得意ドメインの設計で 保守性アップ 得意領域で開発効率が改善 開発時間の削減 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
47. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
48. 　 何を作るのかを考えるのは時間がかかってしまう 優先度を決める根拠を集めるしかない 世の中に無いものを作る時、そもそも根拠がない、こじつけなっちゃう そもそも、早く世の中に出して、フィードバックをもらうしか無い！ freeeカードで経理にも次の一手を考えるための要素を埋みリリースしています
49. 　 ユーザーさんが声をあげられるようにする プレスリリース 広報チームと連携して実現 プロダクト内のリリースお知らせ
50. 　 ユーザーさんの声を反映して作った実例 1 カードを複数所有している のでカード検索条件を がほしいです。 気がつなかった実際のユーザさんが悩んだり、手こずるポイント 問題自体が分かれば解決は簡単だったりします 「詳細」登録画面で、 管理番号を入力する欄を 追加していただけると 大変助かります。
51. 　 既存機能との互換性をどこまでもたせるのかは決めの問題 機能の提供順や提供範囲を検討にあたりユーザーさんの声は助かる ユーザーさんの声を反映して作った実例 2 自動で経理のような、 推測ができるようになると ありがたいです 取引内容の自動推測を 「自動で経理」機能と 同じクオリティで
52. 　 どの様に開発速度につながったのか • ユーザーさんの声をもとにした意思決定 意思決定にかかる根拠の収集を圧縮 ユーザさんに確実に刺さるから⾛って良いという安⼼感 高い確率でユーザーに 提供できる価値アップ 短時間で角度が高い意思決定 根拠集めの時間の削減 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
53. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
54. 　 まとめ 「freeeカードで経理」を題材に開発速度が実際上がった実例を紹介した プロダクトの価値 プロジェクトに使う時間 開発速度 の総和 価値を⾼めるアクション、プロジェクトの効率を上げるアクション様々あるけど 誰かが意思を持って変化を先導しないと開発速度は下がる ⾃分の役割や得意、そしてチームの作っているプロダクトの価値を理解して 何を変えたら、開発速度に繋がるのか考えて変化を起こしていきましょう！