Slide 1
Slide 1 text
アジャイルに向き合うソフトウェア開発の技
術面 "ライトウィング"
Technical aspects of software development towards agile
Retty, Inc
常松祐一 / Yuichi Tsunematsu
5th/Jan, 2022
Slide 2
Slide 2 text
自己紹介
Self introduction
顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースす
る開発体制のあり方を模索しています。
I'm trying to find a way to create a development system where the entire team can work together to release products that
are valuable to customers in a short period of time.
常松祐一 / Yuichi Tsunematsu
● Engineering Manager
● Software Engineering Coach
● Agile Development
SNSアカウント
● tunepolo :
● tune :
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
アジャイルの「ライトウィング」と「レフトウィング」
Two aspect of agile, “right wing” and “left wing”
https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
“Left wing”
Culture and mindset
“Goal of agile”
business value, etc
“Right wing”
Technical practice
Slide 5
Slide 5 text
● アジャイルのゴールを実現するには「技術
面」も必要なはず。
We need to learn “technical practice” for agile goal.
● 事例を広く共有し、良い知見を探究していき
たい。
I would like to share the case studies widely and explore good knowledge together.
Photo by Thomas Serer on Unsplash
今日の話の背景
Background of today’s talk
Slide 6
Slide 6 text
技術面 “ライトウィング” の目的
Purpose of “Right wing” a.k.a technical practice
● 高速に石橋を叩いて渡る / Hit the stone bridge and cross at high speed
○ 早期に失敗する / Fail earlier
○ 高速に失敗する / Fail faster
○ 頻繁に失敗する / Fail more frequently
● 上記を実現する技術プラクティスを紹介します。
I will now introduce the technical practices that make the above possible.
Slide 7
Slide 7 text
● 自分が経験した事例を紹介。
A case study of my own experience.
● 自分が考案したものではない。
It is not something I invented.
● 全ての状況でうまくいくわけではない。
It doesn't work in every situation.
Photo by Drew Patrick Miller on Unsplash
期待値調整
Adjusting expectations
Slide 8
Slide 8 text
アジェンダ
Agenda
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視/運用 / Monitoring and operation
Slide 9
Slide 9 text
1. 設計
Design
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 10
Slide 10 text
「アジャイルは設計しない」なんてことはない
There is no such thing as "enagile does not design in agile development
「アーキテクチャ」「クラス・テーブル設計」「言語
・技術選定」が取り上げられるが、他にすべきこ
とがある。
"Architecture," "Class and DB Table Design," and "Language and Technology Selection" are covered,
but there are other things that need to be done.
Photo by Evgeniy Surzhan on Unsplash
Slide 11
Slide 11 text
大きな開発を始める前にユースケースと責務を議論
Discussing use cases and responsibilities before starting huge development
● ユースケースを拾い上げ正常
系・異常系を網羅しているか確
認。
Confirm that use cases are properly picked up and
that normal and error paths are covered.
● 総務・営業・企画・CS・QAなど
関係者を含めて行う。
Include all stakeholders such as general affairs,
sales, planning, CS, QA, etc.
Minutes from the discussion of the coupon
verification process of "Go to Eat" campaign.
Slide 12
Slide 12 text
タスク分解は開発を進めやすくするために行う
Let's do task planning to make it easier to proceed development
● 分担して進めやすい形を考える
Think through a form that is easy for the team to
share and proceed with.
● 細かければ良いわけではない
It is not enough to have a detailed unit.
● 付箋を使えば良いわけではない
It's not enough to use sticky notes.
Sprint backlog for recommend feature development
Slide 13
Slide 13 text
開発に着手する前に実装方針を揃える
Aligning implementation strategies before starting development
● 実装が終わってからPull Requestで設計議論を始めない。
Don't start design discussions with pull requests after implementation is finished.
Feature requests to add radio button to
hide some contents.
Throughout the discussion, developers found it
desirable to control the function, not the display.
Slide 14
Slide 14 text
コードを書き始める前にコメントで補足
Add supplementary information in the comments before you start writing code
Slide 15
Slide 15 text
2. 実装 (ブランチ戦略)
Implemantation : branching strategy
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 16
Slide 16 text
ブランチ戦略とは
What is branching strategy?
Git Flow vs Github Flow
git-flow GitHub Flow
● ブランチの運用ルールのこと
The branch operation rules.
Slide 17
Slide 17 text
ブランチ戦略はアジャイルのゴールに繋がっている?
Is branching strategy linked to agile goal?
Photo by Evgeniy Surzhan on Unsplash
● コントロールできることがリリースまでの長期化に繋がってい
ないか。
The ability to control change lists makes it easy to prolong the release process.
● ブランチの寿命を短くし、細かく統合し続けなくてはならない。
Need to keep branch lifetimes short and keep integrating continuously.
Slide 18
Slide 18 text
トランクベース開発
Trunk based development
開発者はTrunk(またはmaster)ブランチを共有し、ビルドが通る状態を保ちなが
ら、小さな修正を直接コミットする。
Slide 19
Slide 19 text
大規模チームでのトランクベース開発
Trunk based development at scale
短寿命(数日)のブランチを作り、PRベースのレビュー・CIを通じてTrunk(または
master)にマージしていく。
大きな機能開発は複数の PRが
揃って動作するように作る。
Large development is made so
that multiple PRs can work
together.
Slide 20
Slide 20 text
フィーチャーフラグ(トグル)による機能の出し分け
Enable/disable features by feature flag (a.k.a. feature toggle)
● デプロイなく外部からシステムの振る舞いを変更できるソフト
ウェアスイッチ。
Allows you to change the behavior of the system without deploy.
● 準備ができたら設定を変えて動くように作る。
When it's ready, change the settings and make it work.
Slide 21
Slide 21 text
2. 実装 (リファクタリング)
Implementation : refactoring
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 22
Slide 22 text
リファクタリングはいつ行うべきか?
When should we refactor code?
Photo by Brian Yurasits on Unsplash
● 「リファクタリングの時間が取れない」という言い訳
Excuses for not taking time to refactor.
● あなたが知っているすごいプログラマは「リファクタリングして
いいですか」と許可をとっていないのでは?
The great programmers you know don't ask for permission to refactor, do they?
Slide 23
Slide 23 text
ボーイスカウトルール : 来た時よりも美しく
Boy scout rule : “Always leave the campground cleaner than you found it
Photo by Andrea Sánchez on Unsplash
● 修正を入れるたび、元より綺麗なコードにする。
Make the code cleaner every time you commit it.
● タスク分解時に「リファクタリングする」タスクを積んでみたら?
How about adding a "refactoring" task automatically when planning?
Slide 24
Slide 24 text
削除(不要機能・不要コード)も流れを作る
Also create a flow for removing unnecessary functions and codes
Create a branch to remove unnecessary code, and verify and release it all at once.
In most cases, the main page will be tested automatically, and if there are no errors, judges it's OK.
Slide 25
Slide 25 text
ライブラリ更新
Library update
● 更新があることに気がつく仕組
みを作る
Create a system to notice
that there’re updates.
● 更新を継続的に行うことで、自
分たちに合ったやり方が見つ
けられる。
We can find the right way to do this by continuously
updating.
Slide 26
Slide 26 text
2. 実装 (コードレビュー)
Implementation : code review
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 27
Slide 27 text
コードレビューの目的
Purpose of code review
Photo by John Schnobrich on Unsplash
● “The primary purpose of code review is to make sure that
the overall code health of Google’s code base is improving
over time.”
from Google Engineering Practices Documentation
○ バグを見つけるプロセスではない。
It's not a process of finding bugs.
○ 「読みにくいんですけど」と率直に指摘したい。
I would like to point out frankly, "It's hard to read.
Slide 28
Slide 28 text
コードレビューがうまく回らない要因
Factors that prevent code reviews from running well
Photo by Aubrey Odom on Unsplash
1. 特定の人しかOKを出さない、出せない。
Only certain people will or can give you the OK.
2. 自動アサインされ、他の人は見ない。
Automatically assigned and no one else sees them.
3. コードを書くことだけが仕事だと思っている。
Developer think their only job is to write code.
4. 普段からよい設計を考えておらず、コメントが浮かばない。
Because they don't usually think of good design, they can't come up with any comments.
Slide 29
Slide 29 text
Photo by christopher lemercier on Unsplash
レビュー自動アサインの悪い面
The bad aspects of automatic review assignments
● 「偏らないように使っている」というが、レビューしない人がいる問題
をこじらしているだけでは?
Some people say, "We use automatic assignment to avoid unbalanced man-hours,"
but isn't that just complicating the problem that some people don't do reviews?
● 「レビューも開発の大事な仕事だからやれ」ではダメ?
Isn't it enough to say, "Reviews are an important part of development, so do them.
● 早くレビューすればデリバリーまで短くできる。
If you review quickly, you could shorten the time to delivery.
Slide 30
Slide 30 text
linter/formatterの活用
Utilize of linter/formatter
● さっさと入れた方が良い。
There is no reason not to use it, so the sooner you use it, the better.
● アーキテクチャの決まりや文言、アクセシビリティをチェックす
るものもある。
Some of them check architectural rules, texts and accessibility.
Slide 31
Slide 31 text
linter/formatterを頻繁に動かす
Run linter/formatter frequently
● エディタと連携させる設定を知らない人が意外といる。
Some developer don't know the settings to link with editors.
● Git hooksを設定し動かす。commit・pushの前など。
○ husky(Node.js), pre-commit(Pytnon), Lefthook(Go)
Set up and run Git hooks in the repository, pre-commit and pre-push timing.
● CI(Continuous Integration)でもチェックしよう。
○ Danger JS, Reviewdog
Check in CI process.
Slide 32
Slide 32 text
自分たちでスタイルガイド・ルールを作らない
We should not create our own style guide/rules.
● テックジャイアントがコストかけて作ったものを超えるのは大変。
It's hard to surpass what the tech giants have cost to build.
Google Style Guides API 設計ガイド
Slide 33
Slide 33 text
3. テスト
Test
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 34
Slide 34 text
Photo by Glenn Carstens-Peters on Unsplash
テストが多いほど良いわけではない
More tests are not always better
● 失敗しないテストは書く意味がない。
There is no meaning to write tests that never fail.
● 「その単体テストはどういう時に失敗するんですか?」
“When does the unit test fail?”
● 「その障害は単体テストがあれば防げましたか?」
Could the incident have been prevented by the unit test?
Slide 35
Slide 35 text
Photo by Artur Pokusin on Unsplash
意味のない自動テストが書かれる要因
Backgrounds that produce meaningless tests
● 実装とテストが別の人/別タスク
Implementation and testing are done by different people/ they’re separate tasks.
● カバレッジ目標の門番化
Coverage goals as a gatekeeper.
● どんなテストケースを書くべきか話せていない
Developer doesn't talk about what test cases to write with teams.
Slide 36
Slide 36 text
Photo by Jerry Wang on Unsplash
テストコードよりテストケースのレビューをしたい
We'd rather review test cases than test code
● どんな状態を想定してテストを用意したのか、わかるように
書いて欲しい。
Write test description so that
everyone could understand the test target and scope easily.
● 英語で説明できないなら日本語で書いてほしい。
If you can't explain it in English, please write it in your native language.
Slide 37
Slide 37 text
Table Driven Tests
Table Driven Unit
Tests in Go
Table Driven Tests
Given a table of test cases, the actual test
simply iterates through all table entries and
for each entry performs the necessary tests.
The test code is written once and amortized
over all table entries, so it makes sense to
write a careful test with good error messages.
Slide 38
Slide 38 text
「重要なカスタマージャーニー」を継続的にテストする
Continuously test the "critical customer journey”
Slide 39
Slide 39 text
4. リリース
Release
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 40
Slide 40 text
Photo by Ibrahim Boran on Unsplash
リリース日をコントロールするメリットとは?
What’s the benefits to control release timing?
● 「今日は差分が少ないからスキップし
ましょう」
"There's not enough diffs today, let's skip it."
● 「この機能を入れたいのでリリースを延
期しよう」
"We want to add this feature, so let's postpone the release."
Slide 41
Slide 41 text
Photo by Rachel Loughman on Unsplash
定期リリースでリズムを作る
Create a rhythm with the regular release
● 不具合が入り込んだタイミングが特定しやすい。
It is easy to identify when a defect enters the system.
● リリース作業を簡単にする力学が働く。
Mechanisms to simplify the release process
● リリーストレイン = 電車の時刻表のように時期が来たらリリー
スを行う。
Release train = release when the time has come, like a train timetable.
アプリを安全にリリースするための取り組み
(Release trainとClient release process)
| メルカリエンジニアリング
Slide 42
Slide 42 text
リリースにかかる工数を抑えるために
To reduce the man-hours for release
● 自動化を進める。 / Automate release
○ インストーラーを作る。 / Setup Installer
○ CIを使ったインストール。 / Setup install system via CI
○ ChatOps / GitOps
● 問題時にロールバックできるようにする。
Make it possible to rollback in case of problems.
Slide 43
Slide 43 text
Photo by Matthew Smith on Unsplash
Rettyのリリースサイクル
Release train cycle in Retty Inc.
● Web : 1 release /day
○ 飲食店・カスタマーサポート・営業に事前周知が必要なこともあ
り、1日1回で十分。
Once a day is enough since CS, restaurants, and sales need to be informed in advance.
● Mobile App : 1 release / week
○ プラットフォーム側のレビューがある。
○ すぐ切り戻しができないため検証も念入りに。
Because of the platform-side review.
Because of the lack of immediate cutback, verification is also very careful.
Slide 44
Slide 44 text
5. 監視・運用
Monitoring and operation
1. 設計 / Design
2. 実装 / Implementation
3. テスト / Test
4. リリース / Release
5. 監視・運用 / Monitoring and operation
Slide 45
Slide 45 text
計測し、見える化する
Measure and visualize
AWS CloudWatch
Slide 46
Slide 46 text
Photo by Luke Chesser on Unsplash
警告・エラーを0にする。
Keep the number of warning / error to 0
● おかしな状態が一目でわかるように。
To be able to see strange conditions at a glance.
● 「このエラーは大丈夫なもの」のような見分け方を人は容易に
身につけてしまうが、将来見る人にとってノイズになる。
It is easy for people to learn to distinguish between errors like "this error is okay",
but it becomes noise for future viewers.
Slide 47
Slide 47 text
Photo by Luke Chesser on Unsplash
毎日見る、みんなで見る
Check everyday, check with all team members
● 問題発見の属人化を防ぎやす
くできる。
Enables multiple developers to find problems.
● 問題を直す動機づけになる。
Motivates developers to fix what's wrong.
Slide 48
Slide 48 text
Photo by Arisa Chattasa on Unsplash
ドキュメントで全てを引き継げるという幻想
The illusion of being able to hand over everything to others in a document
● 量が多ければ良いものでは無い。目的を明確にする。
A large amount of documentation is not necessarily good. Clarify the purpose.
● 見る人がいないドキュメントは価値がない。
If there is no one to see it, it is worthless.
Diátaxis
Slide 49
Slide 49 text
Photo by Hans Eiskonen on Unsplash
バス係数(トラックナンバー)を小さく保つコツ
Tips for keeping the bus factor (track number) small
● タスクを日頃から分担して属人化を防ぐ。
Work together on tasks on a regular basis to prevent dependency.
● スキルマップを作り、ボトルネックを意識する。
Create a skills map and be aware of bottlenecks.
スキルマップ作成のすすめ |
Ryuzee.com
Slide 50
Slide 50 text
Photo by Hans Eiskonen on Unsplash
それでも作業を属人化させる人がいる時
Advice for when someone still monopolizes the work
● 「離れる時に引き継ぎ資料をたくさん書きたいですか?」
"Do you want to write a lot of handover material when you leave?"
● 「お休みから戻った時に仕事が進んでいる・終わっているほう
がよく無いですか?」
"Wouldn't it be better to have your work in progress or finished when you return from vacation?"
Slide 51
Slide 51 text
その他
Other topic
Slide 52
Slide 52 text
今日紹介しなかったが有用なプラクティス
Useful practices that were not introduced today
● Unit test / Test Driven Develelopment
● Pair programming / Mob programming / Swarming
● Canary release / Blue-Green-Deployment
● DesignDoc / Architecture Decision Records
● Working Out Loud
Slide 53
Slide 53 text
Subway Map to Agile Practices
Slide 54
Slide 54 text
Open Practice Library
Slide 55
Slide 55 text
Photo by William Bout on Unsplash
まとめ
Conclusion
● 高速に石橋を叩いて渡る / Hit the stone bridge and cross at high speed
○ 早期に失敗する / Fail earlier
○ 高速に失敗する / Fail faster
○ 頻繁に失敗する / Fail more frequently
● アジャイルのゴールにつながる技術プラクティスを研鑽して身
につけていきましょう。
Study and learn the technical practices that lead to the goals of agile.