Tweet
Tweet

Slide 1

Slide 1 text

エンジニアとして プロダクトマネジメントに 向き合った1年半 Sansan株式会社 Bill One Engineering Unit 阿左⾒ 蓮 23卒＆中途⼊社1年⽬エンジニアのリアル：経験とこれからの展望

Slide 2

Slide 2 text

⾃⼰紹介

Slide 3

Slide 3 text

3 © Sansan, Inc. ⾃⼰紹介 ● name: 阿左⾒ 蓮 ● age: 24 ● affiliation: ○ BIll One Engineering Unit ■ Core Business UM Group ○ 23卒 ● intern: フルコミ営業→エンジニア ● job: フルスタック(?)なエンジニア

Slide 4

Slide 4 text

4 © Sansan, Inc. ● Bill Oneについて ● プロダクトマネジメントを始めた経緯 ● 失敗事例と学び ● 何がよかったか ● エンジニアとして成⻑したポイント ● これからについて Agenda

Slide 5

Slide 5 text

Bill Oneについて

Slide 6

Slide 6 text

© Sansan, Inc. ※⽉次決算業務 毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。 Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。 郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書を クラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法に も対応し、⽉次決算業務を効率化することで、企業経営における意思決定のスピードを加速します。 6

Slide 7

Slide 7 text

© Sansan, Inc. 請求書 発⾏ 経費 精算 請求書 受領 ⽉次決算を加速する 7

Slide 8

Slide 8 text

© Sansan, Inc. Bill Oneの成⻑ 出典: 2025年5月期通期 決算説明資料 ※ Monthly Recurring Revenue（月次固定収入） 8 リリース4年超でARRは93億円超、契約件数は3,310社

Slide 9

Slide 9 text

© Sansan, Inc. Bill OneのARR（年間固定収⼊）推移 9 リリースから約4年超、T2D3※を超える成⻑速度を⾒せている ※ サービスをスタートしてからの売上額が、前年を基準として毎年3倍・3倍・2倍・2倍・2倍と上昇し、5年間で72倍の売上成⻑を⽬指すという意味。 理想的なSaaSの成⻑モデルとされる。

Slide 10

Slide 10 text

プロダクトマネジメントを始めた経緯

Slide 11

Slide 11 text

© Sansan, Inc. 3L体制 チームで意思決定できる幅を広げ、開発スピードを加速させる取り組み 役割名 責務 ATL (アジャイルチームリード) • ⾃⼰組織化されたアジャイルチームの確⽴を推進 • 継続的なリーダーシップ / 計画 / 実⾏ / リスク低減 / 改 善 PdL (プロダクトリード) • 仕様や要件の整理 • ATL・PdM・デザイナーとの調整 ※ すべてのPdLはPdMがまとめる TL (テクニカルリード) • コード品質を担保 • チームの技術⼒向上 • ロジックが集中するバックエンドの相談役 ※これらは役職ではなくチーム内の分担としての役割 気軽にチャレンジして 伸ばしたいスキルにフォーカスできる環境づくり 副次的効果として 11

Slide 12

Slide 12 text

© Sansan, Inc. 3L体制 チームで意思決定できる幅を広げ、開発スピードを加速させる取り組み 役割名 責務 ATL (アジャイルチームリード) • ⾃⼰組織化されたアジャイルチームの確⽴を推進 • 継続的なリーダーシップ / 計画 / 実⾏ / リスク低減 / 改 善 PdL (プロダクトリード) • 仕様や要件の整理 • ATL・PdM・デザイナーとの調整 ※ すべてのPdLはPdMがまとめる TL (テクニカルリード) • コード品質を担保 • チームの技術⼒向上 • ロジックが集中するバックエンドの相談役 ※これらは役職ではなくチーム内の分担としての役割 気軽にチャレンジして 伸ばしたいスキルにフォーカスできる環境づくり 副次的効果として 12

Slide 13

Slide 13 text

13 © Sansan, Inc. なぜプロダクトマネジメントを選んだのか 組織の状況 ⾃分の状況 学⽣時代から強かった プロダクト志向 チャレンジを推進する⾵⼟ ⾃分の意思 プロダクトの意思 決定に携わりたい ビジネス視点も持 ちたい 前任者の希望 開発に専念したい

Slide 14

Slide 14 text

14 © Sansan, Inc. なぜプロダクトマネジメントを選んだのか 組織の状況 ⾃分の状況 学⽣時代から強かった プロダクト志向 チャレンジを推進する⾵⼟ ⾃分の意思 プロダクトの意思 決定に携わりたい ビジネス視点も持 ちたい 前任者の希望 開発に専念したい チームのニーズと⾃分のwillが⼀致

Slide 15

Slide 15 text

失敗と学び

Slide 16

Slide 16 text

16 © Sansan, Inc. ● ユーザーによる編集を制限する機能 ○ 全体制限→部分制限を可能にした ● 編集制限のトリガーは別機能と密に紐づいていた ● 対象はBill Oneの核となるエンティティの1つ ● 事業判断によって開発が(急に)決まった ○ 事業判断のため必達の納期が設定されていた ポストモーテム 〜プロジェクト概要〜

Slide 17

Slide 17 text

17 © Sansan, Inc. 1. 編集制限対象エンティティの全プロパティの編集制限(納期あり) 2. 編集制限トリガーの拡充(納期あり) 3. 編集制限トリガーのレイアウト設定機能の開発(納期あり) 4. 3と並⾏して編集制限の粒度を細かくする開発(納期あり) ポストモーテム 〜時系列〜

Slide 18

Slide 18 text

