制作実績業務自動化・ツール開発

「動いているシステムを壊さず拡張する」を担保した求人スクレイピングシステムの機能拡張事例｜情シス代行

制作内容

「動いているシステムを壊さず拡張する」を担保した話

求人データを活用したサービスを運営されているお客様から、既存の求人スクレイピングシステム（求人サイトの情報を自動的に収集する仕組み）への機能拡張のご依頼をいただきました。

この記事は「すでに稼働しているシステムに機能を追加したいが、既存部分を壊さないか不安」という方に読んでいただきたい内容です。

クライアント概要

業種: 求人データ活用サービス事業者
規模感: 個人〜小規模
依頼: 既存の求人スクレイピングシステムへの対応サイト5つ追加

すでに納品済みのシステムをお使いいただいている中での、追加開発のご依頼でした。

課題・依頼背景（Before）

すでに稼働しているシステムへの追加開発では、「新機能を足すこと」以上に「既存部分を壊さないこと」が最大の論点になります。

対応サイトが増えるたびに、各サイトの構造差異を吸収する実装が必要になる
対応サイトが増えるほど、サイトごとの表示崩れや仕様変更のリスクが積み重なる
追加開発によって既存の5サイト分の処理に影響が出ないかは、動かしてみるまで分からない不安が残る

「言われた範囲だけ動けばいい」と考えると、テストを省いて素早く機能を足すことも可能です。しかし、それでは「既存機能を壊していないこと」を誰にも証明できないまま納品することになります。

提案・解決アプローチ

着手前に仕様書と工数費用の内訳を提示し、拡張範囲を文書で明確にしてから着手する進め方を最初に提案しました。認識のズレを防ぐため、口頭合意だけで進めることはしていません。

実装方針としては、「全サイト共通の処理に無理に統合する」案も検討しました。共通化できれば将来の保守は楽になりますが、今回の拡張範囲を超えて既存5サイト分のロジックまで触ることになり、影響範囲が必要以上に広がるリスクがあると判断し、見送りました。代わりに、新規5サイトは独立したモジュールとして追加し、既存部分には手を入れない設計にしています。

テストについても、「まず機能を作ってから、あとでテストを書く」進め方ではなく、機能ごとにテストを先に用意するTDD（テスト駆動開発）で進めることを選びました。手間は増えますが、拡張のたびに全体の健全性を検証できる状態を維持できます。

選択肢	メリット	見送った理由
全サイト共通処理へ統合	将来の保守が楽になる	既存5サイト分まで触ることになり影響範囲が広がる
テストなしで機能追加（採用せず）	着手から納品までが早い	既存機能を壊していないことを証明できない
独立モジュール追加＋TDD（採用）	既存部分に手を入れず、健全性を検証できる	─

実装内容

GitHub Actions（GitHub上でプログラムを自動実行できる仕組み）上でPlaywright（Webサイトを自動操作するツール）を用いたスクレイピング処理の構築
対応サイト5つの追加（各サイトの構造差異を吸収する独立モジュール設計）
TDDによる実装（機能ごとにテストを先に用意）
最終的に12件のテストすべてがPASSする状態で納品

成果

検収では7項目のデモ確認を行い、すべてクリアした上でリポジトリ（プログラムのソースコード一式を管理する場所）を譲渡しました。納品後は一定期間の保証期間を設け、その間の不具合対応を行っています。既存の5サイト分の処理に影響がないことをテストで示した状態での納品となりました。

お客様からは、既存システムに手を入れる不安があった中で、テストの結果を確認しながら安心して拡張を依頼できたという評価をいただいています。

本プロジェクトで大切にしたスタンス

ポイント1：全サイト共通処理への統合を選ばなかった理由

共通化できれば将来の保守は楽になる、という発想は技術者としては魅力的です。それでも、「今回依頼された範囲」を超えて既存部分まで触るリスクを取るべきかを検討し、依頼された拡張範囲にちょうど合う設計にとどめ、既存部分には手を入れない判断をしています。

ポイント2：テストを省かなかった理由

「動くものを作る」だけであれば、テストを省いても納品自体はできます。しかし、既存システムへの追加開発において「既存機能を壊していないこと」を示せなければ、クライアントは安心して拡張を依頼できません。手間をかけてでもテストを先に用意する進め方を選んだのは、この安心感を優先したためです。対応サイトが増えるほど、1つの改修が他のサイトの挙動に影響しないかという不安も比例して大きくなります。テストという形で健全性を可視化しておくことが、その不安に対する具体的な答えになると考えました。