時間がないなら、つくればいい〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜

by KAKEHASHI

Slide 1

Slide 1 text

時間がないなら、つくればいい〜数十人規模のチームが　自律性を発揮するために試しているいくつかのこと〜株式会社カケハシ　小田中育生 2025.05.10

Slide 2

Slide 2 text

時間がない

Slide 3

Slide 3 text

文字通り時間がとれない時間をかけていいかわからない時間をかけて取り組む意欲がない「時間がない」という言葉の背後には様々な背景が潜んでいます

Slide 4

Slide 4 text

Slide 5

Slide 5 text

時間がないと何が起こる？

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

でも時間がない

Slide 16

Slide 16 text

どうする？

Slide 17

Slide 17 text

Slide 18

Slide 18 text

小田中育生(おだなかいくお) 株式会社ナビタイムジャパンでVP of Engineeringとしてアジャイル・OKRの組織展開・浸透を実践。 2023年10月にエンジニアリングマネージャーとして株式会社カケハシにジョイン、2025年3月よりSCM Head of Engineering。 Musubi AI在庫管理の開発を通して医薬品流通の最適化支援に挑戦中、しなやかな医療体験の実現を目指す。スクラムフェス、Startup in Agile、EMConf JPなどに出没。著書: ● いちばんやさしいアジャイル開発の教本 ● アジャイルチームによる目標づくりガイドブック受賞: ● Developers Summit 2024 Summer ベストスピーカー賞（2位） ● Developers CAREER Boost 2024 ベストスピーカー賞（1位）

Slide 19

Slide 19 text

Learning Outcome 目指すところを明確にして共有すること、その目指すところに対し自律的に向かうために余白が大切であることを、私のチームが経験したことをベースに実感してもらううまくいったこと・いかなかったことから、自分のチームに当てはめるとしたら？と応用するヒントを得てもらう

Slide 20

Slide 20 text

このスライドのアウトライン Chapter 1: AI在庫管理開発チームとの出会い Chapter 2: 余白を生むためのチームのカタチ Chapter 3: チームの目線が揃うとき Chapter 4: 奪われた余白 Chapter 5: 時間がないなら、つくればいい Chapter 6: エピローグ

Slide 21

Slide 21 text

Chapter 1: AI在庫管理開発チームとの出会い

Slide 22

Slide 22 text

Musubi AI在庫管理 22 患者さん・医薬品ごとに、AIが需要予測在庫管理にまつわるさまざまな課題を解決

Slide 23

Slide 23 text

AI在庫管理の開発チーム ● 20人超の中規模チーム ● いくつかの機能横断型サブチームで構成サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 23

Slide 24

Slide 24 text

僕たちが描いている未来 ● 医薬品廃棄のない、健全な医薬品受給が実現した世界をつくりたい ● そのために発注最適化を実現するプロダクトを提供していきたい ● プロダクトの利用をひろげ、目指す世界を実現していきたい 24

Slide 25

Slide 25 text

どう実現する？ 25 顧客とユーザーと私より引用 https://speakerdeck.com/ikuodanaka/dancing-with-customers-and-users?slide=3

Slide 26

Slide 26 text

既存顧客に価値提供し続ける 26 顧客とユーザーと私より引用 https://speakerdeck.com/ikuodanaka/dancing-with-customers-and-users?slide=3 発注最適化ユーザビリティ向上

Slide 27

Slide 27 text

新規顧客に使ってもらう 27 顧客とユーザーと私より引用 https://speakerdeck.com/ikuodanaka/dancing-with-customers-and-users?slide=3 新規顧客に訴求する機能開発

Slide 28

Slide 28 text

そのためにチームを強くする ● チームとしてのスキル向上 ● DX(Developers eXperience)の継続的改善サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 28

Slide 29

Slide 29 text

プロダクトもチームも良くなり続けるための営み 29 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD

Slide 30

Slide 30 text

そんなAI在庫管理チームに、昨年からジョインサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 30 どんなチームなんだろう？観察してみよう

Slide 31

Slide 31 text

盛り上がるスプリントレビュー（デモを操作して）どれくらい待つんだろうダウンロードにどれくらいかかるか知りたい他のレポートと導線が揃ってるとうれしい！在庫金額みれるのとても便利ですね！めちゃ早でご対応いただき・・・🙏

Slide 32

Slide 32 text

緊急事態が発生すると、すぐみんな集まるサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 32 インシデント疑いインシデント疑いを発見すると即座にMeetが立ち上がり、 Slackで情報共有が始まり、即座に解決に向けて動き出す

Slide 33

Slide 33 text

いいチームだ！サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 33 いいチームだ！

Slide 34

