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. © 2023 LayerX Inc.
    CPOが開発する覚悟
    〜コンパウンドスタートアップにおける、爆速の新規プロダクト開発スタイル〜
    pmconf 2023
    LayerX 榎本悠介 (@mosa_siru)

    View full-size slide

  2. 自己紹介
    榎本 悠介 @mosa_siru
    LayerX バクラク事業部執行役員 CPO/CTO
    東京大学工学部卒。株式会社ディー・エヌ・エーに新卒入社
    後、株式会社Gunosyに入社し、両社にて複数の新規事業立
    ち上げをリードエンジニアやPdMとして牽引。
    2018年にLayerXを取締役CTOとして立ち上げ。現在はバ
    クラクシリーズ全ての新規プロダクトの開発を主導。
    ボンバーマンの実力のみでテレビに出ました。

    View full-size slide

  3. © LayerX Inc.
    3
    今日のテーマ:兼務に関する話
    ● 各社において実態は様々ですが、プロダクトを開発する役割は分化と深化を繰り返してきました。
    ○ CPO, VPoP, PdM, PMM, PjM, Engineer, UX Designer, UI Designer, Domain
    Expert etc…
    ○ エンジニアのリーダーだけで見ても、CTO, VPoE, EM, TechLead など、役割が分化してい
    ます。担当分野で区切ると、数えきれません。
    ● この流れは一定の合理性がありつつも、フェーズによっては役割を限定せず、覚悟をもった個人に集
    約させることが爆発力を生むという話をしていきます。
    ● 兼務をする開発スタイルがいかにプロダクトを良くしていくか見ていきます。
    ※主にプロダクトの立ち上げ期に重心をおいた話をします。

    View full-size slide

  4. 目次
    1. プロダクト紹介と歩み
    2. PdMに求められる要素
    3. 兼務するということ
    4. 今後について

    View full-size slide

  5. © LayerX Inc.
    © LayerX Inc.
    5

    View full-size slide

  6. © LayerX Inc.
    6
    LayerXの事業の中で、今回はSaaSである「バクラク」を対象とします
    バクラク事業
    企業活動のインフラとなる法人支出
    管理(BSM)SaaSを開発・提供
    Fintech事業
    ソフトウェアを駆使したアセットマネ
    ジメント・証券事業を合弁会社にて
    展開
    AI・LLM事業
    先端ソフトウェアモジュールを提供
    し、企業のデータ活用・生産性を向上
    をサポート
    +

    View full-size slide

  7. © LayerX Inc.
    7
    バクラクのプロダクトビジョン
    圧倒的に使いやすいプロダクトで
    わくわくする働き方を。
    企業活動を支えるコーポレート業務は、ミスができない難しい業務。
    バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。
    使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。
    手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。

    View full-size slide

  8. © LayerX Inc.
    8
    バクラクシリーズラインアップ
    体験にこだわり抜いたマルチプロダクトをリリース。単体でも使いやすく、連携するとさらに便利に。
    稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理
    帳票保存・ストレージ 帳票発行
    ・AIが領収書を5秒でデータ化
    ・スマホアプリとSlack連携あり
    ・領収書の重複申請などミス防止機

    ・AIが請求書を5秒でデータ化
    ・仕訳・振込データを自動作成
    ・稟議から会計までスムーズに連携
    ・年会費無料で何枚でも発行可
    ・インボイス制度・電帳法対応
    ・すべての決済で1%以上の還元
    ・AIが書類を5秒でデータ化
    ・あらゆる書類の電子保管に対応
    ・電子取引・スキャナ保存に完全対

    ・帳票の一括作成も個別作成も自由自在
    ・帳票の作成・稟議・送付・保存を一本化
    ・レイアウトや項目のカスタマイズも可能

    View full-size slide

  9. © LayerX Inc.
    9
    「バクラク」 の特徴
    会計システム
    インターネット
    バンキング
    (EBシステム)
    法人カード
    支払管理
    経費精算
    管理
    請求書
    支払管理
    ワークフローツールの統一 経理ツールの統一 会計システム・
    EBシステム連携







    経理業務を一元管理し、債権・債務に関連する業務を一気通貫でなめらかに連携。経理業務の工数を大幅削減。
    出張申請 取引先申請
    押印申請 契約申請
    購買申請
    法人カード
    利用申請
    請求書支払申請
    経費精算申請
    請求書
    発行管理
    保管場所の統一
    領収書
    保管
    受領請求書
    保管
    発行帳票
    保管
    国税関係書類
    保管

    View full-size slide

  10. © LayerX Inc.
    10
    コンパウンドなプロダクト志向
    ● 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供
    ● 部署でサービスを区切るのではなく、データを中心にサービスを統合する
    ● プロダクト間の連携の良さそのものが
    プロダクトである。
    単純なマルチプロダクトではない。
    ● 複数のプロダクトを管理、
    ローンチするケイパビリティを持つ

    View full-size slide

  11. © LayerX Inc.
    11
    2年半で6つのプロダクトと各連携を高速でリリース。
    * 2023年10月時点
    2021/01
    バクラク請求書
    2021/04
    バクラク申請
    2021/11
    バクラク電子帳簿保存
    2022/04
    バクラク経費精算
    2022/07
    バクラクビジネスカード
    2023/07
    バクラク請求書発行

    View full-size slide

  12. © LayerX Inc.
    © LayerX Inc.
    12
    どのような体制で
    これらのプロダクトを開発してきたか?

    View full-size slide

  13. © LayerX Inc.
    © LayerX Inc.
    13
    その前に・・・
    PdMの持つ3要素

    View full-size slide

  14. © LayerX Inc.
    14
    PdMに求められる3つの要素
    事業を推進するにあたって、ビジネス文脈・プロダクト戦略文脈などで多様な能力が求められますが、
    特に「プロダクトの仕様を決める」という役割においては、以下の3つの要素が強く求められると考えます
    ドメインに
    ディープダイブ
    する力
    システム的な
    思考
    デザイン力

    View full-size slide

  15. © LayerX Inc.
    15
    1. ドメインにディープダイブする力
    例えばB2B SaaSなら…
    ● 徹底的なユーザー理解
    ○ 現状の業務フローの理解とペインの分解
    ○ ご要望の理解と整理
    ○ 本当のペインと裏のニーズの理解にはスキルが要る
    ● 息を吸うような競合理解と調査
    ○ プロダクト理解
    ○ 事業理解
    ● 外部環境の理解
    ○ 法理解

    View full-size slide

  16. © LayerX Inc.
    16
    2. システム的な思考
    最低限、以下は抑えておきたいポイントです。
    ● 基本的なシステム理解
    ○ 例:フロントエンドとバックエンドの違い
    ○ 例:同期処理と非同期処理
    ● DBスキーマの理解力
    ○ 仕様策定にもデータ分析にも活きます。
    ○ このデータとこのデータは1:1なのか?1:Nなのか?N:Nなのか?… リレーションの意思決定
    は、プロダクトを大きく左右します
    理想をいえば、エンジニアになること…!
    ● 実際に設計・開発をする力
    ● 概算で見積をする能力
    ● 既に稼働中のシステム仕様を前提にしたときの困難さを嗅ぎ分ける力

    View full-size slide

  17. © LayerX Inc.
    17
    3. デザイン力
    「実現したいこと」と「ユーザー体験」を橋渡しする能力です。
    UIの変更1つで、体験はもちろんシステム全てに影響を与えるので、極めて大事な要素です。
    特にSaaSだと、増え続ける一方な仕様に対し、ユーザーの認知コストをいかに下げられるかは腕の
    見せどころ。
    ユーザーペルソナになりきって考えるのはもちろん大事ですが、
    「理解可能・認知可能かどうか・使いやすいかどうかは同じ人間として普遍のもの」として自信をもっ
    て判断できることも多いと感じています。

    View full-size slide

  18. © LayerX Inc.
    © LayerX Inc.
    18
    なぜ3つの要素を同時に持つのが
    大事?

    View full-size slide

  19. © LayerX Inc.
    19
    なぜ3つの要素を同時に持つことが大事?
    プロダクト開発の流れに関係します。
    プロダクト開発のプロセスは以下のような一直線ではなく・・・

    View full-size slide

  20. © LayerX Inc.
    20
    なぜ3つの要素を同時に持つことが大事なのか?
    現実は、複雑なループを幾重にも繰り返すことになります。リリース単位のループどころではありません。
    この細かい単位のループこそが、プロダクトを良くする本質的なプロセスです。

    View full-size slide

  21. © LayerX Inc.
    21
    なぜ3つの要素を同時に持つことが大事なのか?
    3要素を持つと、一人でループを高速にまわせるようになります。
    さらに言うと、手を動かさなくても脳内である程度のループをまわすことができます。
    複数人で分業して行うと、どうしても1つ1つのループにコストがかかってしまう。
    ● 前提を揃えるコスト
    ● 資料作成コスト、コミュニケーションコスト
    ● 実行して確認し合うコスト
    ● 合意形成コスト
    (なおこれは、エンジニアについても同じことが言えます。
    フロントやバックエンド等、職種が分かれれば分かれるほど、ループをまわすことが遅くなります。
    バクラクでは、各位得意領域はあれど複数領域を担当できるエンジニアを良しとしています)
    ドメインに
    ディープダイブ
    する力
    システム的な
    思考
    デザイン力

    View full-size slide

  22. © LayerX Inc.
    22
    実際の、バクラクの新規プロダクトの立ち上げ方
    ● 以下の体制での少人数立ち上げが多いです
    ○ mosa (PdM, TechLead) ※自分です
    ○ PdM or ドメインエキスパート 1名
    ○ エンジニア1-2名
    ○ デザイナー1名
    ● mosaの動き方は、ヒアリング・仕様策定・デザイン・バックエンド開発・フロントエンド開発を並列で行
    い、兼務・集約することでループを高速に回すこと。
    ● エンジニアは、ユーザーストーリーごとに明確に担当を1人決め、各位がドメインにディープダイブした
    上でループを回す。
    ○ 競合調査を行う、ヒアリングを行う、商談動画を見る、 etc…
    ○ 1ストーリーの開発にあたっての分業は基本しない。

    View full-size slide

  23. © LayerX Inc.
    © LayerX Inc.
    23
    PdMと開発を兼務するメリット

    View full-size slide

  24. © LayerX Inc.
    24
    PdMと開発を兼務するメリット
    ここからは、実際にPdMが開発する、またはエンジニアがプロダクト仕様を考えていくことのメリット
    を見ていきます。
    一人でループを回せること以上に、どのようなメリットがあるでしょうか。
    2つの兼務は高いレベルが求められ、まさに”覚悟”が求められます。

    View full-size slide

  25. © LayerX Inc.
    © LayerX Inc.
    25
    開発のコスパが格段に良くなる

    View full-size slide

  26. © LayerX Inc.
    26
    開発のコスパが格段に良くなる
    見積もりができる
    ● 概算で問題なし。脳内で「やばいか」「やばくない
    か」肌感でわかることが大事
    ● 短期だけでない、長期の負債にならないか判断で
    きる
    ● 既存のシステム仕様に追加したときのやばさの嗅
    覚がある
    アウトカムがわかる
    ● この仕様にしたときに、ユーザーにどれだけのメ
    リットがありペインが解決できるかわかる
    ● どこまで仕様を簡易にしてもユーザー体験に影響しないかわかる
    ● 一方で、妥協してはいけないポイントがわかる
    ● 既存のシステムと整合性がとれ、負債になりにくい仕様に落とすことができる
    コスパの良い落とし所がわかる

    View full-size slide

  27. © LayerX Inc.
    © LayerX Inc.
    27
    ぬけもれに高速に気付ける

    View full-size slide

  28. © LayerX Inc.
    28
    ぬけもれに高速に気付ける
    ● 実際に設計することで、ぬけもれに気づける
    ○ 例: DB設計するときに、NULLがありうるのかどうかで大きく分かれることに気付く
    ○ 例: リレーションを考える時に、考慮漏れに気付く
    ● 実際に開発することで、ぬけもれに気づける
    ○ 修正箇所の周辺コードを読み、考慮漏れに気づく(めっちゃある!)
    ○ 修正箇所のメソッドを呼び出しているところを見て、他の仕様への影響に気づく(めっちゃあ
    る!)
    ● 開発中のものを触ることで、ぬけもれや体験の違和感に気付ける
    これらを事前にすべて想定しておくことは人間の能力を越えるので、いかに速くループを回し、仕様再
    考に戻ることができるかが鍵。

    View full-size slide

  29. © LayerX Inc.
    © LayerX Inc.
    29
    最適な開発ができる

    View full-size slide

  30. © LayerX Inc.
    30
    最適な開発ができる
    ● 設計・実装にあたって、今後の仕様の変化の未来予知をすることができる
    ○ 負債の多くは前提の変化によってもたらされる。
    ○ 「この仕様は将来どう変わりうるか?」の予想は、将来に負債を残さず開発スピードを保
    つ基本。
    ○ ドメインの理解のない先回りは早すぎる最適化になりがち。
    ● 例:「このデータとこのデータの関係は今は1:1だが、 将来的にN:1に変わりうるか?」

    View full-size slide

  31. © LayerX Inc.
    31
    他にも・・・
    ● 柔軟にプロセスを簡略化することができる
    ○ 例:簡単なものならfigmaにおこすより実装して意見もらった方が速い
    ○ 例:要件まとめて依頼するより自分で実装したほうが速い
    ● データを分析できる
    ○ データの意味が手にとるようにわかる(このテーブル・カラムの意味は?)
    ○ データの変化の意味が追える(この日のリリース以降、同じ値でも意味が変わった)
    ● 新しい技術に飛びつきやすくなり、実際に触ることで表面以上の理解をすることができる

    View full-size slide

  32. © LayerX Inc.
    © LayerX Inc.
    32
    ケーススタディ

    View full-size slide

  33. © LayerX Inc.
    33
    ケーススタディ
    帳票発行
    ・帳票の一括作成も個別作成も自由自在
    ・帳票の作成・稟議・送付・保存を一本化
    ・レイアウトや項目のカスタマイズも可能
    バクラク請求書発行(企業が扱う書類を作成できるサービス)を例にとります

    View full-size slide

  34. © LayerX Inc.
    34
    ケーススタディ
    「作成した書類が一覧できる画面を、CSV出力したい!」
    と強い要望を受けたとします。(月ごとの会計上の処理に使いたいからということ)

    View full-size slide

  35. © LayerX Inc.
    35
    ここで仕様を考えてみる例
    出力するデータの選択は、以下のどちら?
    1. ユーザーがcheckboxで選択した書類?
    2. ページングまたいだ全ての検索対象の書類?(Gmailの一括選択)

    View full-size slide

  36. © LayerX Inc.
    © LayerX Inc.
    36
    ここからはガーッと
    思考の流れをかいていきます。
    細かい理解はいらないので、
    複数の役割を行き来していることがわかれば
    OKです

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. © LayerX Inc.
    39
    ここで仕様を考えてみる例
    ちなみに、CSVはどういうカラム構成で出す?
    ● 書類に関連するデータってたくさんあるんだけど、どこまで出す?全部出すとカラム数大変なことになる。
    ○ 書類ごとの明細行(商品ごとの金額とか)まで出すと、そもそもCSVの1行が1書類じゃなくなる。明細有無の二
    種類のデータが出力できるとか?
    ○ あと、CSVヘッダー名や順番もユーザーが設定できるのか?
    ● ➡ 会計処理に必要なデータと考えると、どうなんだろう。究極的には会計ソフトに依存するんだろうか。そうすると上
    記は全部カスタマイズ可能にすべきなのかな。
    ● ➡ 設定は保存できるのか、出力時に指定するのか?保存するのは作業ユーザーごとなのか、会社ごとなのか?
    ● ➡ うーむ… これそもそも、単純にCSVで出す汎用機能にすべきか自信なくなってきた。使っている会計ソフトごとに
    挙動が変わるとか、会計処理に特化した機能にしたほうが良い?
    ● ➡ 要望そのまま受け止めていたけど、もっとヒアリングしないとだめだな。あらためて聞いてこよう。
    この例では手を動かして得られる知見までは至りませんでしたが、こういったループを脳内で高速に
    行うことができます。

    View full-size slide

  40. © LayerX Inc.
    © LayerX Inc.
    40
    兼務するデメリット

    View full-size slide

  41. © LayerX Inc.
    41
    もちろん、役割を兼務するデメリットもある
    ● 作るのが大変な仕様やプロダクトを避ける傾向
    が出る
    ● 特に、既存のシステム仕様に引っ張られると、
    提供者都合が顕著になりがち
    作り手都合になってしまう 一人で考える限界がある
    ● 一人で出せるアイデアには限界があり、
    バイアスがかかっている可能性がある
    ● 一人だと堂々巡りに陥ることがよくある。
    人に話す・相談する中で整理されることは多

    ● フラットな目線でお客様やドメインエキスパート
    に見てもらう
    ● 精神論にはなるが、「開発者としての視点は捨
    てる!」と念じてプロダクトに向き合うタイミン
    グを作る(二重人格)
    ● 過程で壁打ち・相談できる人はとっても大
    事!!兼務が効率が良いことと、一人で完
    結しないことは両立する。
    対策

    View full-size slide

  42. © LayerX Inc.
    42
    ただし、作り手都合で判断できることは、一概に悪いとも言えない
    ● 作るのが大変な時点で、なんらかユーザーにとっても複雑で認知負荷が高い仕様になっていて、最適
    でない可能性が高い
    ● 結局作るのに時間がかかりすぎるなら他の機能のデリバリーが遅れ、トレードオフの中でお客様の体
    験を損なうことになる
    ○ ➡ 作り手都合を完全に排除することはできない

    View full-size slide

  43. © LayerX Inc.
    43
    兼務を恐れない
    ● 今回は開発との兼務を紹介しましたが、他にも兼務したら面白い職種はたくさんあります
    ● 兼務すること、あるいは異動することが全体最適をもたらす
    ○ 例:SalesからPdMになることで、深い顧客理解とともに「売りやすさ」を理解してプロダクトを
    作れる。
    ○ 例:ドメインエキスパートからPdMになることで、法対応の深い理解をプロダクトに活かせる
    ○ エンジニアの領域でも、各領域をエンジニアリングする xOps の概念が当たり前になりつつある
    ■ (DevOps, SalesOps, CSOps, MarkeOps, HROps, CorpOps etc….)
    ● 組織が大きくなっても、お互いがお互いをカバー
    することができ、組織間のぬけもれがなくなる
     ➡兼務を「属人的」だと諦めない
     キャリアにとっても思わぬプラスがたくさんあるはず。

    View full-size slide

  44. © LayerX Inc.
    44
    とはいえ、「いきなり開発は無理でしょ…」と思っているPdMへ
    ● それはそう…!
    ● できるところから始める手はあると思います。
    ○ 例:プロダクトのDB設計を理解し、実際に分析してみる
    ○ 例:オンライン講座を見ながら、簡単なサービスを作ってみる
    ● そしてAIの登場で、開発のハードルは目に見えて下がっています。
    ○ Howのハードルは下がり、WhyとWhatが中心となる時代へ。
    (余談:AIにより人による開発が極小化された世の中が来るかもしれませんが、それでもディレクションで
    き、アウトプットを判断できるレベルのシステム理解は要るのではと思います。)

    View full-size slide

  45. © LayerX Inc.
    © LayerX Inc.
    45
    今後について

    View full-size slide

  46. © LayerX Inc.
    46
    今後もこのスタイルを取り続ける?
    意図的に属人的なプロセスをとって
    きましたが、当然スケールできてい
    ません。
    今後さらなる事業加速のために新規
    プロダクトを複数ラインで立ち上げ
    るには、新しい方法も模索していく
    必要があります。
    後述
    属人性 フェーズの変化
    リリースされたプロダクトは、顧客層
    が広がる・広げるにあたってフェー
    ズが変化してきます。
    運用要件も増えていく中で、その中
    でもさらなる進化をするために、
    チームに求められるものは変化して
    いきます。
    コンパウンドの難しさ
    これまではこのスタイルで新規プロダクトを立ち上げ続けていましたが、まだまだ課題はあります。

    View full-size slide

  47. © LayerX Inc.
    47
    補足:コンパウンドなプロダクトは本当に難しい
    複数のプロダクトを理解し、あるべ
    きを考え続ける必要があります。
    これまではmosaが全てのプロダク
    トを立ち上げてきたことでカバーし
    ていましたが、これを属人性以外で
    解けるかは未解決問題です。
    モノリスではない場合は、
    ● どのコンポーネントにどの
    データを置き、実装するか?
    コンポーネント間の通信を行
    うべきか?
    ● どのような共通部分を抜き
    出すべきか?(認証等)
    ● 現実的なデプロイ形式とは?
    ● またがるコンポーネントの運
    用体制とは?
    仕様の難しさ 届ける難しさ
    複数のプロダクトと顧客を理解しな
    いと、お客様に売ることができませ
    ん。
    ● プロダクトによって顧客ペイ
    ンが違う
    ● 顧客属性が違う
    ● 売り方が違う
    (しかもプロダクトの組み合わせ毎
    に... )
    どのプロダクトを入口にするか?ど
    うクロスセルしていくか?
    アーキテクチャの難しさ
    連携するプロダクト間の兼務・横断が肝だが、どこまでスケールできるか?

    View full-size slide

  48. © LayerX Inc.
    © LayerX Inc.
    48
    まとめ

    View full-size slide

  49. © LayerX Inc.
    49
    まとめ
    ● PdMとして「ドメインへのディープダイブ」「デザイン」「システム的な思考」ができる
    ことが、プロダクト開発のループを高速化し、良いプロダクトを作っていく
    ● プロダクトマネジメントと開発を兼務することが、開発を最適化し加速させる
    ● 覚悟をもって兼務をすることが全体最適につながる

    View full-size slide

  50. © LayerX Inc.
    50
    LayerXでは絶賛採用中です!
    ● 新しい事業やプロダクトをつくり、進化させ連携していくためのPMを募集しています。
    ○ https://jobs.layerx.co.jp/
    ○ (実際はPMに限らず、全方位募集しております!エンジニア、デザイナー、QA、事業開
    発、Sales、CS、マーケ、アナリスト etc…)
    ● カジュアル面談もお待ちしています!
    ○ https://jobs.layerx.co.jp/6a7f145c0ef04a3daa7cd2bb5613ef98

    View full-size slide