スタートアップでのM&A時のサービス引き継ぎ担当のエンジニアへのアドバイス

2023/06/05

, , ,
スタートアップでのM&A時のサービス引き継ぎ担当のエンジニアへのアドバイス

スタートアップの場合、サービスのみ買収するというケースがあります。

その場合、一番大変なのがサービス引き継ぎ担当のエンジニアとなります。

過去に1人で引き継ぐ経験をしたことがあるので、同様の事態に陥ったエンジニアの方に向けてその体験を踏まえた記事を書きたいと思います。

体験

経緯

ある日MTGで上司から伝えられたのが、toC向けアプリ引き継ぐのでエンジニアリング部分は全部任せた、ということでした。

詳しく訊いてみると、エンジニアは来ないのでサービスのみ引き継ぐということでした。 あとから考えると結構無茶な部分もありますが、他社サービス引き継ぎの経験がなかったので、そんなものかなと思っていました。

そしてその会社はすでに解散していたこともあり、とにかく時間が無く以下のような進め方でした。

  • 2日で各領域の担当者に直接ヒアリング

  • あとは最小限Slack上でやり取りする

なので1日あたり3領域ずつくらい訊いて概要を掴み、 後日それを踏まえて気になった部分を詳しく調査するというやり方を取りました。

引き継ぎ内容

では具体的に何を引き継ぐ必要があったかですが、大きく分けて以下の領域でした。

  • インフラ (GCP, Kubernetes)

  • バックエンド (Rails)

  • 業務管理ウェブアプリケーション (Nuxt)

  • アプリ (iOS, Android)

  • LP (HTML, WordPress)

  • 機械学習関連 (主にKeras, APIとしてはBottleで構築)

これ自体が資料として用意されているとは限らないので、この全容をドキュメント、リポジトリ、クラウド(このケースではGCP)を眺めて把握するのがまず最初の仕事となります。

ヒアリングではシステム構成の把握と、それぞれのサービスとアプリについて伺いました。

では次に、ヒアリング以外に引き継ぎとして何をしたかですが、日々の運用以外では

  1. サービス・アプリで使用しているSaaS・クラウドサービスの委譲手続き

  2. 配送先やアプリ、ウェブサイトの社名変更

1. サービス・アプリで使用しているSaaS・クラウドサービスの委譲手続き

1については、iOS、AndroidのアプリやGCPのプロジェクト、GitHubのリポジトリ、その他使用しているSaaSを弊社組織下に移す必要がありました。 ちょっとしたSaaSは支払い方法や登録情報を変えるだけで済むのですが、アプリやGCPなどは委譲元と委譲先両方での作業が必要なので、 なかなか大変です。

2. 配送先やアプリ、ウェブサイトの社名変更

2は多少プログラムを変更した上でデプロイしてリリースする必要があるので、最初の実作業という意味で大きな価値がありました。 ヒアリングしただけでは自分たちのサービスとなったという実感が持ちづらいので、これを経てようやくなんとかなりそうという感触が得られました。

その際の反省点

なんとかサービスがそのまま動作してかつ、その後機能開発が出来る状態で引き継ぎが完了出来たのですが、反省点は多くありました。

  1. アプリの配信周りは経験者でないと厳しい

  2. 全部の要素についてデプロイなどを試さなかった

1. アプリの配信周りは経験者でないと厳しい

1についてはアプリの配信自体がノウハウがいるものですし、AppleやGoogleの都合で対応すべきものが出てくるのでその情報をそもそも知っておく必要があるということもあります。 アプリ開発者にとっては当たり前のことだと思いますが、これは実装だけ担当した私には知識がなく対応しきれませんでした。 iOSについては開発パートナーさんに助けていただき、Androidについてはたまたま開発・リリース経験者が加わったので助けてもらいました。

2については、主要なものは試したのですが、例えばLP関連などは完全に後回しで放置していました。 最終的にはリポジトリやGCPなどを見て何とかなったのですが、Slackで質問できる時に行なえばスムーズでした。 何とかならない場合もあり得たと思います。

経験を踏まえたアドバイス

  1. プロダクションレベルのインフラの知識は必須

  2. 既存のドキュメントはどんな形式でも良いので検索がかけられる状態で保管する

  3. ID/パスワード等に漏れがないか徹底的に確認する

  4. 可能なら、デプロイや改修を引き継ぎ元の社員に見てもらう

  5. 調査内容や実行内容のログを残す

1. プロダクションレベルのインフラの知識は必須

1は、インフラ周りは日々の運用があるのとプロダクションレベルのキャッチアップが難しいという点を踏まえたものです。 アプリケーションに関する部分はバグが無い限りあとから勉強しても何とかなりますし、昨今はDockerのおかげでローカル環境が簡単に構築出来ます。 インフラ周りも勿論個人で試せますが、プロダクションレベルの構成にするのは手間とコストが掛かるのと、障害を経験して学ぶのが難しいです。もちろんインフラ専門エンジニアの方には全然敵いませんが、社内ツールや業務システムの構築経験があったので把握やその後の管理が出来ました。

2. 既存のドキュメントはどんな形式でも良いので検索がかけられる状態で保管する

2については、引き継ぎの限られた時間ではドキュメントの全てに目を通すことが出来ないのと、必要になってから見るのと事前に目を通すのでは見ていても理解度が全然変わってきます。ですので、検索して見られるようにしておくのは重要です。きちんとしたドキュメントがない会社でも、経緯や議事録などは存在する場合があるので、それとコード・PRを照らし合わせるだけでかなり理解の手助けになります。

3. ID/パスワード等に漏れがないか徹底的に確認する

3については当たり前のようで意外に盲点となります。よく使うサービスは大丈夫なのですが、実は使っていたというレベルのサービスの場合はID/パスワードの共有を引き継ぎ元が忘れる場合があります。また、再設定先のメールアドレスが使えなくなってしまう可能性もあるので、再設定が出来るからと安心出来ません。使用しているサービスの把握時に、サービスリストとID/パスワードリストを比較しておくと良いです。

4. 可能なら、デプロイや改修を引き継ぎ元の社員に見てもらう

4に関しては、最初はとにかく不安なので、見て頂けること自体がとても安心出来ます。 また、レビューしていただいたことで抜けている知識が得られますし、それをとっかかりに自分でも調べることも出来ます。

5. 調査内容や実行内容のログを残す

5については当たり前だと思われるかもしれませんが、チームが組まれて新機能やサービスの追加がなされるようになってから役立ちます。 質問をもらってもリンクを共有するだけで済むこともありますし、不足している点はチームメンバーが補足してくれます。 また、どうしても記憶から抜けていく部分があり、雑なメモでも記憶を掘り起こすのに有効だったというのもあります。

感想とまとめ

これからサービス引き継ぎを担当する方の参考に少しでもなれば幸いです。

最後に一言でアドバイスを書くとしたら、インフラ経験者とアプリ経験者は必須ですよ、ということです。