「生産性向上は“共感ポイント”から取り組むと良い」　チーム開発の技術的観点における生産性向上の改善例

髙橋氏の自己紹介

髙橋佑太氏（以下、髙橋）：それでは「開発チームの生産性向上に取り組む」と題して、株式会社ウーオの髙橋が発表します。よろしくお願いします。

まず簡単に自己紹介します。（先に）紹介してもらったとおりですが、もともとAndroidエンジニアとしてキャリアをスタートしていて、メガベンチャーや保険のスタートアップなどを経て、2021年7月に株式会社ウーオにソフトエンジニアとして入社しました。現在は主にFlutterとRuby on Railsで開発をしています。

本日のアジェンダですが、タイトルにもある“生産性”という言葉の認識をそろえたうえで、私が生産性向上に取り組んだ事例を2つ紹介した後に、それらの事例をとおして、技術的観点での生産性向上について、生産性向上を図ることの考察をして最後にまとめとします。

生産性とは何か

まず初めに生産性とは何か（について）ですが、一般的には時間あたりの生産量として言われるものです。しかし、プロダクト開発においてはいくつかの観点があるかなと思っています。

例えば、開発サイクルのスピードを高く保ち、かつ品質が安定しているかどうかと、開発によってそのプロダクトの価値をユーザーに届けられているかなど、いくつかあるかなと思います。

このLTでは、前提として多様な観点がある中で「チーム開発を技術的観点から改善し、開発スピードとプロダクトの安定性を高めていくこと」に着目してみようと思います。

事例1　プルリクエストのマージにかかる時間を短縮した

とりあえず事例1つ目で、これは前職の経験なのですが、プルリクエストのマージのリードタイムの短縮をしていた事例を紹介します。課題としては、チームメンバーの入れ替わりが多い中で、アーキテクチャの浸透とレビューにかかるコストが増大していて、プルリクエストのマージまでに時間がかかっていたという問題がありました。

どういうコストがあったかというと、メンバーごとにアーキテクチャを説明していくコストだったり、ドメインロジック以外のレビューにかかるコストが、かなりあったなと思っています。また、ドキュメントを用意しても、やはりアーキテクチャはどんどん進化していくので、その変化に追いつかずに、あまり役に立たない状況となっていた課題がありました。

そこで、解決手段としては、アーキテクチャとしてレイヤーごとの責務を明確にすることと、アーキテクチャの設計段階で実装のために考えることをできるだけ減らして、ビジネスロジックの実装に集中できる環境を作る手段をとりました。

（スライドを示して）こちらが実際に構築したアーキテクチャです。

詳細は省きますが、どういう考え方を取り入れたかについては、Androidアプリの例で、ローカルのデータベースを使って「信頼できる唯一の情報源」と呼ばれる考え方を用いてデータの整合性を担保して、各画面がデータの変更を意識しなくても良い状態を作ったというところ。

また、クエリとコマンドという登場人物がいるのですが、これはCQRS（Command Query Responsibility Segregation）を参考にドメインレイヤーを構築して、ドメインロジックを集約していくことをやりました。

ビューモデルはそれらのクエリを監視するところと、コマンドを実行する（ところ）。また、ビューからのちょっとした処理を行うところで、処理を限定することで実装をパターン化していくことをやりました。

結果として、ビジネスロジック以外の実装をパターン化できるようにしたことで、そのビジネスロジックの実装に集中できるようになったところと、レビュワーとしては、ビジネスロジックのみに集中してレビューすれば良い状態になりました。また、新しいメンバーが入った時でも、最低限の説明で、既存の実装を見ていけば迷うことなく開発できる状態となりました。

事例2　不具合の早期発見に取り組んだ

次に事例2つ目として、不具合の早期発見に取り組んだ事例です。課題としては、機能が増えていくうちに、アプリのQAにかかるコストが増大してリリースまでに時間がかかっていたというところと、また、既存機能のデグレ（デグレーション）に気づかず、リリース直前に慌てて修正したりとか、最悪の場合リリース後にデグレが見つかってスポットフィックスでまたリリースをすることがありました。

解決手段としては、自動テストを導入して、commit単位でのテストを追加で実施していくところと、これをより短いサイクルでテストを実施することで、不具合の早期発見を目指すこととしました。

