Slide 1

Slide 1 text

Sansan株式会社 部署 名前 ⾃律的なチームを⽀える 仕組み「3L」 Sansan技術本部 ローンチ4年でARR70億を達成するための エンジニアリング組織の取り組み Bill One Engineering Unit ⼩式澤 篤

Slide 2

Slide 2 text

写真が入ります ⼩式澤 篤 (Atsushi Koshikizawa) Sansan株式会社 技術本部 Bill One Engineering Unit 2022年に BtoC 業界から Sansan へ中途⼊社。⼊社以来 Web アプリ ケーション開発エンジニアとして Bill One の開発に従事。 現在は Bill One における請求書受領領域の開発に加えて、 Bill One 全体の品質向上に向き合っている。 @lastarrow21 @lasta

Slide 3

Slide 3 text

Sansanの働き⽅を変えるDXサービス 営業を強くするデータベース 営業DXサービス 請求書受領から、⽉次決算を加速する インボイス管理サービス 経理DX 営業DX 契約DX その他の提供サービス ピアボーナスサービス 契約データベースが、ビジネスを強くする 契約DXサービス 設⽴年 2007年6⽉ 資本⾦ 65億82百万円 (2023年5⽉31⽇時点) 事業 働き⽅を変えるDXサービスの 企画・開発・販売 東京証券取引所 プライム市場 上場証券取引所 表参道本社 Sansan パラシオ 関⻄⽀店 福岡⽀店 中部⽀店 拠点 第三者機関認証の 取得状況 ISO/IEC 27001(ISMS) ISO/IEC 27017 JIS Q 15001(Pマーク) SOC2 Type1 2

Slide 4

Slide 4 text

- 組織におけるチームの役割 - ⾃律的なチームを⽀える仕組み 3L - 3L 体制を取ることにより得られる効果 今⽇お話したいこと

Slide 5

Slide 5 text

組織におけるチームの役割

Slide 6

Slide 6 text

1. フィードバック等からプロダクトバックログアイテム (PBI) を起票する ○ 営業 / CS / エンジニア等問わず全ての⼈がフィードバックし PdM が起票する 2. PBI で解決したい課題とゴールを詳細化し、概算⼯数を⾒積る ○ プロダクトマネジャー (PdM) 、デザイナー、エンジニアが⾏う 3. PBI 間の優先度を決める ○ PdM が中⼼となって⾏う 4. 優先度に基づき担当デザイナーと開発チームを決める ○ PdM + デザイナー、または PdM + エンジニアで⾏う 5. 開発する ○ デザイナーとエンジニアが⾏う Bill One における開発の流れ

Slide 7

Slide 7 text

1. フィードバック等からプロダクトバックログアイテム (PBI) を起票する ○ 営業 / CS / エンジニア等問わず全ての⼈がフィードバックし PdM が起票する 2. PBI で解決したい課題とゴールを詳細化し、概算⼯数を⾒積る ○ プロダクトマネジャー (PdM) 、デザイナー、エンジニアが⾏う 3. PBI 間の優先度を決める ○ PdM が中⼼となって⾏う 4. 優先度に基づき担当デザイナーと開発チームを決める ○ PdM + デザイナー、または PdM + エンジニアで⾏う 5. 開発する ○ デザイナーとエンジニアが⾏う Bill One における開発の流れ エンジニアはほぼすべての フェーズで関わる

Slide 8

Slide 8 text

1. フィードバック等からプロダクトバックログアイテム (PBI) を起票する ○ 営業 / CS / エンジニア等問わず全ての⼈がフィードバックし PdM が起票する 2. PBI で解決したい課題とゴールを詳細化し、概算⼯数を⾒積る ○ プロダクトマネジャー (PdM) 、デザイナー、エンジニアが⾏う 3. PBI 間の優先度を決める ○ PdM が中⼼となって⾏う 4. 優先度に基づき担当デザイナーと開発チームを決める ○ PdM + デザイナー、または PdM + エンジニアで⾏う 5. 開発する ○ デザイナーとエンジニアが⾏う Bill One における開発の流れ 開発は個⼈ではなく チームで⾏う

Slide 9

Slide 9 text

⾃律的なチームを⽀える仕組み 3L

Slide 10

Slide 10 text

の前に

Slide 11

Slide 11 text

- チームリーダー 1名 + チームメンバー数名 - チームリーダーは以下の責務を持つ - PdM やデザイナーとともにプロジェクトのゴールを明確化する - プロジェクトの進捗状況を管理し対外的に説明可能にする - 開発における技術選定や外部設計の中⼼となる よくある (※) 開発チームの構成 ※ 発表者の経験則に基づく主観

Slide 12

Slide 12 text

- PdM やデザイナーとともにプロジェクトのゴールを明確化する - プロダクトの未来を⾒据えた機能設計を⾏う - 継続的な価値提供を⾒据え MVP (※) を選定する - プロジェクトの進捗状況を管理し対外的に説明可能にする - フロー効率を意識したチーム内の交通整理を⾏う - メンバーの成⻑機会を確保する - 開発における技術選定や外部設計の中⼼となる - ⾼度な技術知識や設計⼒を発揮する - プロダクトの品質を担保する 各責務の難しさの例 ※ MVP (Minimum Viable Product) : 必要最⼩限の製品 (機能)