Slide 34 text

運用・保守・カイゼンには伸びしろがあった 34 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD

Slide 35

Slide 35 text

個人のカイゼン活動への停滞感 D-Plus Tokyo #12~個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？「やっぱり余白が大切だった話」松本明紘より https://speakerdeck.com/kakehashi/after-all-margin-is-important

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

とはいえ、悩んでいた 43 ほんとになくしていいのかな…。試してみて、うまくいかなければ戻すのがいいかな。実験の期間を設けてみようか。さて、どういうふうに伝えていくのがよいか・・・タイミングとしては、いつがよいのか・・・

Slide 44

Slide 44 text

そんなとき…

Slide 45

Slide 45 text

YAPC::Hakodate 2024のキーノート 45 https://speakerdeck.com/moznion/develop-to-survive-yapc-hakodate-2024-keynote

Slide 46

Slide 46 text

同僚とバスに揺られながら・・・ 46 キーノート、グッときたね… 僕らのチームも、「個人技」を磨くことを大切にしていきたい・・・

Slide 47

Slide 47 text

思わず相談する 47 個人で考えて行動する時間を増やすためにもミーティングを減らしていきたいんだよね

Slide 48

Slide 48 text

思わず相談する 48 個人で考えて行動する時間を増やすためにもミーティングを減らしていきたいんだよねやってみましょうよ今のチームならきっとできますよ

Slide 49

Slide 49 text

やるなら今しかねぇ

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© KAKEHASHI Inc. 続々と寄せられるメンバーの声午前中に作業が進むようになった。共通の連絡事項などはslackで共有されていてキャッチアップできるため、チーム開発が進むのではないかと思いました。ミーティングで集中が途切れることなく続けられるようになったのはとても助かっているリリース内容や担当者を全員が確認できているか少し不安。「連絡きてるけどこれどうするー？」みたいなのを相談しづらいかも？気づく人が損するみたいな。

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Chapter 2: 余白を生むためのチームのカタチ

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

僕たちがやりたいこと 59 患者さん・医薬品ごとに、AIが需要予測在庫管理にまつわるさまざまな課題を解決

Slide 60

Slide 60 text

全体像を描きながら進んでいきたいサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 60 サブチームではなくチーム全体で優先順位を定めていきたい

Slide 61

Slide 61 text

Slide 62

Slide 62 text

システム的にもキレイに分かれてはいないサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 62 インシデント疑いインシデント時はサブチーム横断で集まっている裏を返すと、緊急時にはサブチームをまたいだ連携が必要

Slide 63

Slide 63 text

© KAKEHASHI Inc. 分割以外の選択肢もあるかもしれない Heidi Helfand 著/永瀬美穂・吉羽龍太郎・原田騎郎・細澤あゆみ訳ダイナミックリチーミング 5つのパターンによる効果的なチーム編成より引用 “チームを分割することでチーム間で作業を共有しなければいけなくなる場合、それが本当に良い選択かどうか慎重に考えましょう。作業が絡み合っているときは、むしろチームを1つにしておくほうが、オーバーヘッドが少なく、メンバーにとっても楽かもしれません。”

Slide 64

Slide 64 text

分割ではなく統合するという選択肢 PdM デザイナー FE BE 64 サブチームの枠組みを取っ払い共通の優先順位を持つ状況にあわせ組成を変える、そんなチームにできないか？

Slide 65

Slide 65 text

状況にあわせて変化するチームチームプロダクト Epic1 Epic2 Epic3 スプリント毎に優先順位を更新し、状況に応じて組成を変えていく前職でやっていたこのフォーメーションがハマるのでは？と考えた・・・が、メンバーにとってどうか？

Slide 66

Slide 66 text

きいてみた目線がサブチームなのが気になっていた。ぜひ、このフォーメーションに移行してほしい早くこれ試してみましょうよ方向性には賛成なんですが・・・サブチームごとに仕事の進め方が違うからなぁ・・・エンジニア側よりマネージャー側が今まで以上に負担増えそうな気がする

Slide 67

Slide 67 text

いきなりガッチャンコはできない方向性には賛成なんですが・・・サブチームごとに仕事の進め方が違うからなぁ・・・サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE サブチームごとの ● ナレッジ ● スキル ● カルチャーに違いがある状況

Slide 68

Slide 68 text

スイッチングしながら変化していけるのでは？サブチーム 1 サブチーム 2 サブチーム N ねらいこれまで在籍していたサブチーム以外で求められるナレッジ・スキルの獲得人が流動することによるカルチャーの緩やかな変化・統合スプリントごとにサブチーム間でメンバーをローテーションする試み

Slide 69

