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

CPOが開発する覚悟 〜コンパウンドスタートアップにおける、爆速の新規プロダクト開発スタイル〜

mosa
November 29, 2023

CPOが開発する覚悟 〜コンパウンドスタートアップにおける、爆速の新規プロダクト開発スタイル〜

・各社において実態は様々ですが、プロダクトを開発する役割は分化と深化を繰り返してきました。

・この流れは一定の合理性がありつつも、フェーズによっては役割を限定せず、覚悟をもった個人に集約させることが爆発力を生むという話をしていきます。

・兼務をする開発スタイルがいかにプロダクトを良くしていくか見ていきます。

mosa

November 29, 2023
Tweet

More Decks by mosa

Other Decks in Technology

Transcript

  1. 自己紹介 榎本 悠介 @mosa_siru LayerX バクラク事業部執行役員 CPO/CTO 東京大学工学部卒。株式会社ディー・エヌ・エーに新卒入社 後、株式会社Gunosyに入社し、両社にて複数の新規事業立 ち上げをリードエンジニアやPdMとして牽引。

    2018年にLayerXを取締役CTOとして立ち上げ。現在はバ クラクシリーズ全ての新規プロダクトの開発を主導。 ボンバーマンの実力のみでテレビに出ました。
  2. © LayerX Inc. 3 今日のテーマ:兼務に関する話 • 各社において実態は様々ですが、プロダクトを開発する役割は分化と深化を繰り返してきました。 ◦ CPO, VPoP,

    PdM, PMM, PjM, Engineer, UX Designer, UI Designer, Domain Expert etc… ◦ エンジニアのリーダーだけで見ても、CTO, VPoE, EM, TechLead など、役割が分化してい ます。担当分野で区切ると、数えきれません。 • この流れは一定の合理性がありつつも、フェーズによっては役割を限定せず、覚悟をもった個人に集 約させることが爆発力を生むという話をしていきます。 • 兼務をする開発スタイルがいかにプロダクトを良くしていくか見ていきます。 ※主にプロダクトの立ち上げ期に重心をおいた話をします。
  3. © LayerX Inc. 6 LayerXの事業の中で、今回はSaaSである「バクラク」を対象とします バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネ

    ジメント・証券事業を合弁会社にて 展開 AI・LLM事業 先端ソフトウェアモジュールを提供 し、企業のデータ活用・生産性を向上 をサポート +
  4. © LayerX Inc. 8 バクラクシリーズラインアップ 体験にこだわり抜いたマルチプロダクトをリリース。単体でも使いやすく、連携するとさらに便利に。 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ

    帳票発行 ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機 能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対 応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
  5. © LayerX Inc. 9 「バクラク」 の特徴 会計システム インターネット バンキング (EBシステム)

    法人カード 支払管理 経費精算 管理 請求書 支払管理 ワークフローツールの統一 経理ツールの統一 会計システム・ EBシステム連携 一 気 通 貫 で 連 携 経理業務を一元管理し、債権・債務に関連する業務を一気通貫でなめらかに連携。経理業務の工数を大幅削減。 出張申請 取引先申請 押印申請 契約申請 購買申請 法人カード 利用申請 請求書支払申請 経費精算申請 請求書 発行管理 保管場所の統一 領収書 保管 受領請求書 保管 発行帳票 保管 国税関係書類 保管
  6. © LayerX Inc. 10 コンパウンドなプロダクト志向 • 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 • 部署でサービスを区切るのではなく、データを中心にサービスを統合する •

    プロダクト間の連携の良さそのものが プロダクトである。 単純なマルチプロダクトではない。 • 複数のプロダクトを管理、 ローンチするケイパビリティを持つ
  7. © LayerX Inc. 11 2年半で6つのプロダクトと各連携を高速でリリース。 * 2023年10月時点 2021/01 バクラク請求書 2021/04

    バクラク申請 2021/11 バクラク電子帳簿保存 2022/04 バクラク経費精算 2022/07 バクラクビジネスカード 2023/07 バクラク請求書発行
  8. © LayerX Inc. 15 1. ドメインにディープダイブする力 例えばB2B SaaSなら… • 徹底的なユーザー理解

    ◦ 現状の業務フローの理解とペインの分解 ◦ ご要望の理解と整理 ◦ 本当のペインと裏のニーズの理解にはスキルが要る • 息を吸うような競合理解と調査 ◦ プロダクト理解 ◦ 事業理解 • 外部環境の理解 ◦ 法理解
  9. © LayerX Inc. 16 2. システム的な思考 最低限、以下は抑えておきたいポイントです。 • 基本的なシステム理解 ◦

    例:フロントエンドとバックエンドの違い ◦ 例:同期処理と非同期処理 • DBスキーマの理解力 ◦ 仕様策定にもデータ分析にも活きます。 ◦ このデータとこのデータは1:1なのか?1:Nなのか?N:Nなのか?… リレーションの意思決定 は、プロダクトを大きく左右します 理想をいえば、エンジニアになること…! • 実際に設計・開発をする力 • 概算で見積をする能力 • 既に稼働中のシステム仕様を前提にしたときの困難さを嗅ぎ分ける力
  10. © LayerX Inc. 17 3. デザイン力 「実現したいこと」と「ユーザー体験」を橋渡しする能力です。 UIの変更1つで、体験はもちろんシステム全てに影響を与えるので、極めて大事な要素です。 特にSaaSだと、増え続ける一方な仕様に対し、ユーザーの認知コストをいかに下げられるかは腕の 見せどころ。

    ユーザーペルソナになりきって考えるのはもちろん大事ですが、 「理解可能・認知可能かどうか・使いやすいかどうかは同じ人間として普遍のもの」として自信をもっ て判断できることも多いと感じています。
  11. © LayerX Inc. 21 なぜ3つの要素を同時に持つことが大事なのか? 3要素を持つと、一人でループを高速にまわせるようになります。 さらに言うと、手を動かさなくても脳内である程度のループをまわすことができます。 複数人で分業して行うと、どうしても1つ1つのループにコストがかかってしまう。 • 前提を揃えるコスト

    • 資料作成コスト、コミュニケーションコスト • 実行して確認し合うコスト • 合意形成コスト (なおこれは、エンジニアについても同じことが言えます。 フロントやバックエンド等、職種が分かれれば分かれるほど、ループをまわすことが遅くなります。 バクラクでは、各位得意領域はあれど複数領域を担当できるエンジニアを良しとしています) ドメインに ディープダイブ する力 システム的な 思考 デザイン力
  12. © LayerX Inc. 22 実際の、バクラクの新規プロダクトの立ち上げ方 • 以下の体制での少人数立ち上げが多いです ◦ mosa (PdM,

    TechLead) ※自分です ◦ PdM or ドメインエキスパート 1名 ◦ エンジニア1-2名 ◦ デザイナー1名 • mosaの動き方は、ヒアリング・仕様策定・デザイン・バックエンド開発・フロントエンド開発を並列で行 い、兼務・集約することでループを高速に回すこと。 • エンジニアは、ユーザーストーリーごとに明確に担当を1人決め、各位がドメインにディープダイブした 上でループを回す。 ◦ 競合調査を行う、ヒアリングを行う、商談動画を見る、 etc… ◦ 1ストーリーの開発にあたっての分業は基本しない。
  13. © LayerX Inc. 26 開発のコスパが格段に良くなる 見積もりができる • 概算で問題なし。脳内で「やばいか」「やばくない か」肌感でわかることが大事 •

    短期だけでない、長期の負債にならないか判断で きる • 既存のシステム仕様に追加したときのやばさの嗅 覚がある アウトカムがわかる • この仕様にしたときに、ユーザーにどれだけのメ リットがありペインが解決できるかわかる • どこまで仕様を簡易にしてもユーザー体験に影響しないかわかる • 一方で、妥協してはいけないポイントがわかる • 既存のシステムと整合性がとれ、負債になりにくい仕様に落とすことができる コスパの良い落とし所がわかる +
  14. © LayerX Inc. 28 ぬけもれに高速に気付ける • 実際に設計することで、ぬけもれに気づける ◦ 例: DB設計するときに、NULLがありうるのかどうかで大きく分かれることに気付く

    ◦ 例: リレーションを考える時に、考慮漏れに気付く • 実際に開発することで、ぬけもれに気づける ◦ 修正箇所の周辺コードを読み、考慮漏れに気づく(めっちゃある!) ◦ 修正箇所のメソッドを呼び出しているところを見て、他の仕様への影響に気づく(めっちゃあ る!) • 開発中のものを触ることで、ぬけもれや体験の違和感に気付ける これらを事前にすべて想定しておくことは人間の能力を越えるので、いかに速くループを回し、仕様再 考に戻ることができるかが鍵。
  15. © LayerX Inc. 30 最適な開発ができる • 設計・実装にあたって、今後の仕様の変化の未来予知をすることができる ◦ 負債の多くは前提の変化によってもたらされる。 ◦

    「この仕様は将来どう変わりうるか?」の予想は、将来に負債を残さず開発スピードを保 つ基本。 ◦ ドメインの理解のない先回りは早すぎる最適化になりがち。 • 例:「このデータとこのデータの関係は今は1:1だが、 将来的にN:1に変わりうるか?」
  16. © LayerX Inc. 31 他にも・・・ • 柔軟にプロセスを簡略化することができる ◦ 例:簡単なものならfigmaにおこすより実装して意見もらった方が速い ◦

    例:要件まとめて依頼するより自分で実装したほうが速い • データを分析できる ◦ データの意味が手にとるようにわかる(このテーブル・カラムの意味は?) ◦ データの変化の意味が追える(この日のリリース以降、同じ値でも意味が変わった) • 新しい技術に飛びつきやすくなり、実際に触ることで表面以上の理解をすることができる
  17. © LayerX Inc. 37 ここで仕様を考えてみる例  ※この色はAs PdMとしての思考です。 1. checkbox指定の場合 •

    件数が少ないならこっちにしたい。ページまたぐよりは確実に楽だ! ◦ もしかしたら、バックエンドAPIでは何も考えずこれまで通りデータを返すだけで、フロントエンドで CSVを組み立ててしまうのもありうるなぁ、さらに楽できるかも。 • ➡ うーん、さすがに対象100件とかは越えるかな。毎月行う処理だとして、月あたりの書類数を考えると。 • ➡ このためだけに1ページ1,000件とかまで表示可能にするのはパフォーマンス的にまずそう、ダメだな
  18. © LayerX Inc. 38 ここで仕様を考えてみる例  ※この色はAs PdMとしての思考です。 2. ページングまたいだすべての書類の場合 •

    最大レコード数を気にする必要があるな。処理時間や負荷によっては非同期でCSVを作らないといけない? ◦ 非同期の場合、フロントは終わるまでポーリングしている?失敗した場合はユーザーにどう見せる?待ち時間に リロードされてしまった場合は? ◦ ➡ それらを踏まえると、CSV出力履歴ページを別途つくって成功も失敗もわかると落ち着きが良い? ◦ ➡ 出力履歴ページには何を出すんだろう、出力者や日時?もしかして過去の出力ファイルは再ダウンロードでき るの?他の人の出力履歴は見れていいのか? • ➡ 今の想定だと、多くて10,000件とかいうレベルかなぁ…複雑になるなら一定の件数制限をかけてもいいと思う。 • ➡ それくらいならたぶん非同期にするレベルでもないかな・・・履歴ページもコスパ悪そう。 • ➡ 結論、シンプルに同期処理が体験上も良さそうだ • ちなみに一部のレコードだけcheckbox外したいとか許す?ちょっと実装面倒になるが・・・ • ➡ おそらくマストではないし、妥協しても良いポイントだとは思う。gmailもやってない。検索条件を工夫してもらった り、直接CSVをいじってもらったりでいいのでは。そのかわり将来的には書類にタグつけて検索できたり、検索条件の 保存機能とかは必要になるかもしれん。そうすると汎用的に他の要望もかなえられそうだし。 • ➡ それは開発コスパも良さそうだし全然あり。
  19. © LayerX Inc. 39 ここで仕様を考えてみる例 ちなみに、CSVはどういうカラム構成で出す? • 書類に関連するデータってたくさんあるんだけど、どこまで出す?全部出すとカラム数大変なことになる。 ◦ 書類ごとの明細行(商品ごとの金額とか)まで出すと、そもそもCSVの1行が1書類じゃなくなる。明細有無の二

    種類のデータが出力できるとか? ◦ あと、CSVヘッダー名や順番もユーザーが設定できるのか? • ➡ 会計処理に必要なデータと考えると、どうなんだろう。究極的には会計ソフトに依存するんだろうか。そうすると上 記は全部カスタマイズ可能にすべきなのかな。 • ➡ 設定は保存できるのか、出力時に指定するのか?保存するのは作業ユーザーごとなのか、会社ごとなのか? • ➡ うーむ… これそもそも、単純にCSVで出す汎用機能にすべきか自信なくなってきた。使っている会計ソフトごとに 挙動が変わるとか、会計処理に特化した機能にしたほうが良い? • ➡ 要望そのまま受け止めていたけど、もっとヒアリングしないとだめだな。あらためて聞いてこよう。 この例では手を動かして得られる知見までは至りませんでしたが、こういったループを脳内で高速に 行うことができます。
  20. © LayerX Inc. 41 もちろん、役割を兼務するデメリットもある • 作るのが大変な仕様やプロダクトを避ける傾向 が出る • 特に、既存のシステム仕様に引っ張られると、

    提供者都合が顕著になりがち 作り手都合になってしまう 一人で考える限界がある • 一人で出せるアイデアには限界があり、 バイアスがかかっている可能性がある • 一人だと堂々巡りに陥ることがよくある。 人に話す・相談する中で整理されることは多 い • フラットな目線でお客様やドメインエキスパート に見てもらう • 精神論にはなるが、「開発者としての視点は捨 てる!」と念じてプロダクトに向き合うタイミン グを作る(二重人格) • 過程で壁打ち・相談できる人はとっても大 事!!兼務が効率が良いことと、一人で完 結しないことは両立する。 対策
  21. © LayerX Inc. 43 兼務を恐れない • 今回は開発との兼務を紹介しましたが、他にも兼務したら面白い職種はたくさんあります • 兼務すること、あるいは異動することが全体最適をもたらす ◦

    例:SalesからPdMになることで、深い顧客理解とともに「売りやすさ」を理解してプロダクトを 作れる。 ◦ 例:ドメインエキスパートからPdMになることで、法対応の深い理解をプロダクトに活かせる ◦ エンジニアの領域でも、各領域をエンジニアリングする xOps の概念が当たり前になりつつある ▪ (DevOps, SalesOps, CSOps, MarkeOps, HROps, CorpOps etc….) • 組織が大きくなっても、お互いがお互いをカバー することができ、組織間のぬけもれがなくなる  ➡兼務を「属人的」だと諦めない  キャリアにとっても思わぬプラスがたくさんあるはず。
  22. © LayerX Inc. 44 とはいえ、「いきなり開発は無理でしょ…」と思っているPdMへ • それはそう…! • できるところから始める手はあると思います。 ◦

    例:プロダクトのDB設計を理解し、実際に分析してみる ◦ 例:オンライン講座を見ながら、簡単なサービスを作ってみる • そしてAIの登場で、開発のハードルは目に見えて下がっています。 ◦ Howのハードルは下がり、WhyとWhatが中心となる時代へ。 (余談:AIにより人による開発が極小化された世の中が来るかもしれませんが、それでもディレクションで き、アウトプットを判断できるレベルのシステム理解は要るのではと思います。)
  23. © LayerX Inc. 46 今後もこのスタイルを取り続ける? 意図的に属人的なプロセスをとって きましたが、当然スケールできてい ません。 今後さらなる事業加速のために新規 プロダクトを複数ラインで立ち上げ

    るには、新しい方法も模索していく 必要があります。 後述 属人性 フェーズの変化 リリースされたプロダクトは、顧客層 が広がる・広げるにあたってフェー ズが変化してきます。 運用要件も増えていく中で、その中 でもさらなる進化をするために、 チームに求められるものは変化して いきます。 コンパウンドの難しさ これまではこのスタイルで新規プロダクトを立ち上げ続けていましたが、まだまだ課題はあります。
  24. © LayerX Inc. 47 補足:コンパウンドなプロダクトは本当に難しい 複数のプロダクトを理解し、あるべ きを考え続ける必要があります。 これまではmosaが全てのプロダク トを立ち上げてきたことでカバーし ていましたが、これを属人性以外で

    解けるかは未解決問題です。 モノリスではない場合は、 • どのコンポーネントにどの データを置き、実装するか? コンポーネント間の通信を行 うべきか? • どのような共通部分を抜き 出すべきか?(認証等) • 現実的なデプロイ形式とは? • またがるコンポーネントの運 用体制とは? 仕様の難しさ 届ける難しさ 複数のプロダクトと顧客を理解しな いと、お客様に売ることができませ ん。 • プロダクトによって顧客ペイ ンが違う • 顧客属性が違う • 売り方が違う (しかもプロダクトの組み合わせ毎 に... ) どのプロダクトを入口にするか?ど うクロスセルしていくか? アーキテクチャの難しさ 連携するプロダクト間の兼務・横断が肝だが、どこまでスケールできるか?
  25. © LayerX Inc. 50 LayerXでは絶賛採用中です! • 新しい事業やプロダクトをつくり、進化させ連携していくためのPMを募集しています。 ◦ https://jobs.layerx.co.jp/ ◦

    (実際はPMに限らず、全方位募集しております!エンジニア、デザイナー、QA、事業開 発、Sales、CS、マーケ、アナリスト etc…) • カジュアル面談もお待ちしています! ◦ https://jobs.layerx.co.jp/6a7f145c0ef04a3daa7cd2bb5613ef98