エンジニア目線での、CASH事業譲受時の振り返り

テクノロジー開発部の村上です。
下記リリースのように、弊社は4月にCASHを事業譲受しました。

その際、私はエンジニアリング部分の引き継ぎをほぼ一人で担当しました。半年経過というタイミングもあり、今回の記事ではそのときのことを振り返りたいと思います。

経緯

ある日MTGで上司から伝えられたのが、CASHというサービスを全部引き継ぐのでエンジニアリング部分は全部任せた、ということでした。
詳しく訊いてみると、エンジニアは来ないのでサービスのみ引き継ぐということでした。あとから考えると結構無茶な部分もありますが、他社サービス引き継ぎの経験がなかったので、そんなものかなと思っていました。
そしてすでに株式会社バンクは解散していたこともあり、とにかく時間が無く以下のような進め方でした。

2日で各領域の担当者に直接ヒアリング
あとは最小限Slack上でやり取りする

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

引き継ぎ内容

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

インフラ (GCP, Kubernetes)
バックエンド (Rails)
業務管理ウェブアプリケーション (Nuxt)
アプリ (iOS, Android)
LP (HTML, Wordpress)
機械学習関連 (主にKeras, APIとしてはBottleで構築)

そもそもCASHの構成は以下のようになっています。

f:id:nmu0:20201015024357j:plain — CASHアーキテクチャ

基本的にサービスはGKE上で動いています。ただしサービス間の通信はあまりなく、CASH APIサーバーからデータ解析APIを叩く程度です。プッシュ通知の配信や、有効期限の適用などのためにバッチジョブ・Cronジョブがいくつかあるので、それはSidekiqで実行しています。また、アプリのためのMaaSとしては、Firebaseを使用しています。ですのでヒアリングではそもそもこの構成の把握と、それぞれのサービスとアプリについて伺ったということになります。

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

SaaS等の委譲手続き
配送先やアプリ、ウェブサイトの社名変更

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

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

幸運だった点

上司もそもそもこれを見込んで指名したと思いますが、私・弊社のバックグラウンドとして以下の点が幸運でした。

GCP、Kubernetesは自社サービスで構築経験あり
弊社のメインWebフレームワークがRails
弊社の業務用アプリがiOSで、しかもRxを使用して実装されている
弊社のメインフロントエンドフレームワークがVue.js
機械学習・DNNの基本知識やライブラリ使用経験があり、Kerasも簡単に触ったことがある

弊社には2つの自社用業務アプリケーションがあり、最初にリリースされたものはBE、FE、iOSアプリの全てで実装を経験し、 2つ目はアーキテクチャの構築から担当しました。ですので上で触れた要素については社内で使われているだけではなく全て実装経験がありました。これはかなり幸運で、たとえばCASHのアプリではRxを使っているのですが、これは前提知識がないとかなり厳しいと思います。また、機械学習系も前職で自然言語処理のサブプロジェクトに参加し、弊社でも画像解析の導入に取り組み中だったので特に問題有りませんでした。これも全く知識がないと難しいかなと思います。ただし、AndroidだけはJavaで前職の新卒研修で軽く学習しただけなので、前日に一冊本を流し読みしてから臨みました。

反省点

色々と幸運だったのですが勿論反省点はあります。

アプリの配信周りは経験者でないと厳しい
全部の要素についてデプロイなどを試さなかった

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

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

上手く作用した点

GCPやKubernetesなど、CASHで使っているインフラの知識がほぼ全てあった
過去のドキュメントを移行していた
簡単な改修のPRをバンクのエンジニアの方に見ていただいた
ID/パスワード等漏れがないか何度も確認して引き継いだ
Confluenceにとにかく調査内容や実行内容のログを残した

1は、インフラ周りは日々の運用があるのとプロダクションレベルのキャッチアップが難しいという点を踏まえたものです。アプリケーションに関する部分はバグが無い限りあとから勉強しても何とかなりますし、昨今はDockerのおかげでローカル環境が簡単に構築出来ます。インフラ周りも勿論個人で試せますが、やはりプロダクションレベルの構築経験はまた違うと、ここ1年ほどで学習と経験を得たものとしては思います。特にKubernetesは、ECSやApp Engine、FaaSなどがあるなか個人で使う動機はあまりないと思うので、経験があって良かったです。実際何かしらちょっとした問題が発生するときは、Kubernetes関連が多いです。

2については、2日だけというのもありますが、仮に日数が多くても全てを把握するのは不可能です。ドキュメントをもらっていたことで、キーワードで後日検索してヒントを得ることは多々ありました。

3と4に関してはバンクのエンジニアの方にとにかく感謝です。最初はとにかく不安なので、見て頂けること自体がとても安心出来ました。また、レビューしていただいたことで抜けている知識が得られますし、それをとっかかりに自分でも調べることが出来ました。 ID/パスワードに関しても、いざとなったら再発行や再設定が出来るとはいえ、緊急の場合はそれでは遅いのでとても助かりました。

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

感想とまとめ

半年前を思い出しながら振り返りを書いてみました。これからサービス引き継ぎを担当する方の参考に少しでもなれば幸いです。
喉元過ぎればというのも大きいですが、１人で担当していると全部把握出来るので何か起きても対応はしやすかったですし、非常に良い経験となりました。また、これまで学んだ知識が役立っている感覚がとてもありました。
そして最後にアドバイスを書くとしたら、インフラ経験者とアプリ経験者は必須ですよ、ということです。