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

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

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

Transcript

1. 開発チームの⽣産性向上に取り組む 株式会社ウーオ 髙橋 佑太 ソフトウェアエンジニア
2. 髙橋 佑太 yt-tkhs yt_hizi Android エンジニアとしてキャリアをスタート。 
 メガベンチャー、保険のスタートアップを経て 
 2021年7⽉、株式会社ウーオにソフトウェアエンジニアとして⼊社。 現在は Flutter と Ruby on Rails で開発。 ⾃⼰紹介 Yuta Takahashi
3. • 「⽣産性」とは何か • ⽣産性向上に取り組んだ事例❶ & ❷ • 技術的観点での⽣産性向上についての考察 • まとめ アジェンダ
4. 「⽣産性」とは何か
5. 「⽣産性」とは何か • ⼀般的には「時間あたりの⽣産量」 • プロダクト開発においては、いくつかの観点がある: • 開発サイクルのスピードを⾼く保ち、かつ品質が安定しているか • 開発によってプロダクトの価値をユーザに届けられているか など…
6. 前提として多様な観点があるなかで、 「⽣産性」とは何か 「チーム開発を技術的観点から改善し、 開発スピードと安定性を⾼めていくこと」 に着⽬してみる。
7. 事例❶ 
 PRマージのリードタイム短縮 InsurTechスタートアップでの経験から
8. 事例❶ 
 PRマージのリードタイム短縮 課題 • チームメンバーの⼊れ替わりが多いなかで、アーキテクチャの浸透と 
 レビューにかかるコストが増⼤し、PRマージまでに時間がかかっていた。 • メンバーごとにアーキテクチャの説明をしていくコスト • ドメインロジック以外へのレビューにかかるコスト • ドキュメントを⽤意してもアーキテクチャの変化に追いつかず、 
 あまり役に⽴たなかった。
9. 事例❶ 
 PRマージのリードタイム短縮 • アーキテクチャとして、レイヤーごとの責務を明確にする。 • 実装のために考えることを減らし、ビジネスロジックの実装に 
 集中できる環境を作る。 解決⼿段
10. 事例❶ 
 PRマージのリードタイム短縮 Query Command ViewModel Repository ViewState View Web API Local DB Storage 実際に構築したアーキテクチャ: ※Androidアプリ
11. Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: 「信頼できる唯⼀の情報源」の構築によってデータの整合性を担保し 
 データの変更を意識しなくて良い状態にした (Single Source Of Truth; SSOT) ※Androidアプリ
12. Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: CQRSを参考にしたドメインレイヤーの構築により、 
 ドメインロジックの集約を⾏った ※Androidアプリ
13. Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: Commandの実⾏とQueryの監視のみに限定することで 実装をパターン化した ※Androidアプリ
14. 事例❶ 
 PRマージのリードタイム短縮 • ビジネスロジック以外の実装をパターン化できるようにしたことで • ビジネスロジックの実装に集中できるようになった。 • ビジネスロジックのみに集中してレビューすればよい状態になった。 
 • 新しいメンバーでも、最低限の説明で迷うことなく開発できる状態となった。 効果
15. 事例❷ 
 不具合の早期発⾒
16. 事例❷ 
 不具合の早期発⾒ 課題 • 機能が増えていくうちにアプリのQAにかかるコストが増⼤し、 
 リリースまでに時間がかかっていた。 • 既存機能のデグレに気づかずリリース直前に修正したり、 
 最悪の場合は、リリース後にデグレが⾒つかるケースがあった。
17. • ⾃動テストを導⼊し、commit 単位でのテストを追加で実施する。 • より短いサイクルでテストを実施することで、不具合の早期発⾒を⽬指す。 解決⼿段 事例❷ 
 不具合の早期発⾒
18. テスト環境の構成 • Push するたびに次テストを実⾏するにした。 • 画像回帰テスト (Visual Regression Test; VRT) • 単体テスト (Unit Test) 事例❷ 
 不具合の早期発⾒
