Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

時間がない

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

© KAKEHASHI Inc. という話を3年前にしました https://speakerdeck.com/navitimejapan/shi-jian-ganai-zheng-hou-qun-sofalseqing-xiang-todui-ce

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

© KAKEHASHI Inc. アイゼンハワーマトリクス 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 7

Slide 7 text

© KAKEHASHI Inc. 第一・二領域に取り組んでいたとする 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 8

Slide 8 text

© KAKEHASHI Inc. 第一領域でやるべきことが発生したら? 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 9

Slide 9 text

© KAKEHASHI Inc. 第二領域は尊い犠牲になる 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 10

Slide 10 text

© KAKEHASHI Inc. ● アーキテクチャの刷新 ● 自動テストの整備 ● プレモーテムの実施 ● ラーニングセッション ● スキルトランスファー ● ふりかえり 重要だが緊急ではないもの

Slide 11

Slide 11 text

© KAKEHASHI Inc. ● アーキテクチャの刷新 ● 自動テストの整備 ● プレモーテムの実施 ● ラーニングセッション ● スキルトランスファー ● ふりかえり 重要だが緊急ではないもの うんうん、大事だね。 わかるよ。 絶対、絶対にあとで やる時間とるからさァ… いったん置いておこう?

Slide 12

Slide 12 text

© KAKEHASHI Inc. 先送りしていると・・・ 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 13

Slide 13 text

© KAKEHASHI Inc. 突然、超緊急になったりする 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大 大変だ! ライブラリに 脆弱性が報告されたぞ! 大型顧客が利用開始 したら、コストが バクアゲだ!!

Slide 14

Slide 14 text

© KAKEHASHI Inc. ここって大事なんだよなぁ・・・ 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 15

Slide 15 text

でも 時間がない

Slide 16

Slide 16 text

どうする?

Slide 17

Slide 17 text

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

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

© KAKEHASHI Inc. この頃のチームのカレンダー チーム全体、各サブチームでの同期をとる予定に加え、同じ職能での サブチーム横断の相談会などが多く設定され余白が少ない状況だった

Slide 37

Slide 37 text

© KAKEHASHI Inc. 余白がないと第二領域は先送りされがち 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

Slide 38

Slide 38 text

© KAKEHASHI Inc. 直感的にはカレンダーを軽くしたいが… それぞれの予定は、チームが必要としていたから生まれたもの。 単純に減らすというのは難しい・・・

Slide 39

Slide 39 text

© KAKEHASHI Inc. 同期して議論するべきものは何か? 1-way-door(後戻りが難しい)な意思決定 多様な視点から行うアイデア出し 熱量の伝搬 関係性の構築 決定事項、周知事項の伝達 後戻り可能な意思決定 状況の確認 同期したい 非同期でいい

Slide 40

Slide 40 text

© KAKEHASHI Inc. 定期的に実施したいものは何か? チームの検査と適応 プロダクトの検査と適応 突発事象の情報共有 壁打ち 定期 不定期

Slide 41

Slide 41 text

© KAKEHASHI Inc. 同期・定期でやりたいものにしぼりたい 同期したい 非同期でいい 定期 不定期

Slide 42

Slide 42 text

© KAKEHASHI Inc. 余白ができれば不定期の同期もしやすい 同期したい 非同期でいい 定期 不定期

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

© KAKEHASHI Inc. やるぞ! ● 二週間、実際にいくつかのミーティングを止めてみる ● その間どのような変化が起こるか観察する ● メンバーから気づいたことを共有してもらう ● 目指していること(余白の確保)が実現できるか、発生する課題はリ カバリー可能なものか、など総合的に判断しパーマネントに止めるか 判断する

Slide 51

Slide 51 text

© KAKEHASHI Inc. メンバーに伝え、実験を開始

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

© KAKEHASHI Inc. そして本採用へ 「以前より相談しづらい」といった課題が表出 けれども余白を生むメリットが大きく、ミーティング削減は本採用 「時間がない」を乗り越える1stステップには成功した!

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

© KAKEHASHI Inc. 余白は生まれた 定例に埋め尽くされていたカレンダーは整理され、個々人が 自分の裁量で使える時間は増えた

Slide 56

Slide 56 text

© KAKEHASHI Inc. 横のつながりの弱まり サブ チーム 1 サブ チーム 2 サブ チーム N PdM デザイナー FE BE サブチームをまたいだ定例をなくした結果、「サブチーム外と相談しづら くなった」という声があがっていた

Slide 57

Slide 57 text

© KAKEHASHI Inc. チームの形はどうあるべきなのか Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤 あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “チームが分割に向かう前兆とし て、4つの重要なサインがありま す。ミーティングが長引く、意思決 定が難しくなる、作業が分散する、 そしてチームメンバーの把握が難し くなることです。”

Slide 58

Slide 58 text

© KAKEHASHI Inc. チームを正式に分割する? サブ チーム 1 サブ チーム 2 サブ チーム N PdM デザイナー FE BE サブチーム間の疎結合化を進め、明確に別チームとして分割する? 自分の経験則では、分割したほうがワークする規模感になっていた

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

© KAKEHASHI Inc. 個別最適化の引力 サブ チーム 1 サブ チーム 2 サブ チーム N PdM デザイナー FE BE サブチームごとに最適化してしまう傾向があった その中で明確にチームを分けると、より個別最適化が進む?

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