18 © Sansan, Inc. 1. 編集制限対象エンティティの全プロパティの編集制限(納期あり) 2. 編集制限トリガーの拡充(納期あり) 3. 編集制限トリガーのレイアウト設定機能の開発(納期あり) 4. 3と並⾏して編集制限の粒度を細かくする開発(納期あり)🔥🔥🔥 ポストモーテム 〜結果〜

Slide 19

Slide 19 text

19 © Sansan, Inc. ● 既存コードが複雑+機能間の密結合 ○ 既存仕様や背景情報の資料不⾜ ● 編集制限対象を管理しているテーブルの分割とコードの分割 ● データフローを同期→⾮同期への変更 ● ⾮同期処理において ○ タスクQueueの流量制限超過 ○ 結果整合がうまく⾏かない ○ 原因不明の神業連打の考慮不⾜ 原因分析

Slide 20

Slide 20 text

20 © Sansan, Inc. 左図はTypeScriptでサンプル ● 対象エンティティが編集制 限状態を管理 ● 全部制限する場合はこれで も問題なかった ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割

Slide 21

Slide 21 text

21 © Sansan, Inc. 左図はTypeScriptでサンプル ● 編集制限管理のクラスを導⼊ ○ 状態管理の責務分割 ● 既存コードへの⾼い導⼊コスト ○ 開発リソースの圧迫 ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割

Slide 22

Slide 22 text

22 © Sansan, Inc. 左図はTypeScriptでサンプル ● 制限状態管理のクラスを導⼊ ○ 状態管理の責務分割👍 ● 既存コードへの⾼い導⼊コスト ○ 開発リソースの圧迫👎 ※ Bill OneのバックエンドはKotlin テーブルとコードの粒度分割

Slide 23

Slide 23 text

23 © Sansan, Inc. 元々はentityIdと企業Idで編集制限状態を管理 ↓ 編集制限の細分化に伴い複数テーブルに分割+migration ↓ データフローの変更に伴い制限状態反映中のテーブルの作成 テーブルとコードの粒度分割

Slide 24

Slide 24 text

24 © Sansan, Inc. 元々はentityIdと企業Idで編集制限状態を管理 ↓ 編集制限の細分化に伴い複数複製+migration ↓ データフローの変更に伴い制限中状態のテーブルの作成👎 テーブルとコードの粒度分割

Slide 25

Slide 25 text

25 © Sansan, Inc. ● 編集制限状態とトリガーを 同時に永続化 ● 機能間依存を許容した処理 データフローの変更 〜 before 〜

Slide 26

Slide 26 text

26 © Sansan, Inc. ● 機能間依存を減らすため ドメインイベント採⽤ ● 状態反映中を表すために ポーリングの実施 データフローの変更 〜 after 〜

Slide 27

Slide 27 text

27 © Sansan, Inc. ● リクエスト数の増加に伴い頻繁にQueueが滞留 ● 0.1秒未満の連打が時折起こっていた ○ 状態不整合が多く起きた原因 ○ フロントエンドでは対策済み ○ 原因不明 😡 ● ポーリングによりDBのコネクション枯渇 ● 複雑な既存コードにより上記の解消が困難 ● 不可逆な変更のため、リビジョン変更でも対応が不能になった データフローの変更 〜 何が起きたか 〜

Slide 28

Slide 28 text

28 © Sansan, Inc. ● リクエスト数の増加に伴い頻繁にQueueが滞留 ● 0.1秒未満の連打が時折起こっていた ○ 状態不整合が多く起きた原因 ○ フロントエンドでは対策済み ○ 原因不明 😡 ● ポーリングによりDBのコネクション枯渇 ● 複雑な既存コードにより上記の解消が困難 ● 不可逆な変更のため、リビジョン変更でも対応が不能になった データフローの変更 〜 何が起きたか 〜 解消に数ヶ⽉ 😭

Slide 29

Slide 29 text

29 © Sansan, Inc. ● 分割可能なものは最初から分割して永続化 ○ 後から分割のコストが低い ● 機能間依存は極⼒避ける ○ 障害時の規模が増⼤する ● 背景資料や仕様ドキュメントの重要性 ○ 複雑な仕様の理解や想定外の事態を避けられる 学んだこと

Slide 30

Slide 30 text

何がよかった?

Slide 31

Slide 31 text

31 © Sansan, Inc. 良かったこと ● 技術負債解消の重要性が事業として教訓となった ○ この事象は直前の実装だけが原因ではない ● 仕様ドキュメントを残す⽂化に繋がった ○ 属⼈性の排除ができるようになった ○ 開発プロセス標準化に貢献 ● フロントエンドまで波及してリファクタリングが⾏われた ○ ドメイン境界の不整合が是正された ● ステークホルダーも含めた振り返りの実施

Slide 32

Slide 32 text

エンジニアとしのて成⻑

Slide 33

Slide 33 text

33 © Sansan, Inc. 成⻑したポイント ● 上流⼯程といえど技術⼒が重要 ○ ⼤規模設計について重点的に勉強しました ● 副次的に発⽣する考慮事項の知識と経験 ○ ex) ポーリングにおけるDBコネクション、神業連打etc.. ● 精神⼒ ○ 予想外の挙動がきても慌てなくなった

Slide 34

Slide 34 text

今後の展望

Slide 35

Slide 35 text

プロダクトオーナーやります

Slide 36

Slide 36 text

36 © Sansan, Inc. プロダクトオーナーやります ● Bill Oneでも初めての取り組み ● ⼀定期間PBI開発から離れてプロダクトマネジメントを主軸にします ● グループにスクラムを導⼊する⼀貫 ● 開発者の強みを活かした仕組み化を⾏いたい ● ⼀⽅、いずれ開発業務に戻る予定

Slide 37

Slide 37 text

No content