技術デューデリジェンスはコード品質のコンテストではありません。それにもかかわらず、これから受ける側のチームは、たいてい見当違いのところに時間を注ぎ込みます。会社を買おうとしている人間で、あなたの設計した抽象化に点数をつけたい人はひとりもいません。買い手が知りたいのは、このシステムを保有し続けるのにいくらかかるのか、そして資金が動いたあとにどれほどひどいことが起こりうるのか、その二点だけです。

この捉え直しが大事なのは、最初に直すべきものが変わるからです。見た目は汚いけれども動いていて、チームが中身を理解していて、安全に手を入れられるコードは、軽微な指摘で終わります。逆に、洗練されてはいるがひとりの人間しか理解していないコードは重大な指摘になります。価格を動かすのは、いつも後者のほうです。

すべての問いの背後にある問い： 創業エンジニアがクロージングの翌週に辞めたとして、このシステムは動き続け、そして変わり続けられるのか。提示額を下げる指摘は、ほぼ例外なくこの問いへの具体的な答えになっています。ひとりの頭のなかにだけ溜まった知識、文書化されていないデプロイ手順、誰も確認していないライセンス、特定の個人の記憶にしか存在しない認証情報。挙がってくるのは、いつもこの種類のものです。

技術デューデリジェンスが実際に評価しているもの

見られているのは四つのリスクです。企業価値への影響が大きいと考えられる順に並べると、おおむね次のようになります。

属人化リスク。 システムが文書化された手順ではなく、特定の個人に依存していないかどうかです。これは一貫して最も損害の大きい指摘になります。事後に手当てするのが最も難しく、しかも買おうとしている対象そのものを直接脅かすからです。担当者がひとり抜けただけで開発が止まるのであれば、買い手が手に入れるのは資産ではなく人質のようなものになってしまいます。

継続コスト。 システムを動かし続け、発展させ続けるために何が必要になるかです。インフラの支出、ライセンス上の義務、必要になるチームの規模、そしてロードマップのうちどれだけが新規開発ではなく保守に食われるのかが、ここに含まれます。これは買収後の損益計算書にそのまま乗る数字なので、買い手は驚くほど細かく確認します。

法的責任。 商用利用と衝突するライセンス、苦情が来たら説明しきれない扱い方をしている個人データ、セキュリティ上の露出、そして会社が実際には満たしていない規制上の義務です。いずれも、買い手がそのまま引き継ぐことになる負債です。

変更できる力。 新しい機能を予測可能なペースで出せる状態にあるのか、それとも一つ手を入れるたびに、まったく無関係な場所が壊れる危険を抱えるのかという点です。買収の目的が製品を伸ばすことである以上、この力の有無は将来の売上見通しそのものに直結します。

コード品質が意味を持つのは、この四番目を通してだけです。だからこそレビュアーは、創業者が想像するよりもはるかに短い時間しかコードを読まず、そのかわりに、デプロイがどう行われているのかを尋ねることに多くの時間を使います。

価格を下げる指摘

ひとりしかデプロイできない。 リリース手順が誰かの頭のなか、あるいはその人のノートパソコンの上にしか存在しない状態は、今日どれだけうまく回っていようと、深刻な運用リスクとして扱われます。手順が動くことと、手順が引き継げることは別の話だからです。

重要な経路にテストがない。 問題にされるのはカバレッジの数値ではありません。その数字をレビュアーはほとんど見ていません。見られているのは、このシステムに少しでも自信を持って手を入れられるのかどうかです。売上が通る経路のまわりにテストがないコードベースは、そのぶん遅いロードマップを価格に織り込まれます。ソフトウェアテスト戦略 の記事では、どのテストが本当に価値に見合うのかを扱っています。

ライセンスの汚染。 プロプライエタリな製品のなかにコピーレフトのコードが混ざっている状態は、単に値付けを下げるのではなく取引そのものを止めうる、数少ない指摘のひとつです。しかもスキャナーを走らせれば数分で見つかるため、隠しておける類のものではありません。

説明できる根拠のない個人データ。 明確な適法な根拠のないまま集めたデータ、期限を決めずに保持し続けているデータ、あるいは会社自身がどこにあるのか列挙できないデータです。GDPRへの技術的な対応 で扱っている仕組みは、そのままレビュアーが確認する項目でもあります。

個人やベンダーへの文書化されていない依存。 契約のない取引先との重要な連携、あるいは個人アカウントの上に載っているインフラです。どちらも、管理されていないリスクとして読まれます。会社としての契約や所有関係が確認できないものは、買い手にとって存在しないのと同じ扱いになります。

セキュリティの基本が抜けている。 ペネトレーションテストの結果を求められているわけではありません。見られているのは、シークレットがバージョン管理に入っていないか、人が辞めたときにアクセス権が確実に剥奪されているか、そして今この瞬間に、パッチが当たっていないままインターネットに公開されているものがないか、という三点です。

レビュアーが気にしないこと

これはあえて書いておきます。準備に使える時間はかぎられており、しかもたいていは間違ったところに使われるからです。

