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
6 deploys / day を実現するフルサイクルエンジニア組織の文化と仕組み
Search
Niwa Takeru
May 19, 2023
Technology
0
980
6 deploys / day を実現するフルサイクルエンジニア組織の文化と仕組み
2023/05/19 Findy開発生産性Meetupで登壇した際の資料です。
https://findy.connpass.com/event/281567/
Niwa Takeru
May 19, 2023
Tweet
Share
More Decks by Niwa Takeru
See All by Niwa Takeru
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.3k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
98
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
5.5k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
920
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.5k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.4k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
450
プロダクトエンジニアとは何者か。
niwatakeru
4
2.5k
BtoB SaaS開発における Minimum Viable Product への勘所
niwatakeru
1
1.1k
Other Decks in Technology
See All in Technology
2.5Dモデルのすべて
yu4u
2
840
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
140
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
390
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
57k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
2.8k
あれは良かった、あれは苦労したB2B2C型SaaSの新規開発におけるCloud Spanner
hirohito1108
2
540
Platform Engineeringは自由のめまい
nwiizo
4
2.1k
10分で紹介するAmazon Bedrock利用時のセキュリティ対策 / 10-minutes introduction to security measures when using Amazon Bedrock
hideakiaoyagi
0
180
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
240
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
8
1.5k
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
160
RSNA2024振り返り
nanachi
0
570
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Unsuck your backbone
ammeep
669
57k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Become a Pro
speakerdeck
PRO
26
5.1k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
960
The Language of Interfaces
destraynor
156
24k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Rails Girls Zürich Keynote
gr2m
94
13k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Transcript
取締役CTO 丹羽健 【開発生産性 Meetup #2】 6 deploys / dayを実現する フルサイクルエンジニア
組織の文化と仕組み
自己紹介 2
アセンド株式会社 3 アセンドが対象とする 物流・運送業界の課題
4 4
5 運行管理SaaSロジックス 5 多機能プロダクトだけでなく 各機能がデータ連携で繋がる 複雑性にも対応
アセンドが求める開発生産性 ユーザへの検証数がプロダクト価値の積み 上げに相関関係がある。 この目的で 6deploys/day ができる プロダクト開発組織を設計 アセンドが求める生産性はプロダクト的な 価値をどれだけ産み出す事ができるか •
ユーザビリティの高いUX • ユーザの業務課題を解決する機能 リーンマネジメントの考えで ユーザに開発機能を小さく当て 検証による失敗と改善を積み重ねる 6 6 プロダクト的価値 PRマージ数・デプロイ=検証回数 追い求めているのはプロダクト的価値の生産性 相関のある検証回数=deploys/dayをKPIとして設定 毎日デプロイ頻度をSlack Botでチーム内に共有
7 フルサイクルエンジニアでの開発 7 1エンジニアでもソフトウェアの ライフサイクル全てにオーナーシップを 持ち開発できるよう開発環境を設計・投資 ユーザ課題を中心として機能検証の 開発サイクルを高速に進められる ユーザ課題を中心として開発 フルサイクルを支えるため多くの技術的投資と仕組み的な資産を積み重ねています
8 フルサイクルエンジニアでの開発 8 1エンジニアでもソフトウェアの ライフサイクル全てにオーナーシップを 持ち開発できるよう開発環境を設計・投資 ユーザ課題を中心として機能検証の 開発サイクルを高速に進められる ユーザ課題を中心として開発 フルサイクルを支えるため多くの技術的投資と仕組み的な資産を積み重ねています
生産性の高い環境と仕組みは整備したが、 生産性を高めた最終的な鍵は 「数時間毎デプロイのメンタルモデルへのUnlearn」 (フルサイクル開発の仕組みの詳細に興味がある方は懇親会の時にお声がけください)
週次・月次の頻度でのリリースをしていた転職メンバーの中には 失敗を過度に恐れるあまりパフォーマンスが安定しない課題があった。 週次リリースと数時間毎デプロイはパラダイムが異なることを認識し、 メンバーへUnlearn (脱学習) を働きかける必要があった 9 数時間毎デプロイに対する恐れ 9 Unlearn
心理的安全性 仕組み的安全性 「小さく失敗し、高速に価値を積み上げる」メンタルモデルへUnlearnさせる
週次リリースと数時間毎デプロイは パラダイムが異なることを前提として、 過去の成功・経験に対して疑う視点を与える ベストプラクティスに対して ベストである前提条件を与えることで 論理的に脱学習に導くことができる 勇気が必要なUnlearnができる 安全な環境を提供する 10 Unlearn(脱学習)
10 脱学習 Unlearn 再学習 Relearn ブレーク スルー Breakthrough Unlearn のサイクル Unlearn: Let Go of Past Success to Achieve Extraordinary Results Barry O'Reilly (2018) 最近、翻訳版が出たので組織マネジメントに興味がある方はぜひ。 過去の成功・システムの 前提条件を問う
11 数時間毎デプロイの為の心理的安全性 11 オーナーシップ オンボーディング 正社員・副業問わず初日に文言変更レベルのリリース を体験させ初日からパラダイムの違う世界にあること を認識してもらう。 最初の数週間は簡単なタスクを中心に進め、小さく デプロイすることの成功体験を積み重ねられるよう
オンボーディングを設計する。 フルサイクルに開発することで仕様・設計・FE/BEの レベルでブラックボックスが比較的少ない状態での開 発が可能となる。 デプロイ作業を含め運用も自身の管轄でできるため、 切り戻しも自身の手で可能な状況にある。 Customer Success との関係性 障害といった失敗があった場合に顧客対応を取るのが Customer Success。失敗した時に自身の手で救いきれ ない以上、協力者と適切に関係性を築いていることが ベースの安全性に寄与する。 「物流業界の価値最大化」のミッションドリブンな 会社であることが所以。 ポストモーテム 失敗を受け止められる組織を作る為に最も有効な施策 障害の発生後に失敗原因を環境や仕組みの観点で振り 返る。コトを責めてヒトを責めない。 ポストモーテム導入初期での カルチャー形成は難しく3回は実施すること。 小さい成功体験と信頼を積み重ねるサイクルを歩み、小さい失敗に対する心理的安全性を築く SRE Next 2022でのポストモーテムに関する登壇資料 →
12 失敗の体積を小さくコントロール 12 ユーザ数 発生時間 深刻度 失敗を単一の事象として見るのではなく、 失敗を複数軸による掛け算=体積で見る。 失敗を体積の大きさで見ることで、 発生させてはいけない失敗の大きさが分かり
小さな失敗を許容可能と見ることができる。 失敗の軸を分解することでメンバーでも 失敗の大きさをコントロール可能となる • ユーザ数 • 発生時間 • 深刻度 失敗を体積で見る
13 数時間毎デプロイの為の仕組み的安全性 13 FeatureFlag 型安全な Full TypeScript フロントエンドとバックエンドをTypeScriptで共通化 型を最大限に活用し、一部定義を変更すると関連する コードがビルドエラーとなるよう壊れやすいコードの
書き方をする。 早期に失敗することで本番での失敗を減らす 開発途中・検証中の機能をFeatureFlagで利用制限し、 失敗をした場合でも影響を狭めることができる。 環境・機能・ユーザ毎に開放する範囲を適切に コントロールすることで 失敗の影響範囲をコントロールする 小さいPR x Sentry (監視) PR分割し小さい単位でデプロイをすることで失敗をし た際にも対象の特定が容易。 またSentryを利用して即座にエラーが発生しているこ とをSlackで検知できる状態にある。 十数秒でのロールバック GitOpsを利用し、またArgoCDを利用してGUIベース でリリースのロールバック作業が可能。 失敗が発生したとしても最短十数秒でロールバックが 可能であるため、失敗を小さくすることができる 「小さく失敗し、高速に価値を積み上げる」にメンタルモデルに Unlearnさせることができれば成功 Feature Flagに関するアセンドのテックブログ記事→
社会課題解決に一緒に取り組む仲間を募集中です! オフラインミートアップも企画しております。ご興味を持たれた方はぜひお話しましょう! Message 14 CTO丹羽のTwitter(@niwa_takeru) もしよろしければフォローお願いいたします。