感想
- 普段は生産性に関する取り組みは特別やってないけど、やりたいと思うことやらなくていいやと思うこといろいろあったので参加してよかったです
目標設定と習慣化で今よりも一歩生産性を上げる
- 小松代 紘生さん（Sansan株式会社）
- https://speakerdeck.com/sansantech/sansan-20240829
目標の設定と達成
- 生産性を定量的に測っていなかった
- 現状いいのか悪いのか分からなかった
- 目標の設定
- PRのオープンからマージを指標に
- その中でもオープン/レビュー/approce/マージのステップがある
- 現状の値を測ってその半分を目標にした
- PRのオープンからマージを指標に
- 目標への取り組み
- レビューがたまると進まなくてもっとたまる
- レビューを優先するルールに
- 目標を毎日朝会で確認
bugbashを導入して検証工程をカイゼンした取り組み
- 村上 尭聖さん（株式会社Hacobu）
- https://speakerdeck.com/hacobu/deng-tan-zi-liao-cun-shang-yao-sheng
bugbash
- 職種関係なくみんなでバグ出しをする
- sprintの中盤のデイリー後にやる
- 30〜60分程度
- 不具合だけでなく提案もOK
- 全体の2-4割の不具合はbugbashで検出
- bugbashやってみて
- 仕様把握に時間かかって操作の時間が減る
- 出す人が偏る
- チームを作って対象を絞る
- モブテスト
- 不具合がまとめてあがるので対応もしやすい
開発者体験を意識した開発チームの生産性向上の取り組み
- 浜田 直人さん（ファインディ株式会社）
- https://speakerdeck.com/ham0215/kai-fa-zhe-ti-yan-woyi-shi-sitakai-fa-timunosheng-chan-xing-xiang-shang-noqu-rizu-mi
開発生産性の可視化
- DORA Core Model
- Capabilities
- Performance
- Four Keysも含まれてる
- Outcomes
- 指標が向上しただけではダメでその先の価値につながらないと意味がない
FourKeys
- デプロイ頻度
- 高いほどよい
- 現状の頻度になっている理由を解消しないと意味がない
- フィーチャーフラグ使ったりとかの工夫
- 変更のリードタイム
- 本番に変更が反映されるまでの時間が短いほどいい
- 実装やレビューに時間がかかるとか
- 変更障害率
- 本番に反映した際の障害率が低いほどいい
- 予期せず既存処理を壊してしまうとか
- 平均復旧時間
- 障害発生から復旧までの時間が短いほどいい
- デプロイに時間がかかる
- エラーの特定に時間がかかる
- エラーの検知までに時間がかかる
