私たちが呼ばれる問題と、それにどう取り組むか。

状況。 数百件の公開求人がATSにあります。採用サイトは別のCMSで、手作業で更新されています。求人の公開は遅れ、締め切った求人が応募を受け続け、同じ職種が異なる給与帯で2回存在します。リクルーターは候補者にATSのリンクを直接送り始め、採用ブランドと、それに伴うすべての分析イベントを失っています。

アプローチ。 ATSを唯一の情報源として扱い、求人データをほかのどこにも書かないようにします。文書化されたAPIを通じてスケジュールで求人を取り込み、各レコードを境界で検証して、不正な求人や公開途中の求人が誤って表示される代わりに大きな音を立てて失敗するようにします。サイト独自の層は、ATSにフィールドのないもののために残します。オフィスのページ、福利厚生、採用プロセスの説明文です。

何が変わるか。 求人の公開はウェブサイトのチケットではなく、ATSの操作になります。候補者がドメインを離れないので、応募の追跡はそのまま保たれます。

状況。 もともと話すようにできていなかった2つのシステム、たとえばERPとCRMが、毎週、誰かがCSVを書き出し、本人にしか分からないルールでシートに貼り付けることで突き合わされています。その人が休暇に入るまでは動きます。2つが食い違ったとき、どちらが正しいか誰も言えません。

アプローチ。 手作業のステップと文書化されていない例外も含めて、今日実際に動いているものを整理し、コードを書く前に、その仕事をしている人とその読みを確認します。それから、地味な性質を備えたミドルウェア層を。明示的なフィールド単位のコントラクト、リトライがレコードを重複させないための冪等な書き込み、失敗したもののためのデッドレターキュー、そして私たちなしで運用担当者が読めるログ。

何が変わるか。 突き合わせが暗黙知ではなくなります。ベンダーがAPIを変えたとき、来四半期のレポートで黙って壊れるのではなく、既知の場所でアラート付きで壊れます。

状況。 カタログが今の10分の1だったころに選んだCMSとショップのスタック。カテゴリページは遅く、コンテンツの変更のたびに開発者とリリース枠が必要で、価格を扱うプラグインは何年も更新されていません。全面的な書き直しは2回提案され、2回中止されました。URLとチェックアウトが週末の間止まることを、誰も許容できないからです。

アプローチ。 一括切り替えはしません。まず今あるものを棚卸しし（URL、リダイレクト、構造化データ、誰も覚えていない連携）、同じドメインの裏でスライス単位で移し、最後のスライスが検証されるまで新旧のスタックを並行して稼働させます。リダイレクトマップと検索可視性のチェックは、リリース後の驚きではなく構築の一部です。

何が変わるか。 編集者はデプロイなしで公開できます。移行は、誰もが恐れるひとつの週末ではなく、元に戻せるステップの連続になります。