© KAKEHASHI Inc. ありたい形ありきで進めてしまった Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤 あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “リチーミングをうまく行うには人に対す る注意と尊敬が欠かせません。リチー ミングには万能の「インストール方法」 などありません。”

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

© KAKEHASHI Inc. 時間的な余白は生まれた

Slide 79

Slide 79 text

© KAKEHASHI Inc. 余白を生み出す活動がメンバーから誕生 D-Plus Tokyo #12~個人の工夫をチームの力に!開発生産性向上の文化づくりどうしてる? 「やっぱり余白が大切だった話」松本明紘 より https://speakerdeck.com/kakehashi/after-all-margin-is-important

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

© KAKEHASHI Inc. 主体性が第二領域へのコミットを生んだ 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし 緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

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

© KAKEHASHI Inc. チームに起こる変化の息吹 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし 緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大 「重要だが緊急ではない」だった品質への取り組みが、緊急 度が上がったことにより前進するようになった 開発プロセスの カイゼンという 第二領域に対して 目がいくように なってきた

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

時間がない

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

© KAKEHASHI Inc. 第二領域の優先順位が上がらない 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし 緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大 「重要だが緊急ではない」ものは、「時間がない」 ので先送りされる

Slide 111

Slide 111 text

© KAKEHASHI Inc. 僕たちが経験した「時間がない」 ● ミーティングが多く、物理的に時間がなかった ● 部分最適化する中で、余白が有効活用できなかった ● 「重要だが緊急ではない」ものの緊急度が上がった結果、 その対応に時間がとられてしまった

Slide 112

Slide 112 text

© KAKEHASHI Inc. 物理的な時間の確保 2週間の実験を経て実施した、定例の削減による 物理的な時間の確保は余白を生み出した Chapter1の取り組み 定例の削減

Slide 113

Slide 113 text

© KAKEHASHI Inc. 体制変更による全体最適の獲得 余白はできたがサブチームごとに部分最適化し 完全に有効活用はできていなかった Chapter1の取り組み 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 定例の削減

Slide 114

Slide 114 text

© KAKEHASHI Inc. 体制変更による全体最適の獲得 サブチーム間ローテーションを通してスキルトランスファー、 カルチャー融合を試みたが、取り組みは中止 Chapter1の取り組み 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Chapter2の取り組み 定例の削減 ローテーション

Slide 115

Slide 115 text

© KAKEHASHI Inc. 第二領域の活動を目標として定義 後手にまわりやすい第二領域のものを目標として定義し 余白の中で優先的に進められる構造をつくった Chapter1の取り組み Chapter3の取り組み メンバー主導の 目標達成活動 Chapter2の取り組み 定例の削減 ローテーション

Slide 116

Slide 116 text

© KAKEHASHI Inc. 余白の変化 品質向上のプロセス導入で物理的な余白は減少したが 重要だが緊急でなく先送りされやすい品質向上が進むように Chapter1の取り組み Chapter3の取り組み メンバー主導の 目標達成活動 Chapter2の取り組み 定例の削減 ローテーション Chapter4の取り組み 品質向上の プロセス導入

Slide 117

Slide 117 text

© KAKEHASHI Inc. なぜうまくいき、うまくいかなかったか ● うまくいったとき ○ 明確なメッセージングや実験による成功体験 ○ メンバー主導で進める環境 ○ フィードバックの収集と軌道修正 ● うまくいかなかったとき ○ 自分の中の「こうやったらうまくいくだろう」が先行 ○ フィードバックによる軌道修正が不十分

Slide 118

Slide 118 text

© KAKEHASHI Inc. 状況を見極めてアプローチする Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤 あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “リチーミングをうまく行うには人に対す る注意と尊敬が欠かせません。リチー ミングには万能の「インストール方法」 などありません。”

Slide 119

Slide 119 text

© KAKEHASHI Inc. 時間がないなら、つくればいい 物理的に時間がないなら、まずそれを確保する 生まれた余白をチームで有効活用したいなら、 全体最適に向けて働きかける チームは生き物。うまくいったプラクティスが、 ある局面ではうまくハマらないこともある。 だからこそメンバーが主体的に動く、組織としての余白が必要

Slide 120

Slide 120 text

© KAKEHASHI Inc. 余白をつくり、大切なことに取り組もう 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大

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

Slide 125

Slide 125 text

時間がない

Slide 126

Slide 126 text

© KAKEHASHI Inc. 時間をつくるために、いろいろやった ● 物理的な余白を確保する ● 全体最適に向け目線をあわせる ● 時間を使いたいものを目標に組み込み推進しやすくする ● なぜそれをやるか、を話し、チームの主体性を引き出す

Slide 127

Slide 127 text

© KAKEHASHI Inc. 状況が変われば、必要な取り組みも変わる。 うまくいくこともいかないこともある。 けれども「時間がない」と思ったとき、それに流されず 自分たちで考え、工夫し、失敗しながらも 時間を作り出す意思を持とう。 行動し続けよう。 時間を作り出す意思を持ち続ける

Slide 128

Slide 128 text

時間がないなら つくればいい じゃない!

Slide 129

Slide 129 text

© KAKEHASHI Inc. カケハシの技術に関連する情報を 発信しています。 𝕏 @kakehashi_dev 是非フォローしてください! ありがとうございました!!