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.4k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
570
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
9.4k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1.1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
5
1.8k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.9k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
540
プロダクトエンジニアとは何者か。
niwatakeru
4
3.1k
BtoB SaaS開発における Minimum Viable Product への勘所
niwatakeru
1
1.3k
Other Decks in Technology
See All in Technology
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
590
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
460
組織を巻き込む大規模プラットフォーム移行戦略 〜50+サービスのマルチリージョン・マルチプロダクト化で学んだステークホルダー協働の実践〜 / Platform migration strategy engaging all stakeholders
toshi0607
2
220
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
480
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
280
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
260
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
230
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
210
Android Audio: Beyond Winning On It
atsushieno
0
3.4k
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
22
12k
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
1.1k
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
460
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
590
Designing for Performance
lara
610
69k
What's in a price? How to price your products and services
michaelherold
246
12k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
930
Music & Morning Musume
bryan
46
6.8k
The Cult of Friendly URLs
andyhume
79
6.6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
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) もしよろしければフォローお願いいたします。