Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

Yuichi Tsunematsu

January 05, 2022

More Decks by Yuichi Tsunematsu

Other Decks in Technology


  1. アジャイルに向き合うソフトウェア開発の技
    術面 "ライトウィング"

    Technical aspects of software development towards agile 

    Retty, Inc

    常松祐一 / Yuichi Tsunematsu

    5th/Jan, 2022

    View Slide

  2. 自己紹介

    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


    ● tunepolo : 

    ● tune : 

    View Slide

  3. View Slide

  4. アジャイルの「ライトウィング」と「レフトウィング」

    Two aspect of agile, “right wing” and “left wing” 

    “Left wing”
    Culture and mindset
    “Goal of agile”
    business value, etc
    “Right wing”
    Technical practice

    View Slide

  5. ● アジャイルのゴールを実現するには「技術

    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 

    View Slide

  6. 技術面 “ライトウィング” の目的

    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. 

    View Slide

  7. ● 自分が経験した事例を紹介。

    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 

    View Slide

  8. アジェンダ


    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視/運用 / Monitoring and operation

    View Slide

  9. 1. 設計


    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  10. 「アジャイルは設計しない」なんてことはない

    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

    View Slide

  11. 大きな開発を始める前にユースケースと責務を議論

    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.

    View Slide

  12. タスク分解は開発を進めやすくするために行う

    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

    View Slide

  13. 開発に着手する前に実装方針を揃える

    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.

    View Slide

  14. コードを書き始める前にコメントで補足

    Add supplementary information in the comments before you start writing code 

    View Slide

  15. 2. 実装 (ブランチ戦略)

    Implemantation : branching strategy 

    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  16. ブランチ戦略とは

    What is branching strategy? 

    Git Flow vs Github Flow
    git-flow GitHub Flow
    ● ブランチの運用ルールのこと

    The branch operation rules. 

    View Slide

  17. ブランチ戦略はアジャイルのゴールに繋がっている?

    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. 

    View Slide

  18. トランクベース開発

    Trunk based development 


    View Slide

  19. 大規模チームでのトランクベース開発

    Trunk based development at scale 


    大きな機能開発は複数の PRが
    Large development is made so
    that multiple PRs can work

    View Slide

  20. フィーチャーフラグ(トグル)による機能の出し分け

    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. 

    View Slide

  21. 2. 実装 (リファクタリング)

    Implementation : refactoring 

    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  22. リファクタリングはいつ行うべきか?

    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? 

    View Slide

  23. ボーイスカウトルール : 来た時よりも美しく

    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? 

    View Slide

  24. 削除(不要機能・不要コード)も流れを作る

    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.

    View Slide

  25. ライブラリ更新

    Library update

    ● 更新があることに気がつく仕組

    Create a system to notice 

    that there’re updates. 

    ● 更新を継続的に行うことで、自

    We can find the right way to do this by continuously

    View Slide

  26. 2. 実装 (コードレビュー)

    Implementation : code review 

    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  27. コードレビューの目的

    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. 

    View Slide

  28. コードレビューがうまく回らない要因

    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. 

    View Slide

  29. 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. 

    View Slide

  30. 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. 

    View Slide

  31. 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. 

    View Slide

  32. 自分たちでスタイルガイド・ルールを作らない

    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 設計ガイド

    View Slide

  33. 3. テスト


    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  34. 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? 

    View Slide

  35. 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. 

    View Slide

  36. 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. 

    View Slide

  37. 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.

    View Slide

  38. 「重要なカスタマージャーニー」を継続的にテストする

    Continuously test the "critical customer journey” 

    View Slide

  39. 4. リリース


    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  40. 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." 

    View Slide

  41. 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)
    | メルカリエンジニアリング

    View Slide

  42. リリースにかかる工数を抑えるために

    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. 

    View Slide

  43. Photo by Matthew Smith on Unsplash

    Release train cycle in Retty Inc. 

    ● Web : 1 release /day

    ○ 飲食店・カスタマーサポート・営業に事前周知が必要なこともあ

    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. 

    View Slide

  44. 5. 監視・運用

    Monitoring and operation 

    1. 設計 / Design

    2. 実装 / Implementation

    3. テスト / Test

    4. リリース / Release

    5. 監視・運用 / Monitoring and operation

    View Slide

  45. 計測し、見える化する

    Measure and visualize 

    AWS CloudWatch

    View Slide

  46. Photo by Luke Chesser on Unsplash

    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. 

    View Slide

  47. 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. 

    View Slide

  48. 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. 


    View Slide

  49. 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. 

    スキルマップ作成のすすめ |

    View Slide

  50. 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?" 

    View Slide

  51. その他

    Other topic

    View Slide

  52. 今日紹介しなかったが有用なプラクティス

    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

    View Slide

  53. Subway Map to Agile Practices

    View Slide

  54. Open Practice Library

    View Slide

  55. Photo by William Bout on Unsplash


    ● 高速に石橋を叩いて渡る / 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. 

    View Slide