エンジニアとしてプロダクトマネジメントに向き合った1年半

■ イベント
23卒＆中途入社1年目エンジニアのリアル：経験とこれからの展望
https://connpass.com/event/340472/

■ 発表者
技術本部 Bill One Engineering Unit
阿左見 蓮

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

Transcript

1. エンジニアとして プロダクトマネジメントに 向き合った1年半 Sansan株式会社 Bill One Engineering Unit 阿左⾒ 蓮 23卒＆中途⼊社1年⽬エンジニアのリアル：経験とこれからの展望
2. ⾃⼰紹介
3. 3 © Sansan, Inc. ⾃⼰紹介 • name: 阿左⾒ 蓮 • age: 24 • affiliation: ◦ BIll One Engineering Unit ▪ Core Business UM Group ◦ 23卒 • intern: フルコミ営業→エンジニア • job: フルスタック(?)なエンジニア
4. 4 © Sansan, Inc. • Bill Oneについて • プロダクトマネジメントを始めた経緯 • 失敗事例と学び • 何がよかったか • エンジニアとして成⻑したポイント • これからについて Agenda
5. Bill Oneについて
6. © Sansan, Inc. ※⽉次決算業務 毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。 Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。 郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書を クラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法に も対応し、⽉次決算業務を効率化することで、企業経営における意思決定のスピードを加速します。 6
7. © Sansan, Inc. 請求書 発⾏ 経費 精算 請求書 受領 ⽉次決算を加速する 7
8. © Sansan, Inc. Bill Oneの成⻑ 出典: 2025年5月期通期 決算説明資料 ※ Monthly Recurring Revenue（月次固定収入） 8 リリース4年超でARRは93億円超、契約件数は3,310社
9. © Sansan, Inc. Bill OneのARR（年間固定収⼊）推移 9 リリースから約4年超、T2D3※を超える成⻑速度を⾒せている ※ サービスをスタートしてからの売上額が、前年を基準として毎年3倍・3倍・2倍・2倍・2倍と上昇し、5年間で72倍の売上成⻑を⽬指すという意味。 理想的なSaaSの成⻑モデルとされる。
10. プロダクトマネジメントを始めた経緯
11. © Sansan, Inc. 3L体制 チームで意思決定できる幅を広げ、開発スピードを加速させる取り組み 役割名 責務 ATL (アジャイルチームリード) • ⾃⼰組織化されたアジャイルチームの確⽴を推進 • 継続的なリーダーシップ / 計画 / 実⾏ / リスク低減 / 改 善 PdL (プロダクトリード) • 仕様や要件の整理 • ATL・PdM・デザイナーとの調整 ※ すべてのPdLはPdMがまとめる TL (テクニカルリード) • コード品質を担保 • チームの技術⼒向上 • ロジックが集中するバックエンドの相談役 ※これらは役職ではなくチーム内の分担としての役割 気軽にチャレンジして 伸ばしたいスキルにフォーカスできる環境づくり 副次的効果として 11
12. © Sansan, Inc. 3L体制 チームで意思決定できる幅を広げ、開発スピードを加速させる取り組み 役割名 責務 ATL (アジャイルチームリード) • ⾃⼰組織化されたアジャイルチームの確⽴を推進 • 継続的なリーダーシップ / 計画 / 実⾏ / リスク低減 / 改 善 PdL (プロダクトリード) • 仕様や要件の整理 • ATL・PdM・デザイナーとの調整 ※ すべてのPdLはPdMがまとめる TL (テクニカルリード) • コード品質を担保 • チームの技術⼒向上 • ロジックが集中するバックエンドの相談役 ※これらは役職ではなくチーム内の分担としての役割 気軽にチャレンジして 伸ばしたいスキルにフォーカスできる環境づくり 副次的効果として 12
13. 13 © Sansan, Inc. なぜプロダクトマネジメントを選んだのか 組織の状況 ⾃分の状況 学⽣時代から強かった プロダクト志向 チャレンジを推進する⾵⼟ ⾃分の意思 プロダクトの意思 決定に携わりたい ビジネス視点も持 ちたい 前任者の希望 開発に専念したい
14. 14 © Sansan, Inc. なぜプロダクトマネジメントを選んだのか 組織の状況 ⾃分の状況 学⽣時代から強かった プロダクト志向 チャレンジを推進する⾵⼟ ⾃分の意思 プロダクトの意思 決定に携わりたい ビジネス視点も持 ちたい 前任者の希望 開発に専念したい チームのニーズと⾃分のwillが⼀致
15. 失敗と学び
16. 16 © Sansan, Inc. • ユーザーによる編集を制限する機能 ◦ 全体制限→部分制限を可能にした • 編集制限のトリガーは別機能と密に紐づいていた • 対象はBill Oneの核となるエンティティの1つ • 事業判断によって開発が(急に)決まった ◦ 事業判断のため必達の納期が設定されていた ポストモーテム 〜プロジェクト概要〜
17. 17 © Sansan, Inc. 1. 編集制限対象エンティティの全プロパティの編集制限(納期あり) 2. 編集制限トリガーの拡充(納期あり) 3. 編集制限トリガーのレイアウト設定機能の開発(納期あり) 4. 3と並⾏して編集制限の粒度を細かくする開発(納期あり) ポストモーテム 〜時系列〜
18. 18 © Sansan, Inc. 1. 編集制限対象エンティティの全プロパティの編集制限(納期あり) 2. 編集制限トリガーの拡充(納期あり) 3. 編集制限トリガーのレイアウト設定機能の開発(納期あり) 4. 3と並⾏して編集制限の粒度を細かくする開発(納期あり)🔥🔥🔥 ポストモーテム 〜結果〜
19. 19 © Sansan, Inc. • 既存コードが複雑+機能間の密結合 ◦ 既存仕様や背景情報の資料不⾜ • 編集制限対象を管理しているテーブルの分割とコードの分割 • データフローを同期→⾮同期への変更 • ⾮同期処理において ◦ タスクQueueの流量制限超過 ◦ 結果整合がうまく⾏かない ◦ 原因不明の神業連打の考慮不⾜ 原因分析
20. 20 © Sansan, Inc. 左図はTypeScriptでサンプル • 対象エンティティが編集制 限状態を管理 • 全部制限する場合はこれで も問題なかった ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割
21. 21 © Sansan, Inc. 左図はTypeScriptでサンプル • 編集制限管理のクラスを導⼊ ◦ 状態管理の責務分割 • 既存コードへの⾼い導⼊コスト ◦ 開発リソースの圧迫 ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割
22. 22 © Sansan, Inc. 左図はTypeScriptでサンプル • 制限状態管理のクラスを導⼊ ◦ 状態管理の責務分割👍 • 既存コードへの⾼い導⼊コスト ◦ 開発リソースの圧迫👎 ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割
23. 23 © Sansan, Inc. 元々はentityIdと企業Idで編集制限状態を管理 ↓ 編集制限の細分化に伴い複数テーブルに分割+migration ↓ データフローの変更に伴い制限状態反映中のテーブルの作成 テーブルとコードの粒度分割
24. 24 © Sansan, Inc. 元々はentityIdと企業Idで編集制限状態を管理 ↓ 編集制限の細分化に伴い複数複製+migration ↓ データフローの変更に伴い制限中状態のテーブルの作成👎 テーブルとコードの粒度分割
25. 25 © Sansan, Inc. • 編集制限状態とトリガーを 同時に永続化 • 機能間依存を許容した処理 データフローの変更 〜 before 〜
26. 26 © Sansan, Inc. • 機能間依存を減らすため ドメインイベント採⽤ • 状態反映中を表すために ポーリングの実施 データフローの変更 〜 after 〜
27. 27 © Sansan, Inc. • リクエスト数の増加に伴い頻繁にQueueが滞留 • 0.1秒未満の連打が時折起こっていた ◦ 状態不整合が多く起きた原因 ◦ フロントエンドでは対策済み ◦ 原因不明 😡 • ポーリングによりDBのコネクション枯渇 • 複雑な既存コードにより上記の解消が困難 • 不可逆な変更のため、リビジョン変更でも対応が不能になった データフローの変更 〜 何が起きたか 〜
28. 28 © Sansan, Inc. • リクエスト数の増加に伴い頻繁にQueueが滞留 • 0.1秒未満の連打が時折起こっていた ◦ 状態不整合が多く起きた原因 ◦ フロントエンドでは対策済み ◦ 原因不明 😡 • ポーリングによりDBのコネクション枯渇 • 複雑な既存コードにより上記の解消が困難 • 不可逆な変更のため、リビジョン変更でも対応が不能になった データフローの変更 〜 何が起きたか 〜 解消に数ヶ⽉ 😭
29. 29 © Sansan, Inc. • 分割可能なものは最初から分割して永続化 ◦ 後から分割のコストが低い • 機能間依存は極⼒避ける ◦ 障害時の規模が増⼤する • 背景資料や仕様ドキュメントの重要性 ◦ 複雑な仕様の理解や想定外の事態を避けられる 学んだこと
30. 何がよかった?
31. 31 © Sansan, Inc. 良かったこと • 技術負債解消の重要性が事業として教訓となった ◦ この事象は直前の実装だけが原因ではない • 仕様ドキュメントを残す⽂化に繋がった ◦ 属⼈性の排除ができるようになった ◦ 開発プロセス標準化に貢献 • フロントエンドまで波及してリファクタリングが⾏われた ◦ ドメイン境界の不整合が是正された • ステークホルダーも含めた振り返りの実施
32. エンジニアとしのて成⻑
33. 33 © Sansan, Inc. 成⻑したポイント • 上流⼯程といえど技術⼒が重要 ◦ ⼤規模設計について重点的に勉強しました • 副次的に発⽣する考慮事項の知識と経験 ◦ ex) ポーリングにおけるDBコネクション、神業連打etc.. • 精神⼒ ◦ 予想外の挙動がきても慌てなくなった
34. 今後の展望
35. プロダクトオーナーやります
36. 36 © Sansan, Inc. プロダクトオーナーやります • Bill Oneでも初めての取り組み • ⼀定期間PBI開発から離れてプロダクトマネジメントを主軸にします • グループにスクラムを導⼊する⼀貫 • 開発者の強みを活かした仕組み化を⾏いたい • ⼀⽅、いずれ開発業務に戻る予定