急成長するSaaSを支えるエンジニアリング組織の変遷と取り組んだ課題

■イベント
ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み
https://sansan.connpass.com/event/292027/

■登壇概要
タイトル：急成長するSaaSを支えるエンジニアリング組織の変遷と取り組んだ課題
登壇者：技術本部 Bill One Engineering Unit　⼭⼝ 裕明

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. Sansan株式会社 部署 名前 急成⻑するSaaSを⽀える エンジニアリング組織の変遷と 取り組んだ課題 Sansan技術本部 ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み Bill One Engineering Unit ⼭⼝ 裕明
2. ⼭⼝ 裕明 Sansan 株式会社 技術本部 Bill One Engineering Unit 副部⻑ BtoB, BtoC, コンサルなど幅広い IT 業界の経験を経て、2021 年に Sansan 株式会社に⼊社。 Sansan 株式会社では、PMF (プロダクトマーケットフィット) 直後の Bill One で⼀エンジニアとして参画し、 現在は Bill One のエンジニアリング組織を統括するエンジニアリングマネージャーの役割を担当。 RSM (Registered Scrum Master) のスクラム知識をベースにアジャイルな組織づくりを推進。
3. - プロダクト紹介と成⻑⽬標 - エンジニアリング組織の変遷 - 組織が急拡⼤する中で取り組んだ課題 3 選 アジェンダ
4. プロダクト紹介と 成⻑⽬標
5. Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。 郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書を クラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法にも対応し、⽉次決算業務 を効率化することで、企業経営における意思決定のスピードを加速します。 ※⽉次決算業務 毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。
6. Bill Oneができること①（請求書受領と一元管理）
7. Bill Oneができること②（請求書発行と一元管理）
8. Bill Oneができること③（カード発行と一元管理）
9. - T2D3 (Triple, Triple, Double, Double, Double) というベンチマークを 意識し、今期末に ARR70 億円越えを⽬指す 成⻑⽬標
10. エンジニアリング組織の変遷
11. - PMF までは約5名 - PMF 後は 2 年半で約 10 倍のエンジニアリング組織に成⻑ エンジニアリング組織の変遷
12. 組織が急拡⼤する中で 取り組んだ課題 3 選
13. 課題 1 組織拡⼤による 組織構造の複雑化
14. 組織拡⼤による組織構造の複雑化 初のチーム分割 PdM が 複数⼈に ⼈、チームが 急激に増える 単独のチーム
15. 組織拡⼤による組織構造の複雑化 フェーズに合わせた開発フレームワークを導⼊ スクラム開発 LeSS Framework をベースに導⼊ LeSS Huge をベースに導⼊ ⼈、チームが 急激に増える 初のチーム分割 PdM が 複数⼈に 単独のチーム
16. - 1 ⼈ → 10 ⼈ - スクラム開発をベースに取り⼊れる > 1つのスクラムチーム > ⼩さな機能開発が多く、PBI (プロダクトバックログ・アイテム) は個⼈が取る - 10 ⼈ → 50 ⼈ - LeSS Framework をベースに取り⼊れる > 3 から 12 のスクラムチーム > ⼤きな機能開発が増え、PBI は単⼀ PB (プロダクトバックログ) から取る - 50 ⼈ → 現在 - LeSS Huge をベースに取り⼊れる > 12 を超えるスクラムチーム、複数⼈の PdM > ⼤きいかつ複雑な機能開発が増え、PBI は分割された PB から取る フェーズに合わせた開発フレームワークを導⼊
17. 課題 2 組織拡⼤による 開発パフォーマンスの鈍化
18. 組織拡⼤による開発パフォーマンスの鈍化 開発パフォーマンスが 鈍化している肌感
19. 組織拡⼤による開発パフォーマンスの鈍化 Four Keys 試す フロー効率 試す DX Criteria 試す 開発パフォーマンスが 鈍化している肌感 感覚に合う開発パフォーマンス向上のためのKPIを模索
20. - DX Criteria - ベストプラクティスのチェック項⽬を定期的に検査 - ポイントは改善されるが、定性測定なので改善の確信が持てない - Four Keys - GitHub をベースに Four Keys を計測 - 結果は全体的に High の分類だったが、品質に課題感がある中の結果だったので感 覚と合わない (特に変更障害率) - フロー効率 - PBI をベースに PBI の完了数とスループット時間(PBI の開発着⼿からリリースまで の時間)を計測 - PBI はユーザー価値単位としているので、ユーザーに提供できる量を増やす、速度 を上げるのようにわかりやすい 感覚に合う開発パフォーマンス向上のためのKPIを模索
21. 1. PR のサイクルタイム - First Commit から Pull Request がマージ(=リリース)されるまでの期間 - ソースコードで計測できる指標のため開発活動が健全か把握できる 2. PBI の完了数 - PBI はユーザー価値単位としている - PBI の完了数を増やすためフロー効率の指標であるスループット時間の短縮 を合わせて追う 3. ユーザー視点の変更障害率 - 定義は「ユーザーに影響のある障害数 / ユーザーに有益なリリース数」 - PBI の完了数と⼀緒に計測することで開発パフォーマンスの向上が正しく⾏ えているか確認できる 現在採⽤している指標
22. 課題 3 組織拡⼤による マネジメントの難化
23. 組織拡⼤によるマネジメントの難化 単独のチーム 初のチーム分割 グループ分割
24. 組織拡⼤によるマネジメントの難化 単独のチーム 初のチーム分割 グループ分割 3Lの導⼊ GTLの導⼊ EMの導⼊ 細分化した役割 (役職ではない) を定義し増やす
25. - 3L - チームを推進する役割を分割してリードする - PdL (プロダクトリード) - ATL (アジャイルチームリード) - TL (テクニカルリード) - EM (エンジニアリングマネージャー) - ユニット、グループ、チームの全般的なマネジメントをする - 各種マネジメントや⼈事評価の強化が⽬的 - GTL (グループ・テクニカルリード) - グループの技術的なマネジメントをする (ユニット、チームレイヤーは既存) - 技術マネジメントや技術育成の強化が⽬的 細分化した役割 (役職ではない) を定義し増やす
26. - 基本ルール - 1 Pizza Rule - 1 枚のピザを⾷べられる規模でユニット、グループ、チームを構成する > コミュニケーションパスを適切なサイズにしアジリティを⾼める > ⼀⼈ひとりがオーナーシップを持ち、チャレンジしやすい環境をつくる - 細分化した役割を置く - 各レイヤーには EM, (G)TL を置く - 各チームには 3L の役割を置く 現在の組織構造 Unit (EM, Architect) Group (EM, GTL) Group (EM, GTL) Team (EM, 3L) Team (EM, 3L) Group (EM, GTL) Team (EM, 3L) … 1 Pizza … 1 Pizza
27. まとめ
28. - 組織構造の複雑化 - フェーズに合わせた開発フレームワークを導⼊ - スクラム、LeSS、Less Huge - 開発パフォーマンスの鈍化 - 感覚に合う開発パフォーマンス向上のためのKPIを模索 - PR のサイクルタイム、PBI 完了数、ユーザー視点の変更障害率 - マネジメントの難化 - 細分化した役割 (役職ではない) を定義し増やす - EM、GTL、3L 組織が急拡⼤する中で取り組んだ課題
29. Sansan 技術本部 Bill One 開発エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer