点と点をつなぐ：開発+ビジネスリスク+デューデリジェンス

Sep 18, 2023 / 1 min read

通常、M&A取引におけるデューデリジェンスを調整するのは実業家や弁護士です。わずかながら元開発者もいるかもしれません。元開発者は多くの場合、ソフトウェアがどのように構築されるかをある程度理解しており、少なくとも技術的なリスクについて直観的な感覚を持っています。弁護士、企業開発担当者、金融投資家は、ソフトウェアの開発方法と、開発が軌道を外れる可能性のあるポイントについて理解が深まるにつれ、ソフトウェアのリスクに対して会社や顧客に適切に注意喚起できるようになります。これにより、取引成立後の管理のあり方をより的確に計画することができます。

プロセスを遵守する

組織のソフトウェア開発チームとプロセスによって、コードの属性が決まります。優れたソフトウェアを開発するには、プロセスの適切な設計が重要です。プロセスの詳細により、具体的な出力属性が決まります。開発者がアプリケーション・セキュリティに関する十分なトレーニングを受け、日常的に静的アプリケーション・セキュリティ・テスト（SAST）ツールを使用していれば、ソフトウェアのセキュリティが向上する可能性が高くなります。

プロセスが適切に設計されている必要があることは当然ですが、実態とドキュメントの内容が乖離している場合があります。ベストプラクティスを遵守できるのは、適切に管理された規律ある組織だけです。激務で開発が進まないケースが多く見受けられます。もちろん、セキュリティ・コードの徹底的なレビューには意義がありますが、プロジェクトが遅れ、リリースの期限が迫っているときに、チームは計画を守るでしょうか。多くの場合、近道を選んで「技術的負債」を蓄積していきます。

評価を重ねる

組織と開発プロセスの評価は、取引成立後の計画の基礎となります。これにより、開発チームがロードマップの実行段階でどの程度の成果を実現できるかについての将来的な見通しが得られます。また、買収企業の価値の大部分をソフトウェアが占めている場合は特に、コードの内容を評価することが重要です。定義されたプロセスを新たに実装する可能性がありますが、必ずしもそのプロセスに従うとは限りません。コードには技術的負債や、セキュリティ、品質、ライセンスの問題が山積し、チームはロードマップの実行に加えてこれらを解決する必要があります。金融負債が制御不能になる可能性があるのと同様に、技術的負債も制御不能になる可能性があり、「返済」をビジネス・ケースに組み込む必要があります。

大半の買収側企業は、組織とプロセスに対する一定のデューデリジェンスを自ら行っていますが、これは理にかなった重要なことです。コードに対する徹底的なデューデリジェンスによりプロセス評価を補完して全体像を完成させ、取引と取引完了後の統合計画を報告します。詳細は、ソフトウェア・プロジェクトで起こり得るあらゆる問題を見てきたDeclan Burns氏によるWebセミナー「Software Construction & Business Risk: A Crash Course for Investors and Lawyers（ソフトウェア構築とビジネス・リスク：投資家と弁護士のための短期集中コース）」、および筆者による2つのホワイトペーパー「Understanding Software Development, Technical Debt, and Risk（ソフトウェア開発、技術的負債、リスクの理解）」と「Mitigating Risk in Mergers and Acquisitions（合併・買収におけるリスクの軽減）」をご覧ください。Synopsysのソフトウェア・デューデリジェンス・チェックリストもお勧めします。これは私たちがこれまで見てきた中で最も包括的なチェックリストです。