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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

© LayerX Inc. 8 バクラクシリーズラインアップ体験にこだわり抜いたマルチプロダクトをリリース。単体でも使いやすく、連携するとさらに便利に。稟議・支払申請・経費精算仕訳・支払処理効率化法人カードの発行・管理帳票保存・ストレージ帳票発行・AIが領収書を５秒でデータ化・スマホアプリとSlack連携あり・領収書の重複申請などミス防止機能・AIが請求書を５秒でデータ化・仕訳・振込データを自動作成・稟議から会計までスムーズに連携・年会費無料で何枚でも発行可・インボイス制度・電帳法対応・すべての決済で1%以上の還元・AIが書類を5秒でデータ化・あらゆる書類の電子保管に対応・電子取引・スキャナ保存に完全対応・帳票の一括作成も個別作成も自由自在・帳票の作成・稟議・送付・保存を一本化・レイアウトや項目のカスタマイズも可能

Slide 9

Slide 9 text

© LayerX Inc. 9 「バクラク」の特徴会計システムインターネットバンキング (EBシステム) 法人カード支払管理経費精算管理請求書支払管理ワークフローツールの統一経理ツールの統一会計システム・ EBシステム連携一気通貫で連携経理業務を一元管理し、債権・債務に関連する業務を一気通貫でなめらかに連携。経理業務の工数を大幅削減。出張申請取引先申請押印申請契約申請購買申請法人カード利用申請請求書支払申請経費精算申請請求書発行管理保管場所の統一領収書保管受領請求書保管発行帳票保管国税関係書類保管

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© LayerX Inc. 41 もちろん、役割を兼務するデメリットもある ● 作るのが大変な仕様やプロダクトを避ける傾向が出る ● 特に、既存のシステム仕様に引っ張られると、提供者都合が顕著になりがち作り手都合になってしまう一人で考える限界がある ● 一人で出せるアイデアには限界があり、バイアスがかかっている可能性がある ● 一人だと堂々巡りに陥ることがよくある。人に話す・相談する中で整理されることは多い ● フラットな目線でお客様やドメインエキスパートに見てもらう ● 精神論にはなるが、「開発者としての視点は捨てる！」と念じてプロダクトに向き合うタイミングを作る（二重人格） ● 過程で壁打ち・相談できる人はとっても大事！！兼務が効率が良いことと、一人で完結しないことは両立する。対策

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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