Slide 69 text

やってみた他のサブチーム、やり方が違って学びがあって楽しいです！ ◯◯さんが来てくれてすごく助かってます。ローテーションいいですね！

Slide 70

Slide 70 text

しかし・・・ ◯◯さんが来てくれてすごく助かってます。ローテーションいいですね！どんどん人が入れ替わっちゃうと深いナレッジの共有とかは難しいなぁ・・・今のサブチームでやりきりたいことがあったんだけどなぁ・・・他のサブチーム、やり方が違って学びがあって楽しいです！

Slide 71

Slide 71 text

うまくいかない側面が浮き彫りになっていった今のサブチームでやりきりたいことがあったんだけどなぁ・・・やりたいことはわかるんだけど進め方がモヤモヤするローテーション自体が目的化してませんか？どんどん人が入れ替わっちゃうと深いナレッジの共有とかは難しいなぁ・・・

Slide 72

Slide 72 text

Slide 73

Slide 73 text

ローテーションをいったん止めるサブチーム 1 サブチーム 2 サブチーム N 何がうまくいき何がうまくいかなかったのかよりよくあるために僕たちはどうするといいのか二ヶ月ほど試したあと、見直しが必要だと判断

Slide 74

Slide 74 text

OST！OST!O！S！T！でふりかえり取り組みのふりかえり、ありたい姿について話した

Slide 75

Slide 75 text

取り組みをふりかえり、学びを深めるメンバーたち異動してきたメンバーからこうしたいですね！みたいなカイゼンアイデアが出てきて良かったチームが動的だと、計画は難しくなる。すでに障害時には動的に一時的なチームを組んでいたたくさんの人と働けるのはポジティブ

Slide 76

Slide 76 text

立ち止まったが、停滞ではないサブチーム 1 サブチーム 2 サブチーム N 全体最適の中で余白を作りたいという想いは持ちつつ、いかにチームを巻き込むか今一度かんがえるローテーション自体は止めたが、学ぶことは多かった。自分の「現場の巻き込み」が弱くなっているという気付きもあった

Slide 77

Slide 77 text

Chapter 3: チームの目線が揃うとき

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

少しずつ、保守運用・カイゼンも回り始めた 80 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD

Slide 81

Slide 81 text

あらためて、全体像を描きながら進んでいきたいサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 81 現地点ではサブチームの垣根を取り払うのは難しいそれでも、チーム全体をみた優先順位づけをしていきたい

Slide 82

Slide 82 text

共通で目指すところを定める 82 店舗数を拡大していきたい、それを支えられるプロダクト・体制にしたいニーズを捉えた機能開発利用拡大に耐えうるシステム品質向上クラウドコストの最適化

Slide 83

Slide 83 text

品質を犠牲にしたくない 83 店舗数を拡大していきたい、それを支えられるプロダクト・体制にしたいニーズを捉えた機能開発利用拡大に耐えうるシステム品質向上クラウドコストの最適化僕が犠牲に・・・なりたくない

Slide 84

Slide 84 text

共通で目指すところを定める 84 店舗数を拡大していきたい、それを支えられるプロダクト・体制にしたいニーズを捉えた機能開発利用拡大に耐えうるシステム品質向上クラウドコストの最適化 AI活用などによる開発プロセスのアップデート

Slide 85

Slide 85 text

ビジネスとつながるものは優先順位が上がりやすい 85 店舗数を拡大していきたい、それを支えられるプロダクト・体制にしたいニーズを捉えた機能開発利用拡大に耐えうるシステム品質向上クラウドコストの最適化 AI活用などによる開発プロセスのアップデート

Slide 86

Slide 86 text

後手にまわりやすいものにどう取り組んでいくか 86 店舗数を拡大していきたい、それを支えられるプロダクト・体制にしたいニーズを捉えた機能開発利用拡大に耐えうるシステム品質向上クラウドコストの最適化 AI活用などによる開発プロセスのアップデート

Slide 87

Slide 87 text

モチベーションのあるメンバーを明示的にアサイン 87 利用拡大に耐えうるシステム品質向上 AI活用などによる開発プロセスのアップデート限られた余白の中で「重要だが緊急ではない」ことを進めるために明確にオーナーシップをもってもらう

Slide 88

Slide 88 text

SLOを定め、グイッと進み始めた DevOpsDays Tokyo 2025「システムとの会話から生まれる先手のDevOps」松本明紘より https://speakerdeck.com/kakehashi/proactive-devops

Slide 89

Slide 89 text

チームでのAI活用が一気に活性化した D-Plus Tokyo #13 これからどうする？生成AIによって変わるエンジニアの学び方「AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話」鳥海航より https://speakerdeck.com/kakehashi/we-learn-together

