Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「モバイルアプリの大規模開発における組織的なソフトウェア改善から得た学び」の書き起こしです。
花田善仁氏：ただ今から「モバイルアプリの大規模開発における組織的なソフトウェア改善から得た学び」についてお話したいと思います。
まずは自己紹介から。株式会社メルペイの花田と申します。Androidチームで働いております。経歴としては、約5年前にメルカリのバックエンドエンジニアとして入社し、その後メルカリのAndroid、そしてメルペイのAndroidチームに移り、今はメルペイのAndroid機能をメルカリに組み込む作業をおもに担当しています。
さて、今回の話ですが、今年の2021年4月に投稿されたこの記事「モバイルアプリの大規模開発における組織的なソフトウェア改善の一事例と考察」この記事に関連して、実作業者として関わった経験をお話したいと思います。
はじめに、このバージョンアップデートは、約9カ月かかりました。その間にいろいろあったのですが、そこで学んだこと、経験したことなどをお話したいと思います。具体的にどういう問題が起きたか、そこで工夫したこと、残念ながらできなかったことなどについてお話したいと思います。
このプロジェクトの概要ですが、そもそも単純な話です。Kotlinのバージョン1.3.31から1.3.72に上げる、Kotlinxシリアライゼーションのバージョンを同じく0.10.0から0.20.0に上げるというものです。ただ、このバージョンアップに伴いましていくつかのファイルの修正が必要でした。それらは255ファイルで、コミット数はいろいろあって137コミットとなりました。
はじめに、メルカリのAndroidリポジトリについて紹介したいと思います。これは日高さんの記事にもありましたが、開発者が多いです。2～30人以上の開発者が日々プルリクエストをつくって送り込んでいます。そして、機能が多いです。われわれのルールとしては、1つの機能に対してGradleのモジュールをつくるというふうになっていますので、機能数に比例してモジュールは増えていきます。今およそ100のモジュールがあります。そして、それらのモジュールが相互に依存関係を持って1つの画面なり、機能なりを実現しています。このため依存関係はちょっと複雑になっています。
さて、これらのそれぞれの特徴から、いくつかの問題が見えてきました。まず、人数が多いので共通部分への責任感が薄くなりました。共通ライブラリのアップデート、それらの作業が人任せ、いつか誰かがやってくれるだろうという形になって、割といくつかのバージョンにおいて古いまま使うということになっていました。
次に、誰にレビューをしたらいいか分からない。私自身も実際会ったことがないエンジニアにもお願いしないといけなかったので、依頼自体は各チームに渡すのですが、いったい誰が担当しているのかがよく分からないという問題がありました。
次に、次から次へと新機能などがマージされています。それだけ日々たくさんの機能が追加されていきます。これらの開発ブランチ、Develop（ブランチ）からのマージ時に多くのコンフリクトだったり、新たに修正が必要なファイルが日々増え続けていました。今回一緒に発表しております@smoriwakiさんのチームでは、いろいろたくさんの機能を平行して開発したというお話があったと思いますが、あのチームの影響がたぶん一番大きかったかなと思います。
次に、機能が多いので検証にももちろん時間がかかります。依存関係も複雑なのでその分、組み合わせのテストケースが増え続けていきます。
そして、これは初期の手動の検証で発覚したのですが、直接関係なさそうな部分、全く修正などしていない部分でクラッシュが発生していました。幸い、これはプロジェクトの初期のころに分かったので慌てずに済んだのですけれども。
これらの問題に対していくつかの取り組みを行い、いくつか役に立ったものについてご紹介したいと思います。
まずは、修正事例集です。これは事前の調査、そして初期の修正作業によって、いくつかの修正パターンに分類できるということが分かりました。それぞれのパターンに書き換えるというような方法と、なぜかという理由などをまとめてGitHubのプルリクエストに日高さんがまとめてくれました。これらを使って修正を依頼する場合、あるいは、われわれが修正したケースをレビューしてもらうようなときにこれらの事例集を参照してもらい、なぜ必要なのか、どうしてこうなったのかということが共有できるようになりました。
次に、レビューチェックリストです。これらは修正されたファイルの一覧です。どういう状態にあるか、レビュー待ちなのか、最中なのか、終わったのか、担当者が誰なのか、アサインされているのかなどを一覧にしたものです。これは本当のものではなくて、雰囲気を感じてもらうために再現したものなんですけれども、全体で何パーセントくらいレビューが終わったかということを誰でも確認できるようになっています。今回は長期間でしたので、都度、ディペロップからマージで対象ファイルが増えるということもありましたが、そういう場合には私が主導で都度追加ということをしていました。おもに私とレビューアー、レビュー担当者の間で担当などを割り振ったりとか、進捗確認のときに使っていました。
次に、マイルストーンです。先ほどはレビューだけだったのですが、リリースまでのいくつかあるステップ、マイルストーン、どこまで終わって、今 何をしているか、次に何をやらなければいけないかということを定期的にシェアするために使っていました。今回、9カ月という長丁場だったんですけれども、四半期、クォーターについては4四半期、ほぼ1年にわたる長期のプロジェクトだったので、プロジェクトで時間をとるという担当の割り決めを決めるときにマネージャーなどに連絡したりとか、あるいは、QAチームにそろそろこの段階に行くので準備をお願いしますとか、そういう情報の共有などに使っていました。
最後に、ユニットテストです。これはエンジニアの方であればいっぱい書かれていることと思いますが、新しく修正が必要なファイルが追加されたとき、シリアライゼーションのパターンによっては全くコンパイルエラーなど発生しないケースもありました。そういう場合にも発見できるようにするためにユニットテストを追加していきました。これは一見、影響なさそうな部分で発生したという問題を見つけるためのもので、受け入れ側、渡す側の双方にテストを追加して、すぐに見つかるようにしています。これは、きょうの@hideyさんの発表にもありましたが、チームとしてテストのカバレッジだけじゃなくて効果的なテストという意味で、チームの目標とも合致していたというのもあるので一緒に作業を進めていきました。
今後の課題です。検証時間の短縮、これは機能が増えるので、当然、検証時間も増えますが、もっとも望ましいのは検証時間の短縮です。ですが、今回はここまでには至りませんでした。クライアント開発をされている方ならご存知だと思いますが、年末になると審査期間が一時的に止まる期間があります。その期間を利用して一気に検証を進めました。ただ、この手は年に1回しかリリースできないというふうになってしまうので、さらなる工夫が必要だということでいくつかの取り組みをやろうとしています。
次に、組織的な対応です。Client Platform Group、これはクライアントに共通の問題を解決するためのバーチャルグループです。メルカリ、メルペイのクライアントエンジニア、Androidだけじゃなくて、iOSのエンジニアも参加しています。参加は任意ですが、これは去年2020年5月ぐらいから活動を開始しています。いくつかのチームに分かれていまして、Build/Tool、Test/CI、Release/CDなどのチームがあります。Kotlinアップデートのような共通部分のライブラリアップデートはBuild/Toolチームが今は担当するようになっています。
まとめです。このように、現場レベルではいくつかの工夫が生まれました。また、組織をまたがる共通の課題を解決するための新たな組織、バーチャルグループをつくりました。ただ、いくつか残る問題もありますので、自動テストなどの検証をさらに効率化するための取り組みを進めていく必要があると思います。これについては、また何か良いアイデアなり、取り組みなりが生まれましたら、どこかの機会でご紹介したいと思います。
短い間ですが、きょうはありがとうございました。ご清聴ありがとうございます。以上でセッションを終了します。
