Slide 1

Slide 1 text

Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜 株式会社カケハシ 小田中 育生、椎葉 光行 2024.04.17

Slide 2

Slide 2 text

小田中 育生(おだなか いくお) 株式会社ナビタイムジャパンでVP of Engineeringを務め、 2023年10月にエンジニアリングマネージャーとして株式会社カケ ハシにジョイン。テクノロジーとドメインに関する深い知識や経 験をもって高速に仮設検証のサイクルを回すチームづくりとチー ムを起点にした事業価値最大化に確約・集中・公開・尊敬・勇気 している。 東京都町田市在住。 著書に『いちばんやさしいアジャイル開発の教本 人気講師が教え るDXを支える開発手法』(2020年、インプレス、共著)がある。 ブログ: dora_e_m|note

Slide 3

Slide 3 text

椎葉 光行(しいば みつゆき) ● 新規事業のプロダクトエンジニア ○ バックエンド・フロントエンド・インフラを見てる ○ 軸足はバックエンド ● 経歴 ○ 楽天グループ株式会社(30代) ○ CircleCI合同会社(1年) ○ 株式会社カケハシ(2023年4月〜) ● 大阪の自宅からフルリモートで仕事をしてる ○ 分割キーボードのMoonlander気に入ってる→ X: @bufferings

Slide 4

Slide 4 text

私達が働くチーム

Slide 5

Slide 5 text

© KAKEHASHI Inc. チームyabusame

Slide 6

Slide 6 text

© KAKEHASHI Inc. 私達はフルリモートで働いている 北は北海道、ミナミは大阪まで。 だから、毎日のコミュニケーションはSlack上で 行われるものが大半。

Slide 7

Slide 7 text

© KAKEHASHI Inc. そのわりによく集まる(月イチくらい?) みんなで インセプションデッキを 作ったり おぎじゅんさんに コーヒー 淹れてもらったり

Slide 8

Slide 8 text

© KAKEHASHI Inc. この人たち、遊んでるのでは… LGTM画像の バラエティが 異様に豊富

Slide 9

Slide 9 text

Findy Team+で チームを見てみる

Slide 10

Slide 10 text

© KAKEHASHI Inc. いわゆるFour Keys

Slide 11

Slide 11 text

そんな私たちが働く カケハシ

Slide 12

Slide 12 text

© KAKEHASHI Inc. カケハシってどんな会社? Mission 日本の医療体験を、しなやかに。 Vision 明日の医療の基盤となる、 エコシステムの実現。

Slide 13

Slide 13 text

© KAKEHASHI Inc. 医療体験をしなやかにするため頑張ってます

Slide 14

Slide 14 text

© KAKEHASHI Inc. 新規事業でプロダクト開発をしています 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い

Slide 15

Slide 15 text

© KAKEHASHI Inc. 不確実性が高い!なので・・・ 仮説検証ループを すばやく回したい!

Slide 16

Slide 16 text

チームを支える ツール

Slide 17

Slide 17 text

トランクベース開発 詳しくききたいとことかあったらXで声をかけてね! (@bufferings)

Slide 18

Slide 18 text

© KAKEHASHI Inc. トランクベース開発 mainブランチ(トランク = 幹)に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/ (アクセス日 2024-04-07) mainに直接コミットしていくスタイル 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル

Slide 19

Slide 19 text

© KAKEHASHI Inc. トランクベース開発 mainブランチ(トランク = 幹)に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/ (アクセス日 2024-04-07) こっちでやってるよ→ 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル

Slide 20

Slide 20 text

© KAKEHASHI Inc. ある日のこと・・・ 毎日本番環境にデプロイしてるのいいですね!!!!! というかこれ、トランクベース開発ですよね!!??? うぉー!!!!! やっぱりこれ、トランクベース開発ですか???

Slide 21

Slide 21 text

© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい!

Slide 22

Slide 22 text

© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない

Slide 23

Slide 23 text

© KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない ので、トランクベース開発を参考にして仕組みを作った ら、周りから見てもトランクベース開発になってた!わーい!

Slide 24

Slide 24 text

© KAKEHASHI Inc. 実際にどうやってるの? こんな感じでほぼ毎日本番環境へデプロイしてる

Slide 25

Slide 25 text

© KAKEHASHI Inc. 3つの工夫 (1)CIとCDを分けている (2)フィーチャーフラグを使っている (3)制約を受け入れている 工夫を3つ紹介するよー!

Slide 26

Slide 26 text

© KAKEHASHI Inc. (1)CIとCDを分けている コード用リポジトリ(モノリポ)と、デプロイ用リポジトリを別にしている

Slide 27

Slide 27 text

© KAKEHASHI Inc. (1)CIとCDを分けている もうちょっと詳しく

Slide 28

Slide 28 text

© KAKEHASHI Inc. (1)CIとCDを分けている もうちょっと詳しく このへん自動 ここワンクリック

Slide 29

Slide 29 text

© KAKEHASHI Inc. (1)CIとCDを分けている なぜ? ● 本番環境にデプロイする前にステージング環境へデプロイしたい ● でも、あんまり複雑なブランチモデルにはしたくない ● それに、ステージング環境と本番環境で同じコンテナイメージを使いたい → CIとCDを分けると良さそう 思いがけず便利 ● プルリクエストの履歴がデプロイの履歴になる ● デプロイのプルリクエストをリバートするとロールバックになる

Slide 30

Slide 30 text

© KAKEHASHI Inc. (2)フィーチャーフラグを使っている 開発中の機能をユーザーから隠すためにフィーチャーフラグを使っている ● 社内ユーザーだけが新機能を使えるようにしている ● OKだねってなったらフラグをはずして全ユーザーに展開

Slide 31

Slide 31 text

フィーチャーフラグで気をつけていること 極力使わない!!! えー!

Slide 32

Slide 32 text

分岐が入って コードが複雑になるから

Slide 33

Slide 33 text

© KAKEHASHI Inc. (2)フィーチャーフラグを使っている 極力使わない ● 使わなくていいなら使わない ○ 最初から全ユーザーに使ってもらって大丈夫ならそうする ● 用途を限定 ○ デプロイ時に機能を隠すためだけに使う ○ ユーザーによる機能の出し分けには使わない(恒久利用しない) ● 削除を常に考える ← とても大切 ○ 実装前に「どうフラグを削除するか」をPdMと話し合う ○ 全ユーザーに公開したらすぐにフラグに関係するコード分岐を削除する

Slide 34

Slide 34 text

© KAKEHASHI Inc. (3)制約を受け入れている (3−1)本番環境を壊さないように変更する (3−2)デプロイされる順番に気をつける (3−3)チームでひとつずつ作る トランクベース開発をするにあたって 受け入れている制約を3つ紹介するよー!

Slide 35

Slide 35 text

© KAKEHASHI Inc. (3−1)本番環境を壊さないように変更する これが最重要 ● ひとつひとつの変更が本番環境を壊さないように分割する ● 機能を隠している場合は新旧両方で正しく動くように作る なので ● 複雑な機能は最初にPoCを作って全体像を把握してから順番を決めている ちからが試されるとこー!

Slide 36

Slide 36 text

© KAKEHASHI Inc. (3−2)デプロイされる順番に気をつける これも重要 ● モノリポでデプロイを自動化しているので ○ 複数のアプリケーションが同時に変更・デプロイされる ● CDではデプロイの順番の細かい制御をしていない ○ それによってデプロイのフローをシンプルにしている ● だから、タスク分割の段階でデプロイされる順番に気をつけている ○ デプロイの途中で現行バージョンと新バージョンが混ざっても 正しく動くように分割してデプロイする必要がある シンプルさを大切にしてるよ

Slide 37

Slide 37 text

© KAKEHASHI Inc. (3−3)チームでひとつずつ作る ● チームで1つのユーザーストーリーに取り組む ○ 複数のユーザーストーリーを同時に進めない ○ 1つずつ最速で届ける ● モブプログラミングやペアプログラミングで取り組んでいる チーム全員で同じ課題に取り組むモビング大切!

Slide 38

Slide 38 text

© KAKEHASHI Inc. 3つの工夫 (1)CIとCDを分けている (2)フィーチャーフラグを使っている (3)制約を受け入れている トランクベース開発のフローをシンプルにして開発スピードを保っている!

Slide 39

Slide 39 text

その結果

Slide 40

Slide 40 text

© KAKEHASHI Inc. 新規プロダクトの仮説検証ループをすばやく回し続けるためのプロダクトエンジニアリング https://speakerdeck.com/kakehashi/pdenight3?slide=6 より

Slide 41

Slide 41 text

© KAKEHASHI Inc. 仮説検証ループを すばやく回せてる!!! やったー!!!

Slide 42

Slide 42 text

今はこんな感じだけど 最初からこうだった わけじゃない

Slide 43

Slide 43 text

© KAKEHASHI Inc. 立ち上げ期のカオスからチームの型へ サービスの運用が始まると開発スタイルは変わる カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を 見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人

Slide 44

Slide 44 text

カルチャーを編む

Slide 45

Slide 45 text

© KAKEHASHI Inc. カオスを駆け抜けたチーム

Slide 46

Slide 46 text

© KAKEHASHI Inc. いったんのゴールは達成した クローズドβはローンチできた。俺達の戦いはこれからだ! カオスを選択して 駆け抜けた クローズドβ ローンチ

Slide 47

Slide 47 text

© KAKEHASHI Inc. 次は何を目指す? サービスを良くしていくことはやりたい。具体的に、何を目指す? カオスを選択して 駆け抜けた クローズドβ ローンチ ???

Slide 48

Slide 48 text

© KAKEHASHI Inc. そんな中、チームに仲間が増えたよ!

Slide 49

Slide 49 text

© KAKEHASHI Inc. 僕たちが目指すゴールはなんだろう 目指す ゴール

Slide 50

Slide 50 text

© KAKEHASHI Inc. そもそも、ゴールが変わっていく状況 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い

Slide 51

Slide 51 text

© KAKEHASHI Inc. 変化するゴールに対して、僕たちはどうありたい? ありたい 姿

Slide 52

Slide 52 text

© KAKEHASHI Inc. それを話すため、インセプションデッキを作った

Slide 53

Slide 53 text

© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか ● XX事業の推進へ貢献するため ● プロダクトやチームの枠を超えたプロフェッショナル集団であるため ● 上記のためには、手段を問わない エレベーターピッチ ● 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 ● 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます

Slide 54

Slide 54 text

© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか ● XX事業の推進へ貢献するため ● プロダクトやチームの枠を超えたプロフェッショナル集団であるため ● 上記のためには、手段を問わない エレベーターピッチ ● 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 ● 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます

Slide 55

Slide 55 text

© KAKEHASHI Inc. 価値を届けたい、という共通の目的ができた 仮説検証ループを すばやく回したい! だからこそ「仮説検証ループを回そう」という意識が生まれた

Slide 56

Slide 56 text

© KAKEHASHI Inc. もうひとつ作ったのが、ワーキングアグリーメント

Slide 57

Slide 57 text

© KAKEHASHI Inc. チームに息づくワーキングアグリーメント

Slide 58

Slide 58 text

ところで、なんで ワーキングアグリーメントを 作りたいんだっけ?

Slide 59

Slide 59 text

© KAKEHASHI Inc. 僕たちはバックグラウンドが違う。意見も違う。 こっち! そっち! あっち! どっち?

Slide 60

Slide 60 text

© KAKEHASHI Inc. 迷ったときの道しるべとしてWAを作りたかった

Slide 61

Slide 61 text

それも、一気につくるのではなく ちょっとずつ作っていきたかった

Slide 62

Slide 62 text

© KAKEHASHI Inc. そのときのチームはDevに振り切っていた Badプラクティスを選んで失敗しながら進めた新規プロダクト開発 (https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices) より

Slide 63

Slide 63 text

© KAKEHASHI Inc. やりたいことはある 仮説検証ループを すばやく回したい! 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない

Slide 64

Slide 64 text

© KAKEHASHI Inc. やりたいことは、できてる? 仮説検証ループを すばやく回したい! 仮説検証ループを すばやく回せたか?

Slide 65

Slide 65 text

© KAKEHASHI Inc. 検査と適応 仮説検証ループを すばやく回したい! 仮説検証ループを すばやく回せたか?

Slide 66

Slide 66 text

© KAKEHASHI Inc. 毎週ふりかえりをする 毎週ふりかえりをやった。毎回、違うプラクティスを採用した。 チームの状況にあわせて手法を選んでいた。

Slide 67

Slide 67 text

© KAKEHASHI Inc. 大切にしていたこと チームの学びを最大化すること。 実験が多かったスプリントではCelebration Gridsを。 深い対話をしたいタイミングではLean Coffeeを。 具体的なアクションを出すことより、 ふりかえりの時間に交わされる対話を通して 学びが最大化することを大切にした。

Slide 68

Slide 68 text

© KAKEHASHI Inc. 毎回、ほぼ全員が参加するふりかえり

Slide 69

Slide 69 text

© KAKEHASHI Inc. 自然に変化していく土壌ができていった 次はモブプロでやってみる? これ、ワーキングアグリーメントに 書いておきたいね。 チームの会議は、(Slackの)Huddleで 統一してみない?

Slide 70

Slide 70 text

© KAKEHASHI Inc. そうやって型を見つけていった 継続的な価値貢献を実現するために、DevチームからDevOpsチームになっていった カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を 見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人

Slide 71

Slide 71 text

変化するチーム

Slide 72

Slide 72 text

5:2:3

Slide 73

Slide 73 text

© KAKEHASHI Inc. 新規開発とエンジニア提案の割合についてのWA

Slide 74

Slide 74 text

© KAKEHASHI Inc. プロダクトが成長すると開発の労力は増す チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト 価値貢献に 必要な労力

Slide 75

Slide 75 text

© KAKEHASHI Inc. カイゼンは労力を小さくし、スピードを保つ チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト カ イ ゼ ン 価値貢献に 必要な労力

Slide 76

Slide 76 text

モビング

Slide 77

Slide 77 text

© KAKEHASHI Inc. 暗黙知の共有 元からいたメンバー 新しいメンバー プロダクト

Slide 78

Slide 78 text

© KAKEHASHI Inc. 構造的にユーザーストーリーへ集中してしまう 5:2:3 トランクベースとの相性の良さ 新メンバーとの暗黙知との共有 1つの物事に集中するがゆえに 5:2:3で取り組めない

Slide 79

Slide 79 text

エンジニアが ペア中心の モビング

Slide 80

Slide 80 text

© KAKEHASHI Inc. 数ヶ月のモブ期間で暗黙知は共有された 元からいたメンバー 新しいメンバー プロダクト

Slide 81

Slide 81 text

© KAKEHASHI Inc. モブの中で役割分担をした 元からいたメンバー 新しいメンバー プロダクト 開発者体験の向上 ユーザーストーリー の開発

Slide 82

Slide 82 text

© KAKEHASHI Inc. この体制でついに5:2:3が機能 5:2:3

Slide 83

Slide 83 text

同じものを見ているPdM

Slide 84

Slide 84 text

© KAKEHASHI Inc. 5:2:3 エンジニアにとっては嬉しい 5:2:3

Slide 85

Slide 85 text

© KAKEHASHI Inc. 5:2:3 PdMにとってはあまりにも大胆 5:2:3 マジ すか?

Slide 86

Slide 86 text

© KAKEHASHI Inc. 大事なのは仮説検証 仮説検証ループを すばやく回したい! ポイントは「仮説検証ループをすばやく回せるか」

Slide 87

Slide 87 text

© KAKEHASHI Inc. 成果を元に、このWAを受け入れてくれた 5:2:3 いい ですね! 目先の不安感ではなく、実際の成果で判断してくれた

Slide 88

Slide 88 text

© KAKEHASHI Inc. ユーザーストーリーの分解もPdMが貢献 こんな感じでほぼ毎日本番環境へデプロイしてる

Slide 89

Slide 89 text

© KAKEHASHI Inc. 毎日、朝会の後にプチリファインメント ユーザー ストーリー ユーザー ストーリー ユーザー ストーリー チームでユーザーストーリーをブラッシュアップして、プランニングするころには 十分に小さなサイズのユーザーストーリーになっている

Slide 90

Slide 90 text

© KAKEHASHI Inc. 壁ごしに仕事を投げるのではなく、ともに働く関係

Slide 91

Slide 91 text

まとめ

Slide 92

Slide 92 text

私達は 何を大切にしているのか

Slide 93

Slide 93 text

© KAKEHASHI Inc. インセプションデッキ(一部) われわれはなぜここにいるのか ● XX事業の推進へ貢献するため ● プロダクトやチームの枠を超えたプロフェッショナル集団であるため ● 上記のためには、手段を問わない エレベーターピッチ ● 我々は、事業拡大に向けて患者さん/薬局/医薬品卸/製薬会社/国といった各ス テークホルダーへの提供価値を最大化します。 ● 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます

Slide 94

Slide 94 text

価値貢献に集中!

Slide 95

Slide 95 text

© KAKEHASHI Inc. 価値貢献のために仮説検証ループを回したい! 仮説検証ループを すばやく回したい!

Slide 96

Slide 96 text

© KAKEHASHI Inc. 結果として開発生産性指標はいい感じ

Slide 97

Slide 97 text

© KAKEHASHI Inc. そして、楽しく働けていそう WevoxのスコアはAランク

Slide 98

Slide 98 text

© KAKEHASHI Inc. リリースノートをたくさん出した

Slide 99

Slide 99 text

© KAKEHASHI Inc. エンジニアとCSのやりとり

Slide 100

Slide 100 text

© KAKEHASHI Inc. CSからの声

Slide 101

Slide 101 text

© KAKEHASHI Inc. お客様の声 「機能改善の速さに驚いている。
  出した声が反映されるのでありがたい」

Slide 102

Slide 102 text

価値貢献できてる!

Slide 103

Slide 103 text

僕たちが大切にしていた ツールとカルチャー

Slide 104

Slide 104 text

© KAKEHASHI Inc. ふりかえるとベストプラクティスだったもの ● トランクベース開発 ○ CI/CDの分離 ○ ここ一番でのフィーチャーフラグ ○ 制約を受け入れる(WIP制限など) ● 5:2:3フォーメーション ● モビング ● ペア中心のモビング ● チーム全員での目線合わせ

Slide 105

Slide 105 text

© KAKEHASHI Inc. 少し抽象化すると・・・ ● トランクベース開発 ● カイゼンの余地を残すタスクマネジメント ● 状況に合わせたモブ・ペアのフォーメーション チェンジ ● チーム全員での目線合わせ

Slide 106

Slide 106 text

© KAKEHASHI Inc. ツールとカルチャー カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア PdMとの協働 トランクベース開発 5:2:3

Slide 107

Slide 107 text

© KAKEHASHI Inc. ツールとカルチャーと価値貢献 カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア PdMとの協働 トランクベース開発 5:2:3 価値貢献

Slide 108

Slide 108 text

価値貢献のために 変化し続ける 変化し続けるために 開発者体験を良くし続ける

Slide 109

Slide 109 text

Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