ゼロからはじめるシステム引き継ぎ

はじめに

エブリーで小売業界向き合いの開発を行っている @kosukeohmura です。

今年、エブリーでは ネットスーパーのシステムを株式会社ベクトルワン様から引き継ぎました。その裏で、私たちのチームでは知見のないシステムを、自分たちで運用・開発可能な状態にするように様々なことをやってきました。

ここでは every Tech Blog Advent Calendar 2023 の 7 日目の記事として、システムを別の会社から引き継いだ中で考えたこと・やってきたことを紹介したいと思います。今回引き継いだシステムは具体的には Web アプリケーションサーバー、スマホアプリ、複数のスマホアプリ向け API サーバー、及びそれに付随するシステム（非同期処理・バッチ処理基盤、ロードバランサーなど）です。

なお、私は引き継ぎ作業の前段階（デューデリジェンス、大枠のスケジュール策定、契約締結など）が済んで、さあ実際にシステムを引き継ぐぞというところでこのプロジェクトのオーナーとなったので、実際のシステムの引き継ぎ作業に絞ってお話します。

目指す状態と現状のギャップを考える

私はシステムを他社から引き継いだ経験がなく担当となった当初何をしていいかわかりませんでした。両社のソースコードは GitHub で管理されていたので、とりあえず自社の開発メンバーを 外部のコラボレーター として招待していただきました。その後ソースコードをざっと眺めましたが、今回引き継いだネットスーパーのシステムはそれなりに大きく、ソースコードを読み続けてシステムを理解するのは筋が悪そうだとわかりました。

そこで引き継ぎのプロジェクトを通してどうなりたいかを考えだしました。システムを引き継いだらそれは自社のシステムとなります。ということは自社のメンバーで運用を行っていくのはもちろん、障害が起こったら自分たちで復旧し、プロダクトの詳細な仕様やバグへの説明責任も基本的には自分たちが持つことになります。その役割が果たせる状態と現状とのギャップは何か、それを埋めていくには何をすべきかを考えていきました。

足りない情報を要求・整理

何もわからないという状態を紐解いていくと、当たり前ではあるのですが自社のプロダクトなら当然知っているような情報が欠如していることに気づきました。例えば次のようなものです。

• システムの実現するサービスとユースケース
• 全体的なシステムの構成、構成要素それぞれの関係
• システムと周辺システム、外部のシステムとの関係
• ネットワーク、DNS
• アクセス制御
  • 各種アカウント・認証情報
• アプリケーションコード
  • 責務の分割のされ方
  • アプリケーションコード・テストコード記述のルール・方針
• データベースの構造
• システムの監視方法、正常性の把握の方法、異常時の対処方法
• セキュアな情報の取り扱い方
• 各種運用フロー
  • QA
  • リリース
  • 手動の作業

etc...

これらをリスト化し、それぞれについて情報を要求・整理していきました。知りたい項目についてドキュメントが無いこともありますし、ドキュメントが存在しても断片的、あるいは前提知識を必要としたりします。不足する情報はドキュメントを用意してもらったり、断片的な情報は受け取った後に情報をまとめて包括的に構成します。

この時強く思ったことは、引き継ぎは引き継ぐ側と引き継がれる側が協力して行うプロジェクトであるということでした。引き継がれる側としてはただ情報を待っているのではなく、どんな情報がなぜ必要で、どのようなアウトプットを期待しているのかをなるべく明確に伝える必要があると感じ、一つ一つの項目ごとにどういう状態になれば引き継ぎが完了となるのかの合意を取っていきました。

コミュニケーションツール、ドキュメンテーションツールの重要性

前述の通り、引き継ぎは自社・他社含めた協力プロジェクトであり、その中では多くのやり取りや資料の作成が行われます。社内ならば既定のツールを使用すればいいですが、社外の方とのやり取りでは既定のツールというものがありません。しかしフロー情報とストック情報を記入できるツールの導入は非常に重要です。

私達は共用のコミュニケーションツールとして Slack や Zoom を、ドキュメンテーションツールとして Notion を、タスク管理に Google スプレッドシートを使用しました。いずれのツールも一方が他方の普段使いのツールに相乗りする形を取っています。この場合引き継ぎプロジェクトが終わればツールへの相乗りも終了するので、相乗りしている側は必要な情報をエクスポートすることになります。

契約上の引き継ぎ時点を迎えての作業

引き継ぎのプロジェクトは契約上の引き継ぎ時点より数ヶ月前から始めましたが、実際の移管作業については契約上の引き継ぎ時点の近辺で行います。例えば次のようなことです。

• Git リポジトリ移管
• クラウドベンダー、ドメインレジストラなど各種契約の移管
• 各種管理者の認証情報の受領

それぞれについて軽く触れます。

Git リポジトリの移管

GitHub の リポジトリの移譲 作業を行いました。ドキュメントに書いてあることではあるのですが、組織間のリポジトリの移譲には

• 移譲前のリポジトリに対する管理者権限(または移譲前の組織の管理者権限またはオーナー権限)
• 移譲先の組織のリポジトリを作成する権限

が必要でした。外部コラボレーターとして移譲前のリポジトリに招待してもらっている引き継ぎ元の開発者アカウントをリポジトリの管理者にしていただき、そのアカウントにて移譲作業を行いました。

リポジトリ移譲後は GitHub 引き継ぎ後にソースコードの内容を質問させていただくことを考え、逆に引き継ぎ元の開発メンバーを外部のコラボレーターとして招待させていただきました。

