Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

髙橋 佑太 yt-tkhs yt_hizi Android エンジニアとしてキャリアをスタート。 
 メガベンチャー、保険のスタートアップを経て 
 2021年7⽉、株式会社ウーオにソフトウェアエンジニアとして⼊社。 現在は Flutter と Ruby on Rails で開発。 ⾃⼰紹介 Yuta Takahashi

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

「⽣産性」とは何か

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

事例❶ 
 PRマージのリードタイム短縮 課題 • チームメンバーの⼊れ替わりが多いなかで、アーキテクチャの浸透と 
 レビューにかかるコストが増⼤し、PRマージまでに時間がかかっていた。 • メンバーごとにアーキテクチャの説明をしていくコスト • ドメインロジック以外へのレビューにかかるコスト • ドキュメントを⽤意してもアーキテクチャの変化に追いつかず、 
 あまり役に⽴たなかった。

Slide 9

Slide 9 text

事例❶ 
 PRマージのリードタイム短縮 • アーキテクチャとして、レイヤーごとの責務を明確にする。 • 実装のために考えることを減らし、ビジネスロジックの実装に 
 集中できる環境を作る。 解決⼿段

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: 「信頼できる唯⼀の情報源」の構築によってデータの整合性を担保し 
 データの変更を意識しなくて良い状態にした (Single Source Of Truth; SSOT) ※Androidアプリ

Slide 12

Slide 12 text

Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: CQRSを参考にしたドメインレイヤーの構築により、 
 ドメインロジックの集約を⾏った ※Androidアプリ

Slide 13

Slide 13 text

Query Command ViewModel Repository ViewState View Web API Local DB Storage 事例❶ 
 PRマージのリードタイム短縮 実際に構築したアーキテクチャ: Commandの実⾏とQueryの監視のみに限定することで 実装をパターン化した ※Androidアプリ

Slide 14

Slide 14 text

事例❶ 
 PRマージのリードタイム短縮 • ビジネスロジック以外の実装をパターン化できるようにしたことで • ビジネスロジックの実装に集中できるようになった。 • ビジネスロジックのみに集中してレビューすればよい状態になった。 
 • 新しいメンバーでも、最低限の説明で迷うことなく開発できる状態となった。 効果

Slide 15

Slide 15 text

事例❷ 
 不具合の早期発⾒

Slide 16

Slide 16 text

事例❷ 
 不具合の早期発⾒ 課題 • 機能が増えていくうちにアプリのQAにかかるコストが増⼤し、 
 リリースまでに時間がかかっていた。 • 既存機能のデグレに気づかずリリース直前に修正したり、 
 最悪の場合は、リリース後にデグレが⾒つかるケースがあった。

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

画像回帰テスト(VRT) • UIの状態が多いアプリのため、単なるコード上の検証ではテスト⼯数が⾼い。 • スクリーンショットを⽬視で確認することで、 
 細かなUIの変化に気づきやすくする。 • golden_toolkit + reg-suit + CloudFront + S3 で構築した。 事例❷ 
 不具合の早期発⾒

Slide 21

Slide 21 text

• 短いサイクルでテストを回すことで、 
 早期に不具合を⾒つけやすい環境ができた。 • 画像回帰テスト(VRT)導⼊により、開発時のUI上の差分が明確になり 
 UIの変化を捉えやすくなった。 • UIカタログとしての副次的効果も⾒込める状態になった。 効果 事例❷ 
 不具合の早期発⾒ ⚠ ⼀⽅、まだ浸透しきっていないなどの課題もある

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

技術的観点での⽣産性向上についての考察 • 冒頭の通り、「⽣産性」には多様な観点がある⼀⽅で、 
 改善できるポイントも多くある。 • チーム開発をしていると、改善したいポイントがあるはず。 • 他のメンバーも同様に改善したいと思っているか、 
 共感を得られるポイントがあるので、そこを改善していく。

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

技術的観点での⽣産性向上についての考察 
 どうあるべきかを考える 修正が遅れるほど修正コストは⾼まるという考えのもと、 
 短いサイクルでテストを実施することで、早期にバグを発⾒・修正できる状態。 事例①「アーキテクチャ設計」の場合 レイヤーごとの責務や実装のパターン化により 
 ドメインロジックの実装に集中でき、PRレビューもしやすい状態。 事例②「⾃動テスト導⼊」の場合 チーム全体に対してどういう効果があると良いか?

Slide 27

Slide 27 text

技術的観点での⽣産性向上についての考察 
 チームに新しいやり⽅を浸透させる ドキュメントを⽤意し、テストの考え⽅をインストールする。 
 まだ模索中だが、テストケースの網羅を進めることで書きやすい⽂化を作る。 
 事例①「アーキテクチャ設計」の場合 ドキュメントは簡易なものに留め、参考実装を⽤意する。 
 必要に応じてペアプログラミングなどを実施する。 事例②「⾃動テスト導⼊」の場合 いかにチームに浸透させ、その効果を発揮させるか?

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

まとめ

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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