はじめに
HRMOSプロダクト本部の徳吉です。 この度、株式会社ビズリーチの社内表彰の場で、FY22下期の最高技術賞を頂きました。 評価を頂いた取り組みの一部として、「M&Aに関わる作業を年2回実施」「IEYASU、イージーソフト社のシステムDD（システムデューデリジェンス）」がありました。この取り組みは社内のエンジニアを含め一般的にあまり身近ではなく、謎過ぎる、かつ興味を持って頂けそうな内容なので、この場を借りて、「M&Aに関わる作業」について深掘りして解りやすく紹介させていただきます。なお、IEYASU株式会社、イージーソフト株式会社は現在株式会社ビズリーチの一員となっています。
※文中では「システムデューデリジェンス」については「システムDD」と表記します。
M&AになぜシステムDDが必要なのか
M&Aの際にシステム会社を買収する場合、IT資産としての現在の価値だけでなく未来的に維持メンテナンスしていくための価値評価も必要となります。 資産価値は、わかりすい形に言い換えると「ゼロから作った場合、どのくらい（人数×時間＝費用）で作れるか」です。
価値というと資産価値の方に目が行ってしまいがちですが、リスク評価も（主にマイナス方向の）価値評価として必要となります。 例えば、今は機能十分であった場合でも未来的に機能追加しにくい構造であったり、非常に古いプログラム言語を採用していたり、といった場合は概ねマイナス評価がつくでしょう。
こういった内容を「経営判断する人にわかる言葉で」資料化する作業がシステムDDとなります。
システムDDとは
システムDDでは以下のことを網羅した資料を作成します。以下の例では実際に私が作成した調査結果レポートで記載した章立てをご紹介します。
前提条件・調査範囲
システムDDを行う際の前提や、調査範囲を定義します。どこまでやったのか、どこは除外しているのか、などを明確にし第三者が後で見た場合にも認識齟齬が起きないようにする必要があります。
調査結果サマリー
「経営判断する人」が知りたい情報をコンパクトにまとめて記載してあると、きっと喜ばれます。
実際の報告書では「リスク分析」「システム規模」「インフラ維持費用」「買収後に想定される各種スケジュール」などを記載しました。
調査手法
どのように調査を実施したか最低限の情報を記載します。どうやって調査を行ったか方法を記載することで第三者が調査結果の妥当性を判断する材料になるため記載しておくことが望ましいです。
調査結果
この章は実際に行った結果を記載しますが、実際は結果サマリーになると思います。本当の調査結果は大量の表などになるはずなので、それらは別紙や別ファイルに分けると良いでしょう。
結果としてまとめる場合、「課題サマリー」と「事実をまとめた表」に分けると良いです。「事実をまとめた表」だけだと、その結果が良いのか悪いのかがわかりません。そこで課題をまとめた形で記載することで読む側も見やすく理解しやすくなります。
課題分析
前の章で課題サマリーを記載しましょう、と書いていますが、この章では課題に対して分析結果を記載します。 「こんな課題がありました」だけでは報告を見た人も、きっと困ってしまいます。そこで「この課題に対して、こんな解決策が考えられます」といった提案をセットにすることが望ましいです。
その他、報告事項
補足事項がある場合、ここにまとめて記載しましょう。
参考資料一覧
調査結果の章で「別ファイルに分ける」としたものは、ここにそれらのファイルを記載しておきます。
システムDDの作業内容解説
実際にどういった作業を実施していったのか、順に解説していきます。
各種一覧作成
そもそも買収対象のシステムのソースコードや設計書を見せてもらえない可能性があります。なぜなら、買収先の会社と交渉する前に調査を行う場合もあるからです。そういった場合、システムを触れる範囲（公開されているWebページや、ログインIDで触れる範囲のシステム機能など）で操作を行い、そこから読み取れる情報と見えていない情報を想像力や過去の経験値からの推測で「多分こうなっている」と、つなぎ合わせて一覧化します。
一覧は
- URL一覧
- 画面一覧
- 機能一覧
- API一覧
などになります。
もし、調査対象のシステムのソースコードを閲覧することが可能な場合、ファイル一覧、ソースコード行数、DBテーブル一覧なども作成します。
実際に記述したURL一覧
製造原価概算
有名なソフトウェア見積方法としてファンクションポイント法、などがありますが、システムDDのレベルであると情報が粗すぎて、それらの方法を利用することができません。 とはいえ、半ばこじつけといいますか無理やりでも「概算」を出さなければならないので、そのための数字を集めて計算・集計します。
計算に使えそうな数字としては「ソースコード行数」「画面数」「API数」といったものになります。 例えば製造工程として「1日あたり150行」「1APIあたり5日」といった数字を仮置し、その結果に対し、要件定義・設計・テストの各工程についての按分を係数で掛け算する、といった方法です。
実際に記述したソースコード行数一覧
インフラ構成図
可能な範囲で細かなインフラ構成図を作成します。調査対象のシステムについてヒアリング可能であれば良いのですが、ヒアリング出来ない場合でも推測の範囲でインフラ構成は把握しておくことが望ましいです。
もし詳細にヒアリング可能であれば、インフラの月額費用やアクティブアカウント数も、是非確認しましょう。１アカウントあたりの月額運用費も、可能であれば算出しましょう。
課題一覧
上記までの調査結果の中で課題となるものを一覧化します。大分類としては「インフラ」「アーキテクチャ」を記載しましたが、もしソースコードを閲覧することが可能な場合は「アプリーケーション」という分類で一覧にまとめます。
M&A以外でも役立つ
M&Aの文脈でシステムDDをご紹介しましたが、M&A以外の場面でもシステムDDは役立てることが出来ます。実は「ビズリーチ」、「HRMOS」に対してもシステムDDを実施しており、プロダクト開発における長期戦略検討のためのインプットの１つとして利用してもらっています。この調査を経て得た「HRMOS」の各プロダクトの規模比率などが役立っている・・・らしいです！
最後に
システムの全体感を理解することは、例えば5年10年先のアーキテクチャを選定する、といった場合に必須となります。 もし現在、色々なチャレンジを行いたいといった場合にシステムの全体感が把握出来ていない場合、上記で示した方法を使って自分たちのチームで実施してみると、きっと役立つでしょう。
