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

by MisatoKii

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介紀井美里（きいみさと）経歴新卒でラクス入社楽楽精算に配属楽楽精算の国内開発に従事ラクスベトナムでのオフショア開発に従事多い時は年の4分の1はベトナムに滞在好きなベトナム料理はバインミー現在楽楽精算の国内開発のPM役割 2

Slide 3

Slide 3 text

本日お話すること SaaSを支える開発原則 ● OODAループ ● 心理的安全性 ● 銀の弾丸などない 3つの原則を含み、人が寄せ集まっているだけでチームとして機能していなかった私たちが、 2年間でチーム開発ができるようになった、泥臭いお話をお届けします。 3

Slide 4

Slide 4 text

きっかけ楽楽精算がサービスとして成長ビジネスのスピードと開発量、サービス品質を求められるようになり、国内での開発をスケールアップすることに ● それまでは国内開発はしていたが、個人で開発。子会社のラクスベトナムが発足後、オフショア開発を中心 ● 楽楽精算はチームで開発をするようにシフトしていった 4

Slide 5

Slide 5 text

なんこつ発足楽楽精算開発内でメンバーを3つのグループに分けた ● 砂肝 ● ぼんじり ● なんこつグループ名メンバーが焼き鳥のメインのお肉取りまとめる人を串はれて私は『なんこつの串』となった 5

Slide 6

Slide 6 text

＜本編＞ ● なんこつ発足 Stage1 課題：属人化 ● なんこつ発足 Stage2 課題：メンバー間のコミュニケーション ● なんこつ発足 Stage3 グループからの脱却〜そして、チームになる〜 6

Slide 7

Slide 7 text

＜本編＞ ● なんこつ発足 Stage1 課題：属人化 ● なんこつ発足 Stage2 課題：メンバー間のコミュニケーション ● なんこつ発足 Stage3 グループからの脱却〜そして、チームになる〜 7

Slide 8

Slide 8 text

なんこつ発足 Stage1 メンバー構成私＝なんこつの串→役割 PM メンバー3〜4名 ● 1名は楽楽精算歴 5、6年目エンジニア歴はベテラン ● 2名は楽楽精算歴1年未満の新米 ● 1名は新卒若手もいれば、自分よりキャリアのある人もまとめないといけない 8

Slide 9

Slide 9 text

なんこつ発足 Stage1 まず始めにしたこと ● 進捗MTGは対面で顔を合わせて 1日のうち必ずメンバーとの時間を確保し、課題をキャチアップすることに注力課題は一緒に解決していく ● kptで振り返りそれまで振り返りを行う習慣がなかった開発案件ごとで振り返りを行い、なんこつ内のノウハウの蓄積 9

Slide 10

Slide 10 text

なんこつ発足 Stage1 ＜課題＞ ● コードレビューや第三者テストが串に集中するカンファレンス参加で2日間チームを離れただけでメンバーの開発業務に影響がでてしまう串に集中しているタスクで属人化を排除できるものはないか？ →第三者テストの属人化を排除する 10

Slide 11

Slide 11 text

なんこつ発足 Stage1 ポイントなんこつ内で標準化 ● 楽楽精算の在籍年数が長いメンバーと新しい施策に取り組んでいく →今思えばよき理解者、相談相手がいてとても心強かった ● 困ったことがあれば進捗MTGで相談できる環境を作る ● 属人化の排除、テスト項目書は誰がテストしても同じ品質になるものを作るメンバーの状態に合わせていかにして開発業務を分担していくかに注力した 11

Slide 12

Slide 12 text

なんこつ発足 Stage1 串として気をつけたこと ● 新しい取り組みをしたいなら、言い出した串が先頭に立って動く ● 自分たちに合わなければやめればよいくらいの気軽さで、とりあえずやってみようとメンバーを巻き込んでいく ● なんこつで成果が出たものは砂肝、ぼんじりにも展開その結果、テスト項目書の作成方法は、なんこつで提案した方法が楽楽精算では定着 12

Slide 13

Slide 13 text

＜本編＞ ● なんこつ発足 Stage1 課題：属人化 ● なんこつ発足 Stage2 課題：メンバー間のコミュニケーション ● なんこつ発足 Stage3 グループからの脱却〜そして、チームになる〜 13

Slide 14

Slide 14 text

なんこつ発足 Stage2 メンバーの入れ替わり & 増員メンバー構成 ● 1名は楽楽精算歴 5、6年目エンジニア歴はベテラン★ ● 2名は楽楽精算歴新人エンジニア歴はベテラン ● 1名楽楽精算の運用チームから異動楽楽精算歴3年 ● 2名新卒若手もいれば、自分よりキャリアのある人もまとめないといけないのは相変わらず 14

Slide 15

Slide 15 text

なんこつ発足 Stage2 まず始めにしたこと ● Stage1で標準化したことはメンバーが入れ変わっても継続  対面での進捗MTG  課題は一緒に解決していく  困ったことがあれば進捗MTGで相談できる環境である→新卒でも困ったことがあれば質問する ● ベテランメンバーチームと若手メンバーチームに分けたたまに若手メンバーをベテランチームへ短期留学 ● モブプログラミング新メンバーが増えたので、楽楽精算のコードの暗黙知などを少しでも伝承できないかと始めた 15

Slide 16

Slide 16 text

なんこつ発足 Stage2 ＜課題＞ベテランメンバーチームでの出来事 ● 個人能力が高くスピードが早いメンバーが、一時的に手空きになることが頻繁に起こる →そのたびに調整これまでメンバーにタスクをどう割り振っていたか機能開発の案件ごとにWBSを作成し、メンバー1人1人をアサインする個人個人の能力は高いのに、その能力を集結してもなんだか相乗効果が出てないような気がする 16