Slide 13

Slide 13 text

- リーダーに責務が⼀極集中する - リーダーは外部調整等で会議が集中する - メンバーの挑戦機会が減り主体的に動きづらくなる - リーダーの難易度が⾼いため⼈を集めにくくなる - 責務の複雑性が⾼いため漠然と課題が発⽣した際の原因の特定が難しくなる - …… プロジェクト開発以外の課題

Slide 14

Slide 14 text

⾃律的なチームを⽀える仕組み 3L

Slide 15

Slide 15 text

チームで意思決定し、開発スピードを加速させる取り組み 3L 役割名 責務 PdL (プロダクトリード) - 仕様や要件の整理 - ATL, PdM, デザイナーとの調整 ※ すべての PdL は PdM がまとめる ATL (アジャイルチームリード) - チームパフォーマンス最⼤化のために、アジリティの⾼いチームづくりをリード - 上記のための、透明性の維持、検査の実施、適応の促進を推進 TL (テクニカルリード) - コード品質の担保 - チームの技術⼒の向上 - ロジックが集中するバックエンド開発の相談役 - これらは役職ではなくチーム内での役割 - それぞれがチームを「引っ張る」のではなく「押し上げる」役割であるという意味をこめて 「リード」という単語を採⽤

Slide 16

Slide 16 text

- チームリーダー 1名 + チームメンバー数名 - チームリーダーは以下の責務を持つ - PdM やデザイナーとともにプロジェクトのゴールを明確化する - プロジェクトの進捗状況を管理し対外的に説明可能にする - 開発における技術選定や外部設計の中⼼となる よくある (※) 開発チームの構成 (再掲) ※ 発表者の経験則に基づく主観

Slide 17

Slide 17 text

- チームリーダー 1名 + チームメンバー数名 - チームリーダーは以下の責務を持つ - PdM やデザイナーとともにプロジェクトのゴールを明確化する → PdL - プロジェクトの進捗状況を管理し対外的に説明可能にする → ATL - 開発における技術選定や外部設計の中⼼となる → TL よくある (※) 開発チームの構成 (再掲) と Bill One での分担 ※ 発表者の経験則に基づく主観 チームリーダーの各責務を 3L それぞれで分担

Slide 18

Slide 18 text

- リーダーに責務が⼀極集中する - リーダーは外部調整等で会議が集中する - メンバーの挑戦機会が減り主体的に動きづらくなる - リーダーの難易度が⾼いため⼈を集めにくくなる - 責務の複雑性が⾼いため漠然と課題が発⽣した際の原因の特定が難しくなる - …… プロジェクト開発以外の課題 (再掲)

Slide 19

Slide 19 text

- リーダーに責務が⼀極集中する - リーダーは外部調整等で会議が集中する → 3L で分散 - メンバーの挑戦機会が減り主体的に動きづらくなる → 挑戦機会の向上 - リーダーの難易度が⾼いため⼈を集めにくくなる → 3L のいずれかに挑戦 - 責務の複雑性が⾼いため漠然と課題が発⽣した際の原因の特定が難しくなる → 3L に分解され複雑性を低減 - …… プロジェクト開発以外の課題 (再掲) と 3L 体制による解決

Slide 20

Slide 20 text

- 責務が分解されることにより - 気軽にチャレンジ可能になる - 伸ばしたいスキルにフォーカスできるようになる - 各チームそれぞれに 3L がいることにより - 同じ L 同⼠で⾼め合い、各チームにフィードバック可能になる - チームを横断するような施策を細かく打ちやすくなる - 責務が定義されていることにより - メンバーの挑戦意欲の尊重と組織構成のバランスを取りやすくなる 3L 体制を取ることによる副次的な効果

Slide 21

Slide 21 text

- 責務が分解されることにより - 気軽にチャレンジ可能になる - 伸ばしたいスキルにフォーカスできるようになる - 各チームそれぞれに 3L がいることにより - 同じ L 同⼠で⾼め合い、各チームにフィードバック可能になる - チームを横断するような施策を細かく打ちやすくなる - 挑戦しやすくなることにより - 成⻑機会と組織構成のバランスを取りやすくなる 3L 体制を取ることによる副次的な効果 ⾃律的なチームを ⽬指しやすくなる

Slide 22

Slide 22 text

まとめ

Slide 23

Slide 23 text

- 組織におけるチームの役割 - 開発メンバーは多くのフェーズで関わっている - ⾃律的なチームを⽀える仕組み 3L - PdL, ATL, TL の3つの責務に分散しチーム開発を⽀えている - 3L 体制を取ることにより得られる効果 - 挑戦機会が向上するとともに、より⾃律的なチームを⽬指しやすくなる まとめ

Slide 24

Slide 24 text

No content