サービスクローズ、それはプロダクト開発に携わる者には決して無視できない可能性の一つ。
ですが、その内容が語られることはあまり多くないと感じています。
私はこの3年で2つのサービスクローズに関わりました。
一つは完全なサービスクローズ。
もう一つは自社でのサービス提供は終了で、新しい会社で新サービスとして生まれ変わる引き継ぎを行ったケース。
この記事では、その時にあったことと、そこから得た学びをまとめることで、サービスクローズに直面することになるかもしれない貴方の負担や悲しみが少しでも減らせる一助に出来ればと思っています。
1. サービスが終わると伝えられるとき
1つ目のサービス終了は、渋谷のstreamにあるレストランで伝えられました。
関わっているすべての職種を含めて6人の小さなサービス。
業務時間中に週5で稼働していた4人が「ちょっと外出られる？」と急遽集められて、プロダクトオーナーから終了を伝えられました。
2つ目のサービス終了はプロダクトオーナーとの1on1の中で。
自社でのサービスは終了だけれど、なんとかしてサービスを残したいと思っている旨も伝えていただきました。
サービスクローズに直面するという経験。
多く経験するものではありません。
当然これらを受け止めることは困難なことです。
まなび
悲しみと辛さがくるタイミングは人それぞれ異なっていることを認めよう
クローズの話があったのち、「クローズを伝えたときに泣いた人もいる」という話を聞きました。
自分は二回ともその場は冷静に受け止めていたのですが、後々じわじわと悲しみが押し寄せてきました。
最初に「悲しい・辛い」と伝えられた人は、その後もそれを吐露しやすくなりますが、人によってそれが溢れてくるタイミングは異なるものです。
クローズが決まると、期限内にやるべきことも沢山生まれ、チームの余裕や明るさも当然のように失われがちになります。それによってチームの空気は重くなり、益々自身で悲しみと辛さを背負ってしまうことになります。
「最初に泣かなかったから自分には泣く資格がない」なんてことはないです。
サービスクローズというハードシングスに向き合うために、悲しみや辛さが出来てたときにチームメンバーと分かち合いましょう。
それらの感情をチームに共有することは、どの局面においてもネガティブなものではありません。愛です。
2. サービスが終わると伝えられたあと
サービスが終わると伝えられたあとは、クローズに向けた動きが始まります。
しかし、貴方がクローズを知るのと、同僚がクローズを知るのは同じタイミングではない可能性があります。
それは、どんな理由でのクローズにせよ、会社全体に不安が広がらないようにクローズの公開には丁寧なコミュニケーションが必要になるからです。
一方、サービスに関わる人には、その丁寧なプロセスをも超越して早く伝えることが重要な場合があります。
結果、貴方と同僚は違うタイミングでそれを知ることになります。それは同僚だけではなく、社外の親友や家族なども同じかもしれません。
「自分が今一番不安に思っていること」を話したい人に話せない。
「自分が今やっていること」を社内の人に話せない。
これはとても苦しいことの一つです。
まなび
苦しみを誇りに思おう
どうしてもそれを隠すことが苦しい場合は、勿論チームに相談をして隠さずにいられるように努めることが良いと思います。
ただ、今振り返ると、他の人よりも先に自分が知れているという状況は、幸福な事だと捉えることも出来ます。
それだけの権利と、その権利を掴むまでの責務を担ってきたからこそ、貴方は早くそれを知れています。
知るタイミングに差があるのは、誰かを苦しめるためではなく、会社全体を守るためです。
知っている者同士で協力をして、今出来ることを着実にこなしましょう。
3. クローズへと動き出すとき
サービスクローズがチーム全体や、全社に伝わり、実際にクローズに向けた動きが始まる頃。
目の前の仕事だけでなく、他の人のその先を見据えた動きが目につくこともあります。
- 今のサービスをなんとか違う形で続けてコミットし続けようと思っている人
- サービス終了後は自社の違うサービスで働こうと思っている人
- 転職を考える人
色んなパターンの動きや話が出てくることがあります。
それに際して「貴方はどうするの？」とふらっと聞かれることもあります。
目の前のクローズ対応でアップアップなのに、その先のことを聞かれても…と困惑するかもしれません。
また、本当は違う選択を取りたいのに、目の前のチームメンバーへの配慮で意図しない同意や共感を行ってしまうかもしれません。
まなび
自分の想いを大切にすればよい
二つのサービス終了を通して、プロダクトオーナーは「貴方が選びたいことを選ぶのが一番だよ」と終始言い続けてくれました。
この観点は今振り返ってみても凄く大切な考え方でした。
決まっていないことには、決まっていないと正直に伝え、
「〇〇の場合はこういう想定で、xxの場合はこうです。あくまで現状ですが…」と、曖昧や不確かな考えでもよいのでありのままを伝えるようにしましょう。
サービス終了に向き合うというのは、誰かの人生の岐路に向き合うということです。
「僕も一緒に転職します！」「独立してこのサービスを続けましょう！」などと、無理してチームやメンバーに寄り添う言葉をかけるのは、その人の人生を大きく左右することに繋がるかもしれません。
今思っていることをありのまま伝えるのが一番誠実だと考えています。
また、それが現在のチームにとって不都合な意見だとしても、貴方の意見を尊重して調整してくれる人は社内に絶対にいるはずです。
自分の想いを大切にしましょう。
4. サービスクローズ業務
実際のクローズ業務に関しても見てみます。
サービスクローズが決まっても、「では明日クローズです！」とはならなく、「新規開発をせずに人手は減らしつつ運用は一定期間続ける」のような選択を取ることが多いと思います。
その運用期間におけるクローズ業務としては下記のようなものがあります。
- 運用効率化
- エンジニアの手離れや人員を削減するための施策
- 管理画面やBIツールで見れる内容の拡充
- エンジニアが手動で行っていた業務の自動化
- 運用ミスによるデータ修正が発生しがちな項目の補助機能開発
- 通知周りの最適化
- 運用期間中にEOLが来るもののアップデート対応
- ドキュメント作成
- エンジニアの手離れや人員を削減するための施策
- クローズ対応
- クローズに関する案内
- 機能制限
- 返金処理
- アカウント関連
- ダウングレード
- テスト環境のアカウント削除
日々縮小化していくメンバーや予算に対して、上記のようにやるべきことは沢山あります。
その中でやりきるために大切だと感じたことをまとめます。
まなび
1. 優先度設計をチーム全体でしっかりする
やるべきことは多いですが、時間もリソースも限られています。
限られた時間でやるべきことを達成できるようにサービス終了までの項目の洗い出しと優先度設計を開発チームだけでなく、biz側も含めて全体で行うことが重要です。
- 私のチームの場合は下記の項目に分けて洗い出しを行っていました
- 開発が手動対応している箇所
- 運用上のコストが大きい箇所
- 事故につながる懸念がある箇所
- 運用が一定続くことでグロース的な負債が生まれる箇所
項目ごとに、優先度を設定し、捨てるものは捨て、着実に作業を進める。
サービス終了時こそが、開発とbizが一番ロードマップに沿った対応が出来ると思うほどに、やるべきことの合意を徹底して進められる期間でした。
2. やる場合のスコープとやらない場合の対応方針を決める
1で洗い出した課題や新規開発は、必ずしも完全な形で機能になる必要がない可能性もあります。
サービス終了に際してのコスト削減が目的である場合は、「やる場合のスコープ」と、「やらない場合の対応方針のすりあわせ」も重要になってきます。
- やる場合のスコープ
たとえば、長期で使うのではなく数ヶ月使うだけなら「デザインを捨てる」「拡張性を捨てる」など、普段の機能追加では必要だとされていたものが不要になる可能性もあります。
そのため、その実装をやると決めた一番の課題が解決できるだけのMVPを意識して実装を行う態度が必要になります。
- やらない場合の対応方針のすりあわせ
「エンジニアが手離れ出来るように管理画面でデータを見れるように」のようなタスクでは、開発をせずに「Redashでデータを見れるようにする」なども選択になります。
やる場合はMVPと言いましたが、代替手段があれば機能開発自体をやらないという選択も勿論あります。
5. クローズ前にサービスから離れるとき
前項ではクローズに向けた実際の業務に関して見ましたが、それらの業務を最後まで行うのが自分ではない場合もあります。
そういったときに、今振り返って大切だと感じることを二つ共有させてください。
まなび
残されたチームメンバーへのコミュニケーションをしっかりと取る
クローズ業務を自分が担当しないということは、自分は新しい環境で挑戦を行っている最中かと思います。
そのため、自分自身もいっぱいいっぱいで、クローズを行っている残されたメンバーのことを意識するのは難しいかも知れません。
しかし、新しいチャレンジではなく、クローズするサービスの業務をやるのははっきり言って孤独で辛いです。
クローズ担当は貴方が関わったサービスのそんな辛い業務を行うために動いてくれている仲間です。
貴方が話を聞くだけでも負担は減りますし、またクローズに関する話を聞けることは、サービスクローズに関わった人のみ得られるかけがえのない知見でもあります。
積極的にコミュニケーションを取ることで、直接関わらない上でも出来る心理的なサポートをしましょう。
サービス終了後にも「わかる」という状態にしておく
サービスが終了すると、その後はすべての仕様を忘れても問題ないと思うかもしれません。
しかし、監査や統制、顧客対応などでクローズしたサービスの調査や仕様把握が必要になるケースもありえなくはありません。
また、インフラや有料ツールのアカウントが残ったままになっていてコストが掛かり続けているなども起こりえます。
こういったことはクローズ業務に関わる人が責務を持つ部分ですが、漏れは必ず発生するものです。
漏れたままクローズになり、クローズ対応した人が退職するなどした場合、残った貴方が将来対応を行う必要があるかもしれません。
そのため、下記のような情報はチームメンバー以外のメンバーが見てもわかるような状態にしておくと良いと考えています。
- インフラ構成
- 自身がインフラ担当でなかった場合などに把握漏れがおきやすい箇所
- アカウント関連
- ステージングのものなど、環境差分で見過ごされることも多いので環境ごとに確認しておく
- 決済周り
- 問題が発生した際は徹底的に調査が必要なケースが多いので、将来見たときの振り返りチェックポイントをまとめておく
6. サービス引き継ぎ業務
自社ではクローズになるが、他の形でサービスが残る場合の新チームへの引き継ぎ業務に関しても触れておきます。
まなび
引き継ぎは「機能をすべて明らかにすること」ではなく「引き継ぎ先のみで走れること」を目的にする
サービスジョイン時に完全な仕様書がないように、引き継ぎに関してもそれを作るのは現実的ではありません。
そのため、引き継ぐというよりも、並走で業務を行い、引き継ぎ先のみで走れるようになることを目的にしたほうが良いです。
たとえば、機能開発や運用も新チームを主軸に動くべきだと考えています。
- 機能開発
- 自身で実装できる機能も新チームになるべく作ってもらう
- 仕様設計やレビューを通してサポートを行う
- 自身で実装できる機能も新チームになるべく作ってもらう
- 障害対応や運営からの問い合わせ対応
- 自身はccにして、新チームにメンションを飛ばしてもらう
- こちらも対応は新チーム、旧チームはフォローの観点
- 実際にやってもらわないと不明点や引き継ぎ課題は洗い出せないという前提を持つ
- 自身はccにして、新チームにメンションを飛ばしてもらう
コミュニケーションコストは新チームではなく旧チームが払う
「今後サービスを担っていく新しいチーム」があると、どうしても舵取りは新しいチームに行ってもらうほうが良いと考えがちです。
しかし、新しいチームは仕様把握や新サービスの方針づくりで手がいっぱいになり、コミュニケーションにかける労力を裂くのは難しいです。
こういったときに、「新チームから問い合わせがあったら動こう」という待ちの姿勢は絶対にうまくいきません。
そもそも、新チームにとってみると、「何がわからないのか分からない」という状態なので、質問や課題が見つかるまで時間がかかりますし、密なコミュニケーションが生まれるまでの期間が空けば空くほど、コミュニケーションハードルが高くなってしまいます。
新しい会社への引き継ぎ業務だとしても自社に新規で入社したエンジニアと同じように先輩チームとして手厚いオンボーディングやコミュニケーションコストをかけるべきだと感じました。
それが結果として良い引き継ぎに繋がり、引き継ぎ期間の短縮や、将来的なコミュニケーションコスト削減に繋がると考えています。
誰がボールを持つかをしっかりと＆都度都度整理すること
自社から新会社への引き継ぎ業務を行う際、チームメンバーが変わり続けます。
引き継ぎが進むに連れ自社のメンバーが減ったり、引き継ぎ先企業のメンバーが増えることがあります。
また、正社員で関わっていたメンバーが転職をし、業務委託で関わるなど役割が変わることもあります。
そういったメンバー自体の増減や役割が変わるとしても、その人が担っていたタスクが無くなるとは限りません。
そんなときに、「じゃあ誰がやるの？」という問いはしっかりチームで共通認識を持っておくべきです。
会社によってエンジニアやPMの担う領域も変わってくるため、場合によってはエンジニアでもPMやPdM的な動きが必要になることもありますし、CS対応が必要になる場合もあります。
これらは最初に触れたように「変わり続ける」ため、引き継ぎが始まったタイミングでの整理だけでなく、変化があるたびに整理を行っていきましょう。
引き継ぎタスクの見える化をする
引き継ぎを行う際、完全に引き継ぎ業務だけに集中出来ることは多くなく、実際には新しいサービスでの業務と、引き継ぎ業務が同時に走ることになると思います。
加えて、引き継ぎ会社とのやりとりは、slackなどのコミュニケーションラインが自社とは独立しているケースもあり、引き継ぎ業務を行っている人以外から見えにくくなってしまいます。
また、引き継ぎ業務の優先順位などは、貴方が関わっている新しいサービスのチームでは認識が出来ていない場合が多いです。
そのため、引き継ぎ業務の内容や優先度を明示化できるのは引き継ぎチームや自分だけになります。
「自分の引き継ぎタスクが現在の新チームメンバーから見えない」というのは「進捗全然出てないじゃん」と思われてしまいがちで想像以上に辛いことです。
こういったことを防ぐためにも、積極的に自身の引き継ぎタスクを現在のチームにも開示していきましょう。
7. サービスクローズ業務、自社以外の会社への引き継ぎ業務を通して
サービス終了や他社への引き継ぎに関して見てきましたが、共通して持っておくと良い考え方も共有させてください。
まなび
取り組む態度を変えずに、徹底する
サービス終了や、自社サービスからの引き継ぎとなると、どうしても「終わったことへの対応」というイメージを持つかも知れません。
リリースチャンネルで取り上げられることもなく、プロダクト定例で触れられることもない業務の場合も多いです。
しかし、サービス終了や他社への引き継ぎを行うというのは明確な自社の意思決定です。
それを問題なく完遂することこそが、インフラや運用コスト削減に繋がる自社の利益であり、またブランドイメージを保つための重要な施策でもあります。
だから、何百万人、何千万人、何億人に使ってもらうための機能開発と同じ態度でやり遂げてください。
それをやりきることが、プロダクト開発者の誇りと自信に繋がると信じています。
チームを離れたメンバーへ定期的に連絡をする
先程「残されたチームメンバーへのコミュニケーションをしっかりと取る」と書きましたが、この反対もそうです。それは退職したメンバーへの連絡も含めてです。
サービス終了に際してそれが完全に終わる前にチームを離れるというのは、どのタイミングであれチームメンバーにとっては心残りになるものです。
だからこそ、その重要な経験を離れたメンバーに伝えることは、自身にとっての記録、相手にとっての糧になるはずです。
また、サービス終了は、新しいサービスへの出会いでもあります。それを最大限感受してもらえるように、終了したサービスの報告を行い、しっかりと昇華させましょう。
最後に
「3年間で2つのサービスクローズと向き合って」というタイトルで記事を書いてみました。
サービスクローズに向き合うことは困難なことだと思っていますが、だからこそ得られる学びも多くあります。
今でもクローズしたサービスの話をふとしたときに「あれっていいサービスだったよね」と言ってくれる人がいます。
それって凄く誇らしいことだと思いますし、しっかりとサービスをクローズ出来たからこそ言って貰える言葉でもあると考えています。
サービスクローズ、次にいつそれと向き合う日が来るのかはわからないですし、それを避けられるように日々頑張っています。
でも、いつかその日が来るとしたら、この２つのクローズで得た知見と経験をもとに、「いいサービスだったよね」と言ってもらえる、そんなクローズ対応をしていきたいです。
ここまで読んでいただきありがとうございました。
あなたの向き合うことになるクローズ対応の負担が、
あなたのチームメンバーが向き合っているクローズ対応に対する理解が、
少しでも良い方向に繋がることを祈って。
Happy Hacking!!!
この記事は2022年CAMPFIRE Advent Calendarの20日目の記事です。
昨日の記事である Webでうごくレトロなパズルゲームをつくる など素敵な記事がたくさんあるので、ぜひ他の記事も覗いていってくださいね！