Slide 90

Slide 90 text

余談他のメンバーに混じってふるまいを称賛されるDevinさん

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Chapter 4: 奪われた余白

Slide 93

Slide 93 text

身構えている時には、死神は来ないものだ『機動戦士ガンダム閃光のハサウェイ』より

Slide 94

Slide 94 text

ある時から、立て続けに問題が発生 94 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ヒヤリハット含むインシデント対応ヒヤリハット含むインシデント対応

Slide 95

Slide 95 text

一匹みつけたらなんとやらこれまで起こっていなかったことが、立て続けに起こるということは、他にも問題があるかもしれない開発を止め、網羅的な検証に乗り出す ● ペアワイズ法でのテストケース洗い出しとテスト実施 ● QMチームに外部仕様からの網羅的な検証を依頼 ● PdMによるモンキーテスト

Slide 96

Slide 96 text

サブチームの垣根を超えた協働サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 96 網羅的な検証緊急度が高いというメッセージングのもとチームは有機的に連携し、短期間でこの網羅的な検証をやりきった

Slide 97

Slide 97 text

今やらなければという共通認識は連帯を生む移動してきたメンバーからこうしたいですね！みたいなカイゼンアイデアが出てきて良かったチームが動的だと、計画は難しくなる。すでに障害時には動的に一時的なチームを組んでいたたくさんの人と働けるのはポジティブ

Slide 98

Slide 98 text

網羅的な検証、そのあとサブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 98 網羅的な検証網羅的な検証からはいくつかの対応するべき事項が見つかったリリースするまでに問題を取り除くための仕組み化が急務になっていた

Slide 99

Slide 99 text

外部仕様ドキュメントのレビューをプロセスに追加 99 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ドキュメントレビュー外部仕様の確認は開発の早い段階で行いたいが、進行中の開発もある中で水際で問題を発見するためにリリース前の段階で実施

Slide 100

Slide 100 text

このときの葛藤 100 品質を上げるために、外部仕様に曖昧さがないかもれなく検証されているかの確認は重要でも、せっかく生まれつつあった「余白」を破壊する行為なのでは・・・

Slide 101

Slide 101 text

でもやる

Slide 102

Slide 102 text

ある日のメンバーとの会話仕様レビューに対して、素早く対応してくれてありがとうございます！いえいえ。ちょっと思ったんですけど、小田中さんにレビューお願いするの、リリース直前じゃなく開発始まるタイミングのほうがいいですよね？

Slide 103

Slide 103 text

Slide 104

Slide 104 text

そのメンバーが全体へメッセージを送った新しい開発プロセスに変更してから、昨日のリリースが最初のリリースでした。何が変わったのか、何を気をつけるべきか、を明確化するために以下、共有させてください！外部仕様書の記載と小田中さんによる内容確認は、開発におけるできるだけ早いタイミングで（基本的にはコーディングを始める前）に完了しておくのが良いと思います余談: 「Weeks of Coding Can Save You Hours of Planning」　　　という名言があります直訳: 数週間のコーディングで、数時間の事前計画を節約できる / 意訳: 事前に数時間計画するのをサボると、　　　数週間無駄にコーディングすることになる

Slide 105

Slide 105 text

実際の学びからカイゼンの提案が出た 105 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ドキュメントレビュー

Slide 106

Slide 106 text

Slide 107

Slide 107 text

Chapter 5: 時間がないなら、つくればいい

Slide 108

Slide 108 text

時間がない

Slide 109

Slide 109 text

時間がないと何が起こる？

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

Slide 118

Slide 118 text

Slide 119

Slide 119 text

Slide 120

Slide 120 text

Slide 121

Slide 121 text

Chapter 6: エピローグ

Slide 122

Slide 122 text

サブチームの融合サブチーム 1 サブチーム 2 サブチーム N PdM デザイナー FE BE 122 現在、2つのサブチームを融合させる試みを実施中学びが多くもあり、大変なことが多くもあり

Slide 123

Slide 123 text

開発プロセスもまだまだ変化していく 123 小さい PullRequest 小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト効果検証インフラコストの定期確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ドキュメントレビュードキュメントレビューを、Devinを活用してできないか、という取り組みにチャレンジ中（通称、小田中失業プロジェクト）

Slide 124

Slide 124 text

余白をつくり、納得をもとに、前に進む 124 プロポーザルを出した時点で想像していたチームの着地点と今、実際に立っているところはけっこう違っているこれからもきっとそう、外も中も変化し続けるだからこそ余白をつくり、変化に適応できるようにしたいなぜその変化をするのか納得を生み、みんなで変化したい