19. 画像回帰テスト(VRT) 事例❷ 
 不具合の早期発⾒ • 前のcommitの画⾯のスクリーンショットを⽐較し、差分を検出する。 • 差分があれば、それが正しいかどうかを⼈間の⽬でチェックする。
20. 画像回帰テスト(VRT) • UIの状態が多いアプリのため、単なるコード上の検証ではテスト⼯数が⾼い。 • スクリーンショットを⽬視で確認することで、 
 細かなUIの変化に気づきやすくする。 • golden_toolkit + reg-suit + CloudFront + S3 で構築した。 事例❷ 
 不具合の早期発⾒
21. • 短いサイクルでテストを回すことで、 
 早期に不具合を⾒つけやすい環境ができた。 • 画像回帰テスト(VRT)導⼊により、開発時のUI上の差分が明確になり 
 UIの変化を捉えやすくなった。 • UIカタログとしての副次的効果も⾒込める状態になった。 効果 事例❷ 
 不具合の早期発⾒ ⚠ ⼀⽅、まだ浸透しきっていないなどの課題もある
22. 技術的観点での⽣産性向上についての考察
23. 技術的観点での⽣産性向上についての考察 • 冒頭の通り、「⽣産性」には多様な観点がある⼀⽅で、 
 改善できるポイントも多くある。 • チーム開発をしていると、改善したいポイントがあるはず。 • 他のメンバーも同様に改善したいと思っているか、 
 共感を得られるポイントがあるので、そこを改善していく。
24. 技術的観点での⽣産性向上についての考察 • やるべきことはたくさんある • 改善ポイントを⾒つける • どうあるべきかを考える • 実装する • チームに浸透させる • 効果を検証する
25. 技術的観点での⽣産性向上についての考察 • やるべきことはたくさんある • 改善ポイントを⾒つける • どうあるべきかを考える • 実装する • チームに浸透させる • 効果を検証する
26. 技術的観点での⽣産性向上についての考察 
 どうあるべきかを考える 修正が遅れるほど修正コストは⾼まるという考えのもと、 
 短いサイクルでテストを実施することで、早期にバグを発⾒・修正できる状態。 事例①「アーキテクチャ設計」の場合 レイヤーごとの責務や実装のパターン化により 
 ドメインロジックの実装に集中でき、PRレビューもしやすい状態。 事例②「⾃動テスト導⼊」の場合 チーム全体に対してどういう効果があると良いか？
27. 技術的観点での⽣産性向上についての考察 
 チームに新しいやり⽅を浸透させる ドキュメントを⽤意し、テストの考え⽅をインストールする。 
 まだ模索中だが、テストケースの網羅を進めることで書きやすい⽂化を作る。 
 事例①「アーキテクチャ設計」の場合 ドキュメントは簡易なものに留め、参考実装を⽤意する。 
 必要に応じてペアプログラミングなどを実施する。 事例②「⾃動テスト導⼊」の場合 いかにチームに浸透させ、その効果を発揮させるか？
28. Appendix 
 ⼩さく始めるなら？ ボーイスカウトルール 
 “プログラマが知るべき97のこと” - Robert C. Martin (Uncle Bob) より • 「来た時よりも美しく」 • ⽬的のコードを変更するとき、ついでに周りを少しだけ綺麗にしてみる。 • 変数名をわかりやすくしてみる。 • ⻑いメソッドを分割してみる。 • 重複コードを排除してみる。など • 規模が⼤きくなる場合は別途リファクタリングとして実施するのがベター。
29. まとめ
30. • 「技術的観点でのチームの⽣産性向上」について取り上げた。 • 紹介した事例が、考え⽅として参考になれば🙏 • 課題の発⾒〜チームへの浸透までをやりきる必要がある。 • ⼩さく始めるなら「ボーイスカウトルール」から。 まとめ
31. microsoft/ fl uentui-emoji: https://github.com/microsoft/ fl uentui-emoji/blob/main/LICENSE Thank you!