Value Driven DevOps Team

Transcript

1. Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜 株式会社カケハシ　小田中 育生、椎葉 光行 2024.04.17
2. 小田中 育生(おだなか いくお) 株式会社ナビタイムジャパンでVP of Engineeringを務め、 2023年10月にエンジニアリングマネージャーとして株式会社カケ ハシにジョイン。テクノロジーとドメインに関する深い知識や経 験をもって高速に仮設検証のサイクルを回すチームづくりとチー ムを起点にした事業価値最大化に確約・集中・公開・尊敬・勇気 している。 東京都町田市在住。 著書に『いちばんやさしいアジャイル開発の教本 人気講師が教え るDXを支える開発手法』（2020年、インプレス、共著）がある。 ブログ: dora_e_m｜note
3. 椎葉 光行（しいば みつゆき） • 新規事業のプロダクトエンジニア ◦ バックエンド・フロントエンド・インフラを見てる ◦ 軸足はバックエンド • 経歴 ◦ 楽天グループ株式会社（30代） ◦ CircleCI合同会社（1年） ◦ 株式会社カケハシ（2023年4月〜） • 大阪の自宅からフルリモートで仕事をしてる ◦ 分割キーボードのMoonlander気に入ってる→ X: @bufferings
4. 私達が働くチーム
5. © KAKEHASHI Inc. チームyabusame
6. © KAKEHASHI Inc. 私達はフルリモートで働いている 北は北海道、ミナミは大阪まで。 だから、毎日のコミュニケーションはSlack上で 行われるものが大半。
7. © KAKEHASHI Inc. そのわりによく集まる（月イチくらい？） みんなで インセプションデッキを 作ったり おぎじゅんさんに コーヒー 淹れてもらったり
8. © KAKEHASHI Inc. この人たち、遊んでるのでは… LGTM画像の バラエティが 異様に豊富
9. Findy Team+で チームを見てみる
10. © KAKEHASHI Inc. いわゆるFour Keys
11. そんな私たちが働く カケハシ
12. © KAKEHASHI Inc. カケハシってどんな会社？ Mission 日本の医療体験を、しなやかに。 Vision 明日の医療の基盤となる、 エコシステムの実現。
13. © KAKEHASHI Inc. 医療体験をしなやかにするため頑張ってます
14. © KAKEHASHI Inc. 新規事業でプロダクト開発をしています 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い
15. © KAKEHASHI Inc. 不確実性が高い！なので・・・ 仮説検証ループを すばやく回したい！
16. チームを支える ツール
17. トランクベース開発 詳しくききたいとことかあったらXで声をかけてね！ （@bufferings）
18. © KAKEHASHI Inc. トランクベース開発 mainブランチ（トランク = 幹）に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/ （アクセス日 2024-04-07） mainに直接コミットしていくスタイル 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル
19. © KAKEHASHI Inc. トランクベース開発 mainブランチ（トランク = 幹）に細かく修正を加えていくブランチモデル 参照 - https://trunkbaseddevelopment.com/ （アクセス日 2024-04-07） こっちでやってるよ→ 寿命の短いフィーチャーブランチを作って プルリクエストでマージしていくスタイル
20. © KAKEHASHI Inc. ある日のこと・・・ 毎日本番環境にデプロイしてるのいいですね！！！！！ というかこれ、トランクベース開発ですよね！！？？？ うぉー！！！！！ やっぱりこれ、トランクベース開発ですか？？？
21. © KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい！
22. © KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい！ 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない
23. © KAKEHASHI Inc. 意識してたこと 仮説検証ループを すばやく回したい！ 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない ので、トランクベース開発を参考にして仕組みを作った ら、周りから見てもトランクベース開発になってた！わーい！
24. © KAKEHASHI Inc. 実際にどうやってるの？ こんな感じでほぼ毎日本番環境へデプロイしてる
25. © KAKEHASHI Inc. 3つの工夫 （１）CIとCDを分けている （２）フィーチャーフラグを使っている （３）制約を受け入れている 工夫を3つ紹介するよー！
26. © KAKEHASHI Inc. （１）CIとCDを分けている コード用リポジトリ（モノリポ）と、デプロイ用リポジトリを別にしている
27. © KAKEHASHI Inc. （１）CIとCDを分けている もうちょっと詳しく
28. © KAKEHASHI Inc. （１）CIとCDを分けている もうちょっと詳しく このへん自動 ここワンクリック
29. © KAKEHASHI Inc. （１）CIとCDを分けている なぜ？ • 本番環境にデプロイする前にステージング環境へデプロイしたい • でも、あんまり複雑なブランチモデルにはしたくない • それに、ステージング環境と本番環境で同じコンテナイメージを使いたい → CIとCDを分けると良さそう 思いがけず便利 • プルリクエストの履歴がデプロイの履歴になる • デプロイのプルリクエストをリバートするとロールバックになる
30. © KAKEHASHI Inc. （２）フィーチャーフラグを使っている 開発中の機能をユーザーから隠すためにフィーチャーフラグを使っている • 社内ユーザーだけが新機能を使えるようにしている • OKだねってなったらフラグをはずして全ユーザーに展開
31. フィーチャーフラグで気をつけていること 極力使わない！！！ えー！
32. 分岐が入って コードが複雑になるから
33. © KAKEHASHI Inc. （２）フィーチャーフラグを使っている 極力使わない • 使わなくていいなら使わない ◦ 最初から全ユーザーに使ってもらって大丈夫ならそうする • 用途を限定 ◦ デプロイ時に機能を隠すためだけに使う ◦ ユーザーによる機能の出し分けには使わない（恒久利用しない） • 削除を常に考える ← とても大切 ◦ 実装前に「どうフラグを削除するか」をPdMと話し合う ◦ 全ユーザーに公開したらすぐにフラグに関係するコード分岐を削除する
34. © KAKEHASHI Inc. （３）制約を受け入れている （３−１）本番環境を壊さないように変更する （３−２）デプロイされる順番に気をつける （３−３）チームでひとつずつ作る トランクベース開発をするにあたって 受け入れている制約を3つ紹介するよー！
35. © KAKEHASHI Inc. （３−１）本番環境を壊さないように変更する これが最重要 • ひとつひとつの変更が本番環境を壊さないように分割する • 機能を隠している場合は新旧両方で正しく動くように作る なので • 複雑な機能は最初にPoCを作って全体像を把握してから順番を決めている ちからが試されるとこー！
36. © KAKEHASHI Inc. （３−２）デプロイされる順番に気をつける これも重要 • モノリポでデプロイを自動化しているので ◦ 複数のアプリケーションが同時に変更・デプロイされる • CDではデプロイの順番の細かい制御をしていない ◦ それによってデプロイのフローをシンプルにしている • だから、タスク分割の段階でデプロイされる順番に気をつけている ◦ デプロイの途中で現行バージョンと新バージョンが混ざっても 正しく動くように分割してデプロイする必要がある シンプルさを大切にしてるよ
37. © KAKEHASHI Inc. （３−３）チームでひとつずつ作る • チームで１つのユーザーストーリーに取り組む ◦ 複数のユーザーストーリーを同時に進めない ◦ １つずつ最速で届ける • モブプログラミングやペアプログラミングで取り組んでいる チーム全員で同じ課題に取り組むモビング大切！
38. © KAKEHASHI Inc. 3つの工夫 （１）CIとCDを分けている （２）フィーチャーフラグを使っている （３）制約を受け入れている トランクベース開発のフローをシンプルにして開発スピードを保っている！
39. その結果
40. © KAKEHASHI Inc. 新規プロダクトの仮説検証ループをすばやく回し続けるためのプロダクトエンジニアリング https://speakerdeck.com/kakehashi/pdenight3?slide=6 より
41. © KAKEHASHI Inc. 仮説検証ループを すばやく回せてる！！！ やったー！！！
42. 今はこんな感じだけど 最初からこうだった わけじゃない
43. © KAKEHASHI Inc. 立ち上げ期のカオスからチームの型へ サービスの運用が始まると開発スタイルは変わる カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を 見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人
44. カルチャーを編む
45. © KAKEHASHI Inc. カオスを駆け抜けたチーム
46. © KAKEHASHI Inc. いったんのゴールは達成した クローズドβはローンチできた。俺達の戦いはこれからだ！ カオスを選択して 駆け抜けた クローズドβ ローンチ
47. © KAKEHASHI Inc. 次は何を目指す？ サービスを良くしていくことはやりたい。具体的に、何を目指す？ カオスを選択して 駆け抜けた クローズドβ ローンチ ？？？
48. © KAKEHASHI Inc. そんな中、チームに仲間が増えたよ！
49. © KAKEHASHI Inc. 僕たちが目指すゴールはなんだろう 目指す ゴール
50. © KAKEHASHI Inc. そもそも、ゴールが変わっていく状況 立ち上げ期のプロダクト。 PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い
51. © KAKEHASHI Inc. 変化するゴールに対して、僕たちはどうありたい？ ありたい 姿
52. © KAKEHASHI Inc. それを話すため、インセプションデッキを作った
53. © KAKEHASHI Inc. インセプションデッキ（一部） われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため • 上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん／薬局／医薬品卸／製薬会社／国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
54. © KAKEHASHI Inc. インセプションデッキ（一部） われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため • 上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん／薬局／医薬品卸／製薬会社／国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
55. © KAKEHASHI Inc. 価値を届けたい、という共通の目的ができた 仮説検証ループを すばやく回したい！ だからこそ「仮説検証ループを回そう」という意識が生まれた
56. © KAKEHASHI Inc. もうひとつ作ったのが、ワーキングアグリーメント
57. © KAKEHASHI Inc. チームに息づくワーキングアグリーメント
58. ところで、なんで ワーキングアグリーメントを 作りたいんだっけ？
59. © KAKEHASHI Inc. 僕たちはバックグラウンドが違う。意見も違う。 こっち！ そっち！ あっち！ どっち？
60. © KAKEHASHI Inc. 迷ったときの道しるべとしてWAを作りたかった
61. それも、一気につくるのではなく ちょっとずつ作っていきたかった
62. © KAKEHASHI Inc. そのときのチームはDevに振り切っていた Badプラクティスを選んで失敗しながら進めた新規プロダクト開発 (https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices) より
63. © KAKEHASHI Inc. やりたいことはある 仮説検証ループを すばやく回したい！ 小さな変更を すばやくたくさん 届けたい 変化にすばやく 対応したい 本番環境への デプロイを 日常にしたい ブランチのマージに 時間を使いたくない
64. © KAKEHASHI Inc. やりたいことは、できてる？ 仮説検証ループを すばやく回したい！ 仮説検証ループを すばやく回せたか？
65. © KAKEHASHI Inc. 検査と適応 仮説検証ループを すばやく回したい！ 仮説検証ループを すばやく回せたか？
66. © KAKEHASHI Inc. 毎週ふりかえりをする 毎週ふりかえりをやった。毎回、違うプラクティスを採用した。 チームの状況にあわせて手法を選んでいた。
67. © KAKEHASHI Inc. 大切にしていたこと チームの学びを最大化すること。 実験が多かったスプリントではCelebration Gridsを。 深い対話をしたいタイミングではLean Coffeeを。 具体的なアクションを出すことより、 ふりかえりの時間に交わされる対話を通して 学びが最大化することを大切にした。
68. © KAKEHASHI Inc. 毎回、ほぼ全員が参加するふりかえり
69. © KAKEHASHI Inc. 自然に変化していく土壌ができていった 次はモブプロでやってみる？ これ、ワーキングアグリーメントに 書いておきたいね。 チームの会議は、(Slackの)Huddleで 統一してみない？
70. © KAKEHASHI Inc. そうやって型を見つけていった 継続的な価値貢献を実現するために、DevチームからDevOpsチームになっていった カオスを選択して 駆け抜けた クローズドβ ローンチ チームの型を 見つけていった トランクベース開発 ←カオスからチームへの変化をリードした人
71. 変化するチーム
72. ５：２：３
73. © KAKEHASHI Inc. 新規開発とエンジニア提案の割合についてのWA
74. © KAKEHASHI Inc. プロダクトが成長すると開発の労力は増す チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト 価値貢献に 必要な労力
75. © KAKEHASHI Inc. カイゼンは労力を小さくし、スピードを保つ チーム プロダクト 価値貢献に 必要な労力 チーム プロダクト カ イ ゼ ン 価値貢献に 必要な労力
76. モビング
77. © KAKEHASHI Inc. 暗黙知の共有 元からいたメンバー 新しいメンバー プロダクト
78. © KAKEHASHI Inc. 構造的にユーザーストーリーへ集中してしまう ５：２：３ トランクベースとの相性の良さ 新メンバーとの暗黙知との共有 １つの物事に集中するがゆえに 5:2:3で取り組めない
79. エンジニアが ペア中心の モビング
80. © KAKEHASHI Inc. 数ヶ月のモブ期間で暗黙知は共有された 元からいたメンバー 新しいメンバー プロダクト
81. © KAKEHASHI Inc. モブの中で役割分担をした 元からいたメンバー 新しいメンバー プロダクト 開発者体験の向上 ユーザーストーリー の開発
82. © KAKEHASHI Inc. この体制でついに5:2:3が機能 ５：２：３
83. 同じものを見ているPdM
84. © KAKEHASHI Inc. 5:2:3 エンジニアにとっては嬉しい ５：２：３
85. © KAKEHASHI Inc. 5:2:3 PdMにとってはあまりにも大胆 ５：２：３ マジ すか？
86. © KAKEHASHI Inc. 大事なのは仮説検証 仮説検証ループを すばやく回したい！ ポイントは「仮説検証ループをすばやく回せるか」
87. © KAKEHASHI Inc. 成果を元に、このWAを受け入れてくれた ５：２：３ いい ですね！ 目先の不安感ではなく、実際の成果で判断してくれた
88. © KAKEHASHI Inc. ユーザーストーリーの分解もPdMが貢献 こんな感じでほぼ毎日本番環境へデプロイしてる
89. © KAKEHASHI Inc. 毎日、朝会の後にプチリファインメント ユーザー ストーリー ユーザー ストーリー ユーザー ストーリー チームでユーザーストーリーをブラッシュアップして、プランニングするころには 十分に小さなサイズのユーザーストーリーになっている
90. © KAKEHASHI Inc. 壁ごしに仕事を投げるのではなく、ともに働く関係
91. まとめ
92. 私達は 何を大切にしているのか
93. © KAKEHASHI Inc. インセプションデッキ（一部） われわれはなぜここにいるのか • XX事業の推進へ貢献するため • プロダクトやチームの枠を超えたプロフェッショナル集団であるため • 上記のためには、手段を問わない エレベーターピッチ • 我々は、事業拡大に向けて患者さん／薬局／医薬品卸／製薬会社／国といった各ス テークホルダーへの提供価値を最大化します。 • 具体的には、不確実性が高い中で、テクノロジーとドメインに関する深い知識や経験を もって、チーム内でも高速に仮説検証のサイクルを回しながら、そこで得た学びを社内外 に還元していきます
94. 価値貢献に集中！
95. © KAKEHASHI Inc. 価値貢献のために仮説検証ループを回したい！ 仮説検証ループを すばやく回したい！
96. © KAKEHASHI Inc. 結果として開発生産性指標はいい感じ
97. © KAKEHASHI Inc. そして、楽しく働けていそう WevoxのスコアはAランク
98. © KAKEHASHI Inc. リリースノートをたくさん出した
99. © KAKEHASHI Inc. エンジニアとCSのやりとり
100. © KAKEHASHI Inc. CSからの声
101. © KAKEHASHI Inc. お客様の声 「機能改善の速さに驚いている。
 　出した声が反映されるのでありがたい」
102. 価値貢献できてる！
103. 僕たちが大切にしていた ツールとカルチャー
104. © KAKEHASHI Inc. ふりかえるとベストプラクティスだったもの • トランクベース開発 ◦ CI/CDの分離 ◦ ここ一番でのフィーチャーフラグ ◦ 制約を受け入れる（WIP制限など） • 5:2:3フォーメーション • モビング • ペア中心のモビング • チーム全員での目線合わせ
105. © KAKEHASHI Inc. 少し抽象化すると・・・ • トランクベース開発 • カイゼンの余地を残すタスクマネジメント • 状況に合わせたモブ・ペアのフォーメーション チェンジ • チーム全員での目線合わせ
106. © KAKEHASHI Inc. ツールとカルチャー カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア PdMとの協働 トランクベース開発 5:2:3
107. © KAKEHASHI Inc. ツールとカルチャーと価値貢献 カルチャー ツール インセプションデッキ ワーキングアグリーメント ふりかえり モブ・ペア PdMとの協働 トランクベース開発 5:2:3 価値貢献
108. 価値貢献のために 変化し続ける 変化し続けるために 開発者体験を良くし続ける
109. Value Driven DevOps Team 〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