rakus-meetup-tokyo-5-from-dev-group-to-dev-team

Transcript

1. ©2020 RAKUS Co., Ltd. 開発グループが開発チームにな るまでの歩み
2. 自己紹介 紀井 美里（きい みさと） 経歴 新卒でラクス入社 楽楽精算に配属 楽楽精算の国内開発に従事 ラクスベトナムでのオフショア開発に従事 多い時は年の4分の1はベトナムに滞在 好きなベトナム料理はバインミー 現在 楽楽精算の国内開発のPM役割 2
3. 本日お話すること SaaSを支える開発原則 • OODAループ • 心理的安全性 • 銀の弾丸などない 3つの原則を含み、人が寄せ集まっているだけでチームとして機能していなかった私たちが、 2年間でチーム開発ができるようになった、泥臭いお話をお届けします。 3
4. きっかけ 楽楽精算がサービスとして成長 ビジネスのスピードと開発量、サービス品質を求められるようになり、国内での開発をスケールア ップすることに • それまでは国内開発はしていたが、個人で開発。子会社のラクスベトナムが発足後、オフ ショア開発を中心 • 楽楽精算はチームで開発をするようにシフトしていった 4
5. なんこつ発足 楽楽精算開発内でメンバーを3つのグループに分けた • 砂肝 • ぼんじり • なんこつ グループ名 メンバーが焼き鳥のメインのお肉 取りまとめる人を串 はれて私は『なんこつの串』となった 5
6. ＜本編＞ • なんこつ発足 Stage1 課題：属人化 • なんこつ発足 Stage2 課題：メンバー間のコミュニケーション • なんこつ発足 Stage3 グループからの脱却 〜そして、チームになる〜 6
7. ＜本編＞ • なんこつ発足 Stage1 課題：属人化 • なんこつ発足 Stage2 課題：メンバー間のコミュニケーション • なんこつ発足 Stage3 グループからの脱却 〜そして、チームになる〜 7
8. なんこつ発足 Stage1 メンバー構成 私＝なんこつの串→役割 PM メンバー3〜4名 • 1名は楽楽精算歴 5、6年目 エンジニア歴はベテラン • 2名は楽楽精算歴1年未満の新米 • 1名は新卒 若手もいれば、自分よりキャリアのある人もまとめないといけない 8
9. なんこつ発足 Stage1 まず始めにしたこと • 進捗MTGは対面で顔を合わせて 1日のうち必ずメンバーとの時間を確保し、課題をキャチアップすることに注力 課題は一緒に解決していく • kptで振り返り それまで振り返りを行う習慣がなかった 開発案件ごとで振り返りを行い、なんこつ内のノウハウの蓄積 9
10. なんこつ発足 Stage1 ＜課題＞ • コードレビューや第三者テストが串に集中する カンファレンス参加で2日間チームを離れただけでメンバーの開発業務に影響がでてしまう 串に集中しているタスクで属人化を排除できるものはないか？ →第三者テストの属人化を排除する 10
11. なんこつ発足 Stage1 ポイント なんこつ内で標準化 • 楽楽精算の在籍年数が長いメンバーと新しい施策に取り組んでいく →今思えばよき理解者、相談相手がいてとても心強かった • 困ったことがあれば進捗MTGで相談できる環境を作る • 属人化の排除、テスト項目書は誰がテストしても同じ品質になるものを作る メンバーの状態に合わせていかにして開発業務を分担していくかに注力した 11
12. なんこつ発足 Stage1 串として気をつけたこと • 新しい取り組みをしたいなら、言い出した串が先頭に立って動く • 自分たちに合わなければやめればよいくらいの気軽さで、とりあえずやってみようとメンバーを 巻き込んでいく • なんこつで成果が出たものは砂肝、ぼんじりにも展開 その結果、テスト項目書の作成方法は、なんこつで提案した方法が楽楽精算では定着 12
13. ＜本編＞ • なんこつ発足 Stage1 課題：属人化 • なんこつ発足 Stage2 課題：メンバー間のコミュニケーション • なんこつ発足 Stage3 グループからの脱却 〜そして、チームになる〜 13
14. なんこつ発足 Stage2 メンバーの入れ替わり & 増員 メンバー構成 • 1名は楽楽精算歴 5、6年目 エンジニア歴はベテラン★ • 2名は楽楽精算歴新人 エンジニア歴はベテラン • 1名楽楽精算の運用チームから異動 楽楽精算歴3年 • 2名新卒 若手もいれば、自分よりキャリアのある人もまとめないといけないのは相変わらず 14
15. なんこつ発足 Stage2 まず始めにしたこと • Stage1で標準化したことはメンバーが入れ変わっても継続  対面での進捗MTG  課題は一緒に解決していく  困ったことがあれば進捗MTGで相談できる環境である→新卒でも困ったことがあれば質問する • ベテランメンバーチームと若手メンバーチームに分けた たまに若手メンバーをベテランチームへ短期留学 • モブプログラミング 新メンバーが増えたので、楽楽精算のコードの暗黙知などを少しでも伝承できないかと始めた 15
16. なんこつ発足 Stage2 ＜課題＞ベテランメンバーチームでの出来事 • 個人能力が高くスピードが早いメンバーが、一時的に手空きになることが頻繁に起こる →そのたびに調整 これまでメンバーにタスクをどう割り振っていたか 機能開発の案件ごとにWBSを作成し、メンバー1人1人をアサインする 個人個人の能力は高いのに、その能力を集結してもなんだか 相乗効果が出てないような気がする 16
17. なんこつ発足 Stage2 現状を観察することから始めた Observe • メンバーごとにタスクの完了がまばら スケジュールより前倒しで終わる人もいれば、オンスケの人もいる • タスクには依存関係がある 早く終わったメンバーは別のメンバーが対応しているタスクの完了を待つ必要がある 17 OODAループ はじまるよ
18. なんこつ発足 Stage2 あることに気づく Orient • 同じ開発案件を分担しているのに、ほとんどコミュニケーションを取らない 個人個人がWBS上でアサインされたものを黙々とやっている 18
19. なんこつ発足 Stage2 決める Decide • 依存関係を意識させて、手空きにならない状態をメンバー自ら回避するように判断して動 いてもらう 必然とコミュニケーションを取ることを期待 19
20. なんこつ発足 Stage2 実行 Action タスクを自ら取っていくシステムに変える • WBSは作成するが、1つのタスクに対してメンバー全員をアサイン →タスクを進めるにはメンバー同士で話し合って決める必要がある →1つのタスクに対して全員を当事者にした • 細かい判断はメンバーに一任する HOWの部分 • タスクの優先度は串が決める 20
21. なんこつ発足 Stage2 • コミュニケーションを取るようになった 取らざるを得ない仕組みにしたから • 最初は楽楽精算歴ベテランメンバーを介してコミュニケーションをとっていた • 次第に、ベテランメンバーを介さなくてもコミュニケーションをとるようになった 21
22. なんこつ発足 Stage2 ポイント • 方向性やゴールは示すが手段はメンバーに一任する 手段を指定しない 串として気をつけたこと • メンバーを気にしないふりをして、気にしているが串が自らは動かない →ひたすら我慢 22
23. ＜本編＞ • なんこつ発足 Stage1 課題：属人化 • なんこつ発足 Stage2 課題：メンバー間のコミュニケーション • なんこつ発足 Stage3 グループからの脱却 〜そして、チームになる〜 23
24. なんこつ発足 Stage3 OODA 2ループ目 現状を観察することから始めた Observe 日々の進捗報告を受けるくらいで、意識的に観察していたわけではない....... 24 OODAループ、 おかわりいくよ
25. なんこつ発足 Stage3 あることに気づく Orient メンバー1人1人のスキルに特徴がある。しかも被っていない。→非常にバランスが良いことに気 づく • 多少取りこぼしがあるが、スピードが速い スピードで取りこぼしをカバーできる • 慎重で丁寧。見過ごされた小さな違和感を拾う バグをよく発見する • これまでの経験から楽楽精算を幅広く理解している オールラウンダー 25
26. なんこつ発足 Stage3 決める Decide • 新規開発案件に着手する一番初めだけ、タスクへのアサイン順をメンバーの特徴によって 変えてみる メンバーの特徴を生かして、適材適所で相乗効果を期待した 26
27. なんこつ発足 Stage3 実行 Action • スピードが速いメンバーを1番に投入し、懸念点など探索してもらい、不確実性を減らす 大枠をとらえ難易度や工数の見積もりの妥当性を測る • 慎重で丁寧なメンバーを投入し、スピード重視で取りこぼしが起きている部分があった場 合に検知してもらう • 全体を把握しているメンバーがバランスをとる 27
28. なんこつ発足 Stage3 適材適所で相乗効果を発揮 • 個の集まりだったのが自ら状況を判断して動くチームへと変わっていった 指示をしなくてもメンバーの提案ベースで進んでいく • 不確実な部分を最初にある程度洗い出せるため、見積もりが実績ベースで正確、期限を守 れる 心理的安全性とメンバーの自主性 • スケジュールや優先度の都合で見送ったリファクタリングなど、ちょっとした隙間に改善活動をす るようになった 28 そういえば、XXってどうな りましたっけ？ XXはマージしました！
29. SaaSを支える開発原則に当てはめる OODAループ • メンバーの行動をみながら、状況を判断する、決める、実行するを繰り返す • 自分たちに合うところを見出す • チームは常に変化し続けることを前提に、フィット感がなくなれば、いい塩梅にフィットすると ころを探せばよい 29
30. SaaSを支える開発原則に当てはめる 心理的安全性 • 串や中心メンバーがチームメンバーの前で困ってることをさらけ出す • チームの中心メンバーの振る舞いがチームメンバーの心理的なハードルを下げていく • 任せると決めたことは最後まで任せる • メンバーの提案を尊重する 30
31. SaaSを支える開発原則に当てはめる 銀の弾丸などない • 物事が上手く行くときは、様々な要素がからみてあっている • その時の一つ一つ課題に向き合い、解消し積み上げていく • その積み上げが一定以上を超えた瞬間に、一気に目に見える成果となる 31
32. 最後に •チーム作りにマニュアルはない •メンバーを一人一人をみて、うまくフィットするところを 見つける 32
33. ご清聴ありがとうございました 33