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
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
4.1k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
500
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
8.5k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.7k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.7k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
510
プロダクトエンジニアとは何者か。
niwatakeru
4
2.8k
BtoB SaaS開発における Minimum Viable Product への勘所
niwatakeru
1
1.2k
Other Decks in Technology
See All in Technology
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
0
150
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
170
VISITS_AIIoTビジネス共創ラボ登壇資料.pdf
iotcomjpadmin
0
140
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
160
Agentic Workflowという選択肢を考える
tkikuchi1002
1
350
[TechNight #90-1] 本当に使える?ZDMの新機能を実践検証してみた
oracle4engineer
PRO
3
140
SFTPコンテナからファイルをダウンロードする
dip_tech
PRO
0
580
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
13
4.2k
本部長の代わりに提案書レビュー! KDDI営業が毎日使うAIエージェント「A-BOSS」開発秘話
minorun365
PRO
14
2.3k
OTFSG勉強会 / Introduction to the History of Delta Lake + Iceberg
databricksjapan
0
120
CI/CDとタスク共有で加速するVibe Coding
tnbe21
0
230
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
220
Featured
See All Featured
Bash Introduction
62gerente
614
210k
Automating Front-end Workflow
addyosmani
1370
200k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Raft: Consensus for Rubyists
vanstee
140
7k
Optimizing for Happiness
mojombo
379
70k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
The Cost Of JavaScript in 2023
addyosmani
51
8.4k
Being A Developer After 40
akosma
90
590k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
For a Future-Friendly Web
brad_frost
179
9.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) もしよろしければフォローお願いいたします。