開発チームの生産性向上に取り組む

2022年11月2日(水) 開催
一皮むけたエンジニアになる、なりたい、どうする？〜プロダクト開発を引っ張るリーダーに成長するには〜

https://connpass.com/event/262324/

Transcript

1. 開発チームの⽣産性向上に取り組む
   株式会社ウーオ
   髙橋 佑太
   ソフトウェアエンジニア
   

   View Slide

2. 髙橋 佑太
   yt-tkhs yt_hizi
   Android エンジニアとしてキャリアをスタート。
   

   メガベンチャー、保険のスタートアップを経て
   

   2021年7⽉、株式会社ウーオにソフトウェアエンジニアとして⼊社。
   現在は Flutter と Ruby on Rails で開発。
   ⾃⼰紹介
   Yuta Takahashi
   

   View Slide

3. • 「⽣産性」とは何か
   • ⽣産性向上に取り組んだ事例❶ & ❷
   • 技術的観点での⽣産性向上についての考察
   • まとめ
   アジェンダ
   

   View Slide

4. 「⽣産性」とは何か
   

   View Slide

5. 「⽣産性」とは何か
   • ⼀般的には「時間あたりの⽣産量」
   • プロダクト開発においては、いくつかの観点がある:
   • 開発サイクルのスピードを⾼く保ち、かつ品質が安定しているか
   • 開発によってプロダクトの価値をユーザに届けられているか
   など…
   

   View Slide

6. 前提として多様な観点があるなかで、
   「⽣産性」とは何か
   「チーム開発を技術的観点から改善し、
   開発スピードと安定性を⾼めていくこと」
   に着⽬してみる。
   

   View Slide

7. 事例❶
   

   PRマージのリードタイム短縮
   InsurTechスタートアップでの経験から
   

   View Slide

8. 事例❶
   

   PRマージのリードタイム短縮
   課題
   • チームメンバーの⼊れ替わりが多いなかで、アーキテクチャの浸透と
   

   レビューにかかるコストが増⼤し、PRマージまでに時間がかかっていた。
   • メンバーごとにアーキテクチャの説明をしていくコスト
   • ドメインロジック以外へのレビューにかかるコスト
   • ドキュメントを⽤意してもアーキテクチャの変化に追いつかず、
   

   あまり役に⽴たなかった。
   

   View Slide

9. 事例❶
   

   PRマージのリードタイム短縮
   • アーキテクチャとして、レイヤーごとの責務を明確にする。
   • 実装のために考えることを減らし、ビジネスロジックの実装に
   

   集中できる環境を作る。
   解決⼿段
   

   View Slide

10. 事例❶
    

    PRマージのリードタイム短縮
    Query
    Command
    ViewModel Repository
    ViewState
    View
    Web API
    Local DB
    Storage
    実際に構築したアーキテクチャ:
    ※Androidアプリ
    

    View Slide

11. Query
    Command
    ViewModel Repository
    ViewState
    View
    Web API
    Local DB
    Storage
    事例❶
    

    PRマージのリードタイム短縮
    実際に構築したアーキテクチャ:
    「信頼できる唯⼀の情報源」の構築によってデータの整合性を担保し
    

    データの変更を意識しなくて良い状態にした
    (Single Source Of Truth; SSOT)
    ※Androidアプリ
    

    View Slide

12. Query
    Command
    ViewModel Repository
    ViewState
    View
    Web API
    Local DB
    Storage
    事例❶
    

    PRマージのリードタイム短縮
    実際に構築したアーキテクチャ:
    CQRSを参考にしたドメインレイヤーの構築により、
    

    ドメインロジックの集約を⾏った
    ※Androidアプリ
    

    View Slide

13. Query
    Command
    ViewModel Repository
    ViewState
    View
    Web API
    Local DB
    Storage
    事例❶
    

    PRマージのリードタイム短縮
    実際に構築したアーキテクチャ:
    Commandの実⾏とQueryの監視のみに限定することで
    実装をパターン化した
    ※Androidアプリ
    

    View Slide

14. 事例❶
    

    PRマージのリードタイム短縮
    • ビジネスロジック以外の実装をパターン化できるようにしたことで
    • ビジネスロジックの実装に集中できるようになった。
    • ビジネスロジックのみに集中してレビューすればよい状態になった。
    

    • 新しいメンバーでも、最低限の説明で迷うことなく開発できる状態となった。
    効果
    

    View Slide

15. 事例❷
    

    不具合の早期発⾒
    

    View Slide

16. 事例❷
    

    不具合の早期発⾒
    課題
    • 機能が増えていくうちにアプリのQAにかかるコストが増⼤し、
    

    リリースまでに時間がかかっていた。
    • 既存機能のデグレに気づかずリリース直前に修正したり、
    

    最悪の場合は、リリース後にデグレが⾒つかるケースがあった。
    

    View Slide

