SaaS事業者やCTO/CEO/CFOのためのテクノロジー/セキュリティDD入門…でありDD必要ということだけは覚えておいてください
SaaS事業者がSaaS等を買収する際、セキュリティやテクノロジーDD(デューデリジェンス: ざっくりいえば買収先に対する状況調査)を怠る事例が多発しています。
開発面やセキュリティによる事業リスクが見過ごされ、買収してから問題が表面化、買収失敗で特別損失の計上を株主に伝えることになるでしょう。毎回PMI(買収後のプロセス)で担当エンジニアやCTOが悲鳴を上げています。
(買収前にちょっと中身を見ただけでわかるレベルなのに…どうして😭😭)
投資家からの怒号、社内からの悲鳴は避けたいですね。
もちろん財務や事業、法務、人事、コーポレートITといったバックオフィスといったところはDDで精査しているのですが、なぜか技術面だけぽっかり穴が空いています。
米国では当然に行われるのになぜ日本では行われないのでしょうか。
日本でやらない理由
個人的な予測です。
(1) 本やweb記事に書いてないから
Big 4が出すような資料を定期的に確認してますが、テクノロジーやプロダクトセキュリティDDには言及がありません。各社の専門外というのはありそうですがチェック項目にすらないことがほとんどです。
(2) 誰もやっていないから
人は真似するもの。M&A、特にDDは回数も関わる人数も少ないので良い経験も積みにくいでしょう。
外部のM&A支援コンサルだと回数積みやすいのですが、結局やってないので0になにを掛けても0です。
聞き及ぶところでは一部のメガベンチャーではテクノロジーDDを行っているようですが少数派です。
(3) 国内SaaS同士の買収の実績がまだ少ないから
失敗例や成功例が伝播できてない状態です。
(4) IT DDでカバーできそうな気がするから
IT DDは多くのM&Aマニュアルに記載があります。ITとあるのでプロダクトも含まれそうですが実際は社内システムといったコーポレートITだけです。もちろん社内IT統合はコスト効率化の面で重要な観点ですがプロダクトとはまた違います。
(5) エンジニアリングが軽視されているから
プロダクトを買収する以上、エンジニアリングの重要性は全体の5割とはいいませんが数割を占めるでしょう。単純に全社員における人数でも数割占めることがあります。一方、M&Aは長期経営計画における重要トピックの一つです。この状態でテクノロジーDDを無視するということは経営陣がエンジニアリングを軽視していると考えざるを得ません。結局全ては言葉ではなく行動です。
M&AにCTOが介在しないケースも見聞きします。機密保持のためDDは人数が絞られるとはいえ、さすがに成功させるのは無理があるでしょう。
リスク項目とアセスメント
どんなところを見ればいいのかの一例です。DDレベルだと大きなインパクトがありそうなところだけになります。
開発体制
M&Aは買収先に大きく伸びてもらうのが目的の一つです。
まずは開発は外注しているのか、開発メンバーのうち社員の割合はどの程度かを確認しましょう。内部統制にも関わる事項です。
その後買収先のスキルレベルをアセスメントしましょう。技術者外だと判断しづらいですが見る人が見れば一発でランクがわかります。補助的に各種成熟度確認ツールをつかうのもありです。
買収先が自社より明らかにランクが低い場合、(買収を見送ることをおすすめするものの)人を投入することになるでしょう。
過去1年程度のインシデント状況とその対応を確認しましょう。インシデントに追われている状態で追加機能開発は困難です。
コードベース / アーキテクチャの確認
DDは期間も人数も限られており、コードベースの確認に力を入れることはできません。アーキテクチャレベルの確認が主になるでしょう。
AWSであれば以下の記事も参考にできます。AWSの参照権限をもらったり資料をもらうのはなかなか大変ですが、領収書はPDF一つで明確な事実が確認できます。
あとはFour Keysといった外部のパフォーマンス基準も使いましょう。その中でもリリース頻度だけ聞けば実力がおおよそわかります。
大まかな技術的負債とその対応予定も聞きましょう。
プロダクトセキュリティ
まずは外部脆弱性診断機関からの診断結果を説明してもらいましょう。
自社でセキュリティエンジニア、特にレッドチーム側の人材を抱えていればスキャンが可能です。法律と常識、モラルの範囲内で確認し、セキュリティリスクが多ければ買収金額の交渉材料となります。
自社や標準的な開発セキュリティ基準に当てはめて開発状況を確認しましょう。SecurityHubの依頼ぐらいはできるのはないでしょうか
個人情報や決済関係データの保有状況を忘れずに。
技術スタックに合わせ、ライセンス周りの遵守状況も確認が必要です。リスク多し。
セキュリティポリシーや過去のセキュリティインシデント一覧ももらいましょう。
テクノロジーコスト
プロダクトのユニットエコノミクスはどうか。AWSなら領収書も見ながら削減ポテンシャルを確認しましょう。
開発系メンバーを自社標準のSaaSに組み込むときに追加費用はどれくらいか。
契約チェックの一環としてベンダー契約のコミットメント状況や長期契約を合わせて見ます。
DDでやること
CTOを巻き込む
CTO抜きで話が進み、青天の霹靂となることがあります。プロダクトが重要なら早めに巻き込みましょう。DDの失敗をPMIで巻き返すことはできません。
脆弱性診断の結果をもらう
ある程度真面目に開発している会社ならば外部脆弱性診断は実施済みのはずです。結果と対応計画を提出してもらいましょう。
外部脆弱性診断にもレベルがあり、脆弱性診断会社にも能力差があります。診断能力が低いと重要な脆弱性を見過ごします。
以下のラック社の表でいうLV 2が最低限確認したい診断結果です。
自社にセキュリティエンジニアが在籍していれば診断を行った機関のレベルを確認できます。
深刻な脆弱性が多かったり、修正する能力やキャパシティがないようだったりするようなら買収見送りも検討しましょう。
もし直近の診断結果が存在しないようなら計画を立ててもらいましょう。(診断依頼の費用負担は売主側だと思います。)
そもそも診断がない場合はその時点で能力が怪しく、PMIにコストがかかることを想定しましょう。
公開リソースを確認する
公式サイトや採用サイト/求人広告からおおよそのアーキテクチャを推測できます。
開発ブログ含めた採用露出を確認しましょう。技術内容のほか、採用力がわかります。
プロダクトがさわれるならChrome DevToolsやスキャンツールでアーキテクチャや利用技術、バージョンまである程度特定できます。
AWS等の領収書をもらう
前述のとおりです。
追加情報として、代理店が介在していればAWS Organization統合の難易度が上がります
開発ドキュメントをもらう
アーキテクチャや開発プロセスを確認します。
まずドキュメントがあるか確認しましょう。すぐに出せる資料がないなら危険信号です。
体制イメージとロードマップを検討する
今後体制をどうしていくのか。特に自社とのギャップがある場合どう引き上げるのか。日本では解雇が難しいため例えば自社では採用しないレベルのメンバーについてはどう育成したり別のポジションを用意したりするのか。
開発体制や技術標準は自社と揃えるのか、ばらばらにするのか。統制を考えればなるべく高い方に揃えたいですね。
子会社は採用しづらいことがあります。母集団形成は自社と同じように行うのか、別々なのか。そもそも自社の採用に困っている状況で子会社の支援ができるのか。
誰が子会社との間に立つのか。100%稼働が取れる人を割り当てるのが望ましいです。
支援する場合何人ぐらい必要なのか。自社からどれくらい送るのか。送ることができる状況なのか。
いくつかPMIにまたがって行う項目も記載しましたが、実行計画がイメージできないなら買収を控えたほうが良いでしょう。
特にプロダクトセキュリティ関係の実行計画を立てる
例えばアプリがどうしようもないならWAFでしのぐしかありません。脆弱性対応で開発がストップも考えられます。
AWS APIレイヤーで検知や統制するならSecurity Hubなど含め追加コストがかかります。
なににせよコストがかかるので予算を抑えておく必要があります。
自社システムとのデータ連携、API連携方法を検討する
連携しないなら買収する意味はないでしょう。
新規開発予定を確認する
自社ロードマップとのすり合わせが必要です。
その他確認事項
- 過去のインシデント事例一覧をもらう。セキュリティも含む
- セキュリティポリシーの有無を確認する
見えてきたリスクをもとに、法務等担当者に相談しましょう。買収金額や契約条件の交渉に反映させる必要があります。今後かかるコストも想定しておきましょう。
PMIからどう巻き返すか
DDの時点でなにもせず買収してしまった時点で内容は運を天に任せるしかありません。DDの内容をカバーしつつ、より具体性を伴わせる必要があります。撤退戦が一番難しく、負け戦は負け方が大事です。
一にも二にもセキュリティ
とにかくプロダクトセキュリティを優先してアセスメントおよび改善していきましょう。その中でも特にデータ侵害の有無が最優先です。データのありかを深堀りしましょう。
アプリよりはAWSといったインフラのほうが手を打ちやすいです。どうしようもないアプリに対してすぐできることは各種バージョンアップとWAFぐらい。余裕があればアプリケーションへのランタイムセキュリティ、コードベースへのセキュアコーディング支援ツール、SecurityHub含めたCSPMツールといった形で手間をかけずに自動化したいところです。
表明保証の期間中にはせめてアセスメントは終わらせたいです。
開発改善はきっぱり諦める
開発はそのままにしておきます。開発プロセスや体制改善について、セキュリティ関係以外は後回しにせざるを得ません。プロダクトセキュリティに関連するので開発周りのアセスメントだけは早めに行うのが望ましいです。
最後に
CEO / CFOの方は最悪DDにはセキュリティとテクノロジーDDも必要だということだけを覚えて帰ってください。
CTOの方は経営戦略上M&Aは最重要項目の一つであり、それゆえ他人事ではなくCTOが積極的に関わる必要があることを抑えておきましょう。
とにかくM&Aの名手、永守会長の講演を見て備えましょう。
無意味無計画な買収が減り、誰もよろこばないPMIが少しでも減ることを願ってやみません。