どのフレームワークを選んだかは、その技術者を採用できるかぎり誰も気にしません。アーキテクチャの流行も同様です。出荷できているモノリスは指摘事項になりません。コードのスタイル、命名、インターネット上の誰かが薦めているパターンを採用していないこと、そのどれもが評価には響きません。

技術的負債がゼロであることも期待されていません。どの会社にも存在するもので、あること自体はまったく正常です。重要なのは、チームがそれがどこにあるかを把握していて、その代償を説明できるかどうかです。自分たちの既知の問題を明快なリストにして差し出せるチームは、有能に見えます。逆に、問題はひとつもないと言い切るチームは状況が見えていないと受け取られ、レビュアーは自力で探すはめになります。時間は余計にかかり、書き上がる報告書の内容も悪くなります。

何も書き直さずに備える

効果のあることのほとんどは、数か月ではなく数日で終わります。しかも、そのどれひとつとしてアーキテクチャに手を入れる必要がありません。

デプロイの手順を書き出す。 空のマシンから、動いているシステムになるまでを書きます。この一つの文書が、最も損害の大きい指摘のカテゴリに正面から対応します。半日あれば書けます。

依存関係とそのライセンスを洗い出す。 自動化ツールを使えば一覧はすぐに出ます。結果が完璧に綺麗であることよりも、レビュアーより先に自分たちが答えを知っていることのほうが、はるかに価値があります。

シークレットをバージョン管理から取り除き、誰が何にアクセスできるのかを棚卸ししてください。そのうえで、すでに退職した人のアクセス権をすべて外します。

壊れていると分かっていることを文書に残す。 既知の問題と、その修正にかかるおおよその費用をまとめた、短く正直な一覧で十分です。これを自分から差し出すことは、レビューの読まれ方を確実に良くしてくれる数少ない手のひとつです。

インフラの所有者が会社になっているか確認する。 個人アカウントではなく法人の名義であること、ドメイン、証明書、リポジトリのすべてが会社の管理下にあることを確かめてください。

指摘はその後どうなるのか

指摘が取引を殺すことはめったにありません。指摘は条件に変わります。

出てきた指摘は、たいてい三つの結末のどれかに落ち着きます。修正費用を反映した価格の調整、契約書に書き込まれる表明保証または補償条項、そしてクロージング前に満たすべき前提条件です。取引そのものを恒常的に止めてしまうのは、ライセンスの汚染と、放置された重大なデータ保護上の露出くらいのものです。

つまり実務上の目標は、完璧なシステムをつくることではありません。問題が把握されていて、範囲が限られていて、言葉で説明できるシステムにしておくことです。金額の見当がついている問題は価格に織り込まれますが、見当のつかない問題は、実際よりも悪いものとして見積もられてしまうからです。

Mecanikはソフトウェア開発 の業務の一環として、この種の技術レビューを行っています。多くの場合は買い手側の立場です。そこで見えてくる傾向はいつも同じです。レビューを無難に通るシステムは、洗練されたシステムではありません。誰かが物事を書き残しておいたシステムです。

関連記事: ソフトウェアエスクロー：本当に必要なのは誰か 、英国のフィンテック開発：FCA、決済レール、コスト 、固定価格契約か、実費精算か 、英国のカスタムソフトウェア開発：購入者のための完全ガイド 。

よくある質問

技術デューデリジェンスとは何ですか。 ソフトウェアシステムを保有し続けるのにいくらかかるのか、そして買収や出資のあとにどれほどひどいことが起こりうるのかを評価する作業です。コード品質そのものに点数をつけるのではなく、属人化リスク、継続コスト、法的責任、そしてシステムを変え続けられる力を見ます。

価格を最も下げる指摘は何ですか。 知識が特定の個人に集中していること、とりわけデプロイをひとりしか実行できない状態です。その次に来るのは、売上が通る経路に意味のあるテストがないこと、プロプライエタリな製品に混入したコピーレフトのコードによるライセンス汚染、説明できる適法な根拠のない個人データ、そしてバージョン管理にコミットされたシークレットです。

レビュアーはこちらの技術的負債を気にしますか。 あるものとして見ています。どの会社にも存在し、あること自体は指摘事項になりません。重要なのは、チームがそれがどこにあるかを把握していて、直す費用を説明できるかどうかです。既知の問題を整理した一覧は能力の証拠として読まれ、問題はないという主張は認識不足として読まれ、レビューの結果を悪くします。

技術デューデリジェンスにはどう備えればよいですか。 空のマシンからシステムを立ち上げる手順を書き出し、依存関係とそのライセンスを洗い出し、シークレットをバージョン管理から取り除き、まだアクセス権を持っているのが誰かを確認し、インフラとドメインが個人ではなく会社の所有になっていることを確かめ、既知の問題とおおよその修正費用をまとめた正直な一覧を用意してください。

技術的な指摘だけで取引が完全に止まることはありますか。 まれです。ほとんどの指摘は価格の調整、契約上の保証、あるいはクロージング前に満たすべき条件に変わります。実際に取引を止める例外は、プロプライエタリな製品のなかのコピーレフトによるライセンス汚染と、放置された重大なデータ保護上の露出です。