はじめに

初めまして、新人として『ホットペッパービューティー』のAndroid開発チームに配属された25卒の関です。

今回は私が、配属後初めて1人で担当した案件での経験や案件を通して得た学びに関して共有しようと思います。 」 この記事を通して少しでもリクルートの開発組織への魅力を感じてもらえると幸いです。

案件の背景

まず、私が担当した案件の内容と案件が生まれた背景を簡単に説明します。 案件の内容は『ホットペッパービューティー』AndroidアプリでJSONデータを扱う際に利用しているライブラリをJacksonからKotlin serializationに移行するというものです。 移行の背景は以下の理由がありました。

1つ目は障害リスクの低減です。Jacksonは実行時にリフレクションを利用して動作します。そのため、Androidアプリのビルドの際に難読化の設定ミスがあれば、JSONパースが失敗するという障害につながってしまいます。これに対してKotlin serializationはリフレクションを利用せずに動作するのでリスクを軽減できます。

2つ目は、Androidアプリ開発のエンハンスの布石としてです。新しいナビゲーションライブラリであるNavigation3はKotlin serializationに依存しているので将来のライブラリ移行をスムーズに実施するための布石になると考えました。

また、この案件に私がアサインされた背景としては、案件内でアプリ全体を触ることになるので新人がアプリに慣れる機会として良いという理由があったそうです。

新人主導で案件に取り組める環境

この案件は、アプリ全体の通信機能に影響を及ぼし、大規模な障害につながる懸念がある重要なものでした。 変更することになるファイルは700ファイル近くあり、変更範囲が大きいということに加えてアプリ全体のAPI通信に関わる部分なためです。新卒で配属されて数ヶ月程度の自分がやっていいのかというふうにも感じていて不安な気持ちが大きい状態でした。

しかし、私自身やりたくなかったわけではなく、これから関わっていくプロダクト全体に関わることで内部の構造などの知識を得ることができるということや規模が大きい案件を自分1人で任せてもらえるということには価値を感じていました。

そうした中で、周りの環境を見てみると、担当する案件に関して相談できる定例の会議があったり、周りに相談できる先輩達がいるため、新人でも挑戦ができる環境があることに気づきました。また、これに加えて自分が不安に感じるものに挑戦することが自分の成長にもつながると感じたため、この案件を担当するという決意をしました。

案件内でぶつかった壁

作業のアプローチ

実際に案件に取り掛かってみて最初につまずいたポイントは、大量のファイルの変更作業をどのようなアプローチで進めていくかということでした。変更をする方法としては様々な選択肢があり、AI、スクリプト、人力などがありました。 まず人力はファイル数が多すぎるので現実的ではないと判断をして除外しました。

次にAIを利用しての移行ですが、今回の変更は機械的な作業で対応できる部分が多く、AIの「ある程度の柔軟性を持たせて作業ができる」という強みを活かせません。加えて、AIはスクリプトとは違い同じ入力でも毎回異なる結果になるので、出力をそのまま信用できません。そのため、作業自体は早く進めることができても、これを保証するためにはしっかりレビューをする必要が出てきて、PRマージまでの期間が伸びてしまう懸念がありました。

• PR: プルリクエストの略

移行作業自体の所要時間、変更をレビューしてもらう際のレビュワーの負担、マージまでの時間などを考慮した結果、最終的にはスクリプトを利用するという方針に決定しました。スクリプトとスクリプトのUnitテストを作成して、スクリプトのテスト観点に不足はないかを先にレビューしていただくことでこのスクリプトを利用して出力された結果の質を保証できます。この方針で周りの合意を取り、全てのファイルを一つのPRにまとめて出してレビュワーの負担も軽く、マージまでの時間も短縮できました。

アプローチ比較表（AI・人力・スクリプト）

リリースするための期限

スクリプトによる移行作業が進み、作業自体は完了の目処が立ってきた頃、2つ目の壁にぶつかりました。

私が関わっているプロダクトでは、2週間を1つの区切りとする開発サイクルを採用しており、QAチームは前のスプリントで開発したものを2週間かけて検証する流れになっています。スクリプトのおかげで移行速度は上がったものの、元々のスケジュールがタイトだったこともあり、このままではQA開始のタイミングに間に合わないことが発覚したのです。

先輩方にこの状況を相談したところ、「期限を調整できないの？」と言われ、強い衝撃を受けました。当時の私は「期限は絶対に動かせないもの」と思い込んでおり、QA開始に間に合わない＝リリース不可だと直結して考えていたからです。

しかし実際には、QAチームも全ての案件を同時に確認しているわけではありません。2週間の期間内で各案件を順番に検証していくため、その順番を相談すれば、期限調整が可能だったのです。 具体的には、下の図のように「案件A」の後に私の案件を検証してもらうよう順番を調整しました。このようにQAチームと検証順序を交渉して組み替えることで、無事にQAの期限内に作業を間に合わせることができました。

以前の私が思っていたQAフロー

実際のQAフロー

こうしてQAチームにも不具合がないかを確認していただくことができ、リリース後も大きな問題は起こさずに済みました。

案件で得たもの

私がこの案件を通して得たものはたくさんありますが、その中でも大きかったと感じる3つを紹介します。 1つ目は、自分が当初不安に感じていた案件を最後までやり切り、リリース後も大きなトラブルを発生させずに済んだという経験です。この経験によって、その後担当する他の案件でも配属当初と比べて自信を持って開発作業をできるようになりました。

2つ目は、スクリプトによる変更をした経験から、一見すると時間がかかりそうな作業もアプローチ次第で簡単にできるということを学びました。以前の私はいかにスピードアップさせるかだけを考えてましたが、そもそも作業のアプローチ自体を変えることも重要だと感じるようになりました。

3つ目は、QAチームとの期限調整の体験から、自分が見えている景色は一部でしかないことに気づき、見方を変えることで、選択肢を広げることができた経験です。私は当初QAチームがどのように仕事をしているかという解像度が低い状態でしか知らなかったため、相談して期限を調整するという選択肢がそもそも思い浮かんでいませんでした。この経験から自分が見えている景色はほんの一部でしかないので自分が知らないことを積極的に知りに行こうと思いました。

まとめ

今回、大規模かつ影響範囲の大きい案件に挑戦したことで、技術的な知識だけでなく、課題に対するアプローチ方法や周囲を巻き込む調整力など、職業としてエンジニアをやっていくために必要な多くのことを学ぶことができました。

配属当初は不安でいっぱいでしたが、一歩踏み出せたのは、新人の挑戦を温かくサポートし、挑戦の機会を与えてくれるチームの環境があったからだと感じています。 最後まで読んでいただきありがとうございました。