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
アジャイルを始めるための基礎を固める
Search
ham
September 17, 2024
Technology
1
160
アジャイルを始めるための基礎を固める
アジャイルを始めるための基礎を固める方法をスライドにまとめたもの
ham
September 17, 2024
Tweet
Share
More Decks by ham
See All by ham
生成AI導入の効果を最大化する データ活用戦略
ham0215
0
300
データ駆動経営の道しるべ:プロダクト開発指標の戦略的活用法
ham0215
2
380
開発組織における意思決定の実例〜開発優先度・組織構成・ツール導入〜
ham0215
0
76
エンジニアリングで組織のアウトカムを最速で最大化する!
ham0215
1
410
アウトカムを最速で最大化できる開発組織にするために
ham0215
1
120
コード品質向上で得られる効果と実践的取り組み
ham0215
2
320
開発者体験を定量的に把握する手法と活用事例
ham0215
2
290
チームトポロジーの4つのチームタイプ
ham0215
2
110
生成AI活用でエンジニア組織はどう変わったのか?
ham0215
3
230
Other Decks in Technology
See All in Technology
許しとアジャイル
jnuank
1
150
[Codex Meetup Japan #1] Codex-Powered Mobile Apps Development
korodroid
2
470
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
0
280
社内お問い合わせBotの仕組みと学び
nish01
1
580
ComposeではないコードをCompose化する case ビズリーチ / DroidKaigi 2025 koyasai
visional_engineering_and_design
0
110
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
570
Reflections of AI: A Trilogy in Four Parts (GOTO; Copenhagen 2025)
ondfisk
0
110
20251014_Pythonを実務で徹底的に使いこなした話
ippei0923
0
190
オープンソースでどこまでできる?フォーマル検証チャレンジ
msyksphinz
0
130
M5製品で作るポン置きセルラー対応カメラ
sayacom
0
180
コンテキストエンジニアリング入門〜AI Coding Agent作りで学ぶ文脈設計〜
kworkdev
PRO
1
480
Developer Advocate / Community Managerなるには?
tsho
0
140
Featured
See All Featured
The Language of Interfaces
destraynor
162
25k
Documentation Writing (for coders)
carmenintech
75
5.1k
For a Future-Friendly Web
brad_frost
180
9.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Visualization
eitanlees
149
16k
We Have a Design System, Now What?
morganepeng
53
7.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
189
55k
Into the Great Unknown - MozCon
thekraken
40
2.1k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Transcript
© Findy Inc. 2024.09.17 1 アジャイルを始めるための 基礎を固める 浜⽥ 直⼈ Naoto
Hamada (ham)
© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React
/ TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
© Findy Inc. 3 Agenda - アジャイルソフトウェア開発宣⾔は⼼構え - アジャイルを始める基礎を作る
© Findy Inc. アジャイルソフトウェア開発宣⾔は ⼼構え 4
© Findy Inc. 5
© Findy Inc. 6 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf
© Findy Inc. 7 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf ⼼構えはわかった!! やっていき!!!
© Findy Inc. 8 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf ⼼構えはわかった!! で、どうすればいいの??
© Findy Inc. 9 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf
© Findy Inc. 10 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf マインドセットを変えるだけでは 実践できないものがあるな...
© Findy Inc. 11 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf 実践するには 基礎を作る必要がある!
© Findy Inc. アジャイルを始める基礎を作る 12
© Findy Inc. 13 いつでも本番反映できる仕組みを作る main feature 細かく本番反映していく 仕組みが必要
© Findy Inc. 14 ⻑く残るブランチとは? - featureブランチで開発を⾏い、すべて開発‧検証した後に マージ main feature
新規機能‧既存機能 すべて検証後にマージ feature N
© Findy Inc. 15 細かくマージするための考え⽅ - 🙅検証して承認されたコードしかmainにマージしない - 🙆既存に影響を与えないコードはガンガンmainにマージ ◦
(体感ですが)追加‧変更したコードの9割は既存に影響を 与えない形でマージできる ◦ 1つ1つの影響範囲が広い場合、結合度を⾒直すと良い main feature
© Findy Inc. 16 細かくマージするための考え⽅ - 🙅検証して承認されたコードしかmainにマージしない - 🙆既存に影響を与えないコードはガンガンmainにマージ ◦
(体感ですが)追加‧変更したコードの9割は既存に影響を 与えない形でマージできる ◦ 1つ1つの影響範囲が広い場合、結合度を⾒直すと良い main feature 既存に影響を与えないことを 検証するのが⼤変じゃん
© Findy Inc. 17 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる
© Findy Inc. 18 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる 例えば以下のようなPRはCI通ればヨシッ! →mainへマージ PR1: 関数名を変更 PR2: Fix typo PR3: 新しいモジュールを追加(未使⽤) PR4: ライブラリアップデート(ものによるが)
© Findy Inc. 19 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる 例えば以下のようなPRはCI通ればヨシッ! →mainへマージ PR1: 関数名を変更 PR2: Fix typo PR3: 新しいモジュールを追加(未使⽤) PR4: ライブラリアップデート(ものによるが) PRに1つの観点しか⼊っていなければ ⼿動テストの有無も⼀⽬瞭然! →1つのPRに複数の観点を⼊れないこと も⼤事
© Findy Inc. 20 ⾃動テスト書く時間が もったいなくないですか?
© Findy Inc. 21 テスト⾃動化の損益分岐点は「4回」 - 4回以上変更するなら⾃動テストを書いた⽅がお得!! 質とスピード (@t_wada) https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
© Findy Inc. 22 ⾃動テスト書くのは ハードル⾼いのですが...
© Findy Inc. 23 ⾃動テストは書けるようになりましょう! - ⼀度⾃動テストがある環境に⾜を踏み⼊れると、⾃動テス トがない世界には戻れなくなります! - ⾃動テストのある開発環境は開発者体験が良い!!
© Findy Inc. 24 ⾃動テストで100% 品質担保できるんですか?
© Findy Inc. 25 Four Keys - DORAが調査した開発組織のパフォーマンス指標 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 26 Four Keys - Eliteでも変更障害率は5% 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 27 Four Keys - 障害が起きても1時間以内に復旧 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 28 本番障害は起きるものと認識する - 本番障害が⼀定の割合で発⽣することは許容する ◦ ※プロダクトの性質によって許容する範囲は変える -
⼀⽅で障害が発⽣してもすぐに復旧できるように監視やリ カバリ⼿順を確⽴しておく - Tips: エラーバジェット ◦ 可⽤性: 99.9% → 43分/⽉ までは障害を許容 ◦ 許容範囲を超えるまでは積極的に開発を進める ◦ 許容範囲を超えたら信頼性の回復に注⼒する
© Findy Inc. 29 守りたいものを定義して守る - 本番障害に備えるため、守りたいものを定義して守る ◦ プロダクトの振る舞い ▪
⾃動テスト / E2Eテスト / リリース前の⼿動テスト ◦ レスポンスタイム / ステータスコード ▪ ログ監視 ◦ 復旧⼿順を整備 ▪ ⾃動化‧簡易化‧ドキュメント化 ◦ 障害後のふりかえり ▪ 再発防⽌
© Findy Inc. 30 いつでも本番反映できる仕組みができた! あとはアジャイルを実践するのみ! アジャイルには様々な⼿法があります ⾃分に合った⼿法を⾒つけましょう!