1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断

■イベント
【Sansan Tech Meetup マネジメント編 #1】
1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断
https://sansan.connpass.com/event/238006/
ㅤ
■登壇概要
登壇者：Bill One Unit プロダクト開発責任者​ / 大西 真央
「請求書受領から、月次決算を加速する」をコンセプトに2020年 5月にローンチしたクラウド請求書受領サービス「Bill One」。その事業成長を支えるエンジニアリング組織は、直近の1年で5人から30人と急激にメンバーが増えました。
本発表では、組織拡大の過程を振り返るとともに、エンジニア部門のマネジャーがその渦中でどのような課題に向き合い、どのようなことを考え、どのような判断をしたのか。プロダクトグロースの中でのエンジニア組織の変遷と、具体的な取り組み例をご紹介します。
ㅤ
▼EventReport
https://buildersbox.corp-sansan.com/entry/2022/03/07/110000
　
▼Sansan Engineering
https://jp.corp-sansan.com/engineering/

Transcript

1. 1年で6倍にメンバーが急増した エンジニアリング組織の変遷と判断 【 S a n s a n Te c h M e e t u p 】 M a n a g e m e n t # 1 Sansan株式会社 Bill One Unit プロダクト開発責任者 大西 真央
2. SEとしてエンジニアのキャリアをスタートさせ、2012年以降はアジャイルやDDDなどの開発スタイルを経験。 2016年にSansanに入社し、クラウド名刺管理サービス「Sansan」の大阪開発拠点を立ち上げ後、チーフエンジ ニアリングマネジャーとしてエンジニアの組織作りを担当。 2020年以降は新規事業開発部門に移り、エンジニアリング組織の立ち上げと、クラウド請求書受領サービス「Bill One」の立ち上げに携わる。プロダクトマネジメントから開発マネジメントまで、幅広い経験を持つ。 大西 真央 Sansan 株式会社 Bill One Unit プロダクト開発責任者
4. 会社概要 3 社 名 Sansan株式会社 所 在 地 表参道本社 東京都渋谷区神宮前5-52-2 青山オーバルビル13F グ ル ー プ 会 社 Sansan Global PTE. LTD.（シンガポール） Sansan Corporation（アメリカ） ログミー株式会社 従 業 員 数 1036名（2021年11月30日時点） 表参道本社 神山ラボ Sansan Innovation Lab 2007年6月11日 設 立 支店：大阪、名古屋 サテライトオフィス：徳島、京都、福岡、北海道、新潟 拠 点 寺田 親弘 代 表 者
5. Sansan – 働き方を変えるDX – 4 新世代エントリーフォーム 新世代パンフレット 全文書き起こしメディア 名寄せエンジン Sansan Data Hub ピアボーナスサービス クラウド契約業務サービス クラウド請求書受領サービス スマート受付 無人名刺受付システム 名刺作成サービス セミナー管理システム クラウド名刺管理サービス スマート署名取り込み AI名刺管理 オンライン名刺 同僚コラボレーション メール配信 イベント・セミナー 請求書 名刺 契約書 組織コミュニケーション 名刺印刷・発注 データ活用 反社チェックオプション powered by Refinitiv/KYCC 契約管理オプション for クラウドサイン 商談管理オプション for Salesforce アンケートオプション powered by CREATIVE SURVEY powered by MotionBoard 名刺分析オプション 業務連携
6. Agenda - チェックイン - 立ち上げ期 - 拡大期 - 急拡大に向き合い始めた時の課題 - 初めてのチーム分割 - 拡大ピーク時の悩みと解決方法 急増したエンジニアリング組織の変遷と判断
7. チェックイン
8. 請求書受領から、月次決算を加速する
9. 体制 カスタマーサクセス デザイナー エンジニア セールス マーケティング 顧客開発チーム PdM PMM プロダクト開発チーム
10. MRR推移 0 0 5 9 20 34 61 20/05 20/08 20/11 21/02 21/05 21/08 21/11 (百万円) ローンチ タイミング 約12倍 前年同期比
11. エンジニアのメンバー推移 4 5 5 5 11 19 27 33 1 1 1 1 2 5 6 6 20/05 20/08 20/11 21/02 21/05 21/08 21/11 22/02 人数 チーム数 約6倍 人数、チーム数共に 前年同期比
12. エンジニアのメンバー推移 立ち上げ期 拡大期 底上げ期 4 5 5 5 11 19 27 33 1 1 1 1 2 5 6 6 20/05 20/08 20/11 21/02 21/05 21/08 21/11 22/02 人数 チーム数 約6倍 人数、チーム数共に 前年同期比
13. 立ち上げ期
14. 少数精鋭部隊で PMFに向けて 事業を立ち上げている状態 立ち上げ期
15. 振り返り リリース リファインメント ・デモ リリース リファインメント ・デモ プランニング 開発プロセス 毎週 月曜 火曜 水曜 木曜 金曜 金曜
16. 顧客への価値を最短で提供し、顧客からのフィードバックで プロダクトを成長させる - 全役割がプロダクトのより良い体験にコミットするような コミュニケーションを実施する - ビジネス状況に応じて、最適なストーリーを開発する - 安全な環境で素早くリリースする 大切にしていた考え
17. 拡大期
18. PMFに手応えを感じ プロダクトを爆速成長させるために エンジニアを急拡大させている状態 拡大期
19. 拡大期の流れ 拡大に 向き合い始める 初めての チーム分割 拡大のピーク
20. 拡大期の流れ 拡大に 向き合い始める 初めての チーム分割 拡大のピーク
21. 急拡大に向き合い始めた時の課題 その1 約半年程度で5名→30名に急拡大させた経験がなく 半年後の組織構造が見えず漠然な不安
22. 約半年程度で5名→30名に急拡大させた経験がなく 半年後の組織構造が見えず漠然な不安 急拡大に向き合い始めた時の課題 その1 事業成長率低下リスクと組織崩壊リスクを天秤にかけ 自身でコントロールできない事業成長率低下リスクを 回避するためエンジニア急増の覚悟を決める
23. 急拡大に向き合い始めた時の課題 その2 Sansan = 名刺のイメージが強く、Bill Oneに応募が来ない
24. Sansan = 名刺のイメージが強く、Bill Oneに応募が来ない 急拡大に向き合い始めた時の課題 その2 登壇・エンジニアブログ・スカウト・採用イベントなど あらゆる手段を使ってカジュアル面談の回数を増やす
25. 急拡大に向き合い始めた時の課題 その2 Sansan = 名刺のイメージが強く、Bill Oneに応募が来ない 登壇・エンジニアブログ・スカウト・採用イベントなど あらゆる手段を使ってカジュアル面談の回数を増やす ピーク月はカジュアル面談・面接等も含めると 80H/月くらいの工数が掛かっていたので どれだけのパワーで採用に向き合うかを エンジニアメンバーで共通認識を持つことが大事
26. 急拡大に向き合い始めた時の課題 その3 ドキュメントがなく動くコードで会話する
27. ドキュメントがなく動くコードで会話する esaを導入して、ドキュメントに残す環境を用意 全体方針や機能単位など粒度の大小問わずドキュメントに残す 急拡大に向き合い始めた時の課題 その3
28. ドキュメントがなく動くコードで会話する esaを導入して、ドキュメントに残す環境を用意 全体方針や機能単位など粒度の大小問わずドキュメントに残す 急拡大に向き合い始めた時の課題 その3 ドキュメントの考え方を設定することも大事 • 「対話をなくす」ではなく、ドキュメントをきっかけに対話しよう • 最初から完全を求めない • メンテナンス対象のディレクトリとスナップショットのディレクトリを 決める
29. 急拡大に向き合い始めた時の課題 その4 全員で常に会話できる状態だったため あうんの呼吸で開発
30. 目指す文化を定義して 組織内で成果に繋がる考え方を揃える 全員で常に会話できる状態だったため あうんの呼吸で開発 急拡大に向き合い始めた時の課題 その4
31. 事業成果を最優先に各自が主体的に行動し、成長し、一体感を強く持つ文化 - 相談を重ねて、自ら最終判断をする - エッセンシャル思考 - 早期フィードバック - 学習思考 - 情報はオープンに共有 - 信頼マネジメント 急拡大に向き合い始めた時の課題 その4
32. - ドキュメント整備は早い段階で着手してよかった - ドキュメントの存在により、人数が増えるごとに複利で効果を発揮する - ドキュメント文化が出来上がるまでは、推進者にリードしてもらう - 急拡大の組織マネジメントでは文化を基準に考えることが多い - 「相談を重ねて、自らが最終判断をする」という考え方に何度も救われた 急拡大に向き合い始めた時の課題を今振り返ってみて
33. 拡大期の流れ 拡大に 向き合い始める 初めての チーム分割 拡大のピーク
34. - 2021/05/01(3名増)の11名になるタイミングで分割を実施 - ただ、既存メンバーだけで構成されているうちに 分割リハーサルを実施して、分割後の戸惑いをなくす - メリット - チーム内で相談するハードルが下がった。MTG人数減により時間の短縮した。 - 結果として、開発時間が増えた。 - デメリット - 他チームの意思決定に関われない。コードのレビュー依頼先が少ない。 初めてのチーム分割
35. - 各種イベント（朝会やデモ等）で全員参加 or チーム単位を決める - チームで機能の担当領域は区切らない - 期待する役割がなかったため、チームにリーダーは用意しない - チーム単独でユーザー価値を届けることが可能なチームとする - 設計・実装でチーム外メンバーへの相談が必要な場合は積極的に実施する - リリース当日は各チーム主導者を決めて、主導者達で推進する 初めてのチーム分割で最終的に決めたこと
36. 拡大期の流れ 拡大に 向き合い始める 初めての チーム分割 拡大のピーク
37. 拡大ピーク時の悩みと解決方法 その1 コミュニケーションがチームに閉じ始めサイロ化を懸念 全メンバーでより良い組織にしていく方法を模索
38. 全エンジニアに参加してもらい 毎月OST（オープンスペーステクノロジー）を実施 拡大ピーク時の悩みと解決方法 その1 コミュニケーションがチームに閉じ始めサイロ化を懸念 全メンバーでより良い組織にしていく方法を模索
39. 拡大ピーク時の悩みと解決方法 その1 時期 OSTで話し合ったテーマ 2021/07 - 最高のエンジニア集団とは？ - フロントエンドのディレクトリ構造の見直し - とある機能領域のリファクタ案 2021/08 - 自走できる開発者の定義とどうしたら自走できるのか。 - 新しいマイクロサービスを作る上での苦労話 - 速度優先開発で何を捨てて何を拾ってる？ 2021/09 - Bill Oneが大切にする技術の考え方をブラッシュアップする - リリースフロー・プロセスをアップグレードしたい - セキュリティチェックの負荷を軽減したい 2021/10 - テスト戦略としてドメインのテストが足りてないのでは？ - ドメイン知識のキャッチアップ方法 - 現在のルールや風習などで、どれくらいのエンジニアまで耐えれるか？ - 受入プロセスをブラッシュアップする
40. OSTをきっかけに有志で集まって改善できた取り組み - エンジニア増によるリリースフローの最適化 - 毎月実施するライブラリのバージョンアップを推進する体制を確立 - フロントエンドのディレクトリ構造のリファクタ - リリース後に実施するプロトタイプへの反映を楽にする改善 - プロダクトダッシュボードの爆誕(DAU/MAUや請求書枚数など) - 運用改善ダッシュボードの爆誕(エラー件数や運用負荷など) 拡大ピーク時の悩みと解決方法 その1
41. 拡大ピーク時の悩みと解決方法 その2 フラットな組織の弊害が出始める 開発責任者のボトルネックや密度が薄い状態での会話
42. チーム内に正式な役割を定義 拡大ピーク時の悩みと解決方法 その2 フラットな組織の弊害が出始める 開発責任者のボトルネックや密度が薄い状態での会話
43. 拡大ピーク時の悩みと解決方法 その2 役割 責務 アサイン プロジェクトリード - リソース/リリース管理 - 開発プロセス管理 - メンバーのメンタリング 立候補 テクニカルリード - バックエンドの相談役 - 組織全体のアーキテクチャ検討 バックエンドに強い人 プロダクトリード - 各ストーリーに対して定義された課題・ ニーズ等からを開発Readyにする 立候補
44. 拡大ピーク時の悩みと解決方法 その2 権限委譲により チームで意思決定できる幅を広げ、開発スピードを加速させる 役割 責務 アサイン プロジェクトリード - リソース/リリース管理 - 開発プロセス管理 - メンバーのメンタリング 立候補 テクニカルリード - バックエンドの相談役 - 組織全体のアーキテクチャ検討 バックエンドに強い人 プロダクトリード - 各ストーリーに対して定義された課題・ ニーズ等からを開発Readyにする 立候補
45. 拡大ピーク時の悩みと解決方法 その2 同じ役割内で密度の濃いコミュニケーションを実施して 組織全体・メンバーの成長に繋げる 役割 責務 アサイン プロジェクトリード - リソース/リリース管理 - 開発プロセス管理 - メンバーのメンタリング 立候補 テクニカルリード - バックエンドの相談役 - 組織全体のアーキテクチャ検討 バックエンドに強い人 プロダクトリード - 各ストーリーに対して定義された課題・ ニーズ等からを開発Readyにする 立候補
46. 拡大ピーク時の悩みと解決方法 その2 任命ではなく立候補制にしたことにより チャレンジできる環境を用意してモチベーション高い人に権限委譲する 役割 責務 アサイン プロジェクトリード - リソース/リリース管理 - 開発プロセス管理 - メンバーのメンタリング 立候補 テクニカルリード - バックエンドの相談役 - 組織全体のアーキテクチャ検討 バックエンドに強い人 プロダクトリード - 各ストーリーに対して定義された課題・ ニーズ等からを開発Readyにする 立候補
47. 拡大ピーク時の悩みと解決方法 その3 5人時代から進化していない開発プロセスへの不安
48. 拡大ピーク時の悩みと解決方法 その3 5人時代から進化していない開発プロセスへの不安 LeSS(Large Scale Scrum)を参考に開発プロセスをアップデート
49. 拡大ピーク時の悩みと解決方法 その3 5人時代から進化していない開発プロセスへの不安 LeSS(Large Scale Scrum)を参考に開発プロセスをアップデート LeSSの原理原則とルールがBill Oneの考え方に近しいとわかったので 50名くらいまでは現状のままで大丈夫と自信を得た
50. 拡大ピーク時の悩みと解決方法 その4 チーム数が増加したことで チーム毎に担当領域を決めて開発するようになり 各チームで自走するための情報が必要
51. 開発責任者から事業全体への所感を届け続け 各チームへはラブレターを記入することにより チームの存在意義や期待値を言語化 拡大ピーク時の悩みと解決方法 その4 チーム数が増加したことで チーム毎に担当領域を決めて開発するようになり 各チームで自走するための情報が必要
52. 3カ月ごとに組織のフェーズが変わるので 過去の成功体験に固執せず ちょっと先の未来を見据えて 変化を恐れず挑戦していくことが大切 拡大期を振り返り
53. 底上げ期
54. MRR約12倍成長の事業を支える エンジニアリング組織作りの“いま”と“目指す未来” 次回イベント でお話します。
55. まとめ
56. まとめ - 急拡大に向き合う時は、短期目線だと開発スピードが落ちるため、 中長期目線で物事を考えることが重要 - 初めてチーム分割に向き合う際は、必要なタイミングの一歩手前で リハーサルを実施して、感触を確かめることが重要 - チーム最適ではなく、組織最適(全体最適)を重視 - 20名を超えた辺りから密度の濃いコミュニケーションを実施するためには 役割定義は必要 - 変化を恐れず挑戦していくことが大切
57. We are hiring！ 新規事業開発 WEBアプリ開発エンジニア PdM（プロダクトマネジャー） コーポレート コーポレートIT セキュリティエンジニア （SOC、社内教育・内部監査） ブランディング・マーケティング フロントエンドエンジニア 研究開発 研究員 帳票のデータ化技術 , 名寄せ技術 メール分析技術 , 機械学習 自然言語処理 , OCR技術開発 新規プロダクト開発 効果検証,因果推論 データ分析基盤開発 R&D DevOps/MLOpsエンジニア データアナリスト シニアリサーチャー インフラエンジニア WEBアプリ開発エンジニア サービス開発 エンジニアリングマネジャー アーキテクト Site Reliabilityエンジニア QAエンジニア、SET インフラエンジニア iOS/Android エンジニア WEBアプリ開発エンジニア 56
58. カジュアル面談 「もう少し話を聞いてみたい」という方は、カジュアル面談でお話しましょう。
59. エンジニア情報サイト「Sansan Engineering」 58 ・Sansanエンジニアのミッション ・プロダクト、テクノロジー概要 ・エンジニアインタビュー ・技術スタック ・働く環境、社内制度 ・募集職種 ・Blog ・イベント情報 ... and more Sansan Engineering Sansanのプロダクトやテクノロジー、カルチャー、採用情報など、エンジニアリングに関するあらゆる情報を掲載 https://jp.corp-sansan.com/engineering/