2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
開発チームの生産性向上に取り組む(全1記事)
リンクをコピー
記事をブックマーク
髙橋佑太氏(以下、髙橋):それでは「開発チームの生産性向上に取り組む」と題して、株式会社ウーオの髙橋が発表します。よろしくお願いします。
まず簡単に自己紹介します。(先に)紹介してもらったとおりですが、もともとAndroidエンジニアとしてキャリアをスタートしていて、メガベンチャーや保険のスタートアップなどを経て、2021年7月に株式会社ウーオにソフトエンジニアとして入社しました。現在は主にFlutterとRuby on Railsで開発をしています。
本日のアジェンダですが、タイトルにもある“生産性”という言葉の認識をそろえたうえで、私が生産性向上に取り組んだ事例を2つ紹介した後に、それらの事例をとおして、技術的観点での生産性向上について、生産性向上を図ることの考察をして最後にまとめとします。
まず初めに生産性とは何か(について)ですが、一般的には時間あたりの生産量として言われるものです。しかし、プロダクト開発においてはいくつかの観点があるかなと思っています。
例えば、開発サイクルのスピードを高く保ち、かつ品質が安定しているかどうかと、開発によってそのプロダクトの価値をユーザーに届けられているかなど、いくつかあるかなと思います。
このLTでは、前提として多様な観点がある中で「チーム開発を技術的観点から改善し、開発スピードとプロダクトの安定性を高めていくこと」に着目してみようと思います。
とりあえず事例1つ目で、これは前職の経験なのですが、プルリクエストのマージのリードタイムの短縮をしていた事例を紹介します。課題としては、チームメンバーの入れ替わりが多い中で、アーキテクチャの浸透とレビューにかかるコストが増大していて、プルリクエストのマージまでに時間がかかっていたという問題がありました。
どういうコストがあったかというと、メンバーごとにアーキテクチャを説明していくコストだったり、ドメインロジック以外のレビューにかかるコストが、かなりあったなと思っています。また、ドキュメントを用意しても、やはりアーキテクチャはどんどん進化していくので、その変化に追いつかずに、あまり役に立たない状況となっていた課題がありました。
そこで、解決手段としては、アーキテクチャとしてレイヤーごとの責務を明確にすることと、アーキテクチャの設計段階で実装のために考えることをできるだけ減らして、ビジネスロジックの実装に集中できる環境を作る手段をとりました。
(スライドを示して)こちらが実際に構築したアーキテクチャです。
詳細は省きますが、どういう考え方を取り入れたかについては、Androidアプリの例で、ローカルのデータベースを使って「信頼できる唯一の情報源」と呼ばれる考え方を用いてデータの整合性を担保して、各画面がデータの変更を意識しなくても良い状態を作ったというところ。
また、クエリとコマンドという登場人物がいるのですが、これはCQRS(Command Query Responsibility Segregation)を参考にドメインレイヤーを構築して、ドメインロジックを集約していくことをやりました。
ビューモデルはそれらのクエリを監視するところと、コマンドを実行する(ところ)。また、ビューからのちょっとした処理を行うところで、処理を限定することで実装をパターン化していくことをやりました。
結果として、ビジネスロジック以外の実装をパターン化できるようにしたことで、そのビジネスロジックの実装に集中できるようになったところと、レビュワーとしては、ビジネスロジックのみに集中してレビューすれば良い状態になりました。また、新しいメンバーが入った時でも、最低限の説明で、既存の実装を見ていけば迷うことなく開発できる状態となりました。
次に事例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つに分割してみるとか、重複しているコードを排除してみるとか、いろいろできることがあるのかなと思います。
こういうところから小さく品質を上げられるかなと思います。一方、見てみて規模が大きくなる場合は、別途リファクタリングとして実施していくのが良いのかなとは思います。
最後にまとめです。今回は技術的観点でのチームでの生産性向上について取り上げました。先ほど紹介した2つの事例が、考え方として参考になれば幸いです。また、これらを実行していくには課題の発見からチームへの浸透までをしっかりやりきる必要があるかなと思っていて。
また小さく始めるなら、ボーイスカウトルールという考え方を取り入れるのも良いのかなと思います。
以上で発表を終わりにします。ご清聴ありがとうございました。
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略