freeeカードで経理を爆速で開発できたワケ / How we were able to develop accounting with freee cards at a blazing speed
by
freee
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
freeeカードで経理を爆速で 開発できたワケ him0 tsuyuki taro 2024年6⽉1⽇
Slide 2
Slide 2 text
2017年4月 新卒入社 2023年まで会計を開発 2024年からは支出管理 リードエンジニア 2 him0 ⽀出管理 エンジニア マネージャー 2022 freeeにjoin 2016 mikatus株式会社 8年ほど会計畑でプロダ クトデザイナーをしていま す tsuyuki ⽀出管理 デザイナー 2018年4月 新卒入社 2022年までカスタマーサクセス 2023年からfreee支出管理 PdM taro ⽀出管理 PdM 去年の発表
Slide 3
Slide 3 text
「freeeカードで経理」という機能を題材に 企画、開発、運⽤ それぞれのフェーズで取った 開発速度を上げるためのアクションを紹介します この発表でお伝えしたいこと ● チームの開発プロセスを⾔語化する‧⾒直すきっかけ ● 普段使っているサービスの裏側を想像するきっかけ こんな取り組みもある!技術もある!そんな発信が増えると嬉しいです X なら #freee技術の⽇ でお願いします
Slide 4
Slide 4 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 5
Slide 5 text
爆速っていうけど、開発速度ってなんだっけ? ⼿早くできた、少ない⼯数でできた! なんだか、良いことの様に聞こえるけど、⼿放しでよろこべる? 進んだ距離 かかった時間 速度 XXX速度を抽象化してみると 「何らかの効果」を「単位時間」あたりどれだけ出しているかと⾔い換えられる プロダクト開発における「何らかの効果」を定義しないと開発速度は扱えない
Slide 6
Slide 6 text
短期間の開発で、ユーザ体験の良いものができた → よいこと 短期間の開発だけど、ユーザ体験の良くないものができた → よくなさそう 開発速度を定義する たくさんの⼈が関わって、1億円のビジネスインパクトが作る → よいこと 少数精鋭短期決戦で、1億円のビジネスインパクトが作る → もっとよいこと プロダクトの価値 プロジェクトに使う時間 開発速度 機能・非機能 問わず 価値が高いほどよい 少ない人数で意思決定 ができる方が良い 手数が少ない 手段がよい の総和 などなど... ※帰納的なので絶対ではない ポジティブな効果
Slide 7
Slide 7 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 8
Slide 8 text
2023年12⽉に freeeカードで経理 をリリース 法人クレジットカードを日々の支払いに利用してもらう機能 機能としては以前から提供してきたが、制度の変化に合わせて刷新
Slide 9
Slide 9 text
開発のきっかけは2023年インボイス制度 取引先がインボイス制度適格請求書発行事業者か否かで税率が変化 経理処理において領収書の保存がほぼ必須化した 領収書は「簡易インボイス」「適格簡易請求書」 領収書なのに請求書という... インボイス制度の概要|国税庁 より
Slide 10
Slide 10 text
freee会計 Before インボイス制度 法人カードの利用は利用明細だけあれば経理処理できた 経理 取引登録 利用明細 自動同期 利用明細 取引 カードの利用 freeeカード 従業員 利用明細
Slide 11
Slide 11 text
After インボイス制度 従業員から領収書を受け取って電子化して保存する必要ができた 従業員は会計のアカウントを持ってないと電子化する口がない カードの利用 freee会計 freeeカード 領収書 アップロード 取引登録 領収書 業務が増えた 領収書の提出 従業員 経理 利用明細 取引 利用明細 自動同期 利用明細
Slide 12
Slide 12 text
インボイス制度の施⾏に合わせて領収書回収をリリース カード利用を検知してメールやslackで領収書提出を催促 従業員が領収書を提出できる仕組みを構築
Slide 13
Slide 13 text
freeeカード 領収書回収機能で実現できたこと 従業員が領収書を経理担当者に手渡しするフローは廃止できた 領収書が電子化される前に廃棄されてしまう状況は回避できた 従業員 freee会計 通知 カードの利用 領収書 アップロード 領収書 利用明細 取引 経理 取引登録 利用明細 自動同期 領収書 自動同期 領収書 利用明細
Slide 14
Slide 14 text
freeeカード 領収書回収機能でまだ解決できなかった問題 freee会計に利用明細と領収書の関連付けの情報が渡せない 関連付けの情報をfreee会計の画面上で確認するUIがない 従業員 通知 カードの利用 関連付け 確認 領収書 アップロード 利用明細 自動同期 領収書 自動同期 経理 必要な情報は揃ったけど 管理は大変 領収書 利用明細 自動で経理 ファイルボックス
Slide 15
Slide 15 text
freeeカード freeeカードで経理でこうなった 従業員 通知 カードの利用 領収書 アップロード 利用明細 自動同期 領収書 自動同期 同期の仕組みを刷新、利用明細と領収書を関連付けて会計に同期 freee会計上にクレジットカードの経理に特化した画面を作成 経理 利用状況が追いやすい ちゃんと領収書あるね 領収書 利用明細
Slide 16
Slide 16 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 17
Slide 17 text
各ロールで役割・責任を分担するか PdM, Eng, デザイナー, QA, ...
Slide 18
Slide 18 text
各ロールで役割・責任を分担するか チームによる違い PMの腕の⾒せ所 阿吽の呼吸でしょ そこは経験だよ
Slide 19
Slide 19 text
freeeカード 領収書回収機能でまだ解決できなかった問題 従業員 通知 カードの利用 関連付け 確認 領収書 アップロード 利用明細 自動同期 領収書 自動同期 経理 領収書 利用明細 自動で経理 ファイルボックス 経理の人が関連付けを確認しつつ、経理作業を行うUIを 会計上に何らかの形で実現する必要があった
Slide 20
Slide 20 text
実現⽅法は2つ 「⾃動で経理」でいいやん PMとしての最初の思考 自動で経理 新規の UI OR ユーザーも既存画⾯に慣れているし、これをイメージするだろうな… UIも既にあるから、PDも考える必要はないだろうし… 実装も裏側で関連付けやってあげるだけだから、おそらく軽いな…
Slide 21
Slide 21 text
開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか?今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」 PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか?めちゃくちゃ⼤変だけどやる価値あるんです か?」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ
Slide 22
Slide 22 text
開発チームとのミーティングにて PdM「"⾃動で経理"にクレカ領収書の機能をつけたいです」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 PdM「え、難しいそうですか?今の画⾯に載せるからデザインも実装も軽いかと…」 デザイナー「いや、デザインシステムから外れている変更するの結構⼤変なんだよな〜」 Eng「多機能過ぎる"⾃動で経理"に機能追加するのは難しい、なるべくやりたくないです」 PdM「でも明細処理なら"⾃動で経理"ってみんな思ってる気がする…」 デザイナー & Eng「ほんとにそうなんですか?めちゃくちゃ⼤変だけどやる価値あるんです か?」 PdM「それ以外でやるってあんまり考えられないけど…」 デザイナー & Eng「えー… それはあんまりやりたくないな…」 →無限ループ 「ちょっと待った!」
Slide 23
Slide 23 text
👳「画面のこと、言い過ぎだよ」
Slide 24
Slide 24 text
責任領域に対する考え⽅ PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) デザイナーが決める領域 (UIデザイン) 重なる領域は意識合わせが必要な領域、重なりがない部分はそれぞれで意思決定できる
Slide 25
Slide 25 text
デザイナーが決める領域 (UIデザイン) PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) 「"自動で経理"にクレカ領収書機能を付けたい」 責任領域に対する考え⽅ これくらい 言及している デザインシステムとの 兼ね合い 既存の負債との 兼ね合い Eng や デザイナーが意思決定すべき領域まで⾔及していた
Slide 26
Slide 26 text
責任領域に対する考え⽅ 責任領域を踏み越える判断 分からないことが増える PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) ● 想定していないデメリットや問題 ● そもそも決められない ● 納得感の薄い「決め」 デザイナーが決める領域 (UIデザイン) 「"自動で経理"にクレカ領収書機能を付けたい」 これくらい 言及している
Slide 27
Slide 27 text
PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) デザイナーが決める領域 (UIデザイン) 責任領域に対する考え⽅ ここを率先して言及 本来 PdM が率先すべき領域はどこか 👳それが「業務の要求」だよ
Slide 28
Slide 28 text
各役割の責任が明確に ● 責任領域のなかは⾃分で決める ● 領域が被る部分は情報を持ち寄り担 当者の間で議論する 責任領域に対する考え⽅ PdMが決める領域 (解決する課題、業務) Engが決める領域 (実装) デザイナーが決める領域 (UIデザイン) ここを率先して言及 議論で扱う変数を減らして スピード感と納得感のある意思決定
Slide 29
Slide 29 text
要求はこう変わった 「"自動で経理"にクレカ領収書機能を付けたい」 画面(機能・UI)を制約しない 業務(なにができるべきか) を定義 Before After
Slide 30
Slide 30 text
どの様に開発速度につながったのか 各担当者の責任範囲を明らかにしてそれぞれのメンバーが意思決 定できる状態にした それぞれのメンバーが責任領域で価値が⾼い⼿段を選べる 責任領域の判断に集中し、短い時間で意思決定できる 各ロールが クリエイティビティを発揮 価値が増大 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和 責任範囲を分割することで 素早い意思決定
Slide 31
Slide 31 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 32
Slide 32 text
実はfreeeカードで経理は、一度一覧画面が 大きく変わっている
Slide 33
Slide 33 text
Before After
Slide 34
Slide 34 text
大量の明細と領収書を 一覧で一気に登録できるUI インボイス対応から もっと価値を出せるUIに できないか という議論 カード利用をもっと 伸ばしたいという狙いと利 用明細の 量も増える見込み ECサイトやWeb広告など 一部の費用のみで想定から もっと経費で使うような 広い利用の需要が見えた 経費精算をカードに 置き換えるニーズが リサーチで明らかに
Slide 35
Slide 35 text
Before After 明細情報の取捨選択を爆速で議論 皆の知⾒を合わせて項⽬を削る意思決定を短期間で素早く⾏った
Slide 36
Slide 36 text
内容を ● カードの利用明細 ● 領収書のOCR ● ユーザ定義のルール で補完 内容を確認 登録ボタンを押すだけ 経理処理が完了 作りきって完成した体験 チームの知識が集結して 以前のUIより入力が減少 高速で処理できるUIが実 現できた
Slide 37
Slide 37 text
⼀覧画⾯での登録数 半分以上のユーザーが補完を 生かした一覧からの登録を 利用している こだわったUIが ユーザーさんに届いたこと
Slide 38
Slide 38 text
どの様に開発速度につながったのか ● 企画の段階よりもリリースに向けてより価値がある機能を追求 ● チームメンバーのカード ✖ 会計の業務理解の知識を活かして思い切ったUI変更 UIの⼿戻りにならないぎりぎりのタイミングまで価値を追求 チームとしてドメイン知識を⾼めておき意思決定したものを即座に作り込む 実際に新しい⼀覧画⾯のUIの80%くらいまでは2週間かからず詰められた 未来の価値に合わせ 価値増加 素早い意思決定 手数はそのまま プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
Slide 39
Slide 39 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 40
Slide 40 text
freee会計 freeeカード 開発に関わるチームが複数、どう分担する? カードの開発チームがインボイス対応に取り組み始めた 会計チームはすでに走っているプロジェクトがある状態だった カード開発チーム 会計開発チーム インボイス対応が 必要になったから作りたい と言われても今走っている プロジェクトがあるで 遡ることインボイス対応の必要性が⾒えてきたタイミング
Slide 41
Slide 41 text
freee会計 freeeカード カードチームで設計に取り組み始めたが ドメイン知識がないので意思決定ができない 会計開発Tがカード開発Tの作業を止める形になってしまった カード開発チーム 会計のこと全然わからん 設計できない 会計チームはアドバイスだけという形で関わるという話でプロジェクトを始めた 会計開発チーム この設計は やめて欲しい
Slide 42
Slide 42 text
カードチームで設計に取り組み始めたが カード 開発チーム 会計 開発チーム 10月 11月 12月 9月 既存プロジェクトA インボイス対応の見積もり カード開発チームだけでは10⽉の制度施⾏に間に合わないかも 着地が 見えない 既存は作りきりたい 設計は気をつけて欲しい カード開発Tは設計を会計開発Tに確認&締め切りが厳しい板挟み 会計開発Tの既存開発に影響を出す案が話始められた インボイス制度 会計のプロジェクト止めて みんなで対応したほうがいいかも 両立は無理じゃ
Slide 43
Slide 43 text
このままではまずいので課題を分解 課題:クレジットカードを⽤いた経理のインボイス対応 1. 従業員による領収書の提出(領収書回収) 2. 領収書と利⽤明細を関連付けた経理業務(freeeカードで経理) カード 開発チーム 会計 開発チーム 10月 11月 12月 9月 既存プロジェクトA 領収書回収 インボイス制度 クレカ&領収書のPub/Sub 経理業務(freeeカードで経理) 会計の開発を完全にオミット カード開発Tは必達要素が自身のドメインに閉じて意思決定できる 会計の領域は会計開発Tが集中して設計開発できるように要件を整理 データさえあれば 後から処理できる 10月に欲しい
Slide 44
Slide 44 text
freee会計 freeeカード リリースの分離とサービスの構成 領収書 利用明細 利用明細 自動同期 領収書 自動同期 取引 領収書 利用明細 カード開発チーム 会計開発チーム Kinesis Data Streams を用いた Pub/Sub Pub/Sub の Messageを Protocol Buffersで定義 プロダクト上で採用実績もあり こっちの設計はまかせろ! Protocol Buffer によるスキーマ駆動 設計の担当領域がチームの開発領域内に収まり、速度アップ
Slide 45
Slide 45 text
スキーマ駆動の Pub/Sub の連携の恩恵 会計開発T は freeeカードで経理の準備として スキーマ定義をもとにMock機能を作成 freee会計 取引 領収書 利用明細 会計開発チーム 利用明細 自動同期 領収書 自動同期 お互いの開発のタイミングを意識することなく開発が自走 スキーマが決まっているので絶対にうまく合流できる安心感
Slide 46
Slide 46 text
どの様に開発速度につながったのか ● 機能の分離によりそれぞれのチームが詳しい領域の開発に集中 ● スキーマ駆動開発による開発の並列化、影響範囲の制御 エンジニアメンバーのリソース効率の上昇 Mockなどの今後の開発に繋がる⾮機能も実現 開発の独立化 調整コストの削減 得意ドメインの設計で 保守性アップ 得意領域で開発効率が改善 開発時間の削減 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
Slide 47
Slide 47 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 48
Slide 48 text
何を作るのかを考えるのは時間がかかってしまう 優先度を決める根拠を集めるしかない 世の中に無いものを作る時、そもそも根拠がない、こじつけなっちゃう そもそも、早く世の中に出して、フィードバックをもらうしか無い! freeeカードで経理にも次の一手を考えるための要素を埋みリリースしています
Slide 49
Slide 49 text
ユーザーさんが声をあげられるようにする プレスリリース 広報チームと連携して実現 プロダクト内のリリースお知らせ
Slide 50
Slide 50 text
ユーザーさんの声を反映して作った実例 1 カードを複数所有している のでカード検索条件を がほしいです。 気がつなかった実際のユーザさんが悩んだり、手こずるポイント 問題自体が分かれば解決は簡単だったりします 「詳細」登録画面で、 管理番号を入力する欄を 追加していただけると 大変助かります。
Slide 51
Slide 51 text
既存機能との互換性をどこまでもたせるのかは決めの問題 機能の提供順や提供範囲を検討にあたりユーザーさんの声は助かる ユーザーさんの声を反映して作った実例 2 自動で経理のような、 推測ができるようになると ありがたいです 取引内容の自動推測を 「自動で経理」機能と 同じクオリティで
Slide 52
Slide 52 text
どの様に開発速度につながったのか ● ユーザーさんの声をもとにした意思決定 意思決定にかかる根拠の収集を圧縮 ユーザさんに確実に刺さるから⾛って良いという安⼼感 高い確率でユーザーに 提供できる価値アップ 短時間で角度が高い意思決定 根拠集めの時間の削減 プロダクトの価値 プロジェクトに使う時間 開発速度 の総和
Slide 53
Slide 53 text
1. 開発速度を定義する 2. freeeカードで経理の開発背景 3. 役割分担で意思決定の速度を上げる 4. UI にこだわって価値を上げる 5. アサインで実装速度を上げる 6. ユーザーの声を聞いて優先度を決める 7. まとめ 目次
Slide 54
Slide 54 text
まとめ 「freeeカードで経理」を題材に開発速度が実際上がった実例を紹介した プロダクトの価値 プロジェクトに使う時間 開発速度 の総和 価値を⾼めるアクション、プロジェクトの効率を上げるアクション様々あるけど 誰かが意思を持って変化を先導しないと開発速度は下がる ⾃分の役割や得意、そしてチームの作っているプロダクトの価値を理解して 何を変えたら、開発速度に繋がるのか考えて変化を起こしていきましょう!
Slide 55
Slide 55 text
No content