新サービス『楽楽請求』！何を作るかより"なぜ作るか" 顧客価値から逆算する開発現場のリアル / rakustechcon2025-rakurakuseikyu

◆イベント名
RAKUS Tech Conference 2025
https://techcon.rakus.co.jp/2025/

◆発表タイトル
新サービス『楽楽請求』！何を作るかより"なぜ作るか" 顧客価値から逆算する開発現場のリアル

◆登壇者
楽楽請求開発部 開発1課　巽隆氏
楽楽請求開発部 開発1課　庄禮有佑

Transcript

1. 新サービス「楽楽請求」！ 何を作るかより“なぜ作るか” 顧客価値から逆算する開発現場 のリアル 楽楽請求開発部 開発1課　巽隆氏 楽楽請求開発部 開発1課　庄禮有佑
2. 登壇者紹介 楽楽請求開発部 開発1課 巽隆氏 2011年にSIerに新卒で入社し、スマホアプリの 受託開発を経験。その後は、SESで様々なプロ ジェクトに関わり、上流のPM/PL業務から下流工 程まで多様な経験を積んだ後、2021年にラクス 入社。 チャットディーラーAIの開発に携わった後、楽楽 請求の立ち上げに伴い、楽楽請求開発へ異動。現 在は、楽楽請求のPdMを担当。 楽楽請求開発部 開発1課 庄禮有佑 2018年に新卒でラクスへ入社。楽楽精算、楽楽 人事、楽楽販売など複数のプロダクトで、開発やサ ポート業務を担当。 楽楽請求では、バックエンドAPIサーバーの技術 選定や開発リードを務め、現在は要件定義や概要 設計といった上流工程の設計業務を担当。 2

3. 楽楽請求とは？ 請求書を一元管理し、経理業務を効率化する請求書受領システム • 2024年10月サービス開始 • 主な機能 ◦ 複数手段で届く請求書を一元管理 ◦ 請求書を自動でデータ化 ◦ 仕訳データや振込データを作成 ◦ 電子帳簿保存法、インボイス制度対応 3

4. アジェンダ 1. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 2. リリースして見えたこと ― 成果と反省 3. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 4
 新サービス立ち上げにあたって「上手くいったこと」「上手くいかなかったこと」両方あります これから新サービスを立ち上げる方々の参考になれば幸いです（上手くいかなかったことは反面教師に）
5. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 5

6. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 まずは顧客理解から とはいえ、ドメイン知識はゼロスタート 楽楽請求は、楽楽精算の請求書処理支援オプションをスピンアウトした プロダクトなので既存顧客はいる が、このプロジェクト自体が社内でもオフレコで、 社内の経理や楽楽精算関係者にも聞けない… （リリース半年前くらいまでオフレコでした） 6

7. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 まずは顧客理解から ひたすら、仮説と整理・検討を繰り返す 7
 • 業務の流れを書籍やインターネットの情報を元に整理 • 先行サービスの機能から逆算
8. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 8
 請求書受領 内容確認 支払依頼 費用計上 支払処理 原本保管 消込処理 ・手動アップロード ・メールアップロード ・XXXXX ・XXXXX ・XXXXX …etc ・AI-OCR ・入力代行 ・XXXXX ・XXXXX ・XXXXX …etc ・仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・XXXXX …etc ・FBデータ作成 ・振込元口座管理 ・XXXXX ・XXXXX ・XXXXX …etc ・支払依頼申請／承認 ・承認フロー管理 ・XXXXX ・XXXXX ・XXXXX …etc ・支払仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・XXXXX …etc ・インボイス対応 ・電帳法対応 ・XXXXX ・XXXXX ・XXXXX …etc まずは顧客理解から • 最終的に全体の業務の流れと各業務工程ごとに必要な機能を洗い出し
9. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 開発スコープを調整 フル機能でリリースするとリリース時期に間に合わない 請求書受領業務サービスの中では最後発サービス →白地が無くなる前にリリースすることが重要 9

10. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 10
 MVPを定義 　 請求書受領サービスを導入する上で顧客が一番解決したい課題を仮説 一番 　・いろいろな経路や媒体で届く請求書をラクに管理できる 　・漏れなく期日までに正確に支払いを完了することができる 一番解決したい課題 MVP＝これらの課題を解決できる最小限の機能を持つサービス
11. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 11
 カバーすべき工程＋各工程で最小限必要な機能を調整 請求書受領 内容確認 支払依頼 費用計上 支払処理 原本保管 消込処理 ・手動アップロード ・メールアップロード ・XXXXX ・XXXXX ・XXXXX …etc ・AI-OCR ・入力代行 ・XXXXX ・XXXXX ・XXXXX …etc ・仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・XXXXX …etc ・FBデータ作成 ・振込元口座管理 ・XXXXX ・XXXXX ・XXXXX …etc ・支払依頼申請／承認 ・承認フロー管理 ・XXXXX ・XXXXX ・XXXXX …etc ・支払仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・XXXXX …etc ・インボイス対応 ・電帳法対応 ・XXXXX ・XXXXX ・XXXXX …etc
12. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 12
 業務領域に分割して開発 削ったものの開発する機能は膨大 全部まとめて設計し、実装していると間に合わない 請求書受領 内容確認 支払依頼 費用計上 支払処理 原本保管 消込処理 ・手動アップロード ・メールアップロード ・XXXXX ・XXXXX ・AI-OCR ・入力代行 ・XXXXX ・仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・FBデータ作成 ・振込元口座管理 ・XXXXX ・XXXXX ・支払依頼申請／承認 ・承認フロー管理 ・XXXXX ・支払仕訳作成 ・仕訳データ出力 ・XXXXX ・インボイス対応 ・電帳法対応 ・XXXXX ・XXXXX
13. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 13
 サービスとして意味のある3つの領域に再定義 領域ごとに設計完了次第、次の設計と並行して開発を実施し、リードタイムを短縮 ①請求書受領 請求書受領 ・請求書アップロード 原本保管 ・インボイス対応 ・電帳法対応 ②請求書のデータ化 内容確認 ・AI-OCR 支払依頼 ・支払依頼申請／承認 ・承認フロー管理 ③データ連携 費用計上 ・仕訳作成 ・仕訳データ出力 支払処理 ・FBデータ作成 ・振込元口座管理 消込処理 ・支払仕訳作成 ・仕訳データ出力
14. リリースして見えたこと― 成果と反省 14

15. リリースして見えたこと ― 成果と反省 1人での設計の難しさ 新サービスのため、設計より実装がボトルネックになることが予想された 開発リソースを最大限実装に割くために設計をほぼ1人で担当（先行サービスを参考にしつつ） 15
 Good • 意思決定のスピード感 • 仕様統一感 Bad • 思考が固まり視野が狭くなる 　 →実業務にそぐわない仕様
16. リリースして見えたこと ― 成果と反省 実業務にそぐわない仕様の例（申請者による支払情報の必須化） ※支払情報：　どの口座に、いつまでに、何円振り込むか • 経理を楽にするために、できるだけ申請者に入力さ せる • 請求書に金額や口座が記載されているので、申請 者で入力できるはず →実際には、経理判断が必要なケースが多い • 請求内容と支払内容が一致しないことがある • 継続的に取引している場合、口座は書いていない 16

17. リリースして見えたこと ― 成果と反省 リリースしてわかった顧客の声 • 設計時に議論に挙がったが、実際に使わないと思って見送った機能が実際には求められていた ◦ 例： 取引先による請求書の直接アップロード（アップロードサイト） • 楽楽シリーズファンは、楽楽精算や楽楽販売のカスタマイズ性を好んでいる ◦ 楽楽請求はカスタマイズ機能が充実しておらず、期待外れとなってしまっている ◦ 例： 請求書への入力項目の追加、役職などの単位で承認者を設定できるワークフロー 17
 いずれもリリース前に気づくことは難しい
18. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 18

19. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 仮説ドリブンからVoCドリブンへ　　※VoC＝Voice of Customer 19
 Before • 書籍やインターネットの情報による仮説 • 先行サービスの機能から逆算 After • 営業・サポートが収集したVoC • 営業・サポートにヒアリング • 社内経理に壁打ち • 商談動画・オンボーディングへの同席
20. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 仮説ドリブンからVoCドリブンへ VoCはHowベースが多いので、顧客課題の深掘りが必要 「何を作るか」より「なぜそれが必要なのか」を理解することが重要 20
 営業・サポートも交えて ディスカッション 顧客へのヒアリング
21. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 設計メンバーを増員 21
 営業 サポート 要望DB 2000件超 ※2025年6月末時点 失注理由 商談時に いただいた声 解約理由 機能に対する 不満 設計メンバーを増員し、顧客の声を正しく拾うことに注力 →顧客が抱える課題を正しく捉え、ど真ん中で価値提供できる機能に落とし込む
22. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 要望DBを活用し、顧客満足度向上も目指す 現状は、要望度S／A（解約や失注に直結した要望）を中心に吸い上げて開発 要望度B以下の要望＝楽楽請求を継続利用してくれている顧客からのVoCを活かせていない 22

23. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 要望DBを活用し、顧客満足度向上も目指す 23
 既存顧客の課題解決 未来の顧客の課題解 決 商談時の訴求効果アップ 新規受注アップにも繋がる
24. 最後に 24

25. 最後に まとめ • 「開発の進め方」だけを見ると、一定成功した ◦ スコープ調整、業務領域に分割しての開発 • ただし、機能面では十分に顧客要望に応えることができなかった ◦ 完璧ではないものの、ある程度満足してもらえる機能を用意したつもりだった • 現在は、顧客の声を重視した進め方に変えた結果 ◦ 実際に顧客が求めている機能をリリースできており、顧客の反応も良い（機能要因の失注率も改善） 25
 新プロダクトを立ち上げるとすると・・・ ・小さく出して、早急に顧客からフィードバックをもらいながら開発を進められる状態にする ・顧客の生の声を聞く（百聞は一見に如かず！）
26. 最後に 今後の抱負 26
 来年度上期中に PMF達成！ 基本機能の拡張 ＋AIエージェントの 2軸で成長！
27. ご清聴ありがとうございました。 27