この記事は Timee Product Advent Calendar 2025 の6日目の記事です。
こんにちは、タイミーでバックエンドエンジニアをしていますktanooooです！
2025年11月に入社しました！
記事タイトルの事の発端は、2025年8月6日に出されたタイミーのM＆Aに関するリリースでした。スキマワークスという会社がグループ会社になるという内容です。当時そこで働いていた僕も公表の当日に事実を知るわけですが、その直後、社内で正式なお達しがありました。
「今月いっぱいでサービス終了します」
グループ会社となるスキマワークスは物流特化型BPO事業に強みを持つ一方、自社でもスキマバイトサービスを運営していました。グループ入りに伴う事業整理の観点から、スキマワークス側のサービスをクローズするという決定でした。
本記事ではサービスをどう畳んだかについて、振り返って整理をしてみたいと思います。
サービス終了って何やるの？
サービス終了というと「案内を出してサーバーを停止して終わり」と思いがちですが、スキマバイトの場合は職業紹介や労務管理に関わるサービスの特性上、そう簡単にはいきません。
そしてそれ以外にもいろいろな要件が出てきます。
- 法務:「法令に則って資料(データ)を適切に管理する必要がある（ちゃんと管理してね）」
- 経営:「サービス終了だしコストは最小限に（お金かけられないよ）」
- 運用:「インフラは残してなんかあったら復旧できる状態に（いつでも戻せるように）」
- CS:「問い合わせ対応はエンジニア以外で完結したい（資料はPDFだと嬉しい）」
※ 法令に則った資料の管理とは
| 名称 | 保存期間 | 根拠 | 備考 |
|---|---|---|---|
| 源泉徴収簿 | 7年 | 所得税法 第120条 | 源泉徴収票の発行根拠となるもの |
| 労働条件通知書 | 5年 | 労働基準法 第109条 | |
| 賃金台帳 | 5年 | 労働基準法 第109条 | |
| 求人/求職/手数料管理簿 | 2年 | 職業安定法施行規則24条 |
これらの資料はサービス運営していて日常的に取り扱うデータも含まれますが、都度発行するものがほとんどで、事前にすべて「PDF化」して保存しているわけではありませんでした。
そして、サービス終了後もユーザーからの源泉徴収票発行依頼は想定されます。外部機関からの問い合わせ対応もあるかもしれません。
その不定期な対応のためにサーバーを常時稼働させるのはコストの無駄ですし、かといって必要な時だけエンジニアがサーバーを立ち上げる運用も非現実的です。
議論の末、導き出した対応方針は以下の通りです。
-
データの資料化:
法務・CSの要件から、全ての必要書類を発行済みの状態（PDF）にしておく -
インフラの塩漬け:
経営・運用の要件から、ランニングコストを最小化しつつ、万が一の調査やPDF再発行に備えてインフラを復旧可能な状態にする
方針は決まりましたが、いくつか問題があります。
- 労働条件通知書のPDF発行機能が存在しない(アプリ上での明示や問い合わせでの手動発行を行なっていた)
- IaCなんて導入してない
- 資料の総数が100万件規模になるけど間に合う？
そして何より当時のチームはデザイン1名エンジニア1名の最小構成でした。短期間でこれらに向き合う必要がありスケジュールの見直しが必至です。
今月終了と言ったな、あれは嘘だ
実は対応方針の整理をしている段階でスケジュールの見直しは確定していました。プライバシーポリシーに準拠しつつ各種要件のすり合わせを行った結果、最終的に10月10日にサービスを終了することとなりました。
概ね以下のようなスケジュールで進行しました。
スケジュールを引いた段階で１ヶ月と少し猶予がありそうです。厳密にいうと、サービス終了後すぐにサーバー落とす必要はないのですが、なんかそっちの方がキリがいいので10月10日の作業完了を目指しつつ後ろに少しバッファもあるよという心理的余裕もある状態で着手していくことになります。
100万件規模のPDFを捌く
スケジュールが引けたところでいよいよ作業開始します。
サービス開始から5〜6年が経過しており、保存期間の要件（5〜7年）を鑑みると、実質的に過去の全求人と全稼働データのPDF化が必要でした。
対象は100万件規模。これを短期間でPDF化して適切な場所へアップロードして管理する必要があります。
現状の構成ではとても捌き切れず、数で殴る作戦を決行します。
- 非同期処理: Sidekiqで非同期処理
- 水平スケール: 一時的にECSのタスク数を増加
- リソース調整: 各タスクのCPU/メモリを増強し、Concurrencyを増加
- DB調整: 並列数増加に合わせてConnection Poolを調整
※それぞれの具体的な数値は覚えてないです
(nanobananaが言うことを聞きませんが大体こんな感じです)
2~3週間くらいかかった
PDFを管理するストレージへアップロードするため、どうしても避けられない遅延が発生します。
労働条件通知書のPDF発行機能の新規実装に加え、古いデータに対するバリデーションエラーなどのイレギュラー対応を手動で対応しつつ、数の暴力でなんとか片付く目処がつきました。
インフラのランニングコストと復旧性の両立
「今どきIaCくらい整ってるでしょ」と思われるかもしれませんが、エンジニアリソースの少ないスタートアップで、そこまでの環境は整っていませんでした。
これまで手動でインフラリソースをポチポチしていたわけですが、要件を満たすため、皮肉なことにサービスを畳むためにIaCを導入することになります。
Terraformの採用
選定理由では特に悩みませんでした。タイムリミットが迫っている中で、広く使われていて早く片付けられそうだからというだけでした。
ゼロから全てコード管理する時間的余裕はありません。管理が必要な部分だけterraform importで取り込み、必要リソースの復旧・停止ができる状態を作ります。
管理対象のリソースの洗い出し
Billingを確認しながらコードでの管理対象となるリソースの洗い出しをしました。
時間単位でコストのかかるものを優先的にスナップショット化、削除していくことになります。
大きくコスト削減に寄与したものをピックアップすると以下のような感じでした。
(nanobananaに20回くらいやり直させました)
最終的なランニングコスト
結果、最終的なランニングコストは 月額1,600円程度に着地しました。主にS3やスナップショットのストレージ料金と細かい端数の足しあわせという感じです。
ランニングコストとしては許容範囲と判断してここで作業を終えました。
まとめ
「サービスを作る」情報は世の中に溢れていますが、「サービスを綺麗に畳む」 記事はあまり見かけないので整理も含めて書いてみました。この記事が、いつか来るかもしれない誰かの参考になれば嬉しいです。
そして、前職のスキマバイトサービスのクローズを通じて法令遵守維持の壁を感じたと同時に、改めて重要な資料を取り扱っていて大きな責任が伴うサービスなんだと感じました。
そんな責任感のある、社会に影響のあるサービスに携わってみたい方、ご興味があればぜひお話ししましょう！