生産性が上がり続けるチームを作るための第一歩

by KazukiHayase

Slide 1

Slide 1 text

生産性が上がり続けるチームを作るための第一歩【開発生産性 Meetup #1】開発生産性可視化による変化~事例LTから学ぶベストプラクティス~ 2023.04.26

Slide 2

Slide 2 text

自己紹介名前：早瀬和輝経歴：BuySell Technologiesに2021年に新卒入社所属：開発2部出品管理SaaSチーム役職：フルスタックエンジニア、プロジェクトリーダー趣味：開発、マンガ、アニメ、ベース、バスケ Twitter：@KazukiHayase

Slide 3

Slide 3 text

アジェンダはじめに 01 過去の開発体制とチームの課題 02 立ち止まりと振り返り 03 振り返り後の開発生産性 04 まとめ 05

Slide 4

Slide 4 text

01 はじめに

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

出品管理チームに所属

Slide 7

Slide 7 text

チーム体制と開発生産性合計 11 名のチームでスクラムで開発 EM （1名） PdM （1名）デザイナー（1名）エンジニア（8名）

Slide 8

Slide 8 text

一人当たり1日平均3PR作成コミットからマージまで平均12.2h

Slide 9

Slide 9 text

チームのベストプラクティス ● PRの差分は60行以内に収める ● PRのレビューはどんなに遅くても2時間以内に行う ● スクラムイベント、PRのレビューは全員参加 ● 全員フルスタックに開発

Slide 10

Slide 10 text

これらのベストプラクティスを実践し生産性の高いチームになるために最初にやったこと今日の話すこと 01

Slide 11

Slide 11 text

02 過去の開発体制とチームの課題

Slide 12

Slide 12 text

直近1年半の開発生産性の推移

Slide 13

Slide 13 text

直近1年半の開発生産性の推移ここの話

Slide 14

Slide 14 text

当時の開発体制① BE 領域で担当者が別れており、自分は両方を担当 FE 業務委託

Slide 15

Slide 15 text

当時の課題① ● フロントエンドの属人化 ● BE・FE間のコミュニケーションコストが高い ● タスクの依存関係により作業が進められない ● FEのタスクを用意して指示する作業が必要

Slide 16

Slide 16 text

当時の開発体制② リソース効率重視で人にタスクをアサインしていた

Slide 17

Slide 17 text

当時の課題② かなり属人化していたので、詰まっても誰もヘルプに入れない

Slide 18

Slide 18 text

当時の課題② ● 共通認識がないので実装もレビューもリードタイムが長くなる ● 目先の実装を優先した結果、手戻りが頻発する ● タスクが個人に委ねられているので進捗が見えづらい

Slide 19

Slide 19 text

03 立ち止まりと振り返り

Slide 20

Slide 20 text

立ち止まりと振り返り前述した課題についてはチームメンバー各々が感じていた一度立ち止まって、チームの課題と目的の整理を実施

Slide 21

Slide 21 text

チーム内で課題と目的を設定

Slide 22

Slide 22 text

話し合った結果理想のチームの状態を実現するために、本格的にスクラムを導入新しい取り組みに置ける、一時的な生産性の低下もチーム内で合意

Slide 23

Slide 23 text

取り組み始めの開発生産性一時的に低下

Slide 24

Slide 24 text

04 振り返り後の開発生産性

Slide 25

Slide 25 text

振り返り後の開発生産性 ● PRの差分は60行以内に収める ● PRのレビューはどんなに遅くても2時間以内に行う ● スクラムイベント、PRのレビューは全員参加 ● 全員フルスタックに開発改善を繰り返す中でベストプラクティスが生まれた

Slide 26

Slide 26 text

その他の取り組み生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話リファイメントとプランニングを改善することで、チームの属人化が解消された話

Slide 27

Slide 27 text

振り返り後の開発生産性爆上がり

Slide 28

Slide 28 text

フロントエンドのタスク不足 ● FEのテックリードとして新メンバーがjoin ● 直近で優先度の高いFEのタスクが無くなったその後のチームの課題と解決策異動前のチームとのギャップ ● スクラム未採用のチームから新メンバーがjoin ● チームの開発の進め方に疑問を感じていた ○ e.g. スプリントプランニングなどMtgが多いバックエンドをやってみよう！とりあえずやってみよう！

Slide 29

Slide 29 text

過去の経験を踏まえて下記のような選択肢は採用しなかった ● 単独でFEのタスクを進める ● プランニングを省略する ● 人にタスクをアサインする過去の失敗経験から学んだ上での意思決定

Slide 30

Slide 30 text

直近の開発生産性開発生産性は上がり続けている

Slide 31

Slide 31 text

全体の流れなんちゃってスクラム本格的にスクラム導入 + 生産性向上新規メンバー加入さらなる生産性向上立ち止まり + 振り返り生産性の低い状態に戻ることを防いだ

Slide 32

Slide 32 text

全体の流れなんちゃってスクラム本格的にスクラム導入 + 生産性向上新規メンバー加入さらなる生産性向上立ち止まり + 振り返りここで立ち止まり課題と目的の共通理解を作ったからこそ生産性を上げ続けられている

Slide 33

Slide 33 text

05 まとめ

Slide 34

Slide 34 text

まとめ ● 一度立ち止まることで、結果的に生産性の高いチームになれた ● 最初に課題と目的を明確にして、共通の理解を持つことが重要 ○ できればログを残して、いつでも立ち戻れるように