🦔

【マネジメントシリーズ】テックデューデリジェンス

2025/01/17に公開

はじめにのはじめに

この記事はmedicalforce New Year's Blog 2025の9日目の記事として書きました。
皆さん思い思いのテーマで書いてくださっています。是非目を通してくださいね!

はじめに

マネジメントシリーズと題しましたが、マネージャーだけではなく、セルフマネジメントを行う多くの社会人エンジニアの方に読んで欲しいです!
今回のテーマはテックデューデリジェンスで、テクニカルマネジメント的な分野の話です。

テックデューデリジェンス(テクニカルデューデリジェンス、ITデューデリジェンス)とは

テックデューデリジェンス(Tech Due Diligence)という単語に耳馴染みのない方も多いと思います。筆者も割と最近知った概念です。
デューデリジェンスとは投資を受ける際や企業買収・売却の際に企業価値を評価することを指します。
では"テック"デューデリジェンスと言うと技術的な観点から見たデューデリジェンスのことで、技術力やソフトウェアによって他社と差別化したり競争力の源泉となっている企業において、既存の開発資産はもちろん、開発能力や開発・運用等のプロセスについても評価します。

多くの場合は客観的な評価のために被評価企業自身で評価するのではなく投資会社などの別の組織によって行われます。
しかし自社自身によってセルフチェックすることで、金銭的な価値評価は不要としても客観的に見て自社の開発能力やプロセスが今後の成長において優れているかどうかや、改善の余地、技術負債を探るのに使用することも出来、実際に内部評価として運用している企業もあるようです。

本来は監査と同じで、どのタイミングで実施するかや評価の基準となる証跡をどう収集するかなど計画的に行うのですが、今回は簡単にセルフチェック出来ることを目指して、評価観点とチェックリストだけご紹介します。

評価観点

いきなり詳細なレベルであるチェックリストに入っても、意図やあるべき姿が見えにくいので、まずは簡単に評価観点を説明します。
そもそもテックデューデリジェンスは統一された基準はなく、各評価組織によって評価手法・チェックリストがいろいろあるのですが、評価観点としてはある程度似通ったものになっています。
今回は公開されている評価手法を色々見てまとめたものをご紹介します。

技術スタック

  • 使用しているプログラミング言語、フレームワーク、ツール、インフラなどが最新かつ適切であるか
  • レガシーな技術への依存度や、使用している技術の将来性を評価

ソフトウェアの品質

  • コードの品質、可読性、保守性を評価
  • 技術的負債をどの程度の抱えているか

セキュリティ

  • サイバーセキュリティ対策やデータ保護が適切に行われているか
  • 脆弱性の有無やセキュリティインシデントの発生履歴

スケーラビリティとパフォーマンス

  • 現在の技術基盤が事業の成長に対応できるかどうか
  • サービスの応答速度やサービスダウンの状況

IP(知的財産)の評価

  • 保有している特許、商標、著作権などが明確で合法的に所有されているか
  • 技術の独自性や競合優位性を評価

チームと組織

  • エンジニアリングチームの能力や構成、文化を評価
  • チームの管理やスキルアップについて評価

データとプライバシーの管理

  • データの収集、保管、処理、バックアップやリストアについてデータ管理プロセスを評価
  • プライバシーに関する法律・ルールに準拠しているか

ロードマップと技術戦略

  • 将来的な技術計画や開発の方向性が現実的でビジネスの方向性と一致しているか

チェックリスト

それでは参考として使用できるチェックリストを紹介します。
以下はAKF Partners社が公開しているチェックリストを機械翻訳し、若干修正したものです。
はい、が多いほど良い評価になります。

