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

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

Avatar for Rakus_Dev Rakus_Dev
August 07, 2025
83

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

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

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

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

Avatar for Rakus_Dev

Rakus_Dev

August 07, 2025
Tweet

More Decks by Rakus_Dev

Transcript

  1. 登壇者紹介 楽楽請求開発部 開発1課 巽隆氏 2011年にSIerに新卒で入社し、スマホアプリの 受託開発を経験。その後は、SESで様々なプロ ジェクトに関わり、上流のPM/PL業務から下流工 程まで多様な経験を積んだ後、2021年にラクス 入社。 チャットディーラーAIの開発に携わった後、楽楽

    請求の立ち上げに伴い、楽楽請求開発へ異動。現 在は、楽楽請求のPdMを担当。 楽楽請求開発部 開発1課 庄禮有佑 2018年に新卒でラクスへ入社。楽楽精算、楽楽 人事、楽楽販売など複数のプロダクトで、開発やサ ポート業務を担当。 楽楽請求では、バックエンドAPIサーバーの技術 選定や開発リードを務め、現在は要件定義や概要 設計といった上流工程の設計業務を担当。 2

  2. アジェンダ 1. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 2. リリースして見えたこと ― 成果と反省 3.

    仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 4
 新サービス立ち上げにあたって「上手くいったこと」「上手くいかなかったこと」両方あります これから新サービスを立ち上げる方々の参考になれば幸いです(上手くいかなかったことは反面教師に)
  3. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 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 まずは顧客理解から • 最終的に全体の業務の流れと各業務工程ごとに必要な機能を洗い出し
  4. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 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
  5. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 12
 業務領域に分割して開発 削ったものの開発する機能は膨大 全部まとめて設計し、実装していると間に合わない 請求書受領 内容確認 支払依頼

    費用計上 支払処理 原本保管 消込処理 ・手動アップロード ・メールアップロード ・XXXXX ・XXXXX ・AI-OCR ・入力代行 ・XXXXX ・仕訳作成 ・仕訳データ出力 ・XXXXX ・XXXXX ・FBデータ作成 ・振込元口座管理 ・XXXXX ・XXXXX ・支払依頼申請/承認 ・承認フロー管理 ・XXXXX ・支払仕訳作成 ・仕訳データ出力 ・XXXXX ・インボイス対応 ・電帳法対応 ・XXXXX ・XXXXX
  6. 仮説起点のゼロイチ開発 ― ファーストリリースの進め方 13
 サービスとして意味のある3つの領域に再定義 領域ごとに設計完了次第、次の設計と並行して開発を実施し、リードタイムを短縮 ①請求書受領 請求書受領 ・請求書アップロード 原本保管

    ・インボイス対応 ・電帳法対応 ②請求書のデータ化 内容確認 ・AI-OCR 支払依頼 ・支払依頼申請/承認 ・承認フロー管理 ③データ連携 費用計上 ・仕訳作成 ・仕訳データ出力 支払処理 ・FBデータ作成 ・振込元口座管理 消込処理 ・支払仕訳作成 ・仕訳データ出力
  7. リリースして見えたこと ― 成果と反省 リリースしてわかった顧客の声 • 設計時に議論に挙がったが、実際に使わないと思って見送った機能が実際には求められていた ◦ 例: 取引先による請求書の直接アップロード(アップロードサイト) •

    楽楽シリーズファンは、楽楽精算や楽楽販売のカスタマイズ性を好んでいる ◦ 楽楽請求はカスタマイズ機能が充実しておらず、期待外れとなってしまっている ◦ 例: 請求書への入力項目の追加、役職などの単位で承認者を設定できるワークフロー 17
 いずれもリリース前に気づくことは難しい
  8. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 仮説ドリブンからVoCドリブンへ  ※VoC=Voice of Customer 19
 Before • 書籍やインターネットの情報による仮説

    • 先行サービスの機能から逆算 After • 営業・サポートが収集したVoC • 営業・サポートにヒアリング • 社内経理に壁打ち • 商談動画・オンボーディングへの同席
  9. 仮説から顧客の声へ ― 「何を作るか」より「なぜ作るか」 設計メンバーを増員 21
 営業 サポート 要望DB 2000件超 ※2025年6月末時点

    失注理由 商談時に いただいた声 解約理由 機能に対する 不満 設計メンバーを増員し、顧客の声を正しく拾うことに注力 →顧客が抱える課題を正しく捉え、ど真ん中で価値提供できる機能に落とし込む
  10. 最後に まとめ • 「開発の進め方」だけを見ると、一定成功した ◦ スコープ調整、業務領域に分割しての開発 • ただし、機能面では十分に顧客要望に応えることができなかった ◦ 完璧ではないものの、ある程度満足してもらえる機能を用意したつもりだった

    • 現在は、顧客の声を重視した進め方に変えた結果 ◦ 実際に顧客が求めている機能をリリースできており、顧客の反応も良い(機能要因の失注率も改善) 25
 新プロダクトを立ち上げるとすると・・・ ・小さく出して、早急に顧客からフィードバックをもらいながら開発を進められる状態にする ・顧客の生の声を聞く(百聞は一見に如かず!)