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

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

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

Transcript

1. バクラクの爆速開発を支えるチームとアーキテクチャ @mosa_siru 榎本悠介 2022.10
2. Confidential © 2022 LayerX Inc. 2 自己紹介 榎本 悠介 @mosa_siru ・LayerX取締役 バクラク事業部CTO/CPO ・創業時CTO。新規事業、新規プロダクトをひたすらつくる マン ・前線でプロダクト仕様考えまくってコードかきまくってま す
3. 3 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。
4. 4 * 経費精算のSlack連携は申請内容の通知のみ 稟議・支払申請・経費精算・ワークフロー ・AIが領収書を５秒でデータ化 ・承認はチャットアプリから ・シームレスな内部統制構築 仕訳・支払処理効率化 ・AIが請求書を５秒でデータ化 ・仕訳データを自動学習、 手入力ゼロへ ・改正電子帳簿保存法に対応 ・利用料無料 ・即時追加発行 ・最大1億円決済可能 法人向けクレジットカード ・無料で始められる ・手入力ゼロで証憑管理 ・改正電子帳簿保存法に対応 帳票保存・ストレージ バクラクシリーズラインナップ
5. （ありがたいことに） LayerXは開発速度が速いと 言われることがあります
6. 6 • 2020/10 開発 • 2021/01 バクラク請求書リリース🎊 • 2021/04 バクラク申請リリース🎊 • 2021/11 バクラク電子帳簿保存リリース🎊 • 2022/04 バクラク経費精算リリース🎊 • 2022/07 バクラクビジネスカードリリース🎊 開発開始から約2年、合計5つのプロダクトをリリース
7. 爆速開発を支えるカルチャー
8. ・・・を話す時間はなさそうなので...
9. 開発を支えるチーム体制と アーキテクチャを話します
10. 10 QA Design Product Enabling AI-OCR DevOps 現在の開発体制：それぞれのチームに1-4名程度 請求書 申請・経費精算 カード 電子帳簿保存 遊撃 Machine Learning データ基盤 Ops ※プロダクト個別チー ムに、PdMも含まれ る
11. 11 各チームの役割 QA 請求書 申請・経費精算 カード 電子帳簿保存 遊撃 Design Product Enabling AI-OCR DevOps Stream Aligned Team. 各プロダクトのエンジニアとPdMが、こだわり抜いて良いプロダクト と体験を届ける。 スケーラブルな形で品質を担保する。魅力的品質を創り出す。 開発生産性を高める。詳しくは後述 ボールが落ちがちな 共通部分や管理画 面を担当したり、柔 軟に動く お客様の体験を担保し、インシデントを予防する。開発速度を向上させる。 機械学習を軸にOCRの枠を超え、数字の先の体験を追求する 組織、プロダクトの持っている価値を最大化するアウトプットを提供する
12. 12 はじめのころは・・・ 請求書 (Dev4名) Design (1) AI-OCR (1-2) DevOps (1) Domain Expert / QA (1) おおまかな役割はあったが、実際は未分化の1チーム
13. 13 潮目その1: プロダクトが増えた • バクラク請求書リリース後、すぐに新プロダクト（バクラク申請）を作ることとなった。 • 2つは密接にデータ連携するプロダクトであり、アーキテクチャについて論点となった（分割す るか、モノリスにするか） ◦ マイクロサービスにする場合、要件的にサービス間のデータ同期（複製）が必要そうだった • そして筆者は過去にマイクロサービスについて苦い経験があった・・・・
14. 14 結局、分割することにした プロダクトごとに分割し、さらに認証基盤も分割することにした。DBは絶対に独立にする方針。
15. 15 Why Microservices? • 単体でも成立するSaaSプロダクトは、ドメイン境界として適切に見えた • 実際、開発チームは分けた（バクラク請求書2-3人、バクラク申請2人） ◦ チームをスケールさせる覚悟があり、先手を打った • 今後どんどんプロダクトを出す可能性があった • 複数プロダクトを展開するSaaSの先輩たちが、モノリスからマイクロサービスに切り出 すのに苦心しているのを知っていた
16. 16 結果どうだったか：良かった点 • 各位が自律して動き、ファクトとして爆速で開発で きており、運用もできている • 他にも、OCR基盤/認証基盤/タイムスタンプ機構な どプロダクトによらないマイクロサービスもあり、効 率化の恩恵を感じている • 新しいプロダクトでは新しい開発手法を試すことが でき、確実にチームに知見がたまっている
17. 17 結果どうだったか：辛い点 • 絡み合う複数SaaSの宿命として、とにかくデータ同期が辛い ◦ 二重管理、整合性監視と修復の運用負荷がある • 循環参照を避けるために、どのコンポーネントにどのデータを持つべきか、どの画面に機 能をおくべきか、横断しうる機能が出るたびに頭がもげる ◦ 深いドメイン知識と、将来ありそうな要件の 未来予知スキルが必要 詳しくはこのスライドを。超泥臭い話があります。
18. 18 参考：その時のチーム構成 請求書 (2-3名) Design (1) AI-OCR (2) DevOps (1) QA (1-2) 申請 (2)
19. 19 潮目その2: 各プロダクトにPdMをおいた • それまで明確なPdMを置かず、ある種の合議(Dev, Sales, CS, Domain Expert etc…) のもと、開発する優先度を決めていた ◦ 各位がドメイン知識を貪欲に持ち、顧客要望を解像度高く理解していたため、ある意味ま わっていた • しかし以下の理由でPdMをおいた（エンジニアが兼務する形） ◦ プロダクトが増え、見きれなくなってきた ◦ お客様の増加にともない要望が爆発し、整理の必要はもちろん、日々の要望に追われて 戦略的な開発ができない可能性が出てきた
20. 20 結果どうだったか • 良かった（良かった） • マイルストーンが明確になり、Bizサイドのチームにとっても拠り所となった • 時期的にはちょうどよかったかもしれない
21. 21 潮目その3: マネージャーを配置した • 背景 ◦ プロダクトチームは各プロダクトにリーダーはいたものの、基本的にフラットだった。 ◦ 組織の成長に伴い、自分が1５名以上をマネージする体制になっていた。 ◦ 一方、自分は早急に新規事業を立ち上げる必要性があった • Action ◦ 各チームのメンバーに、どんどん新任マネージャーになってもらった（4名） ▪ HRが1on1同席したり、マネージャー研修などで支援を行った
22. 22 結果どうだったか • 良かった（良かった） • 各チームのマネージャーは「チームとしてアウトカムを出す」意識となった。新メン バーのオンボーディングも順調に。 • mosa(CTO/CPO)が９割開発に集中できる体制になり、無事新規事業（バクラ クビジネスカード）を高速にローンチできた
23. 23 そして現在: Enabling Teamが発足 • 背景 ◦ プロダクトが5つとなり、データ連携が増え、アーキテクチャとしての複雑性が増している ▪ これからもどんどんプロダクトが増える可能性 • Action ◦ 名村卓さんのもと、生産性を向上する「Enabling Team」を発足 • マイクロサービスでも管理しやすくする基盤、モノレポ化など、より爆速に、攻めれる構成 にするように
24. 24 「Layerone」プロジェクト
25. 25 参考：現状のアーキテクチャのイメージ図… • 各プロダクトチームごとにコンポーネントがある、コンウェイの法則そのもの。 • 歴史的経緯で、フロントがばらばらのAPIを叩いてしまっている(Gatewayが無い) • 裏側でデータ同期が必要になっている（一部のリソースのみ） ◦ 各種要件上仕方がなかった ◦ 連携するプロダクトが増えるたびに地獄になっていく • 循環参照を鬼のように気を遣って避けているが、深いドメイン知識と未来予知スキルが必要
26. 26 参考：「Layerone」アーキテクチャイメージ Before After • ユーザーからのAPI取得は、全て同じGatewayを通る形式になる • データ同期を極力なくし、お互いがAPIでデータ取得するのを前提とするSSoTに • 循環参照を避けるために、マイクロサービスをプロダクト単位からリソース単位に ◦ enabling teamは、上記を開発者体験よくできる基盤構築を行う ◦ とはいえ切りすぎて後で困ることもあるので、結局未来予知スキルが必要説もある. • この設計によってどうチーム構造に影響するかは、まだ未知数 • とにかくまだ走り出したばかり・・！
27. まとめ
28. 28 まとめ • マルチプロダクトを高速に展開する中で、組織もアーキテクチャも変化して きました。 • これからも柔軟に、先手をうって投資していき、お客様に良い体験を届け ていきます。
29. 29 …なんか、きれいなことばかり言った気がするので・・ 最近感じていることの例 • プロダクトをまたぐ機能が増えてきて、仕様策定・あるべき姿の定義、設計が困難に • プロダクトが増え、それぞれ進化する中で、品質面（QA，DevOps etc..）をどうス ケールする形で担保できるか • 新アーキテクチャ、まだまだ未知数で正直ドキドキ。理想と現実の落とし所… • とにかく、もっとお客様にバクラクの体験を届けたい、やりたいことがたくさんあるけ ど、チームの拡大がおいついていない（月並みな話ですが…） ◦ 事業はもちろん、まだまだ体験も磨き込む余地があるのに、手をこまねいていて 本当に悔しい。
30. 皆さんの力が必要です…！ 最高のプロダクトと体験をつくり、 ハタラクをバクラクにしたいメンバーを募集しています！ （ポジションは全方位です） https://jobs.layerx.co.jp/
31. 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。