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.6k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
110
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
5.6k
プロダクトエンジニアの為のトライアルとオンボーディング
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
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
160
JEDAI Meetup! Databricks AI/BI概要
databricksjapan
0
270
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
250
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
500
2.5Dモデルのすべて
yu4u
2
930
偏光画像処理ライブラリを作った話
elerac
1
120
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
3
1.9k
RSNA2024振り返り
nanachi
0
620
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
670
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
130
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
150
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
GraphQLとの向き合い方2022年版
quramy
44
13k
Building Your Own Lightsaber
phodgson
104
6.2k
Done Done
chrislema
182
16k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
The Invisible Side of Design
smashingmag
299
50k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Code Reviewing Like a Champion
maltzj
521
39k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Raft: Consensus for Rubyists
vanstee
137
6.8k
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) もしよろしければフォローお願いいたします。