チームメンバー爆増！その時に準備したこととその後の成長

DroidKaigi 2024 AfterNight ( https://sansan.connpass.com/event/329244/ )にて発表した内容になります。

Transcript

1. 2024/10/10　中島　遼(はる) チームメンバー爆増！その時に準備した こととその後の成長 @haru2036
2. 目次 • タイミーのAndroidチームの 変遷 • 成長に備えてやったこと • その後のメンバー増加に効 いたこと • まとめ
3. タイミーのAndroidチームの変遷
4. はるが入社したタイミング(2022/12) • 自分含めて3人構成だった • この時点でオンボーディングはかなり丁寧に手厚くしてもらえていたが、 開発体制としてはこれ以上の人数増加に耐えられるかというとちょっと疑問 …くらいの感覚 ◦ Android開発に関するオンボーディング ◦ 組織構造に関するオンボーディング ◦ スクラム開発に関するオンボーディング ◦ etc…
5. そしてやってきた大メンバー増加時代 • 2024/01 に3人同時にAndroidメンバーが入社 • そしてさらに2024/09に2人Androidメンバーが入社 • 最初の3人の時はもともといたメンバー一人につき一人メンティーをつけ、 Androidチーム内で作戦会議をすることに ◦ その結果生まれた施策は次でお話しします
6. 成長に備えてやったこと
7. 成長に備えてやったこと • オンボーディングフローの見直し ◦ 以前のオンボーディングフローをベースに流用が可能なドキュメントテンプレートを作成 ◦ オンボーディングでやっていたことをNotionでチェックリスト化して可視性を強化 • 開発体制の変更 ◦ LADR(Lightweight Architecture Decision Record)を実開発前に書いてレビューするように ▪ LADRはテックリードのレビューを必須とした ◦ READMEをかなり充実した内容に整備した ◦ PRレビューをランダムな複数メンバーで行うようにした • 静的解析の整備 ◦ Spotless, ktlint, CodeClimate, AI Review, etc… ◦ 人力のコメントは労力がかかったり心理的障壁が高い ◦ 瑣末な指摘は機械にやってもらう
8. 実際やってみて 一人当たり一人の新メンバーのオンボーディングをやってみたタイミングでの感 想 • 流用可能なテンプレートのおかげで、メンター側もやることを迷わないでオ ンボできた • チェックリストによって他のメンバーの進み具合も把握でき、それが自分た ちのペースメーカーになった • LADRがあることで、人数が増えたチーム内でも他のメンバーによる変更が なぜされているのかわからないなどの認識齟齬が大幅に軽減できた
9. その後のメンバー増加に効いたこと
10. 2024/09の新メンバーのオンボーディング • メンターの感想 ◦ 「ほぼ全てのフローが流用できた！」 ◦ 「前回のメンバーからのフィードバックを踏まえて修正するだけで済んだ」 • メンティーの感想 ◦ 「オンボにかなり長い期間をかけている、手厚い」 ◦ 「オンボのドキュメントがしっかりしてる、上からやっていくだけでキャッチアップできる しやることが明確になってて良さそう」 ◦ 「いろいろな会の中身もオンボーディングで教えて欲しかった（突然会が始まってしまって わからないことがあった）」 • 以前のメンバー増加タイミングで整備していたことが役に立った • また、2024/01入社メンバーによる開発体験の改善もたくさんあり、すんな りと開発に参加できるようになっていた • 4,5日ほどでPRを出せるくらいの立ち上がりの速さ
11. まとめ
12. まとめ • ある程度の規模のチームから一気にメンバーを増やそうとすると様々な困難 があるが、再利用可能な形でそれに対する対策を整備すると今後の新メン バーのジョインに対しても効果的 • チームのスケールに合わせてLADRのようなドキュメンテーション文化も根 付かせるのが良い • 新しいメンバーを募集するならプラスアルファでこういったアクションも取 るのがおすすめです！
13. ご清聴ありがとうございました