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

freeeカードで経理を爆速で開発できたワケ / How we were able to de...

freee
June 06, 2024
2.2k

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

freee

June 06, 2024
Tweet

More Decks by freee

Transcript

  1. 2017年4月 新卒入社
 2023年まで会計を開発
 2024年からは支出管理 リードエンジニア
 2 him0
 ⽀出管理 エンジニア マネージャー

    2022 freeeにjoin
 2016 mikatus株式会社
 8年ほど会計畑でプロダ クトデザイナーをしていま す
 tsuyuki
 ⽀出管理 デザイナー 2018年4月 新卒入社
 2022年までカスタマーサクセス
 2023年からfreee支出管理 PdM
 taro
 ⽀出管理 PdM 去年の発表

  2. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  3.   短期間の開発で、ユーザ体験の良いものができた → よいこと 短期間の開発だけど、ユーザ体験の良くないものができた → よくなさそう 開発速度を定義する たくさんの⼈が関わって、1億円のビジネスインパクトが作る →

    よいこと 少数精鋭短期決戦で、1億円のビジネスインパクトが作る → もっとよいこと プロダクトの価値 プロジェクトに使う時間 開発速度 機能・非機能 問わず 価値が高いほどよい 少ない人数で意思決定 ができる方が良い 手数が少ない 手段がよい の総和 などなど... ※帰納的なので絶対ではない ポジティブな効果
  4. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  5.   freeeカード 領収書回収機能でまだ解決できなかった問題 freee会計に利用明細と領収書の関連付けの情報が渡せない 関連付けの情報をfreee会計の画面上で確認するUIがない 従業員 通知 カードの利用 関連付け 確認

    領収書 アップロード 利用明細 自動同期 領収書 自動同期 経理 必要な情報は揃ったけど 管理は大変 領収書 利用明細 自動で経理 ファイルボックス
  6.   freeeカード freeeカードで経理でこうなった 従業員 通知 カードの利用 領収書 アップロード 利用明細 自動同期

    領収書 自動同期 同期の仕組みを刷新、利用明細と領収書を関連付けて会計に同期 freee会計上にクレジットカードの経理に特化した画面を作成 経理 利用状況が追いやすい ちゃんと領収書あるね 領収書 利用明細
  7. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  8.   freeeカード 領収書回収機能でまだ解決できなかった問題 従業員 通知 カードの利用 関連付け 確認 領収書 アップロード

    利用明細 自動同期 領収書 自動同期 経理 領収書 利用明細 自動で経理 ファイルボックス 経理の人が関連付けを確認しつつ、経理作業を行うUIを 会計上に何らかの形で実現する必要があった
  9.   実現⽅法は2つ   「⾃動で経理」でいいやん PMとしての最初の思考 自動で経理 新規の UI OR ユーザーも既存画⾯に慣れているし、これをイメージするだろうな…

    UIも既にあるから、PDも考える必要はないだろうし… 実装も裏側で関連付けやってあげるだけだから、おそらく軽いな…
  10.   開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか?今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」

    PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか?めちゃくちゃ⼤変だけどやる価値あるんです か?」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ
  11.   開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか?今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」

    PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか?めちゃくちゃ⼤変だけどやる価値あるんです か?」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ 「ちょっと待った!」
  12.   デザイナーが決める領域 (UIデザイン) PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) 「"自動で経理"にクレカ領収書機能を付けたい」 責任領域に対する考え⽅ これくらい

    言及している デザインシステムとの 兼ね合い 既存の負債との 兼ね合い Eng や デザイナーが意思決定すべき領域まで⾔及していた
  13.   責任領域に対する考え⽅ 責任領域を踏み越える判断 分からないことが増える PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) • 想定していないデメリットや問題

    • そもそも決められない • 納得感の薄い「決め」 デザイナーが決める領域 (UIデザイン) 「"自動で経理"にクレカ領収書機能を付けたい」 これくらい 言及している
  14.   各役割の責任が明確に • 責任領域のなかは⾃分で決める • 領域が被る部分は情報を持ち寄り担 当者の間で議論する 責任領域に対する考え⽅ PdMが決める領域 (解決する課題、業務)

    Engが決める領域 (実装) デザイナーが決める領域 (UIデザイン) ここを率先して言及 議論で扱う変数を減らして スピード感と納得感のある意思決定
  15. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  16.   大量の明細と領収書を
 一覧で一気に登録できるUI
 
 インボイス対応から
 もっと価値を出せるUIに できないか
 という議論 カード利用をもっと
 伸ばしたいという狙いと利

    用明細の
 量も増える見込み
 ECサイトやWeb広告など
 一部の費用のみで想定から
 もっと経費で使うような
 広い利用の需要が見えた
 経費精算をカードに
 置き換えるニーズが
 リサーチで明らかに

  17. 内容を
 • カードの利用明細
 • 領収書のOCR
 • ユーザ定義のルール
 で補完
 内容を確認
 登録ボタンを押すだけ


    経理処理が完了
 作りきって完成した体験
 チームの知識が集結して
 以前のUIより入力が減少
 高速で処理できるUIが実 現できた

  18. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  19.   カードチームで設計に取り組み始めたが カード 開発チーム 会計 開発チーム 10月 11月 12月 9月

    既存プロジェクトA インボイス対応の見積もり カード開発チームだけでは10⽉の制度施⾏に間に合わないかも 着地が 見えない 既存は作りきりたい 設計は気をつけて欲しい カード開発Tは設計を会計開発Tに確認&締め切りが厳しい板挟み 会計開発Tの既存開発に影響を出す案が話始められた インボイス制度 会計のプロジェクト止めて みんなで対応したほうがいいかも 両立は無理じゃ
  20.   このままではまずいので課題を分解 課題:クレジットカードを⽤いた経理のインボイス対応 1. 従業員による領収書の提出(領収書回収) 2. 領収書と利⽤明細を関連付けた経理業務(freeeカードで経理) カード 開発チーム 会計

    開発チーム 10月 11月 12月 9月 既存プロジェクトA 領収書回収 インボイス制度 クレカ&領収書のPub/Sub 経理業務(freeeカードで経理) 会計の開発を完全にオミット カード開発Tは必達要素が自身のドメインに閉じて意思決定できる 会計の領域は会計開発Tが集中して設計開発できるように要件を整理 データさえあれば 後から処理できる 10月に欲しい
  21.   freee会計 freeeカード リリースの分離とサービスの構成 領収書 利用明細 利用明細 自動同期 領収書 自動同期

    取引 領収書 利用明細 カード開発チーム 会計開発チーム Kinesis Data Streams を用いた Pub/Sub Pub/Sub の Messageを Protocol Buffersで定義 プロダクト上で採用実績もあり こっちの設計はまかせろ! Protocol Buffer によるスキーマ駆動 設計の担当領域がチームの開発領域内に収まり、速度アップ
  22.   スキーマ駆動の Pub/Sub の連携の恩恵 会計開発T は freeeカードで経理の準備として スキーマ定義をもとにMock機能を作成 freee会計 取引

    領収書 利用明細 会計開発チーム 利用明細 自動同期 領収書 自動同期 お互いの開発のタイミングを意識することなく開発が自走 スキーマが決まっているので絶対にうまく合流できる安心感
  23. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
  24. 1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5.

    アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次