今後の開発方針について_2022

ロボペイの中長期事業方針と、それに伴う開発部の対応についての近況報告になります。

ROBOTPAYMENTはエンジニアを積極採用中です！！

▼ エンジニア採用HP
https://www.robotpayment.co.jp/recruit/engineer-recruitment/

▼ ROBOT PAYMENT Engineers blog
https://tech.robotpayment.co.jp/

▼ エンジニア採用担当
https://twitter.com/takeo_kamimura

Transcript

1. ビジネス主体からプロダクト主体へ 今後の開発コンセプトとPMの役割 エンジニア採用情報資料 ver.1.0 2022/11/11
2. 会社概要 1 2000年10月 設立 2001年 5月 インターネット決済代行サービス開始 2004年 1月 実店舗クレジット端末決済サービス開始 2014年 8月 継続請求管理クラウド「経理のミカタ」サービス開始 2017年 9月 「経理のミカタ」を「請求管理ロボ」に名称変更 2018年11月 小泉孝太郎氏を起用したCMを公開 2019年 3月 「請求管理ロボ まるなげオプション」サービス開始 2021年 9月 電子インボイス推進協議会(EIPA)の幹事法人に就任 2021年 9月 東京証券取引所マザーズ上場 2022年 1月 インターネット決済代行サービスを「サブスクペイ」 に名称変更 沿革 株式会社ROBOT PAYMENT 東京都渋谷区神宮前6-19-20 第15荒井ビル4F 従業員： 96名 資本金：222百万円
3. 2 決済 で世の中の課題を 解決する ブランドアイデンティティ +α 私たちの強みは、決済の仕組みやノウハウを保有していることです。 これまで20年間決済サービスを運営し、決済に新たな機能を加えることで、 「サブスクペイ」 「請求管理ロボ」「請求まるなげロボ」などの プロダクトやサービスを次々と展開してきました。 これからも、日本の企業の課題を、決済に「+α」（プラスアルファ） の機能を加えることで解決していくことを目指します。
6. 5 安定したビジネスモデル 96.1% 94.5% 95.5% リカーリング収益比率（注1） 0.50% 0.64% 月次平均解約率（注2） 0.55% 国内SaaS企業の 平均値（注3） 1.33% 0 X年後 売上に占めるリカーリング収益（継続的に積み上がる収益）の比率が高く、 解約率が低いため安定的に成長 請求管理ロボ サブスクペイ 請求管理ロボ サブスクペイ （注1） 2022年6月単月の各プロダクトの売上高に占めるリカーリング収益の比率 （注2） 金額で算出した月次の解約率で、「当月解約した顧客から発生していたリカーリング収益÷前月の全顧客のリカーリング収益」の2022年1月～2022年6月までの各月の平均値 （注3） 金額で算出した月次の解約率を開示している国内上場SaaS企業23社を対象に、2022年1月～2022年6月までの各月の平均値を当社内で調査・集計したもの
7. 6 ROBOT PAYMENTの安定成長 444 517 598 706 872 75 119 246 339 495 597 711 911 1,078 1,395 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 請求管理ロボ サブスクペイ サブスクペイ 提供開始 リーマンショック 東日本大震災 コロナ禍 請求管理ロボ 提供開始 請求まるなげロボ 提供開始 主要2プロダクトの売上高推移 2000年の創業以来、外部環境に左右されず安定した成長を継続 （単位：百万円）
8. 7 中期的な事業展開 決済機能を付加することで企業課題を解決できる領域で次々と事業を展開 さらなる事業領域の拡張のためにM&A・資本提携等も視野にあらゆる選択肢を検討 決済機能（決済処理技術/オペレーションノウハウ/金融機関とのネットワーク等） 主な顧客 企業の課題 コアな価値 領域 プロダクト /サービス 提供開始 サブスク管理 クラウド サブスクビジネスの 定常/煩雑な事務作業 サブスクビジネスの 顧客管理/定期課金 サブスクデータ統合 CRMクラウド サブスクビジネスの 収益最大化 サブスク顧客のデータ 統合/分析/アクション BNPL （後払い決済） 景況悪化による中小 企業の資金繰り懸念 決済の仕組みやノウハウ を活かした後払い決済 BtoB BNPL サブスクペイ Professional toC toC toB 2000年 2022年 2015年 2019年 請求管理DX クラウド 事務的/ミスの許され ない請求管理業務 請求～債権管理まで自 動化・効率化 （インボイス制度対応予定） 請求業務BPO/債権保 証/ファクタリング クラウド利用人材の 不足、資金繰り懸念 請求管理業務を代行 売掛債権の支払保証 toB toB 2022年 New New
9. 8 • ROBOT PAYMENTは、いまどんなフェーズ？ • ROBOT PAYMENTは、いまPMを必要としている • プロダクトプロセス、開発フロー • 各プロダクトの今後のフォーカス
10. 9 ROBOT PAYMENTは、いまどんなフェーズ？ ① 決済「＋α」で新規プロダクトを複数展開し販路を拡大 設立当初からの強みである決済領域を付加し新たな事業を幅広く展開 ③ マルチプロダクトマネジメントを可能にする組織体制の構築 事業ごとに切り分けていた開発部を統合し、開発統括室としてプロダクト全体の管理へ ② プロダクト主導型の組織構築 biz・dev共に事業部全体がプロダクト志向での意思決定をおこなう
11. 10 ROBOT PAYMENTは、いまどんなフェーズ？ 過去：アウトプットベース 営業主体の機能提供【期日優先】 現在：アウトカムベース 顧客データに基づく価値提供【価値優先】 ユーザーに寄り添った品質の高いプロダクトを開発・運用 開発軸のコンセプト変革
12. 11 なぜいまPMを必要としているのか？ • 0→1のプロダクト マーケットフィットを目指すフェーズ 顧客からのFBを得てアップデートしていく 新たな価値を感じられるサービスを提供できるか • 1→10のプロダクト 更なる拡販に向けて、エンタープライズ領域にささる機能の追加 更にプロダクトのコアを強くしていく 既存プロダクト機能拡張と複数の新規プロダクトが同時進行中 BtoB BNPL サブスクペイ Professional
13. 12 なぜいまPMを必要としているのか？ • 0→1 スピード プロダクトを立上げ、マーケットフィットを目指すPMが必要 得られる経験：自身でプロダクトをつくり成功まで経験できる • 1→10 深化 顧客ユーザーの研究 決済領域に特化しデータ分析から更なる深化を目指すPMが必要 得られる経験：専門領域(決済関連)に特化した知識を得られる 二軸のアプローチを擁したPMが求められている
14. 13 プロダクトプロセス 1．課題起票 プロダクト開発フローの最初のステップは、プロダクトの開発項目につながる可能 性がある課題を漏れなく収集し、情報を集約することから始まる。あらゆる情報リ ソースを有効活用するために、契約中の利用企業からの要望のみではなく、失注し た潜在顧客や解約した企業、社内からの要望も収集する対象に含める。 2．トリアージ 収集した要望・課題について、プロダクト開発による解決が可能かを検討する。 プロダクト開発による解決が可能と判断された場合は、プロダクト開発項目として 開発内容の概要を定義した上で、開発規模や性質を元に開発カテゴリを決定する。 開発項目は要望・課題と紐付けて管理する。 開発カテゴリは、メジャー、マイナー、リファクタ、運用改善、バグの計5種類で管 理する。社内外に対して可視化が必要なメジャー、マイナーはProductboardで管理 し、それ以外のリファクタ、運用改善、バグについてはスプレッドシートでの管理 を行う。 3．開発判断 各開発項目は、その開発カテゴリに応じた判断基準、会議体、頻度に従って開発可 否の判断を行う。開発が決定した開発項目は開発を行う時期を決定する。 1.PMが開発検討対象を選定する。 2.PMが開発投資対効果試算を入力する。 3.プロダクト定例会議で開発項目の開発可否を判断する。 4．開発・リリース 開発が決定した項目は、開発開始時期に必要な文書を作成し開発を開始する。 メジャー マイナー CSが開発検討 対象を選定 プロダクト開発フローに続く
15. 14 プロダクト開発フロー 1．事前準備 1. CTOがロードマップで決定されているチケットの開発承認と資産性の判定をする 2. 開発開始時期に開発開始 2．企画 1. 企画書をNotionに記載する 2. 要求仕様書の作成 3. 上記企画書と要求仕様書の合意を得る a. 企画・要求仕様レビュー会議を実施 i. 参加者：事業部長、PM、CS、Desk、営業、マーケ、DEV ii. ファシリテーター：PM 3．要件定義・設計・開発 1. 要件定義書の作成 2. 要件定義書のレビュー 3. 開発工程定義に沿って開発 要件定義書の目的 実現可能かを検討した上で要求の詳細を定義し、調査結果を踏まえてどのよう な機能を開発するかを明確にし、ステークホルダー(CS/営業/事業部長etc…を 含む)と開発チームに方向性として問題がないか確認する。 4．検証 1. ユニットテスト、ユーザーテストを実施する 2. ユーザーテストはユーザーテスト仕様書を基に手動で実施する 5．移行 1. 仕様変更が発生する場合CSが利用企業に原則リリース2週間以上前に通知 2. 仕様変更による業務影響が大きい場合、適切な移行期間をCSが利用企業に通知 6．運用 1. 業務運用 a. 要件定義時に作成した運用要件に沿ってCSが業務運用を実施 2. システム運用 a. 要件定義時に作成した運用要件に沿ってDEV、SREが業務運用を実施 7．リリース後検証 1. 企画段階で定義したKPIの取得・集計 2. 仮説検証 a. リリース前に立てた仮説がどうだったか b. ネクストアクションの判断 3. 開発投資対効果検証 a. 見積もりと開発実績の比較
16. 15 各プロダクトの今後のフォーカス テーマ 得意顧客の発見/獲得/拡大 必要最低限の開発投資で価値訴求できる顧客セグメント を発見し、確実に契約を獲得するための仕組みを作る 開発基盤整備 溜まった負債を解消し、新サービスを開発していくため の土台整備 販路拡大/利用促進 パートナー連携（システム）で1click後払いターゲット にリーチ、ユーザー体験や需要の検証を行う 得意顧客深堀り IT/SaaS、コンサル業種の受注率増加 既存顧客の満足度向上 体制強化 販売の体制強化、機能保守改善の体制強化 運用改善 運用チームの生産性向上 運用チームで障壁が出ている点を解消する プロダクトフェーズ/方針 仮説検証期 マーケットフィットを目指す 体制強化/運用改善期 内部コストの削減、最適化 拡販期 攻めの開発を行い受注率を上げる 拡販準備期 今後の新規開発のための土台づくり セキュリティ対策 投資サイズ （開発費のみ） 小 小 小 小 大 大 サブスクペイ Pro 1click後払い ロボアプリ まるなげ ロボクラウド サブスクペイ Standard 社外秘
17. エンジニアが大切にしている価値観 16 解決は、根本から。 私たちのサービスは、お金という企業の根幹にある課題を 解決する存在。エンジニアとして、問題の表面ではなく根 本にある本質と向き合おう。 試みて、振り返る。 サービスの価値を高めるには、常にアップデートを続けな ければならない。失敗を恐れて入念な準備をするよりも小 さく試し、どんな結果でも振り返って少しずつ前へ進もう。 やるなら、みんなで。 どんなに優秀な人でも、ひとりができることには限界があ る。チーム全員の力をかけ合わせて、もっと大きな成果を 目指そう。 楽しいを、選ぼう。 楽しくないより、楽しいほうがいい。和やかな空気のほう が、いいアイデアが出たり、議論が盛り上がったりするも の。チームメンバーと楽しい時間を共有しよう
18. 17 WE ARE HIRING!! 採用HP © ROBOT PAYMENT Inc. 3分でわかる ROBOT PAYMENT