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

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. やっぱり余白が大切だった話 2025年3月13日松本明紘 D-Plus Tokyo #12 個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？

Slide 2

Slide 2 text

©KAKEHASHI inc. 自己紹介株式会社カケハシ(2023年2月〜) ● AI在庫管理、医薬品のSCM関連の新規事業 ● バックエンドに軸足を置くテックリードもっち(@mottyzzz) 松本明紘 2

Slide 3

Slide 3 text

©KAKEHASHI inc. 3 本日のテーマ個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？

Slide 4

Slide 4 text

©KAKEHASHI inc. 4 個人の自主的な取り組みによって、チーム全体の柔軟さや変化への強さを向上させたい！

Slide 5

Slide 5 text

©KAKEHASHI inc. 5 話すこと/話さないこと (※1)本日お話する個人のカイゼン活動の定義エンジニア主体で行っているリファクタリング、緊急性のないライブラリバージョンアップ、古くなったフレームワークの移行、テストの追加、CI/CDの改善など、直接ロードマップに乗っていない開発や開発プロセス改善のこと。話すこと ● ボトムアップの個人のカイゼン活動(※1) をいかに定着させるか ● チームの中で行っている工夫話さないこと ● MVV、目標・評価などのトップダウンの施策

Slide 6

Slide 6 text

©KAKEHASHI inc. AI在庫管理のチーム構成職能を横断したフィーチャーチームで、価値提供までをE2Eで開発 PdM デザイナー FE BE 6

Slide 7

Slide 7 text

©KAKEHASHI inc. 7 AI在庫管理の開発スタイル ● スクラムで1週間スプリントで素早くフィードバックを得る ● フィーチャーチームごとに担当機能を明確に分け、チーム内でのコンテキストの共有を徹底 ● ストーリーを小さく明確化し、目の前のストーリーの達成に集中できるようにする ● レビュー待ち時間を作らないよう、モブやペアでの開発を基本とする ● フロー効率を優先している

Slide 8

Slide 8 text

©KAKEHASHI inc. 8 リソース効率とフロー効率(1/3) リソース効率重視 ● メンバーの稼働率を100%にすることを重視

Slide 9

Slide 9 text

©KAKEHASHI inc. 9 リソース効率とフロー効率(2/3) フロー効率重視 ● リードタイムを短くすることを重視

Slide 10

Slide 10 text

©KAKEHASHI inc. 10 リソース効率とフロー効率(3/3) リソース効率重視 ● 短期的にはスループットが高い ● コンテキストスイッチが発生 ● 属人化してしまいボトルネックが発生フロー効率重視 ● リードタイムが短い ● 同時にナレッジシェアが行える ● 一定の冗長性を保てる https://kakehashi-dev.hatenablog.com/entry/2023/12/02/091000

Slide 11

Slide 11 text

©KAKEHASHI inc. 11 実際のフロー効率重視の開発(1/2) ● Slackの返信、個別のミーティング、個人でできるカイゼンなどによってフロー効率を重視していてもズレがでてくる

Slide 12

Slide 12 text

©KAKEHASHI inc. 12 実際のフロー効率重視の開発(2/2) ● Slackの返信、個別のミーティング、個人でできるカイゼンなどによってフロー効率を重視していてもズレがでてくる

Slide 13

Slide 13 text

©KAKEHASHI inc. 13 ● 想定より時間がかかった、レビュー指摘で修正も必要だった、背景や既存実装を確認していたらレビューが時間かかった、、、その結果フロー効率重視のはずがいつの間にかリソース効率重視のような姿に

Slide 14

Slide 14 text

©KAKEHASHI inc. 14 結果として個人のカイゼン活動を進めにくくなってしまう

Slide 15

Slide 15 text

©KAKEHASHI inc. 15 結果として個人のカイゼン活動が進まなくなる ● カイゼン含めて優先度を並べればいいが、エンジニアも「ユーザーへの価値提供」を大事に思っているメンバーが多く、どうしてもカイゼンの優先度のほうが下がってしまう ● そのスプリントのメインのゴールの範囲外の対応のレビューをお願いする必要があり、それが続くとなんとなく悪いことをしているような感じがしてしまう

Slide 16

Slide 16 text

©KAKEHASHI inc. 16 2つの余白によるアプローチ計画外の小さな余白を上手に使えるようにする余白② 計画的なチームの余白を作る余白①

Slide 17

Slide 17 text

©KAKEHASHI inc. 17 ①計画的にチームの余白を作る(1/3) スプリントごとに、あとでカイゼンする余白を作る

Slide 18

Slide 18 text

©KAKEHASHI inc. 18 ①計画的にチームの余白を作る(2/3) ペア・モブでカイゼンをしてもいいし、個人のカイゼン活動に使ってもいい

Slide 19

Slide 19 text

©KAKEHASHI inc. 19 ①計画的にチームの余白を作る(3/3) 下記のようなワーキングアグリーメントで実際に取り組んでいる ● 1週間スプリントの5日目はロードマップの開発は行わない ● プランニング時点で１週間の最初の3日で完了するくらいの余裕をもった計画にする ● 想定より早くそのスプリントの開発が完了しとしても、次の開発項目を始めない

Slide 20

Slide 20 text

©KAKEHASHI inc. 20 後回しになってしまう課題が増えなくなってきた

Slide 21

Slide 21 text

©KAKEHASHI inc. 21 気持ちにも余裕がでてきた

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

©KAKEHASHI inc. 24 そんなときにチームに信頼があり、盤石な文化があれば、整頓にはレビューは不要だ整頓はレビューしなくてもよいというレベルの安全と信頼に到達するには、何ヶ月もかかる。練習しよう。実験しよう。みんなでエラーをレビューしよう。 https://www.oreilly.co.jp/books/9784814400911/ チーム内で感想会を実施したときにもらえたヒント “ ”

Slide 25

Slide 25 text

©KAKEHASHI inc. 25 どんなPull Requestだったらレビューなしでいけそうか小さいPull Request だったらレビュー無しでもいいんじゃない？ Terraformのコードは plan結果が no-changeだったらどんどんやってしまって良い気がする issue templateとかはやらなくてもいいのでは？テスト通ってる＝挙動が変わっていないのは必須だよねそもそも振る舞いを変えずに整頓する（本来のリファクタリング）のにも練習が必要かも DBマイグレーションみたいな不可逆な変更はダメだよねそれを確かめるためにもどんどん練習していきたい Tidy First?の1部に書いてあるような変更内容だったら良いんじゃない？

Slide 26

Slide 26 text

©KAKEHASHI inc. 26 実際にこんなルールで取り組みを開始しました 1. PR タイトルのプレフィックスを [Tidy] とつけて分かりやすくする 2. 変更内容が単一である（複数の変更をひとつの PR に含めていない） 3. 修正箇所のテストが存在し、テストが通っている（コメントのみの修正等は除く） 4. アプリケーションの挙動は変わっていないこと 5. 可逆的である（仮に不具合が発生した場合は、この PR を Revert するだけでよい） 6. 不具合が発生するリスクが低い自信を持てている（PR 作成者の自己申告でよい）

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

©KAKEHASHI inc. 29 チームに信頼があり、盤石な文化があれば、整頓にはレビューは不要だ整頓はレビューしなくてもよいというレベルの安全と信頼に到達するには、何ヶ月もかかる。練習しよう。実験しよう。みんなでエラーをレビューしよう。 https://www.oreilly.co.jp/books/9784814400911/ “ ”