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日目はロードマップの開発は行わない ● プランニング時点で1週間の最初の3日で完了するくらいの 余裕をもった計画にする ● 想定より早くそのスプリントの開発が完了しとしても、 次の開発項目を始めない

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

©KAKEHASHI inc. 22 息を吸うように日々のカイゼンが できている状態したい! でも、もっと

Slide 23

Slide 23 text

©KAKEHASHI inc. 23 ②計画外の小さな余白を上手に使えるようにする 現実的なプロセスの中で出てきた余白もなんとか上手に使いたい

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

©KAKEHASHI inc. 27 周辺コードを触るついでにしか実施してなかった コメントだけの追加やREADMEの拡充などが 進みはじめた

Slide 28

Slide 28 text

©KAKEHASHI inc. 28 まだレビューがないことに抵抗のあるような メンバーもまだまだいる

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

©KAKEHASHI inc. 30 おわりに 計画的なチームの余白を作って、 チームとしてカイゼン活動を! 計画外の小さな余白を使うために レビューのハードルを下げよう! チームの信頼と文化を作っていくために 練習しよう。訓練しよう。

Slide 31

Slide 31 text

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