Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Scrum Fest Niigata 2025
https://www.scrumfestniigata.org/
での登壇資料です

Avatar for KAKEHASHI

KAKEHASHI

May 09, 2025
Tweet

More Decks by KAKEHASHI

Other Decks in Technology

Transcript

  1. © KAKEHASHI Inc. • アーキテクチャの刷新 • 自動テストの整備 • プレモーテムの実施 •

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

    ラーニングセッション • スキルトランスファー • ふりかえり 重要だが緊急ではないもの うんうん、大事だね。 わかるよ。 絶対、絶対にあとで やる時間とるからさァ… いったん置いておこう?
  3. © KAKEHASHI Inc. 突然、超緊急になったりする 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし緊急でもない

    第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大 大変だ! ライブラリに 脆弱性が報告されたぞ! 大型顧客が利用開始 したら、コストが バクアゲだ!!
  4. 小田中 育生(おだなか いくお) 株式会社ナビタイムジャパンで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位)
  5. プロダクトもチームも良くなり続けるための営み 29 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD
  6. そんなAI在庫管理チームに、昨年からジョイン サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 30 どんなチームなんだろう? 観察してみよう
  7. 緊急事態が発生すると、すぐみんな集まる サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 32 インシデント疑い インシデント疑いを発見すると 即座にMeetが立ち上がり、 Slackで情報共有が始まり、 即座に解決に向けて動き出す
  8. いいチームだ! サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 33 いいチームだ!
  9. 運用・保守・カイゼンには伸びしろがあった 34 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD
  10. © KAKEHASHI Inc. やるぞ! • 二週間、実際にいくつかのミーティングを止めてみる • その間どのような変化が起こるか観察する • メンバーから気づいたことを共有してもらう

    • 目指していること(余白の確保)が実現できるか、発生する課題はリ カバリー可能なものか、など総合的に判断しパーマネントに止めるか 判断する
  11. © KAKEHASHI Inc. 横のつながりの弱まり サブ チーム 1 サブ チーム 2

    サブ チーム N PdM デザイナー FE BE サブチームをまたいだ定例をなくした結果、「サブチーム外と相談しづら くなった」という声があがっていた
  12. © KAKEHASHI Inc. チームの形はどうあるべきなのか Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤

    あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “チームが分割に向かう前兆とし て、4つの重要なサインがありま す。ミーティングが長引く、意思決 定が難しくなる、作業が分散する、 そしてチームメンバーの把握が難し くなることです。”
  13. © KAKEHASHI Inc. チームを正式に分割する? サブ チーム 1 サブ チーム 2

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

    PdM デザイナー FE BE 60 サブチームではなくチーム全体で優先順位を定めていきたい
  15. © KAKEHASHI Inc. 個別最適化の引力 サブ チーム 1 サブ チーム 2

    サブ チーム N PdM デザイナー FE BE サブチームごとに最適化してしまう傾向があった その中で明確にチームを分けると、より個別最適化が進む?
  16. システム的にもキレイに分かれてはいない サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 62 インシデント疑い インシデント時はサブチーム横断 で集まっている 裏を返すと、緊急時にはサブチーム をまたいだ連携が必要
  17. © KAKEHASHI Inc. 分割以外の選択肢もあるかもしれない Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤

    あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “チームを分割することでチーム間で作 業を共有しなければいけなくなる場 合、それが本当に良い選択かどうか 慎重に考えましょう。 作業が絡み合っ ているときは、むしろチームを1つにし ておくほうが、オーバーヘッドが少な く、メンバーにとっても楽かもしれませ ん。”
  18. 状況にあわせて変化するチーム チーム プロダクト Epic1 Epic2 Epic3 スプリント毎に 優先順位を更新し、 状況に応じて組成を 変えていく

    前職でやっていた このフォーメーションが ハマるのでは? と考えた・・・が、 メンバーにとってどうか?
  19. いきなりガッチャンコはできない 方向性には賛成なんですが・・・ サブチームごとに仕事の進め方が違うからなぁ・・・ サブ チーム 1 サブ チーム 2 サブ

    チーム N PdM デザイナー FE BE サブチームごとの • ナレッジ • スキル • カルチャー に違いがある状況
  20. スイッチングしながら変化していけるのでは? サブ チーム 1 サブ チーム 2 サブ チーム N

    ねらい これまで在籍していた サブチーム以外で求められる ナレッジ・スキルの獲得 人が流動することによるカル チャーの緩やかな変化・統合 スプリントごとにサブチーム間でメンバーを ローテーションする試み
  21. © KAKEHASHI Inc. ありたい形ありきで進めてしまった Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤

    あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “リチーミングをうまく行うには人に対す る注意と尊敬が欠かせません。リチー ミングには万能の「インストール方法」 などありません。”
  22. ローテーションをいったん止める サブ チーム 1 サブ チーム 2 サブ チーム N

    何がうまくいき 何がうまくいかなかったのか よりよくあるために 僕たちはどうするといいのか 二ヶ月ほど試したあと、見直しが必要だと判断
  23. 立ち止まったが、停滞ではない サブ チーム 1 サブ チーム 2 サブ チーム N

    全体最適の中で余白を作りたい という想いは持ちつつ、 いかにチームを巻き込むか 今一度かんがえる ローテーション自体は止めたが、学ぶことは多かった。 自分の「現場の巻き込み」が弱くなっているという気付きも あった
  24. 少しずつ、保守運用・カイゼンも回り始めた 80 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD
  25. あらためて、全体像を描きながら進んでいきたい サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 81 現地点ではサブチームの垣根を取り払うのは難しい それでも、チーム全体をみた優先順位づけをしていきたい
  26. ある時から、立て続けに問題が発生 94 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ヒヤリハット含む インシデント対応 ヒヤリハット含む インシデント対応
  27. サブチームの垣根を超えた協働 サブ チーム 1 サブ チーム 2 サブ チーム N

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

    PdM デザイナー FE BE 98 網羅的な検証 網羅的な検証からはいくつかの対応するべ き事項が見つかった リリースするまでに問題を取り除くための 仕組み化が急務になっていた
  29. 外部仕様ドキュメントのレビューをプロセスに追加 99 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

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

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ドキュメント レビュー
  31. © KAKEHASHI Inc. チームに起こる変化の息吹 第二領域 重要だが緊急ではない 第一領域 重要かつ緊急 第四領域 重要ではないし

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

    緊急でもない 第三領域 重要ではないが緊急 緊急度 重要度 小 大 小 大 「重要だが緊急ではない」ものは、「時間がない」 ので先送りされる
  33. © KAKEHASHI Inc. なぜうまくいき、うまくいかなかったか • うまくいったとき ◦ 明確なメッセージングや実験による成功体験 ◦ メンバー主導で進める環境

    ◦ フィードバックの収集と軌道修正 • うまくいかなかったとき ◦ 自分の中の「こうやったらうまくいくだろう」が先行 ◦ フィードバックによる軌道修正が不十分
  34. © KAKEHASHI Inc. 状況を見極めてアプローチする Heidi Helfand 著/永瀬 美穂・吉羽 龍太郎・原田 騎郎・細澤

    あゆみ 訳 ダイナミックリチーミング 5つのパターンによる効果的なチーム編成 より引用 “リチーミングをうまく行うには人に対す る注意と尊敬が欠かせません。リチー ミングには万能の「インストール方法」 などありません。”
  35. サブチームの融合 サブ チーム 1 サブ チーム 2 サブ チーム N

    PdM デザイナー FE BE 122 現在、2つのサブチームを融合させる試みを実施中 学びが多くもあり、大変なことが多くもあり
  36. 開発プロセスもまだまだ変化していく 123 小さい PullRequest 小さな課題 に分割 エンジニア全員で 日々のログ・ダッシュ ボード確認 運用や保守、カイゼンも

    一緒にプランニング ヒヤリハット含む インシデント対応 ペア・モブで 検討・開発 シフト制の 運用作業 自動テスト 効果検証 インフラコスト の定期確認 アラートの 確認と対応 Deploy Monitor R elease Code Test Operate P lan Build CI/CD ドキュメント レビュー ドキュメントレビューを、Devinを活用してできないか、という 取り組みにチャレンジ中(通称、小田中失業プロジェクト)