はじめに
こんにちは。DELISH KITCHEN 開発部 RHRA グループ所属の池です。
2024年6月、エブリーは5つの小売アプリの運営について事業譲渡を受け、『 retail HUB 』へ移管しました。
この事業譲渡において、私はシステムに関するデューデリジェンス（以下、システムDD）を担当しました。
今回 retail HUB へ移管したシステムは具体的には 5つプロダクトそれぞれにおける、iOS/Androidのネイティブアプリと、入稿管理画面の Web アプリケーションサーバー、アプリ向け API サーバー、それらを構成するシステム（AWS環境、ロードバランサー、データベース、バッチサーバーなど）です。
システムDDは譲渡されるIT資産の把握やリスクの確認を行う重要なプロセスですが、方法や手順が明確に決まっているようなものではなく、どう進めるべきか迷うことが多くありました。 そこで、本記事では、今回私が行ったシステムDDの具体的な手順の実例について紹介します。進め方に明確な正解のないシステムDDについて、手順の実例を共有することで、同様のプロセスを進める方々の参考になれば幸いです。
システムデューデリジェンスとは
システムデューデリジェンスとは、事業譲渡やM&Aの際に、譲渡対象となるシステムやIT資産の現状を詳細に調査し、リスクを特定するプロセスです。主に、譲渡後に予期しない障害やコストの増加を防ぐために実施されます。
システムDDの手順実例
私が行ったシステムDDの手順を振り返ると、以下の手順に整理できました。
- 事前準備
- 前提・目的の認識合わせ
- 調査範囲の明確化
- 調査
- システムの満たしたい状態の定義
- ドキュメントの満たしたい状態の定義
- システム評価
- 調査項目の洗い出しとグルーピング
- アプリケーション（iOS/Android/サーバー）
- インフラストラクチャ（AWS）
- 調査項目の洗い出しとグルーピング
- 現場エンジニアへのヒアリング
- 調査後
- 見つかった課題・リスクにおける対応の整理
ここからはそれぞれの手順について詳細を紹介します。
事前準備
前提・目的の認識合わせ
システムDDを進めるにあたり、まず最初に取り組んだことは事業譲渡における前提や目的の認識合わせです。
システムDDは社内でも初めても取り組みでもあることに加え、デューデリジェンスは実際にはその時の事業状況や、事業譲渡の目的などによって具体的な調査範囲・内容は変わり得るため、認識を合わせる必要があると考えました。認識合わせは当たり前なことですが忘れてはいけない大切な作業だと考えています。
今回の場合、事業譲渡がプロダクト単位で複数のプロダクトが譲渡対象であることや、各プロダクトの所有権や権利等の状況が異なる状況であること、のようなことが前提となります。
そして、主な目的は、譲渡対象となるIT資産の現状を把握し重大なリスクを特定することです。特に、譲渡後の運用が想定通りの工数で行えるか、また運用に影響を与える潜在的な課題やリスクを洗い出すことが重要でした。さらに、前提を踏まえると譲渡対象のソフトウェア資産を特定することも大事な目的になります。
調査範囲の明確化
以上の前提と目的を踏まえ、以下の点が重要となります。
- プロダクト固有のリスクの評価
- 運用に要する工数の把握、および運用に影響するリスクの特定
- 譲渡対象のソフトウェア資産の洗い出しと特定
これらの点を踏まえて調査範囲を明確化し、システムDDを行いました。
調査
ここからは具体的に行った調査方法について紹介します。
システムの満たしたい状態の定義
運用保守への影響確認という前提の観点を踏まえて、譲渡後にエブリーが運用保守していくあたり、困難なく開発・保守・運用できるかどうかという観点で、システムの満たしたい理想状態を定義し、その状態との差分を確認していくことで調査および評価を行いました。
例えば、「バグ検知」という調査の大項目については以下のように定義しました。
- エラー検知の仕組みが導入されていてバグやシステム異常の発生が即時に検知・通知されること
- 各システムの各種メトリクス監視
- アプリのクラッシュ計測
など...
このような定義との差分をドキュメントや、実際のソースコードおよびシステム構成の確認、現場エンジニアへのヒアリングなどを通して確認していきました。 また、満たしたい状態を定義することで、調査の際に確認すべきポイントが明確になります。
ドキュメントの満たしたい状態の定義
システムの状態定義と同様に、ドキュメントについても運用保守という観点を踏まえて期待する状態を定義し、その状態との差分を確認していくことで調査および評価を行いました。
例えば、「DB設計書・ER図」というドキュメントについては以下のように定義しました。
- 下記の内容を把握でき、結果としてDBの運用・改修が可能な状態
- 各物理データベース
- 用途
- スペック
- DBMS ソフトウェアバージョン
- 各種メトリクスの閲覧方法
- 異常時の検知手法・対応手法
- 各論理データベース
- 各テーブルの構成、ER 図
- 各テーブルやビュー・ストアド等の用途
- 各テーブルやビュー内のカラムの定義
- 各物理データベース
以下のようなドキュメントについて、同様の状態定義を行い、評価していきました。
- 外部システム連携仕様書
- 機能一覧
- 要件定義署
- 機能仕様書
- API設計書
- DB設計書・ER図
- ログ設計書
- 各種アカウント情報
- 環境構築手順書
- リリース手順書
- 管理画面操作手順書
- 画面一覧・画面遷移図
- デザイン
- バッチ処理概要
- レポート作成マニュアル
など...
システム評価
システム評価では、上記の満たしたい状態を踏まえつつ、調査項目を洗い出してグルーピング行い、それぞれの調査項目についてGitHubやAWS環境などに招待いただいて閲覧操作することで評価を行いました。
アプリケーション（iOS/Android/サーバーなど）
アプリケーションの評価は、以下のグルーピング項目に基づいておよそ40項目ほどの調査項目を確認していきました。 確認対象のリポジトリは約30個ほどあり、膨大な作業量であったため、現場エンジニアへのヒアリングを交えながら効率的に調査を進めました。
評価のグルーピング項目
- ソースコード品質
- 設計
- プロセス
- セキュリティ
- パフォーマンス
- 構成要素
具体的な調査項目（一部抜粋）
- ソースコード品質
- コードベースの長さ
- コードベースの複雑さ
- テストコードのカバレッジ
- エラーハンドリング
- 適切なコメントの有無
- 一定期間内のエラー件数
- 既知の不具合の数
- コーディング規約の有無
- 言語/FW/ライブラリのバージョン
など...
可能であれば、全てのソースコードを実際に動作させて運用保守への影響を確認することが望ましいです。
インフラストラクチャ（AWS）
インフラストラクチャの評価は、AWS環境に関する以下のグルーピング項目に基づいて行いました。AWSアカウントに招待していただき、各項目に沿って確認しました。 アプリケーション評価と同様、現場エンジニアへのヒアリングを交えながら調査を進めました。
評価のグルーピング項目
- アーキテクチャ設計
- セキュリティ
- コスト管理
- 運用・保守
具体的な調査項目（一部抜粋）
- アーキテクチャ設計
- VPC設計
- ネットワーク構成
- データベース設計
- コンテナ化の有無
- IaCの有無
- CI/CD構成
- ログ収集とモニタリング
- セキュリティ
- IAMポリシーとロールの設定
- セキュリティグループとネットワークACLの設定
- データの暗号化
- ログ管理と監視
現場エンジニアへのヒアリング
上述の調査での不明点や把握しきれない点について、現場エンジニアの方々からヒアリングを行いました。 現場のエンジニアの方々は、システムの現状をよく理解しているため、ヒアリングを通して価値のある情報を多く早く得ることができます。 ヒアリングは必須の作業として行うと望ましいです。できればシステムDDの早い段階で行い、かつ定期的に行うことで効率的に調査を進めることができると思います。
見つかった課題・リスクにおける対応の整理
以上の調査を行った結果、見つかった課題・リスクを一覧化し、それぞれに対して影響範囲を整理しました。 その内容をもとに先方と対応方針について協議を行いました。
やっておけばよかったこと
譲渡後に運用保守を始めから振り返ってみて、システムDDでいくつかやっておけばよかったと感じたことがありました。主に運用してみて想定外の工数に繋がったものです。
- システムの移管作業を想定した調査観点の追加
- 既知の不具合に対する詳細と影響範囲の把握
など...
譲渡契約後にシステムを当社に移管する作業を行う進め方をしましたが、実際に移管作業を始めると、移管するための事前作業で多くの工数を要するものがあることがわかりました。 例えば、iOSアプリの移管について、キーチェーンやAppleでサインイン機能を利用しているiOSアプリを別組織に移管すると、それらの機能が一時的に利用できなくなることがわかりました。これらをユーザー影響なく移管するには多くの工数を要するため、譲渡時には想定していなかった想定外の工数となります。
また、把握していた既知の不具合が譲渡後に想定外の影響を及ぼし、改修するのに多くの工数を使ったケースがありました。事前に不具合の詳細と影響範囲の把握を行っていれば、多少は事前に織り込めたと思います。
まとめ
今回の経験を通じて、事業への影響を最小限に抑えるために事前にシステムDDを行うことの重要さを再認識したとともに、観点やノウハウなど知見を貯めることができました。 また、5つのプロダクトを同時に移管するという稀有な経験から、私自身の成長として、未知で決まった答えのない領域に対して試行錯誤しつつ最大限の決定を繰り返して推進していく能力が向上したと感じました。
本記事が少しでもどなたかのお役に立てれば幸いです。
