3年前に作った社内ツールを、今期で閉じることになった。使っている人はもうほとんどいない。サーバーを止めれば終わり、のはずでした。
実際に始めてみると、そうはなりません。ドメインはどこで取ったのか。決済はどのサービスを通していたのか。監視ツールからのメールがまだ届いているが、あの契約は誰の名義なのか。止める作業ではなく、探す作業になります。
Zenn で話題になった「Webサービスの終わらせ方」という記事が的確なのは、作った本人が同じ状況に陥っている点です。Cloudflare Workers、Supabase、決済 SaaS、AI、監視。現代の開発では外部サービスを足すコストがほぼゼロなので、楽しく足していける。そして閉じるときに、管理画面を一つずつ巡回しながら「全部自分が登録したんだった」という事実に向き合うことになります。
作った本人ですらこうなるのだから、外部に発注したシステムなら、終了作業はもっと重くなります。
止める対象はサーバーではなく契約
終了作業が想定より重くなる理由は単純で、止めるべき対象がサーバーではないからです。
サーバーやコンテナを落とすのは一瞬です。時間がかかるのは、そこにぶら下がっている契約と権限のほうです。
- 課金が続く契約 — ドメイン、証明書、CDN、DB、ストレージ、監視、エラー通知、決済、メール配信。個別には月数百円でも、放置すれば数年ぶん請求され続けます
- 名義が個人になっている契約 — 制作会社の担当者や退職した社員のアカウントで取得されているもの。解約しようにも本人にしか操作できません
- 他のシステムから参照されている資産 — 画像の直リンク、リダイレクト元のドメイン、社内文書に貼られた URL。消した瞬間に別の場所が壊れます
- データそのもの — 顧客情報や取引履歴を、法令や社内規程に沿って保管するのか削除するのか。決めていなければ止められません
このうち実務でいちばん詰まるのは2番目です。契約の名義が組織になっていないと、技術的にどうにもできません。制作会社が代行してドメインを取っている場合、移管手続きが必要になり、その会社との関係が良好でなければそこで止まります。
重くなる原因は技術ではなく記録
終了作業が難しいのは、技術的に高度だからではありません。依存の一覧がどこにも存在しないからです。
作っている最中は、依存を足すたびに記録を残す動機がありません。動けば正解で、その時点では全員が把握しています。記録が要るのは、把握している人がいなくなった後です。つまり記録が必要になるタイミングと、記録を書ける（書く気になる）タイミングが完全にずれています。
しかも依存は、コードを読んでも全部は分かりません。環境変数に入っている API キーが、どのサービスのどのプランのものかはコードに書かれていない。請求書を見ても、サービス名だけでは何に使っているか判別できない。コードと請求書の両方を突き合わせないと復元できない構造になっています。
引き継ぎのときに何が渡されていれば足りるかは納品ドキュメントの4種類で整理しましたが、そこで挙げた資料は終了作業にもそのまま効きます。逆に言えば、引き継げないものは終わらせることもできません。
発注の段階で決めておける4項目
終了条件は、稼働してから決めようとすると誰も決められません。関係者の関心が薄れているうえに、決めるための情報が失われているからです。発注時に契約や仕様書へ入れておくべきなのは、次の4点です。
1. 外部サービスの契約名義を組織にする。ドメイン、クラウド、SaaS のすべてを自社名義のアカウントで契約し、制作会社には権限を付与する形にします。ここを最初に決めておくだけで、終了作業の難易度が大きく変わります。
2. 依存サービスの一覧を納品物に含める。サービス名、用途、プラン、課金額、契約者、解約時の影響。この6項目が並んだ表が1枚あれば足ります。更新のタイミングは、依存を足したときと、年に1回の棚卸しのときです。
3. データの返還形式と期限を決める。「終了時にデータを CSV および画像ファイルとして引き渡す」といった具体的な形式まで書きます。書いていないと、独自形式のダンプを渡されて実質的に使えない、ということが起きます。
4. 停止後の跡地をどうするか決める。ドメインを維持して案内ページを置くのか、リダイレクトするのか、完全に手放すのか。手放したドメインは、期限切れを狙って再取得する「ドロップキャッチ」の対象になります。過去にアクセスがあり検索評価の付いたドメインほど狙われやすく、詐欺サイトやメールアドレスとして悪用される事例が報告されています。社名やサービス名を含むドメインは、閉鎖ページを置いたうえで一定期間は保持する、という前提で扱いを決めておく必要があります。
この4点は、終了のためだけの取り決めではありません。制作会社を変更するときにも、そのまま同じ条件が効きます。乗り換えの自由度を確保するコストだと考えると、発注時に交渉する動機が持てます。既存サイトの引き継ぎで実際に何が問題になるかはレガシーサイトの引き継ぎと保守にまとめています。
稼働中にやっておくと効くこと
すでに動いているシステムについては、発注時に戻れません。それでも効果が大きいのは、支払いから逆算した棚卸しです。
クレジットカードの明細と請求書を1年分並べ、海外 SaaS への支払いを抜き出す。金額が小さいものほど誰も見ていないため、ここに「何に使っているか分からない契約」が溜まっています。使っていないものはその場で解約でき、使っているものは依存一覧の初版になります。
この作業が効くことには裏付けがあります。SaaS 管理の調査では、SaaS 購入のおよそ4割が IT 部門を経由せずに行われていると報告されており、中堅企業では稼働中のアプリのうち情シスが把握しているのは半数程度とされます。つまり明細から入るほうが、システム側から辿るより網羅性が高い。「使っていないものを解約する」だけの作業に見えて、実際には存在を知らなかった依存を見つけるための手段です。
ライセンスやアカウントの棚卸しと同じ作業なので、まとめて進めるほうが効率的です。進め方はGoogle Workspace のライセンス棚卸しで扱った手順が流用できます。
次にやること
いま動いているシステムを1つ選び、「これを来月止めるとしたら、何を解約する必要があるか」を書き出してみてください。書き出せない項目が出てきたら、それが記録の欠けている場所です。止める予定がなくても、その空白は担当者が変わった瞬間に問題になります。
新規に発注する予定があるなら、上の4項目を要件に入れてください。追加費用が発生する性質のものではなく、決めておくかどうかだけの差です。
既存システムの依存関係の棚卸しや、終了・移管を見据えた契約条件の整理については、グリームハブの開発・AI・自動化のご相談で承っています。構成や契約の経緯によって進め方は変わるため、個別にご相談ください。お問い合わせからどうぞ。