具体的にテスト環境がどういう構成だったかというと、GitHubでプッシュするたびに次のテストを実行するようにしていました。1つ目が画像回帰テストと呼ばれるもので、2つ目がよくある単体テストです。

画像回帰テストについて、なじみのない方もいると思うので簡単に説明します。画像回帰テストは名前のとおり、前のcommitの画面をスクリーンショット（して、現状と）比較して差分を検出して、差分があればそれが正しいかどうかを人間の目でチェックしていくみたいなことが主な概要になります。

弊社のアプリは特にUIの状態が多いアプリのため、単なるコード上の検証だけではテスト工数がかなり高くなってしまうので、実際にスクリーンショットを撮って目視で確認していくことで、細かなUIの変化に気づきやすくするところを目指しました。

ちょっと具体的な話になりますが、Flutter側ではgolden_toolkitというパッケージとreg-suitというVRT（Visual Regression Test）の実装に使えるツールと、他にS3とCloudFrontを使って構築していきました。

これらの効果としては、短いサイクルでテストを回すことで早期に不具合を見つけて修正していける環境ができたところと、画像回帰テストの導入によって、開発時にUI上の差分が明確になってUIの変化を捉えやすくなったところ。また、撮ったスクリーンショットがUIカタログとして使えるというところで、副次的な効果も見込める状態になったかなと思っています。

一方、このあたり（で）まだまだ浸透しきってない課題もあるので、これから改善の余地があるところもあります。

「生産性」には多様な観点があるが、改善ポイントも多くある

それでは先ほど2つの事例をとおして、技術的観点での生産性向上についてどうすべきかという考察をしていこうと思います。冒頭のとおり、生産性という言葉については多様な観点がある一方で、改善できるポイントも多くあるかなと思っていて。

例えば、チーム開発していると改善したいポイントは少なからずあるのかなと思っていて、そういったところは他のメンバーも同様に改善したいと感じているか、説明していけば共感を得られるポイントがあると思うので、そういうところを改善していくのが良いのかなと思っています。

一方、これをやるためにすべきことはたくさんあって、先ほどのとおり改善ポイントを見つけるというところと、その改善ポイントに対してどうあるべきかを考えていくところと、実際に実装して、その後チームに新しいやり方を浸透させていくところ、（そして）最終的にその効果が検証できると良いのかなと思っています。

「どうあるべきかを考える」と「チームに新しいやり方を浸透させる」

ここでは（そのうちの）2つ、どうあるべきかを考えるところと、チームに浸透させていくところをかいつまんで説明していきます。

「どうあるべきかを考える」とはどういうことかというと、チームに対してどういう効果があると良いかというところで、事例1に関してはレイヤーごとの責務や実装のパターン化によってドメインロジックの実装にメンバーが集中できて、かつ、レビュワーもレビューをしやすい状態にするというところ。

事例2では、修正が遅れるほど修正コストが高まっていくという考えの下、短いサイクルでテストを実施することで、早期にバグを発見・修正できる状態をチームに作っていくというところがありました。

また、「チームに新しいやり方を浸透させる」ところに関しては、いかにチームにその新しいやり方を浸透させて自分がやった効果をどんどん発揮させていけるかというところ。

事例1に関しては、ドキュメントは簡易なものにとどめて参考実装を用意していき、必要に応じてペアプログラミングを実施していくというところ。

事例2に関しては、VRT（Visual Regression Testing）はまだチームに浸透はしきってない考え方だというところもあるので、ドキュメントを用意して、テスト自体の考え方をチームメンバーにインストールしていくというところ。まだこのあたりは模索中なのですが、テストケースの網羅性を高めていくことで、書きやすい文化を作っていくのが大事かなと思っています。

これはちょっとオマケですが、これまで話してきたことをもう少し小さく始めることもできるかなと思っていて。

ボーイスカウトルールという考え方があります。これはよく「来た時よりも美しく」という言葉で表現されるのですが、例えば「目的のコードを変更する時に、ついでにその周辺を少しだけきれいにしてみる」というところで、例えば変数名をちょっとわかりやすく短くしてみたり、長いメソッドを2つに分割してみるとか、重複しているコードを排除してみるとか、いろいろできることがあるのかなと思います。

こういうところから小さく品質を上げられるかなと思います。一方、見てみて規模が大きくなる場合は、別途リファクタリングとして実施していくのが良いのかなとは思います。