目標設定と習慣化で今よりも一歩生産性を上げる

■ イベント
開発生産性向上の鍵 〜開発者体験・効率・検証改善・リードタイム短縮の実例〜
https://sansan.connpass.com/event/326409/

■ 発表者
技術本部 Bill One Engineering Unit 小松代 紘生

■ Bill Oneエンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. Sansan株式会社 部署 名前 目標設定と習慣化で 今よりも一歩生産性を上げる Bill One Engineering Unit 小松代 紘生
2. 小松代 紘生 (こまつしろ ひろき) Sansan株式会社 Bill One Engineering Unit 新卒でSIerに就職。2023年7月にSansan株式会社へ入社。 インボイス管理サービス Bill Oneの開発を担当。 チームのデリバリーと生産性向上に向き合っている。 最近釣りと料理にハマっており、シロギスを釣って天ぷらを 作っています。
3. 発表のテーマとアジェンダ 発表のテーマ 特に問題なく開発は回っているけれど伸びしろがあるチームで、 生産性を今よりも一歩向上させるには？ アジェンダ 1. 当時のチームの状況と課題 2. 目標設定とアクション検討 3. 目標を達成するための習慣 4. 施策の結果
4. チームの状況と課題
5. チームの状況 Bill Oneの開発スタイル - スクラムのエッセンスを取り入れたアジャイル開発 メンバ構成と状況 - 4名 - このメンバー構成になってから4ヶ月経過 - 混乱期から統一期にちょうど移り変わるフェーズ - 生産性に目を向けられるようになってきた 所属組織の状況 - Bill Oneの急成長を背景に生産性向上を組織目標として掲げていた 形成期 混乱期 統一期 機能期 チームの成長段階を示すタックマンモデル 成 果 時間
6. チームはうまく回っている 現メンバー構成での開発に慣れてきた - チームに開発方針や開発プロセスが浸透 おおむね計画通りにリリースできてる - 全6リリース中、5リリースは計画通り - 計画超過した1件は仕様追加やユーザ側の事情によりリリース延期 品質も良い - 現在のチームになってから発生したインシデントは1件のみ - 昔に作り込まれた潜在バグ
7. 伸びしろはある 生産性が高いかと聞かれたら自信を持って答えられない - 現状の生産性を定量的に測れていない - 定量的な基準や目標がないので比較対象がなく良い悪いの判断ができない 改善施策は単発になりがち - ふりかえりでネクストアクションは決めるもののしばらくすると忘れ去られる 定量的な目標と、達成に向けたアクションを徹底する習慣が必要
8. 目標設定とアクション検討
9. 生産性指標 PRのオープン〜マージまでのリードタイム 定量的な改善の意識づけを目的に据えてミニマムに始める - 顧客に価値が届くまでの生産性(付加価値生産性)が重要である前提に立ちつつ、 まずは意識づけを目的に据えてエンジニアがコントロール可能な指標を選んだ コミットからオープンまでの平均時間は計測対象外 - 個人作業が占める割合が多くチームでカバーできる部分が少ない - チームとして定量的な視点を持ち改善に取り組めるようになることがゴール 計測対象外 ※ Findy Team+ サイクルタイム分析画面より抜粋 Findy Team+ サイクルタイム分析 (https://findy-team.openpage.site/pages/maz1gJOjKQJyBllx5Bt8O0gMC5ddnXGr)
10. 目標値 今よりもリードタイムを半減させ、ひとつ上のレベルを目指す 8.0h 12.0h 12.0h 各フェーズの課題を分析しアクションを決める 目標 現状 ベンチ マーク High 4.0h以上 - 11.0h未満 Medium 9.0h以上 - 22.0h未満 Medium 8.0h以上 - 20.0h未満 ※ 図はFindy Team+ サイクルタイム分析画面より抜粋 ベンチマークの凡例
11. オープンからレビューの平均時間 課題: レビューを後回しにすることで負のスパイラルに陥っている コミット 〜 オープン アプルーブ 〜 マージ レビュー 〜 アプルーブ オープン 〜 レビュー 対象外 レビューを 後回しにする 次のタスクに 着手する レビュー待ちのPR が次々に溜まる レビューが 億劫になる レビューを 優先する すぐに レビュー指摘対応 できる レビュー待ちのPR が溜まらない レビューが 苦にならない レビューを優先するルールにすることで良い循環を生み出す
12. 認識のズレ レビューからアプルーブの平均時間 課題: 認識のズレによってレビュー指摘が増えアプルーブが遅延している コミット 〜 オープン アプルーブ 〜 マージ レビュー 〜 アプルーブ オープン 〜 レビュー 粗い設計を基にタスク分解を するので認識のズレがあっても 気が付けない 認識がずれたまま詳細設計を 行う ※ 詳細設計ではUIコンポーネント設計、APIスキーマ設計、クラス設計、テーブル設計を行っている 実装段階でも認識のズレが残り レビュー指摘が増える タスク分解 詳細設計※ 実装 対象外 ex) モジュール間のkey項目の認識のズレ
13. 認識のズレ レビューからアプルーブの平均時間 解決策: 開発プロセスの見直し&モブプロ推奨で認識のズレを減らす コミット 〜 オープン アプルーブ 〜 マージ レビュー 〜 アプルーブ オープン 〜 レビュー 実装段階でも認識のズレが残り レビュー指摘が増える 詳細設計※1 タスク分解 実装 タスク分解 詳細設計※ 実装 タスク分解前に同期的に 詳細設計レビューを行い 設計の認識を合わせる 詳細設計に基づき細かい粒度で タスク分解を行うことで認識を 合わせる サイズの大きいタスク(5h以上)は モブプロを推奨することで実装 段階でも認識のズレを減らす 認識のズレ 対象外 ※ 詳細設計ではUIコンポーネント設計、APIスキーマ設計、クラス設計、テーブル設計を行っている 粗い設計を基にタスク分解を するので認識のズレがあっても 気が付けない 認識がずれたまま詳細設計を 行う
14. アプルーブからマージの平均時間 課題: 細かな指摘対応と複数アプルーブ待ちでマージできていない コミット 〜 オープン アプルーブ 〜 マージ レビュー 〜 アプルーブ オープン 〜 レビュー 対象外 ex) ex) 細かな指摘の対応 - approveは出ているけれど nitsなどの細かなコメントへの 対応に時間を要している 複数アプルーブ待ち - まだ誰かレビューするかもしれないと いう思い - 複数人がレビューしないとなんとなく 安心できない
15. アプルーブからマージの平均時間 解決策: 別PRへの切り出しと1approveを推奨しすぐにマージできるようにする コミット 〜 オープン アプルーブ 〜 マージ レビュー 〜 アプルーブ オープン 〜 レビュー 対象外 別PRへの切り出し 1approveでマージOK 細かな指摘の対応 - approveは出ているけれど nitsなどの細かなコメントへの 対応に時間を要している 複数アプルーブ待ち - まだ誰かレビューするかもしれないと いう思い - 複数人がレビューしないとなんとなく 安心できない
16. まとめ: 課題に対するアクションと目標値 アクション(=チームのお約束)を浸透させる必要がある 指標 現状 目標値 課題 アクション オープンから レビュー 16.1h (Medium) 8.0h (High) ・レビューが後回しされること による負のスパイラル ・手持ちのタスクが完了したら レビューを優先する レビューから アプルーブ 29.3h (Low) 12.0h (Medium) ・認識のズレによるレビュー指摘 増加 ・大きいサイズのタスクはモブプロ ・開発プロセスの見直し アプルーブから マージ 31.3h (Low) 12.0h (Medium) ・アプルーブ後の指摘対応 ・複数アプルーブ待ち ・細かな指摘対応は別PRへ切り出し ・1approveでマージ可 目標を達成すべく課題に対するアクションを定めた
17. 目標を達成するための習慣
18. お約束・目標・実績の3点セットを毎日確認する お約束だけでは形骸化する。改善を実感できることが重要。 お約束を守れない時もあるがどうすればよいか 朝会で毎日全員で確認する 1. チームのダッシュボードに記載 2. お約束を読み上げ 3. 目標と実績を確認 ※チームのダッシュボードページ (notion)より抜粋
19. お約束を守れなかった時は即座に対応する 目標値を逸脱していたらチーム全員で PRをひとつづつ確認しその場で対応する 即座に対応することでお約束を守る意識が醸成される レビューされていないオープン プルリクのアラートが上がって います デイリープルリクアラート ※チームのslackよりFindy Team+の通知を抜粋 このPRは朝会後に〇〇さんが すぐレビューしましょう！
20. 週次のふりかえりで改善を確認する 長期的な視点での改善を定期的に確認しモチベーションを持続させる リバウンドする時もあるがどうしたらよいか 施策開始 正月休暇 リバウンド ※ Findy Team+ サイクルタイム分析画面より抜粋
21. 原因を分析してお約束を見直す その時々の状況に応じて重視すべきことは変わる 新しいお約束 既存のお約束のブラッシュアップ ※当時のふりかえり(miro)より抜粋
22. 施策の結果
23. リードタイムを改善することができた 目標値を達成し、生産性を定量的に計測し改善する意識も醸成された 8ヶ月後 Before After -62.7% -70.2% -66.5% ※ 画像はFindy Team+ サイクルタイム分析画面より抜粋
24. 1. 生産性向上の指標と目標値を設定 2. 現状の課題を分析しアクションを検討 3. 習慣化 - お約束と目標と実績の3点セットを毎日確認する - 逸脱は即対応する - 週次の振り返りで長期的な視点での改善を確認する - うまくいかないときはお約束を見直す まとめ (生産性を今よりも一歩上げるためのスキーム)
25. 目標設定と習慣化で 昨日の自分を超えていこう
26. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/
28. Appendix
29. Apx1. リードタイムのベンチマーク指標 ベンチマーク コミットからオープン までの平均時間 オープンからレビュー までの平均時間 レビューからアプルーブ までの平均時間 アプルーブからマージ までの平均時間 Elite 17.0h未満 4.0h未満 2.0h未満 3.0h未満 High 17.0h以上 - 48.0h未満 4.0h以上 - 11.0h未満 2.0h以上 - 9.0h未満 3.0h以上 - 8.0h未満 Medium 48.0h以上 - 120.0h未満 11.0h以上 - 25.0h未満 9.0h以上 - 22.0h未満 8.0h以上 - 20.0h未満 Low 120.0h以上 25.0h以上 22.0h以上 20.0h以上 出典: Findy Team+ (https://findy-team.openpage.site/pages/Sg9UP5ZvHrRuT2W6Jj5w1q7kRiN9kMh0#step- ywHTaQ6OsIakOdTuvPVQ5hPsgaAHqvtN)