Webエンジニアの入江です。 2児の親なのですが、衣替えの季節になると毎回子供の服が足りないなと思ってしまいます。成長期は大変。

さて、OpenWorkはクチコミサイトの印象を持たれる方が多いと思われますが、実は求人掲載も行っています。これまで、主に外部サイトに遷移させる求人（外部パートナーのサイトで情報登録&求人応募する）を中心にサービスを展開していましたが、OpenWorkに登録している企業が直接求人掲載できる機能の拡充が進み、この度4万件まで到達したため、外部遷移型のサービスを終了する運びとなりました。

サービス終了にあたり、大量のソースコードがデッドコードとなったので、先人に感謝を表しつつ削除しました。今回は、対応する中で経験した苦労ポイントについてご紹介します。

関連記事：20,000行のソースコードを削除した話 techblog.openwork.co.jp

どんな機能があったか

主に以下のような機能が実装されており、合計で約7万行のソースコードを削除しました。よく保守されていたな・・・

求人取り込み
求人検索（Elasticsearch）
求人表示
職種判定（機械学習）
重複求人削除（機械学習）
レコメンド（機械学習）
ブックマーク
閲覧履歴（Cookie/DynamoDB）

苦労ポイント

いにしえの機能の把握

レコメンドや職種判定、重複求人削除など、機械学習を活用したモジュールは実装当時のまま稼働しており、満足に保守対応できるメンバーがいない状態でした。なんとか情報を集めながら対応を進めましたが、結局レコメンドデータ作成の部分でエラーを出してしまいました。（ちょうどレコメンドの精度を上げる施策が走っていたため、旧機能は廃止しました。）

また、AWSのメトリクス監視で余計なエラー通知を飛ばしてしまったりもしました。

求人検索周りのコードの複雑さ

求人検索はElasticsearchで実装していますが、継承の影響で複雑に絡み合っており、どの機能からどのタイミングで呼ばれるのかを把握するのが難しい状態でした。注力サービスの一つであったため、過去に何人ものメンバーが試行錯誤した履歴が垣間見えました。

Cookieの考慮

Cookieはユーザ側で管理されるデータのため、古いデータを削除することができません。そのため、古いデータを考慮する処理を追加する必要がありました。現在、ネイティブアプリとWebアプリで共通利用できるよう、OpenWorkのサーバ上で履歴データを管理するようになったので、そちらに置き換えることを計画中です。

大規模リファクタリングとの順番調整

同時期にブックマーク機能のモジュラモノリス化が進行しており、修正範囲が盛大に競合することが想定されたため、リファクタリングを待ってから対応することとしました。幸いリファクタリングが早めに完了したため問題は起きませんでしたが、機能が密接に結びついていると同時作業の効率が落ちるなと実感しました。モジュール化された後のソースコードは影響範囲が閉じており、テストコードも充実していたため比較的楽だった印象です。