この記事は ANDPAD Advent Calendar 2022 の 11日目の記事です。
アンドパッドで EM (Engineering Manager) を担当している栗山です。現在、施工管理アプリチームというモバイルアプリの開発を専門に担当するチームに所属しています。前職では iOS エンジニアを担当していたことから、前職での経験を活かしながら日々改善を進めているところです。
今回は、入社から約半年が経過した今に至るまでに自分やメンバーが試した改善施策や、私が所属する施工管理アプリチームがスゴいと思う点について書いていきたいと思います。
これまで実施した施策について
ここでは、2つに絞ってこれまでに実施した施策について紹介したいと思います。
なお、ここで紹介する施策は、いずれも自分一人で進めたものではなく、チームメンバーやチーム外の関係者の皆さんの協力なしには進められなかったものばかりです。ありがとうございました！
開発で使用するマシンを M1 CPU 搭載 Mac へ交換
私が入社して真っ先に実施した施策です。施工管理アプリチームでは毎週モブプログラミングを実施していますが、その中でコードを修正する際のビルド時間に結構な時間を要していたことが気になり、それが今回の行動を起こすきっかけとなりました。
新規に入社された方については既に M1 CPU 搭載 Mac (以後、M1 Mac) が貸与されるようになっていました1が、 M1 Mac の貸与が開始される前に入社された方については、一定の貸与期間が過ぎてからでなければ交換ができませんでした。前職で M1 Mac に交換することでビルド時間が劇的に改善することはある程度認識していたので、特例で一定期間が経過していなくとも交換できるようにしていただきました。話を進める上で、自分の経験だけでなく他社さんの実績など、既に十分な実績があり、大変助かりました。
ただ、モバイルエンジニア全体に広げる前にまずは私の所属する施工管理アプリチームが先行で導入し、導入の効果や課題を洗い出してもらうことにしました。
下記は、 ANDPADアプリ(iOS版)のビルド時間の計測結果です。
- フルビルド
- Intel (Core i7): 308 sec
- M1 (M1 Max): 93 sec
- 差分ビルド
- Intel (Core i7): 87 sec
- M1 (M1 Max): 18 sec
同様に、 ANDPADアプリ(Android版) のビルド時間の計測結果です。
- フルビルド
- Intel (Core i7): 145 sec
- M1 (M1 Max): 87 sec
- 差分ビルド
- Intel (Core i7): 11 sec
- M1 (M1 Max): 6 sec
上記のとおり、アンドパッドにおいても同様に M1 Mac を導入することで、ビルド時間が劇的に改善されることが証明されました。
先行導入の結果をひっさげて、他のチームでも希望者は M1 Mac に交換してもらえるようにしました。事前検証の結果が活かされ、導入がスムーズに進みました。事前検証以外にも、導入がスムーズに進んだ要因として下記2点があったと振り返って思います。
- プロダクトが複数あるものの似たような技術スタックだったため、事前検証の横展開がしやすかった
- 隔週で他チームのモバイルエンジニアと情報交換を行う場が設けられており、 M1 Mac の導入状況が小まめに他チームにも連携されていた
さて、ここまでは、主に開発時に使用するローカルマシンでの話でしたが、更に踏み込んで、現在は利用している CI/CD においても M1 CPU を利用するようになりました。
現在、施工管理アプリチームの iOS 開発では Bitrise を利用していますが、 Bitrise ではM1 CPUを利用したスタックが利用可能でした。
スタックとしては Elite XL スタックと同額のクレジットが必要であることから、慎重に検討していましたが、リリースビルドに絞れば決められたクレジットの枠を超えることはないだろうとの判断から、導入に踏み切りました。
結果としては、これまでリリースプロセスにおいてかかっていた時間を短縮することに成功しました。
- リリースビルド (Bitrise)
- Intel (Gen2 Standard): 平均して20分強
- M1 (M1 Elite XL): 14分27秒
リリース時のビルド時間が短縮するだけでも全体のリリースプロセスにおける時間短縮をもたらします。全体のリリースフローにかかる時間から比べると決して大きくない時間ではあるものの、リリース前QAの開始時間を早めることでメンバーのリリース時の負荷軽減につながるなど、さまざまな面で恩恵をもたらします。
M1 CPU のパワーを活かした今回の施策は、費用対効果の面で効果が高い施策だったと振り返って思いました。
「技術的負債リスト」の運用を開始
こちらは最近はじめた施策です。施工管理アプリはアンドパッドの中でも最も歴史の長いプロダクトの一つです。そのため、最新のトレンドやプラクティスとはかけ離れたものとなっている実装が点在していたり、Fatかつ複雑な実装のクラスの存在が品質面に影響している、といった問題があります。
幸いなことに、施工管理アプリチームは改善意識の高いメンバーが揃っており、私が入社する前からこれまでに数多くの負債の返済を継続的に実施してきました。
一方で、負債のボリュームや数によってはチーム体制や採用計画にも影響が出てくるので、特に大規模な改善タスクについては事前にロードマップを引いて計画的に対応しておきたかったのと、チームが認識している技術的負債が現在どのくらいあってどう進行しているのかについて自分自身が把握しておきたい、といった課題がありました。
そのため、メンバーの皆さんの協力のもと、「技術的負債リスト」という仕組みの運用を開始しました2。以下のようなアクションを実施していきます。
- iOS / Android それぞれについて、Google スプレッドシートに思いつく限り技術的負債を書き出してもらう(図1)3
- 書き出してもらった負債について、緊急度と重要度または負債のボリューム感を1〜5の5段階で評価して記載してもらう
- 着手順に並べてもらい、向こう1〜2スプリント先の実行予定を記載してもらう4
こうして、 iOS / Android 共に運用を開始しましたが、運用を回してみたところ、思わぬ副次的な効果がありました。
ある日のエンジニアのミーティングで、「負債がたまっていて困っている」的な話になり「解消するとなると大掛かりになるから現時点で対応するのは厳しそう」といった話の結論になりかけました。そういった場面で「技術的負債リストに起票して対応してみては？」といったひと言を問いかけたことで、負債の解消をあきらめることなく、継続して検討する方向に持っていくことができました。
技術的負債リストがあることで、これまで諦めていた改善を諦めず済む可能性が出てきたという意味で、技術的負債リストの新たな可能性を見た気がしました。
入社半年を経過して思った、施工管理アプリチームのここがスゴい
ここからは、私が入社して半年の間に感じた、施工管理アプリチームの強みについて紹介したいと思います。私が特に良いと思うのは下記2点です。
改善意識が高い
社内で最も歴史のあるモバイルアプリである施工管理アプリは、前述の通り技術的負債も相応に積み重なっている状態です。そのため、積極的な改善を続けていかないことには後々品質や生産性に悪影響が出てしまいます。
そういった事情もあるかと思いますが、それを差し引いてもチームメンバーの改善意識の高さには目を見張るものがあります。
機能開発や機能改善以外の時間については、iOS / Android それぞれで課題やタスクを話し合った上でメンバーが主体的にリファクタリングや CI/CD の改善を進めています。入社以来、iOS / Android それぞれのエンジニアミーティングに参加していますが、次から次へと活発な意見や提案がされていて、レトロスペクティブのときと同様に、ただ課題を出して終わりではなくそれを次のアクションへ繋げている点も大変印象的でした。
また、新しい技術についても他のチームに先駆けて導入することが多く、前述のM1 Macの件もそうですし、 Jetpack Compose (Android)、 Code Climate の利用 (チーム内の iOS エンジニアの発案で iOS チーム内で効果検証中) 、 デザインシステム導入 (iOS / Android) など、先行して導入して他チームに知見を共有するといったケースも多くあり、自チームだけでなく他チームに対しても良い影響をもたらしているように感じました。
チームの雰囲気が良い
ここに書く話でもないかもしれないですが、自分が入社したときから施工管理アプリチームの雰囲気は非常に良いなと感じていました。雰囲気の良さは各種ミーティングにも現れており5、笑いも交えながら終始和やかな雰囲気です。
私が考えた雰囲気の良い要因としては、雑談を大事にしている点や感謝の気持ちを言う場を大事にしていることが挙げられます。
雑談については、朝会冒頭で日替わりでアイスブレークを実施することはもちろん、スプリントレトロスペクティブ冒頭でもメンバー全員がアイスブレークを実施しています。また、スプリントプランニングの余り時間を利用して、ブレークアウトルームで少人数で4〜5分で3〜4回メンバーを変えて雑談をする試みも行っていて、大変手厚いと感じました。リモートメインだと雑談の機会を作るのは難しいなと常々感じていたので、スクラムの仕組みを上手く活用した試みだと思いました。
また、感謝については、施工管理アプリチームではスプリントレトロスペクティブでKPT (Keep Problem Try) を実施していますが、 Keep は図2のとおり毎回多くの感謝と祝福の気持ちで溢れています(Keep 的な使い方と Good 的な使い方を兼ねているイメージです)。こういった活動が、心理的安全性を生み出しているのではないかと改めて思いました。
おわりに
入社して半年が経過しようとしていますが、半年の間にも様々な改善を行うことができたと考えています。
来年も、施工管理アプリチームはやりたいことが目白押しです。ユーザーの利便性を高めるための新機能追加を確実にかつ数多くリリースできるようなデリバリーの改善は今後も続けていきたいですし、Jetpack Compose や SwiftUI といった次のデファクトスタンダードになると思われる技術への対応6 や継続した技術的負債への対応を継続していく必要があります。
私としては、そういった活動をサポートできるよう、各種施策や環境整備、組織体制の改善を来年も実施していきたいと考えています。
EM としての自分自身の今後
最後に、少し私個人の話を少しさせてください。
入社してからここまで、新米 EM として「とにかく情報が大事！」というのをモットーに、様々なミーティングに出席したり部署内外で 1 on 1 を実施して情報収集を実施してきました。上手く行った部分とそうではない部分がありますが、お陰様で、自分が所属するチームとその周辺についてはだいぶ把握できてきたと考えています。
ただ、アンドパッドは Vertical SaaS を標榜する企業で、かつ建設業界のあらゆる業務フローの改善を推進すべくマルチプロダクト展開をしている企業です。ドメインは同一業界といえど非常に奥が深く、開発チーム数が多いため、まだまだ全体像を把握しきれてるとは言えない状態です。引き続き、アンドパッドの事業ドメインの理解を続けていきたいと考えています。
また、EM としてメンバーが力を発揮できるようにサポートすることも情報収集と同じくらい大切なことと考えており、自分だけではなくチーム全体、さらには横断的に会社全体の生産性最大化にフォーカスして、今後も改善活動を続けていきたいと考えています。
余談ですが、自宅の周りで住宅や道路工事が行われているところを見ると、これまでとは違った視点で工事現場を見るようになりました。仕事柄、工事現場に興味を持ち続けることは非常に大事なことだと思うので、これからも街ナカで不意に遭遇する工事現場に思いを馳せることは忘れずにいたいと思います。
一緒にプロダクトグロースや改善活動に携わってみませんか？
そんな施工管理アプリチームでは、事業のさらなる発展や技術課題の解決を一緒に担っていただけるエンジニアの方を大募集しております！施工管理アプリチームにご興味を持たれた方は、ぜひ下記のサイトをご覧ください！
明日はボードチームのエンジニア 原田さんが先日Go言語のイベントで登壇した際のLTの解説ブログを公開してくれる予定です。お楽しみに！！
- andpad-dev/recruit: エンジニア支給PCのスペック表↩
- 「技術的負債リスト」という名称ですが、技術的負債だけでなく改善系のタスク全般を起票可能です。↩
- 表中にある「Codable に移行する」については、 Codable 登場前に実装された箇所を Codable へ置き換えることを目的としています。↩
- 施工管理アプリチームではスクラム開発 (1スプリント2週間) を実施しており、スプリントプランニングで次スプリントで実施する技術的負債をエンジニアの方に共有してもらう運用となっています。↩
- 現在、アンドパッドでは出社日数に制限が無く、特にエンジニア職の方はフルリモートを実践されてる方が多いです。そのため、施工管理アプリチームのミーティングも、オンライン開催を前提とした構成となっています。↩
- おかげさまで、 ANDPAD iOS アプリも Deployment Target を13へ上げることができたので、これから SwiftUI や Swift Concurrency の導入を進めていくことができるようになりました！↩