Slide 17

Slide 17 text

なんこつ発足 Stage2 現状を観察することから始めた Observe ● メンバーごとにタスクの完了がまばらスケジュールより前倒しで終わる人もいれば、オンスケの人もいる ● タスクには依存関係がある早く終わったメンバーは別のメンバーが対応しているタスクの完了を待つ必要がある 17 OODAループはじまるよ

Slide 18

Slide 18 text

なんこつ発足 Stage2 あることに気づく Orient ● 同じ開発案件を分担しているのに、ほとんどコミュニケーションを取らない個人個人がWBS上でアサインされたものを黙々とやっている 18

Slide 19

Slide 19 text

なんこつ発足 Stage2 決める Decide ● 依存関係を意識させて、手空きにならない状態をメンバー自ら回避するように判断して動いてもらう必然とコミュニケーションを取ることを期待 19

Slide 20

Slide 20 text

なんこつ発足 Stage2 実行 Action タスクを自ら取っていくシステムに変える ● WBSは作成するが、1つのタスクに対してメンバー全員をアサイン →タスクを進めるにはメンバー同士で話し合って決める必要がある →1つのタスクに対して全員を当事者にした ● 細かい判断はメンバーに一任する HOWの部分 ● タスクの優先度は串が決める 20

Slide 21

Slide 21 text

なんこつ発足 Stage2 ● コミュニケーションを取るようになった取らざるを得ない仕組みにしたから ● 最初は楽楽精算歴ベテランメンバーを介してコミュニケーションをとっていた ● 次第に、ベテランメンバーを介さなくてもコミュニケーションをとるようになった 21

Slide 22

Slide 22 text

なんこつ発足 Stage2 ポイント ● 方向性やゴールは示すが手段はメンバーに一任する手段を指定しない串として気をつけたこと ● メンバーを気にしないふりをして、気にしているが串が自らは動かない →ひたすら我慢 22

Slide 23

Slide 23 text

＜本編＞ ● なんこつ発足 Stage1 課題：属人化 ● なんこつ発足 Stage2 課題：メンバー間のコミュニケーション ● なんこつ発足 Stage3 グループからの脱却〜そして、チームになる〜 23

Slide 24

Slide 24 text

なんこつ発足 Stage3 OODA 2ループ目現状を観察することから始めた Observe 日々の進捗報告を受けるくらいで、意識的に観察していたわけではない....... 24 OODAループ、おかわりいくよ

Slide 25

Slide 25 text

なんこつ発足 Stage3 あることに気づく Orient メンバー1人1人のスキルに特徴がある。しかも被っていない。→非常にバランスが良いことに気づく ● 多少取りこぼしがあるが、スピードが速いスピードで取りこぼしをカバーできる ● 慎重で丁寧。見過ごされた小さな違和感を拾うバグをよく発見する ● これまでの経験から楽楽精算を幅広く理解しているオールラウンダー 25

Slide 26

Slide 26 text

なんこつ発足 Stage3 決める Decide ● 新規開発案件に着手する一番初めだけ、タスクへのアサイン順をメンバーの特徴によって変えてみるメンバーの特徴を生かして、適材適所で相乗効果を期待した 26

Slide 27

Slide 27 text

なんこつ発足 Stage3 実行 Action ● スピードが速いメンバーを1番に投入し、懸念点など探索してもらい、不確実性を減らす大枠をとらえ難易度や工数の見積もりの妥当性を測る ● 慎重で丁寧なメンバーを投入し、スピード重視で取りこぼしが起きている部分があった場合に検知してもらう ● 全体を把握しているメンバーがバランスをとる 27

Slide 28

Slide 28 text

なんこつ発足 Stage3 適材適所で相乗効果を発揮 ● 個の集まりだったのが自ら状況を判断して動くチームへと変わっていった指示をしなくてもメンバーの提案ベースで進んでいく ● 不確実な部分を最初にある程度洗い出せるため、見積もりが実績ベースで正確、期限を守れる心理的安全性とメンバーの自主性 ● スケジュールや優先度の都合で見送ったリファクタリングなど、ちょっとした隙間に改善活動をするようになった 28 そういえば、XXってどうなりましたっけ？ XXはマージしました！

Slide 29

Slide 29 text

SaaSを支える開発原則に当てはめる OODAループ ● メンバーの行動をみながら、状況を判断する、決める、実行するを繰り返す ● 自分たちに合うところを見出す ● チームは常に変化し続けることを前提に、フィット感がなくなれば、いい塩梅にフィットするところを探せばよい 29

Slide 30

Slide 30 text

SaaSを支える開発原則に当てはめる心理的安全性 ● 串や中心メンバーがチームメンバーの前で困ってることをさらけ出す ● チームの中心メンバーの振る舞いがチームメンバーの心理的なハードルを下げていく ● 任せると決めたことは最後まで任せる ● メンバーの提案を尊重する 30

Slide 31

Slide 31 text

SaaSを支える開発原則に当てはめる銀の弾丸などない ● 物事が上手く行くときは、様々な要素がからみてあっている ● その時の一つ一つ課題に向き合い、解消し積み上げていく ● その積み上げが一定以上を超えた瞬間に、一気に目に見える成果となる 31

Slide 32

Slide 32 text

最後に ●チーム作りにマニュアルはない ●メンバーを一人一人をみて、うまくフィットするところを見つける 32

Slide 33

Slide 33 text

ご清聴ありがとうございました 33