取り組んだこと
決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご提供するという性質上、突然のサービス終了は関係する方々のビジネスに直接的・間接的に大きく影響する可能性もあり、慎重にすすめる必要があります。
今回システム停止を計画するにあたり、下記の要件が存在しました。
- お客さま・加盟店様・その他パートナー様への影響を出来る限り小さくするために、十分な事前告知と準備期間を経てサービス終了を行うこと。
- 障害・不正利用等のシステムリスクを出来るだけ小さくすること。
- サービス終了までのシステム維持コストを出来るだけ小さくすること。
当初から少なくとも半年以上はかかるプロジェクトとなることが見込まれていたため、複数フェーズに分けて段階的に機能を停止していく基本方針を置きました。 対外アナウンスや機能停止は一度行ってしまうと後戻りできないため、下記のように事前計画を入念に行いました。以下ではそれぞれの項目について紹介していきます（便宜上ステップのように順番に記載していますが、実際は途中段階で新しい事実が発覚して前段階に巻き戻ったりといったことを繰り返しながら計画を作っていきました）。
- 外部へ影響を与える機能・業務の特定
- 法務・コンプライアンス要件の特定
- サービス終了計画の作成
- システム停止計画の作成
- 計画に沿ったシステム停止と影響確認
1. 外部へ影響を与える機能・業務の特定
サービスを段階的に停止していくにあたり、外部への影響度・内包されるシステムリスク・維持コストなどの観点から機能や業務を分解していきます。
今回Origami Payサービス終了を計画するにあたり洗い出した機能・業務の一例は以下のようなものです。
- バーコード提示型のインタフェースによるお支払い
- QRコード読み込み型のインタフェースによるお支払い
- クレジットカードを利用したお支払い
- 金融機関口座連携を利用したお支払い
- ウォレット機能を利用したお支払い
- 加盟店様による返金・金額変更
- 加盟店様によるお支払い履歴確認
- 加盟店様への売上金振込
- 一般のお客さまからのお問い合わせ対応
- 加盟店様からのお問い合わせ対応
機能・業務をどこまで細かく分解するかは、「停止タイミングが異なるか」を軸として行いました。例えばOrigami Payではクレジットカードを使ったお支払い方法と、金融機関口座を紐付けたお支払い方法が提供されていましたが、両者では不正利用リスクが異なるために「加盟店でのお支払い」と一括りにするのではなく個別に停止スケジュールを検討することとしました。
2. 法務・コンプライアンス要件の特定
サービスの特性によっては法務・コンプライアンス観点からサービス終了の進め方に要件が存在する可能性があります。
Origami社では資金移動業・第三者型前払式支払手段発行者・電子決済等代行業・クレジットカード番号等取扱契約締結事業者といった各種業法への登録や、PCI-DSSへの準拠を行っていました。 各事業廃止にあたり、リスク管理体制の維持や消費者保護の観点等から法務・コンプライアンスチームと連携して1で特定した機能・業務に抜け漏れがないか、またそれぞれを停止するにあたり注意を要する点がないか密に連携しながら要件を洗い出しました。 例えば資金移動業を廃業するにあたってはお預かりしている残高をお客さまに確実にお返しするために、メール連絡・ウェブサイト告知や官報掲載などのコミュニケーション計画が求められます。
3. サービス終了計画の作成
1で特定した機能・業務それぞれについて停止日・事前告知日等を定めていきます。
法務・コンプライアンス要件を満たすことは当然ですが、外部ステークホルダーの皆様との調整観点で営業・事業開発チームと、社内業務との調整観点でオペレーションチームやコーポレートチームと協力しながら計画していった結果、下図のような9ヶ月にわたるスケジュールが出来上がりました。
細かく全スケジュールに触れていくことは難しいので、システム停止に影響が大きいマイルストーンだけ下記にまとめます。
2020/2 ウォレット機能によるお客さま間送金の停止
2020/3 ウォレット機能によるお支払い停止
2020/4 クレジットカードによるお支払い停止・バーコード提示型のお支払い停止
2020/6 一般のお客さま向けサービスの停止・お客さま向けアプリの配信停止
2020/9 加盟店様向けサービスの停止・加盟店様向けアプリの配信停止
支払い手段ごとに細かく停止時期が異なっていますが、前記のようにシステムリスクや不正利用リスクを早期に小さくしていくことと、外部影響を鑑みて早期に機能を閉じられるかといった現実性をあわせて検討した結果、このように支払手段ごとに段階的な停止を行うこととしました。また、一般のお客さまによる利用が終わった後も返品等による返金・金額変更等が発生する可能性を考慮し、新規のお支払い停止から90日間のバッファ期間を経て加盟店様向けサービスの停止を行うこととしました。
機能の停止とその告知以外にも考慮すべきことはこのタイミングで洗い出します、一例として、広くサービス終了告知を行う際にはそれに便乗したフィッシング詐欺等が発生するリスクもあり、その対策として不正ログイン・不正取引の自動検知・監視体制強化も計画していきました。
4. システム停止計画の作成
サービス停止計画から各フェーズで停止できるサブシステムを特定し、システム停止作業のスケジュール・内容を計画します。
Origami PayはAWS上に構築されたバックエンドシステムとiOS, Android向けに提供されているお客さま向け・加盟店様向けモバイルアプリで構成されていました。バックエンドシステムはウェブアプリケーションの改修でリアルタイムに機能停止を行えますが、モバイルアプリは新しいバージョンをアプリストアに登録しても大多数のお客さまが最新バージョンにアップデートいただくまでにタイムラグがあります。今回はバックエンド側のフラグに合わせて各停止フェーズ向けの画面・挙動に切り替えられる仕掛けを内包したバージョンを事前にアプリストア上で配布し始めておくことで、実際の機能停止タイミングで表示をスムーズに変更する下準備を行いました。
AWS上に存在する内製システムを停止していくことに加えて、システムと接続されている外部サービスや、業務で利用しているクラウドサービスについて利用停止・契約解除タイミングも計画します。 各フェーズで停止する機能から不要となる関連サービスを特定していくのですが、それに加えて最終的にはすべての外部サービス利用が漏れなく終了している必要があります。年次の外部サービス棚卸しが終わった直後だったこともあり、外部サービス台帳を出発点として、各サービスの停止計画を作りました（参考までに下図がOrigamiで作成していた台帳のサンプルになります）。
内部システムと外部サービスの停止計画が決まったら、それをもとにサービス終了までのシステムコストの大まかな見積もりを行います。 AWS環境については構成変更によるコスト推移を完全に予想することが難しいのですが、Billing and Cost Managementを使うことで過去の請求実績の細かい内訳（サービス別・サイズ別・リージョン別など）が分析できるため、そこから各フェーズにおけるシステム停止後のコストを見積もりました。
5. 計画に沿ったシステム停止と影響確認
4のスケジュールにそって機能停止を行います。完全なサービス停止以前では一部機能のみを停止することになるため、予期せぬ影響がでた場合に備えて作業手順を細分化し、切り戻し手順を用意して実施します。数人でダブルチェックを行いながら作業をすすめる必要がありましたが、結果的に関係者が自発的に多く集まったこともあり盤石な体制で多くの作業を進められました。
停止作業・インフラ整理を行った後は数日間AWSコストの監視を行います。システム停止計画で事前に想定していた水準まで日次コストが下がっているかを確認し、想定したコスト減が達成されていない場合は要因を調査・解消します。 Cost Explorerを用いると日次コストのサービス内訳が確認できるので原因分析をしやすくなります。ECS・EC2・RDSなどのComputing / Database系コストは予測しやすいですが、Networking / Governance系等はコスト予想が難しく、目標コストを達成するためにフェーズごとの追加調整なども行いました。
下図が実際にサービスを運用していたAWSアカウントのコスト推移です。全機能の提供を終了したのは9月、そのインフラ整理を行ったのが10月なので11月にコストが大きく下がっていますが、その途中経過でもほぼ事前計画どおりの水準までコストを削減できました。事前にコスト計画を定めて進めたことで金銭的なコストを抑えられたことも勿論ですが、管理すべきリソースが減り、結果的にシステムリスク低減・人的な運用負荷の軽減にもつながりました。
6. (おまけ) Twitterをエゴサしてエモい気持ちになる
まったく余談ですが、事前告知でお支払い機能が停止される日時までお伝えしていたこともあり、停止前後はTwitter検索すると感想や思い出を投稿してくださった方もいらっしゃいました。中には、サービスが止まる直前を狙って記念決済をしてくださっているツイートなどもあり気持ちが温まるタイムラインを眺めながらシステム停止を行っていたりしました。
さいごに
これだけ慎重に時間をかけてサービスを終了していくという経験は初めてだった為、計画段階も実施段階も途中過程でいろいろな学びがありました。しかしそれでも運営してきたサービスを終了するというのは決して楽しい話ではなく、最後まで一緒にがんばってくれた関係者の方々には感謝してもしきれません。 サービス終了なんて頻繁に立ち会うことではないかもしれませんが、本投稿が将来そんなタイミングを担当される方の参考になれば幸いです。
私自身も含め、今回サービス終了を一緒に進めてくれたメンバーも参画してメルペイでは日々サービス開発を進めています。ミッション・バリューに共感できるエンジニアリングマネージャー・エンジニアを募集していますので、一緒に働ける仲間をお待ちしております。
【参考】