システム・技術に関するもの

  • 複数のエンドポイントにリクエストを分散するためにロードバランサが使用されていますか?
  • セッション状態はブラウザに保存されますか?
  • 読み取り/書き込み用のデータベースを使用して、読み取りと書き込みが適切に分離されていますか?
  • キャッシュシステムは利用されていますか?
  • 認証・認可サービスは同期されており、すべての環境で利用できますか?
  • エッジキャッシング (CDN/ブラウザキャッシュ) は活用されていますか?
  • 異なるサービスは異なるサーバー間で分離されていますか?
  • データは異なるデータベースに分散されていますか?
  • サービスは、ニーズ(可用性、変更頻度、依存関係、スキルセットなど)を考慮して適切に規模設定されていますか?
  • エンドポイント (静的コンテンツ、API) は、類似のデータ毎に独立していますか?
  • データベースは関連するデータ毎に独立していますか?
  • マルチテナントを扱う場合、テナント毎に処理は分離していますか?
  • データ保存の要件が定義され、その通りにデータを扱っていますか?
  • サービス間で非同期呼び出しのみが行われていますか?
  • アプリケーション内においてドメイン/サービスごとにデータを分離していますか?
  • アーキテクチャは機能/関心領域の分離を行うよう設計されていますか?
  • 障害によってサービス全体が停止する領域 (単一障害点) はありますか?
  • データ層は論理的な破損や使用不可に対して耐性がありますか?
  • 複数のデータセンター、またはクラウドにおける複数のリージョンを使用していますか?
  • データセンターは地理的にリスクの低い地域にありますか?
  • ストアドプロシージャを使用している場合、ビジネスロジックはストアドプロシージャ内に実装されていませんか?
  • Webサーバー、アプリケーションサーバー、データベースサーバーは同一のサーバ内で実行されていませんか?
  • オートスケーリングは使用されていますか?
  • サードパーティのシステム・技術を使用している場合、コストやデリバリーに合理的な範囲を超えて悪影響はありませんか?
  • 各サーバについて、ハードウェア/仮想インスタンスのサイズは妥当ですか?
  • 仮想化を使用していますか?
  • データセンターは低コストの地域にありますか?
  • ファイアウォール/WAFを使用していますか?
  • 別のパブリッククラウドへは移行可能ですか?
  • 特定の顧客固有のソースコードはありますか?
  • 現在のプラットフォーム・クラウドサービスを採用するにあたって合理的な基準により選定されましたか?
  • 将来のプラットフォーム・クラウドサービスの利用について計画はありますか?

組織・プロセスに関するもの

  • 機能の追加、延期、廃止を決定できる管理者はいますか?
  • 製品管理チームはビジネスの目標決定プロセスに関わってますか?
  • チームは、機能の決定に役立つ成功基準、OKR、KPI、または顧客フィードバックループを用意していますか?
  • チームは、市場価値を検証し、目標を達成するために反復的な発見プロセスを使用していますか?
  • 各主要プロジェクトに対して先行指標(目標を達成できそうか)と遅行指標(目標を達成できたか)が定義されていますか?
  • チームは機能/ストーリーの開発工数を見積もるために、別の見積もりと相対的に比較可能な見積もり方法を採用していますか?
  • チームはリリースまでの時間を改善するためにリリースまでの時間を計測していますか?
  • チームはアジャイル、バーンダウン、メトリクス、振り返りを行い、反復的に進捗やパフォーマンスを測定していますか?
  • チームは開発・運用業務の効率性を測定し、改善することを指揮する者がいますか?
  • チームは工数見積もりを行い、予測値と実際の値を記録していますか?
  • アジャイル開発の場合、ある機能開発について完了の定義はありますか(リリースして完了なのか、機能が使用開始されて完了なのか)?
  • 本番環境のバグ修正ブランチを容易に識別できますか?
  • リリースを阻害するようなブランチ設計になっていませんか?
  • パブリッククラウドでは、新しいサーバー/環境のプロビジョニングは自動化されていますか?
  • チームには文書化されたコーディング基準がありますか?
  • エンジニアは定義されたルールに従ってコードレビューを実施していますか、あるいは自動検証を使用していますか?
  • 使用しているオープンソースについて、ライセンス等の最新状況を追跡していますか?
  • エンジニアはユニットテストを書いていますか?
  • 自動テストの範囲は 75% を超えていますか?
  • 継続的インテグレーション・継続的デプロイメントを利用していますか?
  • 大規模ユーザー向けサービスの場合、リリース前に負荷テストを実施していますか?
  • デプロイの単位は小さく、頻繁にリリースしていますか?
  • コンテナとオーケストレーションは導入されていますか?
  • コードの書き換えを行わなくとも機能を有効化または無効化する仕組みはありますか?
  • リリースされたコードのロールバックは可能ですか?
  • チームは技術的負債について定義をしていますか?
  • 技術的負債は継続的に追跡され、優先順位が付けられていますか?
  • 開発中に見つかったバグ、技術的負債をその開発プロセス中に修正する、または別途管理していますか?
  • Dev/Opsは実施できていますか?
  • チームには従うべき文書化されたアーキテクチャの原則がありますか?
  • アーキテクチャの原則自体をレビューするプロセスはありますか?
  • アプリケーションログはあり、かつ、アクセス管理がされていますか?
  • 監視対象に、顧客体験・ビジネス的なメトリクスが使用されていますか?
  • システムレベルの監視とメトリクス収集がされていますか?
  • 合成モニタリング(疑似ユーザとして実際にシステムに外部からアクセスする監視方法)による監視はしていますか?
  • インシデントは適切な粒度・量の情報とともに集中的に管理されていますか?
  • バグや問題はインシデントから分離されて管理されていますか?
  • バグや問題について重大度を定義していますか?
  • アラートが適切な担当者にリアルタイムで送信されますか?
  • すべての本番環境の変更 (コードとインフラストラクチャ) がログに記録され1か所から全ログにアクセス可能ですか?
  • 重大な問題について事後検証が行われていますか?
  • 問題を完全に解決するまでの時間を測定していますか?
  • 可用性は実際の顧客への影響で測定されていますか?
  • 顧客からの苦情、インシデント、SLAレポート、その他の必要な情報を定期的に確認するサービス品質(QoS)会議が開催されていますか?
  • アーキテクチャの改善について話し合う会議は、四半期に1回以上は開催されていますか?
  • インフラストラクチャにどれだけの余裕があるか、または使用可能なリソースが枯渇するまでにどれだけの時間が残されているか把握していますか?
  • 顧客から報告された問題は、サポートからエンジニアリングチームに伝えるプロセスは定義されていますか?
  • システムの障害を再現する方法はありますか?
  • アーキテクトは開発とインフラストラクチャの両方の経験を持っていますか?
  • チームメンバーをオンボーディング・育成するプロセスは定義されていますか?
  • チームのパフォーマンスは常に評価され、改善されていますか?
  • チームはサブシステム・機能に合わせて分離されていますか?
  • アジャイルチームは他チームに大きく依存することなく自律的に行動できますか?
  • チームは目標を達成するために必要なスキルをすべて備えたメンバーで構成されていますか?
  • 技術的負債の返済と拡張性の確保のため時間・予算を確保していますか?
  • エンジニアとQA・テスターの比率に問題はありませんか?
  • 人材の調達について、スキルレベルとチーム間の人数分配について戦略的に考えていますか?
  • QAチームは自動化を実行していますか?

