$30 off During Our Annual Pro Sale. View Details »

バクラクの爆速開発を支えるチームとアーキテクチャ

mosa
October 28, 2022

 バクラクの爆速開発を支えるチームとアーキテクチャ

開発速度が速いと言われることがある、LayerXのSaaS「バクラク」の開発組織とアーキテクチャを紹介します。

以下のイベントで話した資料となります。
「SmartHR×STORES×LayerX スタートアップとプロダクト開発の組織化 bySELECK」
https://yumemi.connpass.com/event/262328/

mosa

October 28, 2022
Tweet

More Decks by mosa

Other Decks in Technology

Transcript

  1. Confidential © 2022 LayerX Inc. 2 自己紹介 榎本 悠介 @mosa_siru

    ・LayerX取締役 バクラク事業部CTO/CPO ・創業時CTO。新規事業、新規プロダクトをひたすらつくる マン ・前線でプロダクト仕様考えまくってコードかきまくってま す
  2. 4 * 経費精算のSlack連携は申請内容の通知のみ 稟議・支払申請・経費精算・ワークフロー ・AIが領収書を5秒でデータ化 ・承認はチャットアプリから ・シームレスな内部統制構築 仕訳・支払処理効率化 ・AIが請求書を5秒でデータ化 ・仕訳データを自動学習、

    手入力ゼロへ ・改正電子帳簿保存法に対応 ・利用料無料 ・即時追加発行 ・最大1億円決済可能 法人向けクレジットカード ・無料で始められる ・手入力ゼロで証憑管理 ・改正電子帳簿保存法に対応 帳票保存・ストレージ バクラクシリーズラインナップ
  3. 6 • 2020/10 開発 • 2021/01 バクラク請求書リリース🎊 • 2021/04 バクラク申請リリース🎊

    • 2021/11 バクラク電子帳簿保存リリース🎊 • 2022/04 バクラク経費精算リリース🎊 • 2022/07 バクラクビジネスカードリリース🎊 開発開始から約2年、合計5つのプロダクトをリリース
  4. 10 QA Design Product Enabling AI-OCR DevOps 現在の開発体制:それぞれのチームに1-4名程度 請求書 申請・経費精算

    カード 電子帳簿保存 遊撃 Machine Learning データ基盤 Ops ※プロダクト個別チー ムに、PdMも含まれ る
  5. 11 各チームの役割 QA 請求書 申請・経費精算 カード 電子帳簿保存 遊撃 Design Product

    Enabling AI-OCR DevOps Stream Aligned Team. 各プロダクトのエンジニアとPdMが、こだわり抜いて良いプロダクト と体験を届ける。 スケーラブルな形で品質を担保する。魅力的品質を創り出す。 開発生産性を高める。詳しくは後述 ボールが落ちがちな 共通部分や管理画 面を担当したり、柔 軟に動く お客様の体験を担保し、インシデントを予防する。開発速度を向上させる。 機械学習を軸にOCRの枠を超え、数字の先の体験を追求する 組織、プロダクトの持っている価値を最大化するアウトプットを提供する
  6. 12 はじめのころは・・・ 請求書 (Dev4名) Design (1) AI-OCR (1-2) DevOps (1)

    Domain Expert / QA (1) おおまかな役割はあったが、実際は未分化の1チーム
  7. 15 Why Microservices? • 単体でも成立するSaaSプロダクトは、ドメイン境界として適切に見えた • 実際、開発チームは分けた(バクラク請求書2-3人、バクラク申請2人) ◦ チームをスケールさせる覚悟があり、先手を打った •

    今後どんどんプロダクトを出す可能性があった • 複数プロダクトを展開するSaaSの先輩たちが、モノリスからマイクロサービスに切り出 すのに苦心しているのを知っていた
  8. 19 潮目その2: 各プロダクトにPdMをおいた • それまで明確なPdMを置かず、ある種の合議(Dev, Sales, CS, Domain Expert etc…)

    のもと、開発する優先度を決めていた ◦ 各位がドメイン知識を貪欲に持ち、顧客要望を解像度高く理解していたため、ある意味ま わっていた • しかし以下の理由でPdMをおいた(エンジニアが兼務する形) ◦ プロダクトが増え、見きれなくなってきた ◦ お客様の増加にともない要望が爆発し、整理の必要はもちろん、日々の要望に追われて 戦略的な開発ができない可能性が出てきた
  9. 21 潮目その3: マネージャーを配置した • 背景 ◦ プロダクトチームは各プロダクトにリーダーはいたものの、基本的にフラットだった。 ◦ 組織の成長に伴い、自分が15名以上をマネージする体制になっていた。 ◦

    一方、自分は早急に新規事業を立ち上げる必要性があった • Action ◦ 各チームのメンバーに、どんどん新任マネージャーになってもらった(4名) ▪ HRが1on1同席したり、マネージャー研修などで支援を行った
  10. 23 そして現在: Enabling Teamが発足 • 背景 ◦ プロダクトが5つとなり、データ連携が増え、アーキテクチャとしての複雑性が増している ▪ これからもどんどんプロダクトが増える可能性

    • Action ◦ 名村卓さんのもと、生産性を向上する「Enabling Team」を発足 • マイクロサービスでも管理しやすくする基盤、モノレポ化など、より爆速に、攻めれる構成 にするように
  11. 26 参考:「Layerone」アーキテクチャイメージ Before After • ユーザーからのAPI取得は、全て同じGatewayを通る形式になる • データ同期を極力なくし、お互いがAPIでデータ取得するのを前提とするSSoTに • 循環参照を避けるために、マイクロサービスをプロダクト単位からリソース単位に

    ◦ enabling teamは、上記を開発者体験よくできる基盤構築を行う ◦ とはいえ切りすぎて後で困ることもあるので、結局未来予知スキルが必要説もある. • この設計によってどうチーム構造に影響するかは、まだ未知数 • とにかくまだ走り出したばかり・・!
  12. 29 …なんか、きれいなことばかり言った気がするので・・ 最近感じていることの例 • プロダクトをまたぐ機能が増えてきて、仕様策定・あるべき姿の定義、設計が困難に • プロダクトが増え、それぞれ進化する中で、品質面(QA,DevOps etc..)をどうス ケールする形で担保できるか •

    新アーキテクチャ、まだまだ未知数で正直ドキドキ。理想と現実の落とし所… • とにかく、もっとお客様にバクラクの体験を届けたい、やりたいことがたくさんあるけ ど、チームの拡大がおいついていない(月並みな話ですが…) ◦ 事業はもちろん、まだまだ体験も磨き込む余地があるのに、手をこまねいていて 本当に悔しい。