クラウドベンダー、ドメインレジストラなど各種契約の移管

システムの稼働や運営に必要な契約の付け替えを行います。契約しているサービスによって移管の方法は様々でした。ここでは AWS アカウントとドメインレジストラの移管の方法に触れます。

AWS

AWS Organizations のメンバーアカウントを他の組織へ移行する_ Part 1 _ Amazon Web Services ブログ の記事を参考に、メンバーアカウントの移管作業を行いました。

今回は両社ともに組織アカウントを使用しており、また移管対象のメンバーアカウントに移管対象外のシステムが含まれていなかったことから、単にメンバーアカウントを組織アカウントへ移行するのみで済みました。引き継ぎ対象外のリソースが存在するなどで AWS アカウントごとの移管が難しい場合には、前もって計画的にリソースを別の AWS アカウントに移すなどし、AWS アカウント移管を行える状態を作っておくことが必要です。またアカウントごとの移管が現実的ではない場合は、リソース単位で移管を行うことになると思います。

細かい話ですが、AWS アカウントの移行ではその時間を指定するようなことができず、移管作業を行ったタイミングで移管が行われるようです。出来ればとある日時以降の料金の請求がエブリーに対して行われるようにしたかったのですが、その方法は調べた限り無さそうでした。

ドメインレジストラ

引き継ぎ元ではお名前.com が利用されており、エブリーでは別のレジストラを主に使用していたのですが、今回は引き継ぐドメインが十数個と多く、引き継ぎ作業の楽さを優先してエブリーのお名前.com へとドメインを移管しました。お名前.com には お名前 ID 付け替え という機能があり、比較的楽にドメインを移管できました。今後必要となれば社内でお名前.com から普段使いのレジストラへの移管も検討しますが、優先度は低く置いています。

各種管理者の認証情報の受領

各種サーバーの root ユーザーの SSH 鍵や、データベースの root アカウントの認証情報の共有を頂きます。引き継ぎ元の開発者によるアクセスが必要なくなったら、認証情報を変更ができると良いでしょう。

引き継ぎの後にやったこと

ここまでで引き継ぎ作業としては終了ですが、引き継いだままの状態では社内の運用のフローとの齟齬が開発時の戸惑いに繋がったり、改めてプロダクトの状態を自社視点でみると最適化すべき部分が見つかります。そのそれぞれを自社の基準や文化に合わせて修正していくことはアジリティやサービス品質の維持・向上に繋がります。

なお、今回は引き継ぎを受けた後にも引き継ぎ元の開発者の方々に一定期間はサポートをいただけることになっています。契約上の引き継ぎ時点を過ぎ、必要な情報を頂いたつもりでも色々な情報が足りていないことに後から気づく場面が多くありましたので、契約等が許す限り一定期間サポートを受けられる体制をつくることが理想だと強く感じます。

次に具体的に引き継ぎを受けた後にやったことをいくつか紹介します。

クラウドサービスの料金の傾向・コスト構造の確認

AWS Web コンソール内の Cost Explorer にて料金の傾向を簡単に把握し、過剰なリソースがないかをざっとチェックしました。実際に、とあるマシンのインスタンスタイプが不自然に大きいことに気づきその変更を行いました。

これについては早くやるほどコストが節約できるので、AWS アカウントの移管が終わり、Cost Explorer が閲覧できるようになった初日に実施しました。結果として月々 6 万円以上のコスト削減に繋がりました。

手動運用の自動化

手動で行われていた運用について自動化出来そうなところがいくらかあったので、運用の背景を引き継ぎ元の開発者に伺いつつ、無理なく出来そうな部分については自動化をすすめています。

一見自動化できそうでも出来ない理由があったりするので、サポートいただけるうちに背景を聞きます。この作業では手動運用が削減できるだけではなく、システムについてより深く知る機会にもなりました。

監視機構の確認、追加

引き継ぎ前から行われているシステムの監視について整理し、社内の基準を鑑みて監視しておきたくなった点については新たに仕組みを導入しています。

合わせて既存の監視機構の通知先を変更し、自社の開発チームで異常に気付けるようにします。

こちらも不明点は引き継ぎ元の開発者に協力をいただき解消していきました。作業を通して、システムの全体への把握を強める機会にもなりました。

共同でのトラブル対応

移管後しばらくしてちょっとしたトラブルが起こりました。ソフトウェアエンジニアにとって、知らないシステムからの大量のアラートほど絶望するものは無いかもしれません。

ここでも引き継ぎ元の開発者にトラブルの概要を伺いながら原因を特定し、スムーズに対応することができました。もし自社のメンバーだけでの対応だったなら原因の特定や対処方針策定に相当な時間がかかっていたと思います。

余談ですが、このトラブルの原因となったバグは、システムの引き継ぎ前から潜んでいたものが偶然引き継ぎ直後に露見したというものでした。心臓に悪いので、もう少し空気を読んで露見するタイミングを選んでほしいものです。

おわりに

「ゼロからはじめるシステム引き継ぎ」と題して、何もわからないところからシステムを引き継いだプロジェクトについて紹介しました。こう書いてみて思ったこととして、今回は他社からシステムを引き継ぐ形でしたが、たとえ社内であっても異動があったり、新しくジョインされた方は何もわからないような状況に置かれる事に気づきました。システムのドキュメンテーションやクラウド料金・監視体制の見直しなんかは継続的に社内でも行っていけると良いなと思いました。

こういったプロジェクトに携わられる方はそう多くないとは思いつつ、どなたかの役に立つと幸いです。お読みいただきありがとうございました。