セキュリティに関するもの

  • 組織として承認され、かつ組織内の人間は誰でもアクセス可能な情報セキュリティポリシーはありますか?
  • 情報セキュリティの最高責任者は指定されていますか?
  • 各チームが担当するセキュリティの責任は明確に定義されていますか?
  • 組織のセキュリティ目標は組織全体で共有されていますか?
  • 全従業員を対象に継続的なセキュリティトレーニングを実施していますか?
  • すべてのデータ資産について管理責任者が定義されていますか?
  • データの価値・機密性などの観点で管理レベルを分類していますか?
  • 従業員が職務を遂行するために必要なネットワーク・サービスにのみアクセスできるように制限されていますか?
  • 雇用、契約の終了時に、すべての従業員および外部関係者のアクセス権は削除されますか?
  • 重要性の特に高いデータへのアクセスに多要素認証が使用されていますか?
  • ソースコードへのアクセスは、必要な従業員のみに制限されていますか?
  • 開発環境とテスト環境は本番環境から分離されていますか?
  • 脆弱性検査は少なくとも四半期ごとに実行され、見つかった脆弱性は対処されていますか?
  • 機密データはネットワークでの転送中に暗号化されますか?
  • 開発中にセキュリティテストは実施されますか?
  • セキュリティを確保する(脆弱性を作らない)実装ルールは開発者向けに文書化されていますか?
  • インシデント対応計画は文書化され、少なくとも年に1回見直し、インシデント発生時の訓練はされていますか?
  • データの暗号化は、契約や法律に準拠して行われていますか?
  • セキュリティリスクについて対応の優先順位を付けるプロセスはありますか?
  • IDS・IPSを導入していますか?

もし組織目標とする場合の注意

デューデリジェンスの一番の目的は組織外部から見た被評価企業の価値の算出です。
しかし性急にテックデューデリジェンスを求めることで組織の文化や開発者体験が損なわれることもあります。
テックデューデリジェンスで良い評価を得ること自体は良いことで、目標とすることは差し支えありません。
ただし、それだけに囚われて、他の重要な指標や価値・評価を見落とさないように気を付けてください。

最後にまとめ

最後にまとめとなりますが、要点としては以下です。

  • テックデューデリジェンスとはエンジニアリング観点から組織の価値を評価する手法です
  • テックデューデリジェンスを自社でセルフチェックすることで自社の強みや弱みを明らかに出来ます
  • テックデューデリジェンスを参考にするにしてもどこまで目指すか考えて運用しましょう

今回はまずテックデューデリジェンスというものがなんなのか知っていただくことが目的でした。世の中には様々な評価体系・評価手法があります。テックデューデリジェンスもその1つとして適切に取り込んでいき、組織力の強化に役立てていただければ幸いです。

是非他のシリーズも読んでくださいね。

Discussion