layerx-0-to-1-product-development-in-compound-startups

Transcript

1. © LayerX Inc.　　 コンパウンドスタートアップにおける 新規プロダクトの０→１開発 株式会社LayerX バクラク事業部 プロダクト開発部 カード開発グループ EM兼TechLead 高江 信次
2. 　2 © LayerX Inc.　　 自己紹介 高江 信次 (Shinji Takae) 株式会社LayerX バクラク事業部 バクラクビジネスカード開発チーム EM兼TL LayerX • 2019年12月にLayerXにジョイン。バクラク事業の立ち上げから参画し、 当初は主にインフラの開発・運用を担当。 • 現在はバクラクビジネスカードの開発チームマネージャーとTechLeadを兼 任し、インフラからプロダクト開発に軸足を移して事業開発を推進。 • 「爆速開発」を体現する強いチームを作るために、日々奮闘しています。 @shnjtk 経歴・趣味 • 経歴 : ソニー株式会社（R&D） → ソニーコンピュータサイエンス研究所(CSL) → ソニー・グローバルエデュケーション → フリーランス → LayerX • 趣味 : ワイン🍷、旅行(ワイナリー訪問🍷)
3. 　3 © LayerX Inc.　　 コンパウンドスタートアップとは • 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 • 部署でサービスを区切るのではなく、データを中心にサービスを統合する • プロダクト間の連携の良さそのものがプロダクトである • 複数のプロダクトを管理、ローンチするケイパビリティを持つ コンパウンドスタートアップというLayerXの挑戦 https://comemo.nikkei.com/n/n7332c93f50c7
4. 　4 © LayerX Inc.　　 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。
5. 　5 © LayerX Inc.　　 支出管理業務を一元管理 できる経理業務支援サービス 請求書の発行と受取 のツールを統一。 発送もカンタン。 「請求書支払」「経費 精算」「カード支払」の 手間を効率化。振込 データも自動作成。 一度登録された仕訳 データを学習して自 動入力。 電子帳簿保存法に対 応し、電子上で保管が 可能。紙の管理の手 間を削減。 請求 支払い 仕訳 保管 ワークフローと各種 支払いツールを連携 し、内部統制を強化。 ワークフロー ワークフローから支払までの業務を一本化し、業務効率化と法令対応の両立を実現 バクラクシリーズとは
6. 　6 © LayerX Inc.　　 バクラクシリーズの全体像 バクラクは、企業取引の前段となる「稟議の統一」と「債権・債務の一元管理」が可能。 従業員・経理のそれぞれが係る業務領域において、なめらかな業務連携により企業経営を加速させます。 取引先 債権管理 債務管理 ※ 開発予定の機能を含む 請求書処理 経費精算 振込 稟議 法⼈カード 請求書発⾏ 稟議 仕訳 ⼊⾦消込 ※ ※ ※ 仕訳 発注 請求 発注 請求 銀⾏ 会計ソフト 仕訳データ 振込データ ⼊⾦データ 従 業 員 経 理
7. 　7 © LayerX Inc.　　 バクラクシリーズラインナップ 仕訳・支払処理効率化 法人カードの発行・管理 稟議・支払申請・経費精算 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ AIが領収書を５秒でデータ化 スマホアプリとSlack連携あり 領収書の重複申請などミス防止機能 AIが請求書を５秒でデータ化 仕訳・振込データを自動作成 稟議から会計までスムーズに連携 年会費無料で何枚でも発行可 インボイス制度・電帳法対応 すべての決済で1%以上の還元 AIが書類を5秒でデータ化 あらゆる書類の電子保管に対応 電子取引・スキャナ保存に完全対応 帳票の一括作成も個別作成も自由自在 帳票の作成・稟議・送付・保存を一本化 レイアウトや項目のカスタマイズも可能 ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ 今回はココのお話
8. 　8 © LayerX Inc.　　 バクラクビジネスカード開発のきっかけ カード利用”前後”の業務が課題に
9. 　9 © LayerX Inc.　　 プロジェクト開始時点におけるプロダクト間連携の構想 バクラク ビジネスカード バクラク 申請 バクラク 請求書受取 加盟店 明細データ 購買申請 カード利用報告 カード明細仕訳 【データを中心にサービスを統合】 バクラクビジネスカードに届く明細データをバクラク申請やバクラク請求書受取に 連携して、社内の申請や経理業務を一気通貫で処理できる 従業員 経理
10. 　10 © LayerX Inc.　　 クレジットカード決済の流れ バクラク ビジネスカード 加盟店で カードを利用 オーソリ （オーソリ取消） 売上確定 （返品) 通常は オーソリ → 売上確定 のパターンになる ユーザーが決済を行ったタイミングで通知される 利用可能な残高やカードの有効性などをチェックして 決済の承認または拒否を決定する 加盟店による日次バッチなどにより通知される 実際に商品やサービスが提供されたことを示す売上データが 連携される 売上確定前に決済がキャンセルされた場合はオーソリ取消となる 売上確定後に決済がキャンセルされた場合は返品となる
11. 　11 © LayerX Inc.　　 クレジットカード決済の経理業務を扱う上での難しさ 一例を挙げると、、 • 決済パターンが多岐にわたる ◦ オーソリ取消後に売上確定が来たり、オーソリも売上確定もなくいきなり返品が来るなど • 売上確定時に金額が変わる ◦ 海外決済でオーソリ時と為替レートが異なる場合など • オーソリ金額や売上確定金額の一部だけキャンセルされることがある • オーソリから売上確定までの間に月をまたぐことがある ◦ 月次決算を締めた後に売上確定が届くなど • オーソリ明細に含まれる加盟店名が実際に利用した店舗やサービスの名前と異なる ◦ 加盟店が決済代行業者を利用している場合など これら全てにおいて、決済サービスとして１円の誤差もなく正しく処理するだけでなく 経理業務支援サービスとして「どのような仕訳を切るか」まで考えないといけない
12. 　12 © LayerX Inc.　　 プロジェクト開始時点の開発方針 • 初期リリースでは決済サービスとしてのMVPに集中する ◦ MVP : サービスに入会できる、カードを発行できる、決済できる、支払いできる ◦ 開発メンバーにとって決済サービスは初めてのチャレンジであり、万が一大きなトラブルが 発生した場合に備えてプロダクトの機能を最小限に絞った ◦ テストで担保する品質面に濃淡を付けた （決済ロジックの品質を最優先） ◦ どのような決済パターンがあるのか、明細の内容も含めて実際のデータを見てみたかった • DB設計は将来のプロダクト間連携を見据える ◦ 決済サービスは２４時間稼働し続けることが期待されるため、DBスキーマ変更やデータマイ グレーションのためにメンテナンスに入れることはできる限り避けたかった ◦ バクラク申請やバクラク請求書受取など、既存プロダクトにカードのドメイン知識が加わるた め、最初からどのようにデータを連携させるか、カラム名や型といった細部まで考え抜いた 設計にした ▪ 異なるドメイン上のデータ（カラム）に同じ名前が使われていないか ▪ 金額を示すカラムの型に不整合がないか （int、uintが混在していない、など） ▪ プロダクトをまたぐデータの NOT NULL 指定は一致しているか
13. 　13 © LayerX Inc.　　 プロダクトリリースタイムライン 2022年5月 事業者選定など初期検討を終え、本格的に開発に着手 2022年8月 バクラクビジネスカード　リリース 🎉 2023年3月 カード明細のプロダクト間連携機能（カード機能拡張オプション）　リリース 🎉🎉 社内の決済ドメインエキスパートや経理ドメインエキスパートを交えて、DB設計について何度も議論を重ねる 外部のパートナー企業様にご協力いただき、考えられる決済パターンを洗い出してひたすらテストを繰り返す （弊社CFO渡瀬によるSlack日報でのひとこと） プロダクト間連携機能の開発に着手 それぞれのプロダクトに詳しいメンバーが集まり、属人化を恐れず最速でのリリースを目指す
14. 　14 © LayerX Inc.　　 リリースを振り返って • 開発方針の振り返り ◦ 初期リリースをMVPにしたのは正解だった ▪ 結果的に大きなトラブルもなく、安定してサービスを提供できた ▪ 決済機能を徹底的にテストしたことも功を奏した ◦ 早い時点でDB設計を固めたことで、その後の連携機能がスムーズに開発できた ▪ スキーマ変更やマイグレーションのためのメンテナンスをせずに済んだ • リリース後の気付きと今後の課題 ◦ プロダクト間連携機能の開発難易度が高い ▪ 連携するそれぞれのプロダクトとドメインの両方について深い理解が求められる ◦ 連携機能リリース後の属人性排除に時間がかかる ▪ 最初に開発したメンバーから新しいメンバーへの引き継ぎが大変 ◦ チーム編成や開発の優先度順位付けが難しい ▪ 連携機能開発チームのメンバーは各プロダクトとの兼務になることが多い ▪ 特定のプロダクトに閉じないため優先順位を誰がつけるかが曖昧になりやすい
15. 　15 © LayerX Inc.　　 まとめ コンパウンドスタートアップとして新規プロダクトを開発するときは • DB設計は将来を見据えてしっかり考え抜く • 機能は段階的にリリースする。まずはMVPでの最速ローンチを目指す おまけ • DB設計だけでなく、アーキテクチャー設計にもこだわりました • 詳細はこちら ◦ https://x.gd/whVql
16. 　16 © LayerX Inc.　　 コンパウンドなプロダクト開発に興味がある方、ぜひお話しましょう！！
17. © LayerX Inc