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
1.1k
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
6.2k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
550
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
9.3k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1.1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.7k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.7k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
530
プロダクトエンジニアとは何者か。
niwatakeru
4
3k
BtoB SaaS開発における Minimum Viable Product への勘所
niwatakeru
1
1.3k
Other Decks in Technology
See All in Technology
Amazon Qで2Dゲームを作成してみた
siromi
0
170
ウォンテッドリーのアラート設計と Datadog 移行での知見
donkomura
0
160
20250807_Kiroと私の反省会
riz3f7
0
270
LLM 機能を支える Langfuse / ClickHouse のサーバレス化
yuu26
9
2.7k
リモートワークで心掛けていること 〜AI活用編〜
naoki85
0
190
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
140
プロジェクトマネジメントは不確実性との対話だ
hisashiwatanabe
0
160
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
730
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ
disc99
1
660
MCPサーバーを活用したAWSコスト管理
arie0703
0
130
[OCI Technical Deep Dive] OCIで生成AIを活用するためのソリューション解説(2025年8月5日開催)
oracle4engineer
PRO
0
120
EKS Pod Identity における推移的な session tags
z63d
1
160
Featured
See All Featured
For a Future-Friendly Web
brad_frost
179
9.9k
Speed Design
sergeychernyshev
32
1.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Typedesign – Prime Four
hannesfritz
42
2.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Fireside Chat
paigeccino
39
3.6k
Designing Experiences People Love
moore
142
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Measuring & Analyzing Core Web Vitals
bluesmoon
8
560
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
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) もしよろしければフォローお願いいたします。