Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Value Driven DevOps Team
Search
KAKEHASHI
April 17, 2024
Business
14
5.8k
Value Driven DevOps Team
KAKEHASHI
April 17, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
kakehashi
10
1.2k
KAKEHASHI Company Deck / Company Deck
kakehashi
4
370
アジャイルチームがらしさを発揮するための目標づくり / Making the goal and enabling the team
kakehashi
4
570
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
830
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
2
290
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
2
170
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
kakehashi
1
270
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
kakehashi
5
2.4k
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
1.4k
Other Decks in Business
See All in Business
デジタルで創れ!未来の東京消防庁
tokyo_metropolitan_gov_digital_hr
1
220
pmconf2024 意思決定の質とスピードを上げるドキュメントの極意
issei123
1
5.7k
Theoria technologies:About Us
theoriatec2024
1
4.1k
Mercari-Fact-book_jp
mercari_inc
3
150k
AWS re:Invent参加のリアル 〜女性目線で考える健康・美容・安全のベストプラクティス〜
o2mami
1
300
1LDK会社紹介資料
1ldkinc
1
250
経験やセンスに頼らずに成果を出すためのチームマネジメント実践ガイド / Team Management Without Relying on Experience or Intuition
happy_imafuku
4
9.5k
EM、会計を学ぶ
yigarashi
0
190
The AI-savvy operating model - Matthew Skelton, Conflux - Agile to Agility conference
matthewskelton
PRO
2
140
株式会社ワンコイングリッシュ 会社説明資料
oce_recruit
1
5.7k
株式会社AGEST紹介資料/AGEST Recruitment
agest_recruit
0
2.4k
20241211_CMCNagoya_9
hideki_ojima
0
220
Featured
See All Featured
The Language of Interfaces
destraynor
154
24k
Adopting Sorbet at Scale
ufuk
73
9.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
It's Worth the Effort
3n
183
27k
Automating Front-end Workflow
addyosmani
1366
200k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
420
Become a Pro
speakerdeck
PRO
25
5k
Optimising Largest Contentful Paint
csswizardry
33
3k
RailsConf 2023
tenderlove
29
920
Transcript
Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜 株式会社カケハシ 小田中 育生、椎葉 光行 2024.04.17
小田中 育生(おだなか いくお) 株式会社ナビタイムジャパンでVP of Engineeringを務め、 2023年10月にエンジニアリングマネージャーとして株式会社カケ ハシにジョイン。テクノロジーとドメインに関する深い知識や経 験をもって高速に仮設検証のサイクルを回すチームづくりとチー ムを起点にした事業価値最大化に確約・集中・公開・尊敬・勇気
している。 東京都町田市在住。 著書に『いちばんやさしいアジャイル開発の教本 人気講師が教え るDXを支える開発手法』(2020年、インプレス、共著)がある。 ブログ: dora_e_m|note
椎葉 光行(しいば みつゆき) • 新規事業のプロダクトエンジニア ◦ バックエンド・フロントエンド・インフラを見てる ◦ 軸足はバックエンド •
経歴 ◦ 楽天グループ株式会社(30代) ◦ CircleCI合同会社(1年) ◦ 株式会社カケハシ(2023年4月〜) • 大阪の自宅からフルリモートで仕事をしてる ◦ 分割キーボードのMoonlander気に入ってる→ X: @bufferings
私達が働くチーム
© KAKEHASHI Inc. チームyabusame
© KAKEHASHI Inc. 私達はフルリモートで働いている 北は北海道、ミナミは大阪まで。 だから、毎日のコミュニケーションはSlack上で 行われるものが大半。
© KAKEHASHI Inc. そのわりによく集まる(月イチくらい?) みんなで インセプションデッキを 作ったり おぎじゅんさんに コーヒー 淹れてもらったり
© KAKEHASHI Inc. この人たち、遊んでるのでは… LGTM画像の バラエティが 異様に豊富
Findy Team+で チームを見てみる
© KAKEHASHI Inc. いわゆるFour Keys
そんな私たちが働く カケハシ
© KAKEHASHI Inc. カケハシってどんな会社? Mission 日本の医療体験を、しなやかに。 Vision 明日の医療の基盤となる、 エコシステムの実現。
© KAKEHASHI Inc. 医療体験をしなやかにするため頑張ってます
© KAKEHASHI Inc. 新規事業でプロダクト開発をしています 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い
© KAKEHASHI Inc. 不確実性が高い!なので・・・ 仮説検証ループを すばやく回したい!
チームを支える ツール
トランクベース開発 詳しくききたいとことかあったらXで声をかけてね! (@bufferings)
© KAKEHASHI Inc. トランクベース開発 mainブランチ(トランク = 幹)に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/
(アクセス日 2024-04-07) mainに直接コミットしていくスタイル 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル
© KAKEHASHI Inc. トランクベース開発 mainブランチ(トランク = 幹)に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/
(アクセス日 2024-04-07) こっちでやってるよ→ 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル
© KAKEHASHI Inc. ある日のこと・・・ 毎日本番環境にデプロイしてるのいいですね!!!!! というかこれ、トランクベース開発ですよね!!??? うぉー!!!!! やっぱりこれ、トランクベース開発ですか???
© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい!
© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく
対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない
© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく
対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない ので、トランクベース開発を参考にして仕組みを作った ら、周りから見てもトランクベース開発になってた!わーい!
© KAKEHASHI Inc. 実際にどうやってるの? こんな感じでほぼ毎日本番環境へデプロイしてる
© KAKEHASHI Inc. 3つの工夫 (1)CIとCDを分けている (2)フィーチャーフラグを使っている (3)制約を受け入れている 工夫を3つ紹介するよー!
© KAKEHASHI Inc. (1)CIとCDを分けている コード用リポジトリ(モノリポ)と、デプロイ用リポジトリを別にしている
© KAKEHASHI Inc. (1)CIとCDを分けている もうちょっと詳しく
© KAKEHASHI Inc. (1)CIとCDを分けている もうちょっと詳しく このへん自動 ここワンクリック
© KAKEHASHI Inc. (1)CIとCDを分けている なぜ? • 本番環境にデプロイする前にステージング環境へデプロイしたい • でも、あんまり複雑なブランチモデルにはしたくない •
それに、ステージング環境と本番環境で同じコンテナイメージを使いたい → CIとCDを分けると良さそう 思いがけず便利 • プルリクエストの履歴がデプロイの履歴になる • デプロイのプルリクエストをリバートするとロールバックになる
© KAKEHASHI Inc. (2)フィーチャーフラグを使っている 開発中の機能をユーザーから隠すためにフィーチャーフラグを使っている • 社内ユーザーだけが新機能を使えるようにしている • OKだねってなったらフラグをはずして全ユーザーに展開
フィーチャーフラグで気をつけていること 極力使わない!!! えー!
分岐が入って コードが複雑になるから
© KAKEHASHI Inc. (2)フィーチャーフラグを使っている 極力使わない • 使わなくていいなら使わない ◦ 最初から全ユーザーに使ってもらって大丈夫ならそうする •
用途を限定 ◦ デプロイ時に機能を隠すためだけに使う ◦ ユーザーによる機能の出し分けには使わない(恒久利用しない) • 削除を常に考える ← とても大切 ◦ 実装前に「どうフラグを削除するか」をPdMと話し合う ◦ 全ユーザーに公開したらすぐにフラグに関係するコード分岐を削除する
© KAKEHASHI Inc. (3)制約を受け入れている (3−1)本番環境を壊さないように変更する (3−2)デプロイされる順番に気をつける (3−3)チームでひとつずつ作る トランクベース開発をするにあたって 受け入れている制約を3つ紹介するよー!
© KAKEHASHI Inc. (3−1)本番環境を壊さないように変更する これが最重要 • ひとつひとつの変更が本番環境を壊さないように分割する • 機能を隠している場合は新旧両方で正しく動くように作る なので
• 複雑な機能は最初にPoCを作って全体像を把握してから順番を決めている ちからが試されるとこー!
© KAKEHASHI Inc. (3−2)デプロイされる順番に気をつける これも重要 • モノリポでデプロイを自動化しているので ◦ 複数のアプリケーションが同時に変更・デプロイされる •
CDではデプロイの順番の細かい制御をしていない ◦ それによってデプロイのフローをシンプルにしている • だから、タスク分割の段階でデプロイされる順番に気をつけている ◦ デプロイの途中で現行バージョンと新バージョンが混ざっても 正しく動くように分割してデプロイする必要がある シンプルさを大切にしてるよ
© KAKEHASHI Inc. (3−3)チームでひとつずつ作る • チームで1つのユーザーストーリーに取り組む ◦ 複数のユーザーストーリーを同時に進めない ◦ 1つずつ最速で届ける
• モブプログラミングやペアプログラミングで取り組んでいる チーム全員で同じ課題に取り組むモビング大切!
© KAKEHASHI Inc. 3つの工夫 (1)CIとCDを分けている (2)フィーチャーフラグを使っている (3)制約を受け入れている トランクベース開発のフローをシンプルにして開発スピードを保っている!
その結果
© KAKEHASHI Inc. 新規プロダクトの仮説検証ループをすばやく回し続けるためのプロダクトエンジニアリング https://speakerdeck.com/kakehashi/pdenight3?slide=6 より
© KAKEHASHI Inc. 仮説検証ループを すばやく回せてる!!! やったー!!!
今はこんな感じだけど 最初からこうだった わけじゃない
© KAKEHASHI Inc. 立ち上げ期のカオスからチームの型へ サービスの運用が始まると開発スタイルは変わる カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を
見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人
カルチャーを編む
© KAKEHASHI Inc. カオスを駆け抜けたチーム
© KAKEHASHI Inc. いったんのゴールは達成した クローズドβはローンチできた。俺達の戦いはこれからだ! カオスを選択して 駆け抜けた クローズドβ ローンチ
© KAKEHASHI Inc. 次は何を目指す? サービスを良くしていくことはやりたい。具体的に、何を目指す? カオスを選択して 駆け抜けた クローズドβ ローンチ ???
© KAKEHASHI Inc. そんな中、チームに仲間が増えたよ!
© KAKEHASHI Inc. 僕たちが目指すゴールはなんだろう 目指す ゴール
© KAKEHASHI Inc. そもそも、ゴールが変わっていく状況 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い
© KAKEHASHI Inc. 変化するゴールに対して、僕たちはどうありたい? ありたい 姿
© KAKEHASHI Inc. それを話すため、インセプションデッキを作った
© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため •
上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため •
上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
© KAKEHASHI Inc. 価値を届けたい、という共通の目的ができた 仮説検証ループを すばやく回したい! だからこそ「仮説検証ループを回そう」という意識が生まれた
© KAKEHASHI Inc. もうひとつ作ったのが、ワーキングアグリーメント
© KAKEHASHI Inc. チームに息づくワーキングアグリーメント
ところで、なんで ワーキングアグリーメントを 作りたいんだっけ?
© KAKEHASHI Inc. 僕たちはバックグラウンドが違う。意見も違う。 こっち! そっち! あっち! どっち?
© KAKEHASHI Inc. 迷ったときの道しるべとしてWAを作りたかった
それも、一気につくるのではなく ちょっとずつ作っていきたかった
© KAKEHASHI Inc. そのときのチームはDevに振り切っていた Badプラクティスを選んで失敗しながら進めた新規プロダクト開発 (https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices) より
© KAKEHASHI Inc. やりたいことはある 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく
対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない
© KAKEHASHI Inc. やりたいことは、できてる? 仮説検証ループを すばやく回したい! 仮説検証ループを すばやく回せたか?
© KAKEHASHI Inc. 検査と適応 仮説検証ループを すばやく回したい! 仮説検証ループを すばやく回せたか?
© KAKEHASHI Inc. 毎週ふりかえりをする 毎週ふりかえりをやった。毎回、違うプラクティスを採用した。 チームの状況にあわせて手法を選んでいた。
© KAKEHASHI Inc. 大切にしていたこと チームの学びを最大化すること。 実験が多かったスプリントではCelebration Gridsを。 深い対話をしたいタイミングではLean Coffeeを。 具体的なアクションを出すことより、
ふりかえりの時間に交わされる対話を通して 学びが最大化することを大切にした。
© KAKEHASHI Inc. 毎回、ほぼ全員が参加するふりかえり
© KAKEHASHI Inc. 自然に変化していく土壌ができていった 次はモブプロでやってみる? これ、ワーキングアグリーメントに 書いておきたいね。 チームの会議は、(Slackの)Huddleで 統一してみない?
© KAKEHASHI Inc. そうやって型を見つけていった 継続的な価値貢献を実現するために、DevチームからDevOpsチームになっていった カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を
見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人
変化するチーム
5:2:3
© KAKEHASHI Inc. 新規開発とエンジニア提案の割合についてのWA
© KAKEHASHI Inc. プロダクトが成長すると開発の労力は増す チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト
価値貢献に 必要な労力
© KAKEHASHI Inc. カイゼンは労力を小さくし、スピードを保つ チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト
カ イ ゼ ン 価値貢献に 必要な労力
モビング
© KAKEHASHI Inc. 暗黙知の共有 元からいたメンバー 新しいメンバー プロダクト
© KAKEHASHI Inc. 構造的にユーザーストーリーへ集中してしまう 5:2:3 トランクベースとの相性の良さ 新メンバーとの暗黙知との共有 1つの物事に集中するがゆえに 5:2:3で取り組めない
エンジニアが ペア中心の モビング
© KAKEHASHI Inc. 数ヶ月のモブ期間で暗黙知は共有された 元からいたメンバー 新しいメンバー プロダクト
© KAKEHASHI Inc. モブの中で役割分担をした 元からいたメンバー 新しいメンバー プロダクト 開発者体験の向上 ユーザーストーリー の開発
© KAKEHASHI Inc. この体制でついに5:2:3が機能 5:2:3
同じものを見ているPdM
© KAKEHASHI Inc. 5:2:3 エンジニアにとっては嬉しい 5:2:3
© KAKEHASHI Inc. 5:2:3 PdMにとってはあまりにも大胆 5:2:3 マジ すか?
© KAKEHASHI Inc. 大事なのは仮説検証 仮説検証ループを すばやく回したい! ポイントは「仮説検証ループをすばやく回せるか」
© KAKEHASHI Inc. 成果を元に、このWAを受け入れてくれた 5:2:3 いい ですね! 目先の不安感ではなく、実際の成果で判断してくれた
© KAKEHASHI Inc. ユーザーストーリーの分解もPdMが貢献 こんな感じでほぼ毎日本番環境へデプロイしてる
© KAKEHASHI Inc. 毎日、朝会の後にプチリファインメント ユーザー ストーリー ユーザー ストーリー ユーザー ストーリー
チームでユーザーストーリーをブラッシュアップして、プランニングするころには 十分に小さなサイズのユーザーストーリーになっている
© KAKEHASHI Inc. 壁ごしに仕事を投げるのではなく、ともに働く関係
まとめ
私達は 何を大切にしているのか
© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため •
上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
価値貢献に集中!
© KAKEHASHI Inc. 価値貢献のために仮説検証ループを回したい! 仮説検証ループを すばやく回したい!
© KAKEHASHI Inc. 結果として開発生産性指標はいい感じ
© KAKEHASHI Inc. そして、楽しく働けていそう WevoxのスコアはAランク
© KAKEHASHI Inc. リリースノートをたくさん出した
© KAKEHASHI Inc. エンジニアとCSのやりとり
© KAKEHASHI Inc. CSからの声
© KAKEHASHI Inc. お客様の声 「機能改善の速さに驚いている。 出した声が反映されるのでありがたい」
価値貢献できてる!
僕たちが大切にしていた ツールとカルチャー
© KAKEHASHI Inc. ふりかえるとベストプラクティスだったもの • トランクベース開発 ◦ CI/CDの分離 ◦ ここ一番でのフィーチャーフラグ
◦ 制約を受け入れる(WIP制限など) • 5:2:3フォーメーション • モビング • ペア中心のモビング • チーム全員での目線合わせ
© KAKEHASHI Inc. 少し抽象化すると・・・ • トランクベース開発 • カイゼンの余地を残すタスクマネジメント • 状況に合わせたモブ・ペアのフォーメーション
チェンジ • チーム全員での目線合わせ
© KAKEHASHI Inc. ツールとカルチャー カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア
PdMとの協働 トランクベース開発 5:2:3
© KAKEHASHI Inc. ツールとカルチャーと価値貢献 カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア
PdMとの協働 トランクベース開発 5:2:3 価値貢献
価値貢献のために 変化し続ける 変化し続けるために 開発者体験を良くし続ける
Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