17. • ⾃動テストを導⼊し、commit 単位でのテストを追加で実施する。
    • より短いサイクルでテストを実施することで、不具合の早期発⾒を⽬指す。
    解決⼿段
    事例❷
    

    不具合の早期発⾒
    

    View Slide

18. テスト環境の構成
    • Push するたびに次テストを実⾏するにした。
    • 画像回帰テスト (Visual Regression Test; VRT)
    • 単体テスト (Unit Test)
    事例❷
    

    不具合の早期発⾒
    

    View Slide

19. 画像回帰テスト(VRT)
    事例❷
    

    不具合の早期発⾒
    • 前のcommitの画⾯のスクリーンショットを⽐較し、差分を検出する。
    • 差分があれば、それが正しいかどうかを⼈間の⽬でチェックする。
    

    View Slide

20. 画像回帰テスト(VRT)
    • UIの状態が多いアプリのため、単なるコード上の検証ではテスト⼯数が⾼い。
    • スクリーンショットを⽬視で確認することで、
    

    細かなUIの変化に気づきやすくする。
    • golden_toolkit + reg-suit + CloudFront + S3 で構築した。
    事例❷
    

    不具合の早期発⾒
    

    View Slide

21. • 短いサイクルでテストを回すことで、
    

    早期に不具合を⾒つけやすい環境ができた。
    • 画像回帰テスト(VRT)導⼊により、開発時のUI上の差分が明確になり
    

    UIの変化を捉えやすくなった。
    • UIカタログとしての副次的効果も⾒込める状態になった。
    効果
    事例❷
    

    不具合の早期発⾒
    ⚠ ⼀⽅、まだ浸透しきっていないなどの課題もある
    

    View Slide

22. 技術的観点での⽣産性向上についての考察
    

    View Slide

23. 技術的観点での⽣産性向上についての考察
    • 冒頭の通り、「⽣産性」には多様な観点がある⼀⽅で、
    

    改善できるポイントも多くある。
    • チーム開発をしていると、改善したいポイントがあるはず。
    • 他のメンバーも同様に改善したいと思っているか、
    

    共感を得られるポイントがあるので、そこを改善していく。
    

    View Slide

24. 技術的観点での⽣産性向上についての考察
    • やるべきことはたくさんある
    • 改善ポイントを⾒つける
    • どうあるべきかを考える
    • 実装する
    • チームに浸透させる
    • 効果を検証する
    

    View Slide

25. 技術的観点での⽣産性向上についての考察
    • やるべきことはたくさんある
    • 改善ポイントを⾒つける
    • どうあるべきかを考える
    • 実装する
    • チームに浸透させる
    • 効果を検証する
    

    View Slide

26. 技術的観点での⽣産性向上についての考察
    

    どうあるべきかを考える
    修正が遅れるほど修正コストは⾼まるという考えのもと、
    

    短いサイクルでテストを実施することで、早期にバグを発⾒・修正できる状態。
    事例①「アーキテクチャ設計」の場合
    レイヤーごとの責務や実装のパターン化により
    

    ドメインロジックの実装に集中でき、PRレビューもしやすい状態。
    事例②「⾃動テスト導⼊」の場合
    チーム全体に対してどういう効果があると良いか？
    

    View Slide

27. 技術的観点での⽣産性向上についての考察
    

    チームに新しいやり⽅を浸透させる
    ドキュメントを⽤意し、テストの考え⽅をインストールする。
    

    まだ模索中だが、テストケースの網羅を進めることで書きやすい⽂化を作る。
    

    事例①「アーキテクチャ設計」の場合
    ドキュメントは簡易なものに留め、参考実装を⽤意する。
    

    必要に応じてペアプログラミングなどを実施する。
    事例②「⾃動テスト導⼊」の場合
    いかにチームに浸透させ、その効果を発揮させるか？
    

    View Slide

28. Appendix
    

    ⼩さく始めるなら？
    ボーイスカウトルール
    

    “プログラマが知るべき97のこと” - Robert C. Martin (Uncle Bob) より
    • 「来た時よりも美しく」
    • ⽬的のコードを変更するとき、ついでに周りを少しだけ綺麗にしてみる。
    • 変数名をわかりやすくしてみる。
    • ⻑いメソッドを分割してみる。
    • 重複コードを排除してみる。など
    • 規模が⼤きくなる場合は別途リファクタリングとして実施するのがベター。
    

    View Slide

29. まとめ
    

    View Slide

30. • 「技術的観点でのチームの⽣産性向上」について取り上げた。
    • 紹介した事例が、考え⽅として参考になれば🙏
    • 課題の発⾒〜チームへの浸透までをやりきる必要がある。
    • ⼩さく始めるなら「ボーイスカウトルール」から。
    まとめ
    

    View Slide

31. microsoft/
    fl
    uentui-emoji: https://github.com/microsoft/
    fl
    uentui-emoji/blob/main/LICENSE
    Thank you!
    

    View Slide