やっぱり余白が大切だった話

D-Plus Tokyo #12~個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？
https://d-plus.connpass.com/event/346580/
での登壇資料です

Transcript

1. ©KAKEHASHI inc. やっぱり余白が大切だった話 2025年3月13日 松本 明紘 D-Plus Tokyo #12 個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？
2. ©KAKEHASHI inc. 自己紹介 株式会社 カケハシ(2023年2月〜) • AI在庫管理、医薬品のSCM関連の新規事業 • バックエンドに軸足を置くテックリード もっち(@mottyzzz) 松本 明紘 2
3. ©KAKEHASHI inc. 3 本日のテーマ 個人の工夫をチームの力に！ 開発生産性向上の文化づくりどうしてる？
4. ©KAKEHASHI inc. 4 個人の自主的な取り組みによって、 チーム全体の柔軟さや変化への強さを 向上させたい！
5. ©KAKEHASHI inc. 5 話すこと/話さないこと (※1)本日お話する個人のカイゼン活動の定義 エンジニア主体で行っているリファクタリング、緊急性のないライブラリバージョンアップ、古くなったフレームワークの移行、テストの追加、CI/CDの 改善など、直接ロードマップに乗っていない開発や開発プロセス改善のこと。 話すこと • ボトムアップの個人のカイゼン活動(※1) をいかに定着させるか • チームの中で行っている工夫 話さないこと • MVV、目標・評価などのトップダウンの施策
6. ©KAKEHASHI inc. AI在庫管理のチーム構成 職能を横断したフィーチャーチームで、価値提供までをE2Eで開発 PdM デザイナー FE BE 6
7. ©KAKEHASHI inc. 7 AI在庫管理の開発スタイル • スクラムで1週間スプリントで素早くフィードバックを得る • フィーチャーチームごとに担当機能を明確に分け、チーム内でのコンテキスト の共有を徹底 • ストーリーを小さく明確化し、目の前のストーリーの達成に集中できるように する • レビュー待ち時間を作らないよう、モブやペアでの開発を基本とする • フロー効率を優先している
8. ©KAKEHASHI inc. 8 リソース効率とフロー効率(1/3) リソース効率重視 • メンバーの稼働率を100%にすることを重視
9. ©KAKEHASHI inc. 9 リソース効率とフロー効率(2/3) フロー効率重視 • リードタイムを短くすることを重視
10. ©KAKEHASHI inc. 10 リソース効率とフロー効率(3/3) リソース効率重視 • 短期的にはスループットが高い • コンテキストスイッチが発生 • 属人化してしまいボトルネックが発生 フロー効率重視 • リードタイムが短い • 同時にナレッジシェアが行える • 一定の冗長性を保てる https://kakehashi-dev.hatenablog.com/entry/2023/12/02/091000
11. ©KAKEHASHI inc. 11 実際のフロー効率重視の開発(1/2) • Slackの返信、個別のミーティング、個人でできるカイゼンなどによって フロー効率を重視していてもズレがでてくる
12. ©KAKEHASHI inc. 12 実際のフロー効率重視の開発(2/2) • Slackの返信、個別のミーティング、個人でできるカイゼンなどによって フロー効率を重視していてもズレがでてくる
13. ©KAKEHASHI inc. 13 • 想定より時間がかかった、レビュー指摘で修正も必要だった、背景や既存実装 を確認していたらレビューが時間かかった、、、その結果 フロー効率重視のはずがいつの間にかリソース効率重視のような姿に
14. ©KAKEHASHI inc. 14 結果として個人のカイゼン活動を 進めにくくなってしまう
15. ©KAKEHASHI inc. 15 結果として個人のカイゼン活動が進まなくなる • カイゼン含めて優先度を並べればいいが、エンジニアも「ユーザーへの価値提 供」を大事に思っているメンバーが多く、どうしてもカイゼンの優先度のほう が下がってしまう • そのスプリントのメインのゴールの範囲外の対応のレビューをお願いする必要 があり、それが続くとなんとなく悪いことをしているような感じがしてしまう
16. ©KAKEHASHI inc. 16 2つの余白によるアプローチ 計画外の小さな余白を上手に使えるようにする 余白② 計画的なチームの余白を作る 余白①
17. ©KAKEHASHI inc. 17 ①計画的にチームの余白を作る(1/3) スプリントごとに、あとでカイゼンする余白を作る
18. ©KAKEHASHI inc. 18 ①計画的にチームの余白を作る(2/3) ペア・モブでカイゼンをしてもいいし、個人のカイゼン活動に使ってもいい
19. ©KAKEHASHI inc. 19 ①計画的にチームの余白を作る(3/3) 下記のようなワーキングアグリーメントで実際に取り組んでいる • 1週間スプリントの5日目はロードマップの開発は行わない • プランニング時点で１週間の最初の3日で完了するくらいの 余裕をもった計画にする • 想定より早くそのスプリントの開発が完了しとしても、 次の開発項目を始めない
20. ©KAKEHASHI inc. 20 後回しになってしまう課題が 増えなくなってきた
21. ©KAKEHASHI inc. 21 気持ちにも余裕がでてきた
22. ©KAKEHASHI inc. 22 息を吸うように日々のカイゼンが できている状態したい！ でも、もっと
23. ©KAKEHASHI inc. 23 ②計画外の小さな余白を上手に使えるようにする 現実的なプロセスの中で出てきた余白もなんとか上手に使いたい
24. ©KAKEHASHI inc. 24 そんなときに チームに信頼があり、盤石な文化があれば、整頓には レビューは不要だ 整頓はレビューしなくてもよいというレベルの安全と 信頼に到達するには、何ヶ月もかかる。練習しよう。 実験しよう。みんなでエラーをレビューしよう。 https://www.oreilly.co.jp/books/9784814400911/ チーム内で感想会を実施したときにもらえたヒント “ ”
25. ©KAKEHASHI inc. 25 どんなPull Requestだったらレビューなしでいけそうか 小さいPull Request だったらレビュー無しで もいいんじゃない？ Terraformのコードは plan結果が no-changeだったらど んどんやってしまって良 い気がする issue templateとかは やらなくてもいいので は？ テスト通ってる＝挙動が 変わっていないのは必須 だよね そもそも振る舞いを変え ずに整頓する（本来のリ ファクタリング）のにも練 習が必要かも DBマイグレーションみた いな不可逆な変更はダメ だよね それを確かめるために もどんどん練習してい きたい Tidy First?の1部に書 いてあるような変更内容 だったら良いんじゃな い？
26. ©KAKEHASHI inc. 26 実際にこんなルールで取り組みを開始しました 1. PR タイトルのプレフィックスを [Tidy] とつけて分かりやすくする 2. 変更内容が単一である（複数の変更をひとつの PR に含めていない） 3. 修正箇所のテストが存在し、テストが通っている （コメントのみの修正等は除く） 4. アプリケーションの挙動は変わっていないこと 5. 可逆的である （仮に不具合が発生した場合は、この PR を Revert するだけでよい） 6. 不具合が発生するリスクが低い自信を持てている （PR 作成者の自己申告でよい）
27. ©KAKEHASHI inc. 27 周辺コードを触るついでにしか実施してなかった コメントだけの追加やREADMEの拡充などが 進みはじめた
28. ©KAKEHASHI inc. 28 まだレビューがないことに抵抗のあるような メンバーもまだまだいる
29. ©KAKEHASHI inc. 29 チームに信頼があり、盤石な文化があれば、整頓に はレビューは不要だ 整頓はレビューしなくてもよいというレベルの安全と 信頼に到達するには、何ヶ月もかかる。練習しよう。 実験しよう。みんなでエラーをレビューしよう。 https://www.oreilly.co.jp/books/9784814400911/ “ ”
30. ©KAKEHASHI inc. 30 おわりに 計画的なチームの余白を作って、 チームとしてカイゼン活動を！ 計画外の小さな余白を使うために レビューのハードルを下げよう！ チームの信頼と文化を作っていくために 練習しよう。訓練しよう。
31. ©KAKEHASHI inc. やっぱり余白が大切だった話 2025年3月13日 松本 明紘 D-Plus Tokyo #12 個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？