いま開発しているそのサービス、問題無く閉じられますか
サービスを終了する方針が決まった。
ところが、本当に大変なのはそこからです。課金、認証、Webhook、定期ジョブ、ユーザーデータ、DNS、監視、APIキーの棚卸しが始まります。
止める日を決めても、すぐに安全に止められるとは限りません。
サーバーをシャットダウンして終わりではなく、新規登録、課金、書き込み、通知、データ削除、外部連携を順番に片付ける必要があります。
便利なSaaSを一つ追加する。Webhookを一つ増やす。バックアップを一つ作る。そのたびに、将来の「閉じる作業」も一つずつ増えることになります。
終了作業ではなく、設計の品質として見る
AWSのガイドは、依存関係の把握、関係者への通知、制御された停止、データや設定の保存、運用ツール・DB・ストレージ・バックアップの切り離しまでを挙げています。
これは大規模なクラウド移行だけの話ではありません。
例えばStripeのサブスクリプションは、即時解約と期末解約で動きが違います。
最終請求や日割り、未処理の請求項目、キャンセルを知らせるWebhookもあります。「課金を止める」という一言では、何を止めたことになるのか決まりません。
だから、サービスの終了を設計することは運用手順より前に考えられるべきことかもしれません。
新しい責任がどこから増えるか分かる
読み取り専用でも残す処理が分かる
最後に何をもって「終わった」とできるのか
この三つが答えられないなら、いま閉じる予定がなくても、依存関係の一部はすでに見えなくなっています。
AWS Well-Architectedも、使われているかの確認、関連するライセンスやストレージ、Ownerへの完了通知を含む標準的な廃止プロセスを推奨しています。閉じる直前に探すのではなく、設計段階や運用開始してからも常に持っておく方がよい情報です。
閉じることを設計段階で考慮したプロダクトは品質、信頼性は向上するはずです。
まず「止める順番」ではなく「残す責任」を書く
台帳は、一枚あれば十分です。最初から細かな手順書にはしません。次の四つを埋めます。
1. 依存する仕組みに紐づく責務
ボタンを消すだけでは止まりません。流入元(LPとか)、API、外部サービスの三か所で、新しい責任が増えないことを確認します。
2. 終了日まで残す責任
画面は読むだけなのに裏で書き込みや外部API呼び出しが走るサービスは、読み取り専用へ切り替えにくい。
「Read」と「Write」を分けられているかを見る材料になります。
3. 元に戻せない操作
保持すべきデータや期間は、サービスの契約、社内基準、法令で変わります。プロダクトオーナー、必要ならリーガルと確認します。
4. 終了したことの証拠
CIが成功したことと、外からサービスが止まって見えることは別です。ブラウザ、API、決済、外部ジョブを、それぞれの境界から確かめます。
恒久的に使えなくなったURLには、状況に応じて `410 Gone` を使えます。RFC 9110では、対象リソースが利用不能で、その状態が恒久的と見込まれる場合の応答です。ただし、すべてのURLを410にする必要があるわけではありません。案内を残すページ、移転先、APIの利用者を見て決めます。
シミュレーションをする
実際に本番を止める必要はありません。CTOまたはEM、プロダクトオーナー、データまたは課金の管理者でやることをレビューします。
責任を生む入口を列挙する
終了日まで残す操作を一つ選ぶ
その操作に必要な依存だけをたどる
不可逆操作と承認者を置く
証拠を取れない項目にオーナーと期限をつける
細かな手順を書く会議ではありません。
「誰も答えられない場所」を見つけるのが目的です。
判定は三段階で足ります。
閉じられる：残す処理、不可逆操作、完了証拠、残存コスト、外部データの扱いが埋まる
整理してから：依存は見えるが、認証・課金・データの境界が混ざっている
まだ閉じられない：Owner不明、請求やデータ保持を確認できない、完了証拠が取れない
細かいところまで洗い出す必要はありません。
具体的な停止コマンドやベンダー別手順まで中央で標準化すると、更新されない巨大な文書になります。
サービスを閉じる予定がなくても、この台帳は役に立ちます。
オーナーが分からないなど、いまの運用でも事故やコストにつながる問題だからです。
次のアーキテクチャレビューやスプリントプランニングで、「このサービスを来月閉じるなら」をチームでぎろんしてみると、普段は見えない依存が可視化されるはずあり、プロダクトの保守性、品質向上にもきっと寄与するはずです。
