生産性が上がり続けるチームを作るための第一歩【開発生産性 Meetup #1】開発生産性可視化による変化~事例LTから学ぶベストプラクティス~2023.04.26
View Slide
自己紹介名前:早瀬和輝経歴:BuySell Technologiesに2021年に新卒入社所属:開発2部 出品管理SaaSチーム役職:フルスタックエンジニア、プロジェクトリーダー趣味:開発、マンガ、アニメ、ベース、バスケTwitter:@KazukiHayase
アジェンダはじめに01過去の開発体制とチームの課題02立ち止まりと振り返り03振り返り後の開発生産性04まとめ05
01はじめに
出品管理チームに所属
チーム体制と開発生産性合計 11 名のチームでスクラムで開発EM(1名)PdM(1名)デザイナー(1名)エンジニア(8名)
一人当たり1日平均3PR作成コミットからマージまで平均12.2h
チームのベストプラクティス● PRの差分は60行以内に収める● PRのレビューはどんなに遅くても2時間以内に行う● スクラムイベント、PRのレビューは全員参加● 全員フルスタックに開発
これらのベストプラクティスを実践し生産性の高いチームになるために最初にやったこと今日の話すこと01
02過去の開発体制とチームの課題
直近1年半の開発生産性の推移
直近1年半の開発生産性の推移ここの話
当時の開発体制①BE領域で担当者が別れており、自分は両方を担当FE業務委託
当時の課題①● フロントエンドの属人化● BE・FE間のコミュニケーションコストが高い● タスクの依存関係により作業が進められない● FEのタスクを用意して指示する作業が必要
当時の開発体制②リソース効率重視で人にタスクをアサインしていた
当時の課題②かなり属人化していたので、詰まっても誰もヘルプに入れない
当時の課題②● 共通認識がないので実装もレビューもリードタイムが長くなる● 目先の実装を優先した結果、手戻りが頻発する● タスクが個人に委ねられているので進捗が見えづらい
03立ち止まりと振り返り
立ち止まりと振り返り前述した課題についてはチームメンバー各々が感じていた一度立ち止まって、チームの課題と目的の整理を実施
チーム内で課題と目的を設定
話し合った結果理想のチームの状態を実現するために、本格的にスクラムを導入新しい取り組みに置ける、一時的な生産性の低下もチーム内で合意
取り組み始めの開発生産性一時的に低下
04振り返り後の開発生産性
振り返り後の開発生産性● PRの差分は60行以内に収める● PRのレビューはどんなに遅くても2時間以内に行う● スクラムイベント、PRのレビューは全員参加● 全員フルスタックに開発改善を繰り返す中でベストプラクティスが生まれた
その他の取り組み生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話 リファイメントとプランニングを改善することで、チームの属人化が解消された話
振り返り後の開発生産性爆上がり
フロントエンドのタスク不足● FEのテックリードとして新メンバーがjoin● 直近で優先度の高いFEのタスクが無くなったその後のチームの課題と解決策異動前のチームとのギャップ● スクラム未採用のチームから新メンバーがjoin● チームの開発の進め方に疑問を感じていた○ e.g. スプリントプランニングなどMtgが多いバックエンドをやってみよう! とりあえずやってみよう!
過去の経験を踏まえて下記のような選択肢は採用しなかった● 単独でFEのタスクを進める● プランニングを省略する● 人にタスクをアサインする過去の失敗経験から学んだ上での意思決定
直近の開発生産性開発生産性は上がり続けている
全体の流れなんちゃってスクラム本格的にスクラム導入+生産性向上新規メンバー加入さらなる生産性向上立ち止まり+振り返り生産性の低い状態に戻ることを防いだ
全体の流れなんちゃってスクラム本格的にスクラム導入+生産性向上新規メンバー加入さらなる生産性向上立ち止まり+振り返りここで立ち止まり課題と目的の共通理解を作ったからこそ生産性を上げ続けられている
05まとめ
まとめ● 一度立ち止まることで、結果的に生産性の高いチームになれた● 最初に課題と目的を明確にして、共通の理解を持つことが重要○ できればログを残して、いつでも立ち戻れるように