国内最大級の転職サイト「doda」は、15年以上稼働するシステムの技術的負債をどう乗り越えたのか？

　人材業界において、幅広い事業を展開しているパーソルキャリア。なかでも転職サービスサイト「doda」は国内最大級の求人数を掲載し、多くの転職希望者に利用されている。しかし、15年以上の歴史を持つ大規模システムゆえに複雑化が進んでおり、技術的負債の解消と柔軟性の確保が大きなテーマとなっていた。そこで同社はdodaのリビルドプロジェクトとマイクロサービス化プロジェクトを推進。歴史のある巨大なサービスだからこそ抱える課題をいかに乗り越えているのか。プロジェクトの中でチームリーダーとして活躍する奥野堅斗氏に話を伺った。

パーソルキャリア株式会社 カスタマープロダクト本部 プロダクト開発統括 dodaシステムアーキテクト／サブマネジャー 奥野堅斗氏

歴史ある国内最大級の転職サービスサイト、だからこそ抱えていた課題

──まずは自己紹介をお願いします。これまでどのようなお仕事に携わってこられましたか？

　私は2022年7月にパーソルキャリアに入社しました。前職でもエンジニアとしてキャリアを積んでいたので、エンジニア歴は約8年になります。入社直後は転職サービスサイト「doda」の機能追加を担当するチームに配属され、その後は自ら希望して「dodaリビルドプロジェクト」に参画しました。自から手を挙げたのは、新しい技術を積極的に取り入れているプロジェクトに挑戦したかったからです。

　現在はシステムアーキテクトとして、「doda」に関するアーキテクチャ周りの改善や保守を担当しています。その中でもマイクロサービスグループに所属し、「doda」の求人領域のチームリーダーとして、マイクロサービス化を進めています。ちなみに求人領域では、転職検討中の方が実際に触れるWebサイトの領域を担当しています。

──dodaリビルドプロジェクトは、どのような課題感から始まったのでしょうか。

　私が入社した2022年当時、「doda」のシステムは15年以上稼働している古いシステムでした。そして、豊富なデータを保有するスケールの大きさゆえに、フロントエンドとバックエンドのソースが混在しており、ちょっとした機能の追加や改修をしようとするだけでも影響範囲が広くなりがちで、開発速度が低下していました。

　加えてWebサイトの描画速度が遅く、さらにサイト内のパーツの動きも鈍かったため、Googleの「Core Web Vitals」（注：ページの読み込み速度、操作への反応性、視覚的安定性など、実際のユーザーエクスペリエンスを測定する指標）がほかの転職サイトと比べて低い値となっていたことも課題でした。

　これらの要因のひとつとなっていたのは、フロントエンドにJakarta Pages（JSP）を使っていたためで、バックエンドとフロントエンドが密結合になりがちでした。6～7年前までは外部のベンダーに依頼してシステムを開発していたこともあり、保守性をあまり考慮していない作りになっていたのです。開発工数やコスト増加の問題、開発速度および品質の向上のため、2020年からは内製化する方向性になったと聞いています。

　このような課題を解決するため、フロントエンドとバックエンドをきれいに分離し、フロントエンドをJSPからReactに置き換える、dodaリビルドプロジェクトが立ち上がりました。リビルドプロジェクトは私が入社する前から始動しており、私自身は2022年7月から2024年9月までの約2年間、参画していました。

スムーズなコミュニケーションを実現するため、チームの再編成を提案

──リビルドプロジェクトにおいて、奥野さんはどの部分を担当されたのですか。

　最初はバックエンドエンジニアとして改修に携わり、半年後にはバックエンド領域のチームリーダーを任され、タスク管理などに従事しました。

　当初、バックエンドとフロントエンドはチームが分かれて開発していたため、チーム間でのコミュニケーションロスにより、手戻りが発生することがよくありました。特にインタフェースの開発においては、バックエンドが提供するAPIとフロントエンドが開発していたものが合わなくて手戻りになる場面が多々ありました。

　そこで、フロントエンドとバックエンドのメンバーを混在させる形で画面ごとのチームが編成されることになり、私もチームのひとつを率いるリーダーを任されました。実は「画面ごとにチームを編成しては？」という提案をしたのは私なんです。混合チームにしたことでコミュニケーションがスムーズになり、そのような手戻りは改善されましたね。提案したからこそ改善がスムーズに進めたと思うので、受け入れてもらえる環境がありがたかったですね。

　また、リビルドプロジェクトではドキュメントが揃っていないなどの問題もありました。ただ、こうした経験は過去にも何度かあったので、それほど驚きではありませんでしたね。

　設計書は参考程度にするぐらいで、ソースコードを「正」として、ひたすらリバースエンジニアリングでソースコードから仕様を起こしていきました。ただ仕様を起こすだけでは漏れが生じるので、レビュー体制も整備しました。具体的には「このソースはこのような意味」といったコメントを書いていき、それをプルリクエストして、仕様として認識が合っているかレビューしてもらい、ダブルチェックで進めていきました。

　これを細かくすべてに対して行うと、時間がいくらあっても足りないので、ざっと仕様を見て、今の設計書と違う部分を更新し、問題がなければリリースする。リリース後に問題が出てくれば、元に戻すという形式を採りました。古いアーキテクチャをそのまま残し、新しいアーキテクチャで何か問題があれば、すぐに戻せるようにしたのです。最初から100％を目指すのではなく、90％を目指す。そして問題があればアラートを上げ、すぐ戻せる体制を作っておく。リビルドプロジェクトを経たことで「戻せる体制を作ることは最も重要なこと」だと実感し、その経験は現在のプロジェクトにも活きています。

──プロジェクトを通して、Webサイトにはどのような改善が見られましたか？

　Core Web Vitalsには3つの指標があり、いずれの指標もテストカバレッジでは70％以上を「良好」としているのですが、最終的な網羅率は80％を超えました。モダンなアーキテクチャに移行したことでリリースの頻度も増え、開発効率はかなり改善されたと思います。加えて、バックエンドではクリーンアーキテクチャーを採用し、外部への依存を極力なくすことで保守性を高めることもできました。