【M&A事例研究】NTTデータによるPostlight買収から学ぶ、デジタルデザイン・アプリ開発会社の価値

重要な注意書き
本稿は、参考Excelに掲載された公表案件を譲渡企業の準備という観点で分析した事例研究であり、当センターの仲介実績ではありません。 公表されていない取得価格、財務数値、交渉経緯、デューデリジェンス所見、当事者の感情、個別の契約条件を事実のように記載しません。以下では、公表資料で確認できる事実と、デジタルデザイン・アプリ開発会社のM&A実務に照らした一般分析を明確に分けます。

NTTデータによるPostlight買収から、譲渡企業は何を学べるか

デジタルデザイン会社やアプリ開発会社の価値は、画面の美しさやエンジニア人数だけでは測れません。顧客の経営課題を戦略へ落とし、ユーザーを理解し、体験を設計し、Web・モバイルアプリとして実装し、運用後も改善できる一連の力が価値になります。その力が、特定の創業者やスター人材に閉じず、買収後も顧客へ提供できることがM&Aでは重要です。

2022年6月2日、株式会社NTTデータは、北米子会社のNTT DATA Servicesを通じ、米国ニューヨークを本拠とし、デジタルデザインとアプリケーション開発に強みを持つPostlight LLCを買収することで合意したと公表しました。発表では、2021年のNexient、2022年3月のVectorformの買収に続き、北米におけるアプリケーション開発・モダナイゼーション領域をさらに強化する目的が説明されています。

公表資料は、Postlightが金融、メディア、消費財などの顧客に先進的なデジタルデザインと高品質なアプリケーション開発サービスを提供していると説明し、戦略・デザインから開発・サポートまでの提供体制拡充にも言及しています。ここから一般論として学べるのは、デザイン会社の価値が「制作物」だけではなく、業界理解、顧客関係、デザインとエンジニアリングの協働、品質、継続サポート、組織文化に宿るということです。

1. 公表案件の概要――発表時点で確認できる事実

以下はNTTデータが2022年6月2日に公表したニュースリリースに基づく発表時点の情報です。現在の体制、ブランド、サービス、統合状況を示すものではありません。

項目	発表時点の公表内容
買い手	株式会社NTTデータ。北米子会社NTT DATA Servicesを通じて買収
対象会社	Postlight LLC
本社	米国ニューヨーク州ニューヨーク
事業	デジタルデザイン、アプリケーション開発等
公表日	2022年6月2日
取引	Postlightを買収することで合意
戦略上の位置づけ	北米のアプリケーション開発・モダナイゼーション領域をさらに強化
関連する公表上の流れ	2021年のNexient、2022年3月のVectorform買収に続く取り組み
顧客業界への言及	主に金融などへのデジタル対応力を補完。コメントでは金融、メディア、消費財に言及
提供範囲への言及	戦略・デザインからアプリケーション開発・サポートまでの体制拡充
取得価格・財務	当該リリースでは公表されていない

公表資料に、取得価格、Postlightの売上・利益・純資産、取得持分の細部、クロージング日、従業員数、顧客別売上は記載されていません。したがって、本稿では評価倍率や人員単価を推計しません。「デザイン会社だからこの倍率」「米国企業だからこの価格」といった相場の断定も行いません。

本稿が参照する資料

• NTTデータ公式「NTT DATAによる米国Postlightの買収について」
• MARR Online掲載ページ

ニュースリリースは、記載内容と計画・目標が発表日現在のもので、実際の結果が予測と異なる場合がある旨を注記しています。本稿も後日の状況を当時の確定事実として扱いません。

2. この案件がデザイン・アプリ開発会社の譲渡企業に重要な理由

アプリ開発会社のM&Aでは「受託開発売上がいくらか」だけに目が向きがちです。しかし、同じ売上でも、顧客の戦略段階から入る会社と、確定仕様を実装する会社では、案件単価、関係の深さ、競争優位が違います。デザインと開発を分断せず、利用者調査、サービス構想、プロトタイプ、実装、運用改善まで一貫して担える会社は、顧客の意思決定へ早く関与できます。

一方、一気通貫をうたうだけでは価値になりません。各工程の責任者、方法、成果物、承認、品質、原価、顧客満足を示す必要があります。デザイン案が開発制約を無視していないか、開発がユーザー体験を損ねていないか、リリース後のデータが次の設計へ戻るかを、案件の証拠で説明します。

公表資料がNexientとVectorformに続く買収という文脈を示した点も重要です。一般論として、買い手は単に会社を足し合わせるのではなく、既存能力との組み合わせを見ます。譲渡企業は「自社は優れている」と主張するだけでなく、買い手の顧客、業界、技術、地域、デリバリー体制のどこを補完できるかを整理します。ただし、本件で各社が実際にどう役割分担し、どの成果を出したかは当該リリースだけでは分かりません。

3. 価値を「デザイン×エンジニアリング×業界知見」で分解する

デジタルデザイン・アプリ開発会社の価値は、三つの能力の掛け算で捉えると伝わりやすくなります。

1. デザイン：顧客・利用者の課題を見つけ、情報構造、体験、画面、ブランドとして具体化する力。
2. エンジニアリング：アイデアを安全・高速・保守可能なWeb・モバイル・データ基盤へ実装する力。
3. 業界知見：金融、メディア、消費財など固有の業務、規制、顧客行動、収益構造を理解する力。

デザインだけが強くても、実装可能性と運用品質が弱ければ事業成果へ届きません。開発だけが強くても、顧客の目的が曖昧なまま仕様を作れば手戻りが増えます。業界知見だけが強くても、新しい体験へ変換できなければ差別化できません。三つを連動させる工程と人材構成が買い手にとって重要です。

3-1. デザイン能力を検証可能にする

譲渡企業はポートフォリオを美しい画面集で終わらせず、顧客課題、調査、仮説、選択肢、意思決定、成果を示します。NDAで顧客名や画面を出せない場合は、業種、利用者規模、担当工程、期間、チーム、検証方法、定量・定性成果を匿名化します。

ユーザー調査では、対象者の選定、同意、録音・保管、謝礼、個人情報、分析方法を整理します。アクセシビリティ、デザインシステム、コンテンツ、ローカライゼーションも評価対象です。特定デザイナーの感性だけでなく、レビュー、リサーチリポジトリ、コンポーネント、判断記録に再現性があるかを示します。

3-2. エンジニアリング能力を案件成果へつなぐ

技術力は、使用言語やフレームワークの列挙ではなく、品質と事業成果で説明します。アーキテクチャ、コードレビュー、自動テスト、CI/CD、セキュリティ、可観測性、インシデント、リリース頻度、復旧時間を代表案件で追跡します。新規開発だけでなく、既存アプリのモダナイゼーションで、どのリスクを抑えながら移行したかも重要です。

買い手は、技術資産が顧客に帰属するのか、自社の再利用可能な基盤なのかを確認します。共通ライブラリ、テンプレート、デザインシステム、開発ツールがあるなら、権利、利用実績、保守責任、OSSライセンスを示します。属人的な「速い実装」を、見積もり精度、再利用、レビュー、障害低減へ翻訳します。

3-3. 業界知見を個人の経験から組織資産へ変える

金融など規制・セキュリティ要求の高い業界では、顧客業務、本人確認、決済、監査、データ保持、アクセシビリティを理解する力が参入障壁になります。メディアではコンテンツ運用、広告、購読、権利、ピークトラフィック、消費財ではコマース、会員、在庫、店舗、ブランド体験などが論点になり得ます。これは一般論であり、本件の個別案件内容を示すものではありません。

譲渡企業は、業界別の案件数、担当者、要件チェックリスト、失敗事例、再利用可能な知見をまとめます。顧客名や秘密情報を混ぜず、法令や契約の更新責任者を置きます。知見が一人の営業担当者だけにあるなら、提案レビュー、案件振り返り、研修で組織へ移します。

4. 戦略からサポートまでの「一気通貫」を証明する

公表資料では、Postlight側コメントとして、NTTデータとの連携により戦略・デザインからアプリケーション開発・サポートまで、よりトータルに支援できるとの趣旨が示されています。これは発表時点の期待であり、統合後の成果を保証するものではありません。

一般に一気通貫の価値は、工程を多く持つことではなく、工程間の損失を減らすことにあります。戦略で決めた成功指標がデザインへ入り、デザイン判断が技術制約と整合し、実装の計測データが運用改善へ戻る状態です。各工程を別チームが請負い、引き継ぎで背景が消えるなら、一社内にあっても分断されています。

譲渡企業は代表案件について、経営課題、KPI、ユーザー仮説、プロトタイプ、技術意思決定、バックログ、テスト、リリース、運用指標を一本のストーリーで示します。工程ごとの責任者、承認者、顧客参加、変更管理、粗利も示します。戦略・デザインが無償提案に埋もれていないか、サポートが契約化されず赤字になっていないかも分析します。

一気通貫の成熟度表

段階	状態	買い手へ示す証拠
1：個人連携	担当者同士の口頭調整	属人リスクと改善計画
2：工程定義	成果物と引き継ぎ条件がある	テンプレート、承認記録
3：共同チーム	デザイン・開発が同じKPIを持つ	バックログ、レビュー、データ
4：継続改善	運用データが次の戦略へ戻る	実験、リリース、成果推移

5. 顧客ポートフォリオ――ロゴではなく関係の深さを見る

著名顧客のロゴは強い印象を与えますが、許可なくM&A資料へ載せてはいけません。また、一度の小規模案件と長年の戦略パートナーは同じ価値ではありません。顧客別に、売上、粗利、取引年数、部署数、契約、更新、追加受注、担当者、満足、解約、支配権変更条項を整理します。

顧客集中が高い会社は、一社の予算変更で業績が揺れます。しかし集中自体が直ちに悪いわけではありません。複数部署との契約、長期サポート、受注残、経営層との関係、競争力が安定要因になります。譲渡企業はリスクと安定要因を両方出し、分散計画を示します。

デザイン会社では、プロジェクトが完成すると売上が途切れやすいため、リサーチ、プロダクト改善、デザインシステム、保守や分析を継続契約として提供できているかが重要です。継続売上の定義を固定し、単に翌年も別案件を受注した顧客と、契約上のリカーリング売上を分けます。

6. ポートフォリオとケーススタディの知財・守秘義務

買い手は代表実績を見たい一方、顧客とのNDAはM&Aだから自動的に解除されません。譲渡企業は、公開済み事例、匿名化可能、NDA後に限定開示、顧客承諾が必要、開示不可の五段階に分類します。画面、ユーザー調査、ソース、KPI、顧客名を別々に判断します。

ケーススタディには、課題、役割、方法、成果、学びを記載し、誇張を避けます。顧客側が作ったデータやブランド資産を自社の所有物のように扱いません。デザイナー個人のポートフォリオ利用許可と、会社が買い手へ開示できる権利も別です。

データルームでは、閲覧のみ、透かし、アクセスログ、ダウンロード制限を使い、競合する買い手候補へ顧客別価格や未公開製品を早期開示しないようにします。必要ならクリーンチームや顧客匿名コードを使います。

7. 人材価値――職種の足し算ではなく混成チームの力

デザイン・アプリ会社の人材は、ストラテジスト、リサーチャー、プロダクトデザイナー、コンテンツ、フロントエンド、モバイル、バックエンド、データ、QA、PM、営業など多様です。買い手は人数だけでなく、どの組み合わせで案件を完遂できるかを見ます。

匿名スキルマトリクスには、職種、レベル、担当工程、業界、技術、顧客折衝、レビュー、育成、稼働、報酬、勤続、契約区分を入れます。複数職種を横断する人は強みですが、一人に案件獲得・デザイン・技術判断が集中すると承継リスクです。代替者、副担当、文書化、引き継ぎ期間を示します。

買収後のリテンションは金銭だけで決まりません。作品の質、技術的挑戦、顧客との距離、裁量、評価、リモート、地域、ブランド、仲間が重要です。買い手の案件規模や安定性が魅力になる一方、承認階層、営業優先、標準化が不安になる場合があります。公表前から文化差を把握し、何を維持・変更するかを設計します。

8. 文化デューデリジェンス――言葉ではなく行動を比較する

「顧客中心」「品質重視」「自律」という言葉は多くの会社が使いますが、行動は異なります。デザイン案を誰が決めるか、顧客の無理な要求へどう対応するか、障害時に人を責めるか仕組みを直すか、売上と作品品質が衝突したとき何を優先するかを実例で確認します。

文化領域	双方への質問	PMIで決めること
顧客	反対意見をどう伝え、最終決定を誰がするか	エスカレーションと責任
デザイン	批評、リサーチ、アクセシビリティの基準	最低基準と裁量
技術	技術選定、レビュー、負債を誰が決めるか	アーキテクチャ統治
評価	売上、品質、育成、発信をどう認めるか	経過措置とキャリア
働き方	場所、時間、同期・非同期の使い分け	顧客要件との両立
発信	OSS、登壇、ブログ、ポートフォリオ	秘密保持とブランド

文化DDは優劣を決めるものではありません。顧客・法令・セキュリティに必要な統制と、創造性・速度に必要な自律性を領域ごとに調整する作業です。

9. ブランドを残すか統合するか

デザイン会社のブランドは、採用、顧客紹介、価格、作品の評判に影響します。買収直後に買い手ブランドへ統一すると安心感が増す場合もあれば、対象会社が持つ専門性とコミュニティ認知を失う場合もあります。常に残す、常に消すという正解はありません。

判断材料には、ブランド認知、指名受注、採用応募、顧客契約、商標、ドメイン、検索、地域性、買い手との重複があります。維持、エンドース型、段階統合、即時統合の四案で、顧客・人材・運営費への影響を比較します。公表資料のPostlightブランドがその後どう扱われたかを、本稿は当該発表だけから評価しません。

ブランド移行では、Webサイト、メール、提案書、契約、請求、アプリストア、ソーシャル、採用媒体、ポートフォリオ、商標を一覧化します。顧客へ名称変更だけを知らせるのではなく、担当、品質、データ、サポートの継続を説明します。

10. クロスボーダーM&Aで増える確認事項

本件は日本企業グループが北米子会社を通じ米国企業を買収する公表案件です。クロスボーダー取引では、国内取引に加え、法制度、税、通貨、雇用、個人情報、輸出管理、制裁、知財、保険、時差、言語が関係します。具体的な本件条件は非公表であり、以下は一般論です。

譲渡企業は米国の設立州、LLC契約、持分、税務上の扱い、従業員・請負人、福利厚生、訴訟、顧客契約を現地専門家と整理します。買い手が日本側だから日本の契約慣行だけで進むわけではありません。表明保証保険、エスクロー、競業避止の有効性、データ移転も地域に応じて検討します。

PMIでは、時差と言語が意思決定を遅らせます。会議を増やすだけでなく、決定ログ、文書の言語、応答時間、緊急連絡、地域ごとの権限を決めます。為替換算による業績変動と現地通貨での実態を分け、買い手の会計・予算へ統合します。

11. 財務・案件採算――価格非公表案件から倍率を作らない

Postlightの取得価格と財務数値は当該ニュースリリースでは公表されていません。したがって本件から売上倍率、利益倍率、デザイナー一人当たり価格を逆算することはできません。買収目的が戦略的に説明されていても、実際の価格にどの価値がどれだけ反映されたかは不明です。

一般の譲渡企業は、三期程度の決算、月次試算表、顧客別・案件別・サービス別売上と粗利を用意します。戦略、リサーチ、デザイン、開発、サポートの工数を案件へ配賦し、提案・無償作業・手戻りを含めた真の採算を出します。人月売上だけでなく、固定価格、準委任、リテイナー、保守、ライセンスの契約形態を分けます。

デザイン案件は初期の探索でスコープが変わりやすく、固定価格で抱えると採算が崩れます。発見フェーズを別契約にする、仮説と成果物を定義する、変更要求を記録する、開発へ進む承認ゲートを置くといった管理を説明します。開発では検収、技術負債、運用移行、保証対応を原価へ含めます。

正常収益力を説明する調整表

調整候補	必要な証拠	注意点
オーナー固有経費	元帳、領収書、事業関連性	買収後も必要なら足し戻さない
一時的な採用・移転	契約、請求、発生日	成長に毎年必要なら継続費用
無償提案の縮小	タイムシート、受注率	営業に必要な標準工数は残る
一過性の大型案件	契約、粗利、終了	除外後の基礎売上も示す
役員報酬	職務、市場水準	後任経営者コストを考慮
為替差	現地通貨・報告通貨	事業成長と換算影響を分ける

正常化は利益を大きく見せるためではなく、買収後も続く利益を同じ基準で理解するための作業です。不利な調整も含めて一貫させます。

12. 受注残とパイプラインの品質

サービス会社の将来価値では、受注残と営業パイプラインが重要です。しかし「見込み案件」を広く数えれば数字は大きくなります。譲渡企業は、リード、商談化、提案、口頭内示、契約済みを分け、契約済み金額と確率加重額を同列に扱いません。

案件ごとに顧客、担当、サービス、金額、粗利、開始、期間、契約状況、次の意思決定、競合、必要人材を記載します。デザインフェーズだけ受注し、開発は未定なら分けます。買収後に買い手の営業網で増えるかもしれない案件はシナジー仮説であり、対象会社単独の受注残には入れません。

過去二年程度のパイプラインから、ステージ別成約率、提案期間、失注理由、値引き、営業担当依存を分析します。創業者の紹介だけで受注するなら、共同営業、CRM、事例、アカウントプランへ関係を移します。著名案件の話題性だけでなく、安定して再現できる営業工程を示します。

13. 顧客契約デューデリジェンス

基本契約、個別契約、注文書、作業範囲記述書、変更注文、検収、保守、NDAを顧客別にひも付けます。クロスボーダー案件では準拠法、裁判地、通貨、税、制裁、輸出管理、データ移転も確認します。

特に見る条項は、支配権変更、譲渡禁止、解除、キーパーソン、再委託、知財、成果保証、損害賠償上限、補償、保険、セキュリティ、個人情報、監査、広報利用です。株主変更だけで契約が当然に続くとは限りません。顧客承諾が必要なら、秘密保持と公表日程を両立させます。

デザイン会社では「成果が顧客の期待と違う」という主観的な紛争が起きやすいため、成果物、レビュー回数、承認者、受入基準、変更管理を明確にします。アジャイル開発でも、スプリントの目的、バックログ所有、予算上限、終了条件を契約化します。

14. 知財――デザインとコードの権利境界

顧客案件のワイヤーフレーム、画面、デザインシステム、コピー、写真、フォント、アイコン、コード、共通モジュールが誰に帰属するかを確認します。成果物を顧客へ譲渡する契約でも、既存資産と汎用ノウハウを留保できる場合がありますが、契約ごとに異なります。

従業員と業務委託者から会社への知財帰属も重要です。外部デザイナー、フォトグラファー、コピーライター、開発者の契約に、利用範囲、改変、再許諾、地域、期間、著作者人格権への配慮があるかを確認します。買い手グループへ利用範囲が広がる場合、従来の許諾では足りない可能性があります。

フォント、ストック写真、アイコン、音源、動画、プラグインは、席数、顧客納品、埋め込み、譲渡、商用利用の条件を台帳化します。デザインツールやクラウドが個人名義なら法人アカウントへ移します。ポートフォリオ掲載許可と知財所有を混同しません。

15. OSS・コード・技術負債

OSS利用は通常ですが、ライセンス、バージョン、脆弱性、改変、配布形態を把握する必要があります。リポジトリごとにSBOMを作り、コピーレフト条件、著作権表示、ソース提供義務と顧客契約を照合します。退職者や外注者がコピーしたコードの混入も確認します。

技術負債はゼロと主張せず、セキュリティ、可用性、保守コスト、開発速度、顧客契約の軸で優先順位を付けます。古いフレームワーク、手動デプロイ、テスト不足、共有アカウント、暗号鍵の埋め込みを一覧にし、暫定策、恒久策、工数、期限を示します。

モダナイゼーション案件では、対象会社自身の開発基盤が時代遅れでないかも見られます。ただし最新技術へ全面書換えすることが常に正解ではありません。顧客価値、停止リスク、移行費を基に段階更改を説明します。

16. 情報セキュリティとプライバシー

金融、メディア、消費財などの顧客データを扱う会社では、買収によるアクセス主体の拡大が懸念されます。データフローに、収集目的、契約、保存場所、地域、アクセス、委託先、保持、削除を記載します。ユーザーリサーチの録音・映像、テスト参加者、行動分析、採用候補者も対象です。

セキュリティDDでは、MFA、端末、パッチ、秘密管理、権限、ログ、バックアップ、復旧、インシデント、委託先、保険を確認します。顧客環境へアクセスする場合、個人アカウント、共有ID、退職者、VPN、特権操作を点検します。

買収後に買い手のデータ基盤へ顧客情報をコピーするには、契約と目的を確認します。「同じグループになったから自由に共有できる」とは限りません。地域をまたぐ個人データ移転は、現地法と契約に従います。公表前後のアクセス変更をログへ残します。

17. 人事・労務とリテンション

雇用契約、就業規則、報酬、賞与、福利厚生、休暇、勤怠、残業、差別・ハラスメント、請負人の実態を確認します。米国では州・都市による制度差もあるため、現地専門家の確認が必要です。本件の個別人事条件は公表されていません。

キーパーソンは役員だけではありません。主要顧客のプロダクト責任者、デザイン批評を支えるリーダー、アーキテクト、採用責任者、ブランド発信者を含めます。各人の代替困難性、顧客売上、残留希望、報酬差、キャリア、引き継ぎを匿名化して整理します。

リテンションボーナスは選択肢ですが、役割と文化が合わなければ期限後に退職します。買い手の大規模顧客、専門家、グローバル案件という機会と、対象会社の裁量・ブランド・作品品質を両立させます。制度変更は即時統一せず、経過措置と質問窓口を設けます。

18. 企業価値を左右する「再現性」

デジタルサービス会社の高い成果が、一部の天才的な個人だけによるものなら、買い手は将来を割り引きます。再現性は創造性をマニュアル化することではありません。良い問い、批評、技術判断、顧客合意、品質保証を組織で繰り返せる状態です。

譲渡企業は、案件開始、リサーチ、コンセプト、プロトタイプ、デザイン批評、技術設計、見積もり、開発、QA、リリース、振り返りの最低基準を示します。テンプレートの存在だけでなく、代表案件で使われ、改善された証拠を出します。

再現性指標には、提案勝率、見積もり差異、デザイン承認までの反復、開発リードタイム、変更失敗率、障害復旧、継続受注、チーム入替後の品質があります。数字を競わせて創造性を損なわないよう、顧客成果と学びを併記します。

19. 売却準備ロードマップ

12〜18か月前：数値と権利を整える

顧客別・案件別の売上と粗利、タイムシート、受注残を整えます。顧客契約、知財、ポートフォリオ利用許可、OSS、個人データ、雇用を点検します。個人名義のGitHub、デザインツール、ドメイン、クラウドを法人へ移します。

6〜12か月前：属人性と継続性を改善する

主要顧客へ副担当を置き、デザイン批評と技術レビューを複数化します。無償提案、手戻り、サポートの工数を測り、価格と契約を直します。匿名スキル表、文化の行動例、ブランド指標を作ります。

3〜6か月前：データルームと候補先像を作る

財務、法務、顧客、人材、技術、知財、セキュリティを整理し、不備を是正済み・是正中・残存に分けます。買い手候補を価格、顧客、技術、文化、ブランド、地域、PMI能力で比較します。クロスボーダーの税・法務・データ移転を専門家と確認します。

交渉中：通常事業を守る

準備でデザイナーとエンジニアの稼働を奪いすぎず、窓口と週次時間を固定します。質問はQ&A台帳で管理し、未確認事項を推測で答えません。顧客・従業員への開示順を契約と実行確度に合わせます。

20. データルームの推奨構成

1. 会社・持分：設立、定款・LLC契約、持分、議事録、関連当事者。
2. 財務・税務：決算、月次、元帳、予算、資金、税、為替、保険。
3. 顧客・営業：契約、匿名案件台帳、受注残、粗利、集中、解約。
4. 人事：匿名人員、雇用・請負、報酬、勤怠、評価、退職、訴え。
5. ポートフォリオ：開示権限、事例、成果、顧客承諾、受賞・広報。
6. デザイン：工程、リサーチ、デザインシステム、素材ライセンス。
7. 技術：構成、リポジトリ、CI/CD、品質、負債、クラウド、運用。
8. 知財・OSS：帰属、商標、著作権、特許、SBOM、第三者素材。
9. セキュリティ・データ：規程、権限、事故、データフロー、委託先。
10. 法令・紛争：許認可、訴訟、クレーム、輸出・制裁、保険。
11. ブランド・文化：ブランド指標、商標、文化比較、発信ルール。
12. PMI：Day1、顧客通知、人材面談、権限、ブランド、90日指標。

ファイル名に番号、対象期間、版を付け、アクセスと更新を記録します。個人情報、顧客名、ソース、価格は段階開示し、競合候補への情報流出を防ぎます。

21. 買い手候補へ示すシナジーマップ

シナジーは「クロスセルできる」で終わらせず、顧客、課題、責任者、能力、投資、時期、収益へ落とします。公表資料の文脈から一般に考えられるのは、デザイン・アプリ開発・モダナイゼーション・業界対応・グローバルデリバリーの組み合わせですが、本件の実績を断定するものではありません。

組み合わせ	顧客価値の仮説	検証すること
戦略×デザイン	経営課題を体験へ変換	顧客責任者、意思決定、単価
デザイン×開発	引き継ぎ損失と手戻りを削減	混成チーム、共通KPI、粗利
新規開発×モダナイゼーション	既存資産を安全に刷新	移行方法、停止、データ、運用
業界知見×技術	規制・業務に合う体験	専門家、法令、再利用性
現地顧客×グローバル体制	規模と速度を拡張	時差、品質、契約、データ

譲渡企業単独で実現できる価値と、買い手の資源があって初めて生まれる価値を分けます。シナジーの実現に買い手側の営業・採用・統合費用が必要な場合、その全額を譲渡価格に反映できるとは限りません。一方、具体的な顧客需要と再現性があれば交渉材料になります。

22. 買い手候補スコアカード

評価軸	面談で確認すること	重み例
顧客価値	既存顧客と新規市場へ何を提供するか	20
人材・文化	評価、裁量、作品品質、働き方を守れるか	20
技術・デザイン	両機能を対等に扱い、投資するか	15
ブランド	維持・統合の根拠と移行計画があるか	10
クロスボーダー	現地での権限設計、言語対応、法務、データ管理の経験があるか	15
PMI能力	Day1責任者、過去経験、90日指標があるか	10
経済条件	価格、調整、税、補償を含む実質条件	10

提示価格だけでなく、買い手の現場責任者が具体的に答えるか、対象会社の弱みも現実的に扱うかを記録します。PMI担当者と譲渡企業のデザイン・技術リーダーが契約前にDay1案を作ると、相性と実行力が見えます。

23. 株式・持分取得と事業譲渡の比較

観点	会社・持分の取得	事業譲渡
承継単位	法人、契約、資産負債を含む	選定した資産・契約等
顧客契約	法人に残り得るが支配権変更に注意	原則個別承継の同意が必要
人材	雇用主である法人は、原則として変わりません	転籍・新契約が必要になりやすい
知財・ブランド	法人に残るが権利確認は必要	個別の移転・許諾を設計
潜在債務	会社に残る	承継範囲を選べるが例外あり
手続き・税	法域と会社形態で異なる	資産・契約・税の個別論点が多い

本件の詳細スキームは公表リリースの表現を超えて推測しません。一般の譲渡企業は、全体を一つのブランド・チームとして承継するか、特定事業だけを切り出すか、株主・税・契約・許認可とともに比較します。

24. PMI Day1・30・60・90日計画

クロスボーダーのデザイン・開発会社では、クロージング直後に制度とブランドを一気に統一すると、人材と顧客の信頼を失いかねません。最初の目的は、顧客サービスを止めず、重要人材が自分の役割を理解し、データと権限を守ることです。

Day1：継続、安心、責任者

• 取引目的、経営体制、当面の雇用・報酬・勤務地・ブランドを説明する。
• 顧客、従業員、請負人が質問できる窓口と回答期限を示す。
• 主要顧客へ担当、契約、データ、請求、サポートの継続を説明する。
• 直近のリサーチ、ワークショップ、リリース、障害対応、給与、請求を守る。
• GitHub、クラウド、デザインツール、ドメイン、監視の管理者を二重化する。
• 地域別の緊急連絡、意思決定権、インシデント指揮を確定する。

初日の全社説明では、決まったことと未決事項を分けます。「評価制度は90日間検討し、当面現制度を維持する」のように、移行期と責任者を示します。買い手の規模を宣伝するだけでなく、対象会社の強みをなぜ残すのかを説明します。

2〜30日：事実と約束をそろえる

• 全キーパーソンと個別面談し、役割、希望、懸念、残留リスクを把握する。
• 顧客別の契約、受注残、粗利、支配権変更、説明状況を再確認する。
• デザイン・コード・素材・ポートフォリオの権利と利用範囲を確認する。
• クラウド、リポジトリ、SaaS、データ、請求の権限を棚卸しする。
• 文化比較を行い、維持、変更、試行の三分類を作る。
• 会計、予算、稟議、セキュリティの最低限のグループ要件をそろえる。

この期間は買収前の仮説を検証する時間です。デザインとエンジニアリングの関係、案件採算、顧客の期待を現場から聞き、買い手標準を無条件に適用しません。逆に、重大なセキュリティや法令違反は文化を理由に先送りしません。

31〜60日：小さな共同案件で試す

• 戦略・デザイン・開発を組み合わせる候補案件を一つ選ぶ。
• 顧客同意、責任者、契約、価格、知財、データを先に決める。
• 混成チームで共通KPI、批評、技術レビュー、リリース基準を試す。
• 買い手の営業紹介を限定実施し、既存顧客の安心を損なわないか確認する。
• ブランド表記と提案書を試行し、顧客・採用への反応を見る。

共同案件の指標は売上だけではありません。顧客満足、見積もり差異、デザイン承認、手戻り、リリース、障害、チーム負荷を測ります。時差会議が増えたなら、非同期決定ログと地域権限を調整します。

61〜90日：組織、予算、ブランドへ落とす

• デザイン、技術、業界、営業の恒久責任者と権限を決める。
• 評価制度とキャリアの移行案を説明し、経過措置を示す。
• 共同オファリングの対象顧客、価格、品質、収益、投資を決める。
• ブランドの維持・統合方針と一年の移行計画を承認する。
• 技術負債、データ、契約、権利の100日以降計画を予算化する。
• 顧客、人材、品質、文化を含む一年目の指標を取締役会へ報告する。

90日指標の例

顧客の更新・解約、案件別の粗利差異、重大障害、デザイン・開発の手戻り、キーパーソンの定着、全社の退職状況、面談実施状況、権限の棚卸し、知財確認、未解決のDD項目、共同案件数、ブランド名での問い合わせ、採用応募数を追跡します。短期売上だけでPMIを評価しません。

25. クロスボーダーPMIの実務ルール

決定権を地域と領域で分ける

すべてを本社承認にすると速度が落ち、すべてを現地任せにすると統制が効きません。顧客提案、値引き、採用、技術、デザイン、セキュリティ、契約、広報について、金額・リスク別の権限表を作ります。緊急障害は現地が即応し、重大法務はグループへ上げるなど例外を定めます。

文書と言語を決める

会議の同時通訳だけでは背景が失われます。重要決定は短い文書で、目的、選択肢、決定、責任者、期限を残します。原文言語と公式訳を決め、技術用語・契約用語の用語集を作ります。翻訳待ちで顧客対応を止めない権限も必要です。

会議負荷を測る

時差をまたぐ定例が増えると、デザイン・開発時間が削られます。会議目的、参加者、決定、時間帯を見直し、非同期レビューへ変えます。特定地域だけが常に早朝・深夜にならないよう交代します。会議時間を案件原価と組織コストの双方で把握します。

財務を二つの通貨で見る

現地通貨の売上・粗利・人件費と、グループ報告通貨への換算影響を分けます。為替で売上が増えても現地事業が成長したとは限りません。逆に換算で減っても現地顧客・粗利が改善している場合があります。予算レートと実績レートを明記します。

26. ブランド統合の四つの選択肢

独立ブランド維持

対象会社名、サイト、採用、提案を維持し、グループ所属を説明します。専門性とコミュニティ信頼を守りやすい一方、重複費用、顧客のグループ理解、ガバナンスを整える必要があります。

エンドース型

対象会社ブランドに「買い手企業グループの一員」などの承認表記を付けます。専門ブランドと買い手の信頼を両立しやすい一方、表記・商標・提案のルールが複雑になります。

段階統合

一定期間後に買い手ブランドへ移します。顧客、従業員、検索、契約、ドメインを計画的に移せますが、移行の不確実性が長引かないよう期限と条件が必要です。

即時統合

早く一体運営できますが、指名受注、採用、作品の評判を失う可能性があります。法的名称、契約、メール、ポートフォリオ、検索への影響を事前に測ります。

選択はブランド認知、顧客要求、商標、採用応募、統合費、買い手戦略で決めます。譲渡企業は買収前に、指名問い合わせ、オーガニック流入、採用応募、単価、メディア掲載を基準値として保存します。

27. 譲渡企業が使えるリスク判断表

論点	価値への影響	実行への影響	売却前の対応
上位顧客への集中	高	高	更新・関係の証拠、副担当、分散
創業者だけが受注	高	高	CRM、共同営業、アカウント計画
デザインの権利を社外の個人が保有	高	高	譲渡・許諾、素材台帳、差替え
ポートフォリオ開示権が不明	中	高	顧客承諾、匿名化、段階開示
デザインと開発の採算混在	高	中	工数コード、工程別粗利
顧客環境を共有IDで操作	高	高	個人ID、MFA、最小権限、ログ
OSS台帳がない	中	高	SBOM、ライセンス・脆弱性確認
重要人材の報酬が市場以下	高	中	市場比較、役割、リテンション
ブランド統合方針が未定	高	中	四案の顧客・採用影響を比較
時差会議が多い	中	中	非同期、地域権限、交代制
価格・財務データが粗い	高	高	月次、案件粗利、正常化
データ越境が不明	高	高	データフロー、契約、現地法

優先度は影響、発生確率、是正時間で決めます。顧客承諾や知財契約は相手方調整が必要で長くかかるため早く始めます。ツール統合など買収後の方が合理的な項目は、無理に売却前へ変更せず計画を示します。

28. 三つの譲渡企業シナリオ

シナリオA：作品は強いが、案件採算が見えない

著名なデザイン実績はあるものの、リサーチ、提案、批評、開発の時間が計測されず、粗利が不明な会社です。直近12〜24か月のカレンダー、タイムシート、外注請求を案件へ再配賦します。精度に限界があれば推計方法を示します。品質を損なわずに、無償の修正作業の繰り返しを減らせる契約条件と承認手続きを導入します。

シナリオB：開発力は強いが、戦略とデザインが一人に依存

創業者が顧客課題を聞き、コンセプトと画面を決め、エンジニアへ渡す会社です。副担当を顧客面談へ同席させ、リサーチ、デザイン批評、意思決定ログを組織化します。創業者の残留期間を漫然と長くせず、顧客移管、後継育成、ブランド発信など完了条件を定めます。

シナリオC：海外買い手の規模は魅力だが文化差が大きい

大規模案件と販売網は魅力でも、承認、評価、リモート、発信が対象会社と大きく違う場合です。契約前に混成チームの模擬案件、文化比較、PMI責任者面談を行います。法令・セキュリティの最低統制と、デザイン批評・技術実験の裁量を分け、90日試行を約束します。

29. よくある失敗と改善

失敗1：有名顧客ロゴを許可なく資料へ載せる

M&A資料も外部開示です。顧客契約と広報許可を確認し、匿名化や段階開示を使います。買い手の信頼を得るために、顧客からの信頼を損なってはいけません。

失敗2：デザインを主観、開発を人月だけで説明する

デザインは課題・方法・成果・再現性で、開発は品質・速度・運用で説明します。両者を同じ顧客KPIへつなぎます。

失敗3：クロスセルを売却価格へ全額加える

買い手の顧客・営業・投資が必要な価値は共同創出です。対象会社単独、具体化した共同案件、長期仮説を分けます。

失敗4：ブランドを感情だけで残したいと主張する

指名受注、採用、検索、価格などの証拠と、維持費・統合効果を比較します。ブランドは目的ではなく顧客・人材価値の手段です。

失敗5：DDで技術負債を隠す

後日発覚すると価格・契約・信頼へ響きます。負債を一覧化し、影響、優先度、工数、暫定策を示します。

失敗6：Day1に全ツールと制度を統一する

顧客対応と創造性が止まります。重大リスクを先に直し、その他は小さく試して90日以降へ段階化します。

30. M&A準備の月次ダッシュボード

財務、顧客、人材、品質、ブランドを毎月同じ定義で追います。資料作成のためだけに数字を集めず、経営会議で判断に使います。

領域	指標例	意味
財務	案件粗利、継続売上、受注残、回収	将来利益と資金
顧客	集中、更新、追加受注、解約、満足	関係の安定
デザイン	承認反復、調査、アクセシビリティ	工程と品質
技術	リードタイム、失敗率、復旧、脆弱性	提供能力
人材	稼働、採用、退職、代替率、育成	承継可能性
ブランド	指名、検索、応募、掲載、単価	無形価値

受注残、継続売上、重大障害などの定義を途中で変えたら注記し、過去比較を調整します。会計、CRM、勤怠、チケット、分析の元データへつながるようにします。

31. 売却前の実務チェックリスト

経営・財務

• 売却目的、時期、創業者の残留、ブランド希望を株主で合意した。
• 三期決算、最新月次、顧客・案件・工程別粗利がそろう。
• 受注残とパイプラインの定義、確度、粗利が説明できる。
• 正常化調整に証拠があり、不利な項目も含めた。
• 独立計画と買い手シナジーを分けた。

顧客・契約

• 基本、個別、変更、検収、保守、NDAを顧客別にひも付けた。
• 支配権変更、解除、再委託、知財、データ、責任を抽出した。
• 上位顧客の更新、担当、説明時期、承諾要否を確認した。
• 赤字、遅延、クレーム、障害を対応策とともに整理した。
• ポートフォリオ開示を顧客・画面・成果別に分類した。

人材・文化・ブランド

• 匿名スキル表に職種、工程、業界、稼働、代替を記載した。
• キーパーソンの残留リスクと引き継ぎ計画がある。
• デザイン・技術・営業の意思決定を複数化した。
• 買い手との文化差を行動例で比較した。
• ブランド指名、採用、検索、商標を数値化した。

デザイン・技術・知財

• 顧客成果物、自社資産、第三者素材の権利を区別した。
• 外部デザイナー・開発者との知財契約を確認した。
• フォント、写真、アイコン、プラグインの利用条件がある。
• SBOM、OSS、脆弱性、技術負債台帳がある。
• GitHub、クラウド、SaaS、ドメインは法人管理でMFAを使う。
• バックアップ、リリース、ロールバックを実地確認した。

クロスボーダー・PMI

• 現地法、税、雇用、データ、輸出・制裁を専門家と確認した。
• 通貨と換算影響を分けて計画した。
• Day1の顧客、従業員、権限、緊急連絡を準備した。
• 地域・領域別の決定権と文書言語を決めた。
• 90日指標に顧客、人材、品質、ブランドを含めた。

32. 本事例から得られる七つの教訓

第一に、デジタルデザイン会社の価値は画面ではなく、顧客課題から運用改善までの一連の能力です。第二に、デザイン、エンジニアリング、業界知見を、個人ではなく混成チームと工程で示す必要があります。第三に、著名顧客とポートフォリオは、守秘義務と利用許可を守って初めて価値になります。

第四に、買い手の既存能力との組み合わせは重要ですが、本件の個別シナジー実績は公表資料から断定できません。第五に、クロスボーダーPMIでは法務・税だけでなく、時差、言語、決定権、通貨を設計します。第六に、ブランドは感情ではなく顧客・採用・検索の指標で維持・統合を判断します。第七に、Day1は統一ではなく継続、30日は事実確認、90日は検証済みの仮説を組織と予算へ落とす期間です。

33. デザインデューデリジェンスの進め方

デザインDDは、ファイル数や受賞歴を数えるだけではありません。代表案件を三〜五件選び、顧客課題、リサーチ、仮説、批評、意思決定、実装、リリース後の学びを追跡します。成功案件だけでなく、方向転換した案件、成果が出なかった案件も見ると、学習力が分かります。

最初に経営者とデザイン責任者へ、顧客が何を買っているのかを別々に聞きます。回答が「画面制作」「課題発見」「組織変革」など大きく違う場合、事業定義が統一されていません。次にデザイナーとエンジニアへ同じ案件の成功条件を聞き、共通KPIがあるかを確認します。

リサーチでは、参加者募集、同意、個人情報、録音、分析、インサイトの保存を見ます。デザインでは、アクセシビリティ、ブランド、コンテンツ、コンポーネント、レスポンシブ、多言語を見ます。実装では、デザイン仕様とコードの差、QA、ユーザビリティテスト、計測を見ます。成果は売上や転換だけでなく、タスク完了、離脱、問い合わせ、運用工数など案件に合う指標で評価します。

デザインシステムがある場合、コンポーネント数ではなく採用率、重複削減、更新、ガバナンス、アクセシビリティ、コードとの同期を確認します。顧客固有システムを別顧客へ再利用できるとは限らないため、権利を分けます。社内方法論も、名前だけでなく研修、テンプレート、案件適用、改善履歴を示します。

34. モダナイゼーション案件の隠れたリスク

公表資料はアプリケーション開発・モダナイゼーション領域を戦略文脈に置いています。一般にモダナイゼーションは、新規アプリを一から作るより、既存業務、データ、外部連携、停止制約を引き継ぐ難しさがあります。譲渡企業は「新しい技術に書き換えた」だけでなく、安全な移行能力を示します。

確認項目は、現行資産の棚卸し、依存関係、データ品質、ピーク、SLA、並行稼働、切替、ロールバック、ユーザー教育、廃止です。古いシステムの仕様がない場合、ログ、コード、利用者インタビューから現状を復元します。すべてを一度に置換せず、ストラングラーパターンなど段階移行を使う場合は、期間中の二重運用コストを計算します。

固定価格で未知の負債を引き受けると赤字になりやすいため、発見フェーズ、仮説、除外、変更管理を契約に反映します。買い手は過去の見積もり差異、データ移行事故、停止、顧客追加費用を確認します。譲渡企業は失敗を隠さず、原因と再発防止を示します。

モダナイゼーションの価値は移行完了だけでなく、運用費、リリース速度、障害、セキュリティ、顧客体験の改善で測ります。基準値がなければ成果を証明できないため、開始時に現行指標を保存します。

35. 顧客コミュニケーションの段階設計

取引前にすべての顧客へ知らせると情報漏えいの危険があり、成立後まで必要承諾を取らなければ契約違反になり得ます。契約を確認し、顧客を四つに分類します。

1. 支配権変更に事前承諾が必要な顧客。
2. 成立前または成立時の通知が必要な顧客。
3. 法的義務はないが関係維持のため早期説明すべき主要顧客。
4. 公表後の一斉案内で対応できる顧客。

説明者は、対象会社の関係責任者を中心にし、買い手側は顧客が求める範囲で同席します。内容は、法人・契約、担当、サービス、データ、セキュリティ、請求、サポート、ブランドです。将来シナジーを先に売り込まず、既存の約束を守ることを説明します。

顧客から「担当者は残るか」と聞かれた場合、本人確認のない断言は避け、当面の体制と代替計画を示します。「価格は上がるか」には契約期間と更新方針を説明します。「データが日本へ移るか」には実際のデータフローと契約を答え、分からなければ確認期限を示します。

説明後は顧客懸念、追加質問、承諾、次回連絡をCRMへ記録します。解約兆候を売上だけでなく、会議参加、提案停止、サポート不満から捉えます。公表後90日は経営層が主要顧客レビューへ参加します。

36. 表明保証・補償と開示

会社・持分の取得契約では、持分、財務、税務、契約、人事、知財、訴訟、法令、セキュリティなどについて譲渡企業が表明保証をすることがあります。具体的内容、期間、上限、免責、知識限定は案件ごとに異なり、本件の条件は公表されていません。

譲渡企業は、DDで資料を見せたことと契約上適切に例外開示したことが同じとは限らない点に注意します。開示スケジュールに、顧客クレーム、権利不明素材、請負人、OSS、事故、税務、訴訟を具体的に記載し、データルームのファイル番号と結びつけます。クロージングまでに新しい事実が生じたら更新手順に従います。

問題を開示すれば必ず取引が中止されるわけではありません。範囲を測り、是正し、残るリスクを価格、前提条件、補償、保険で分配できる場合があります。隠すと、後の補償と信頼喪失が大きくなります。現地と日本の専門家が同じ論点表を共有します。

37. 100日以降の一年計画

90日で文化とブランドまで完成させる必要はありません。第2四半期は、顧客・人材の安定、権限・契約・技術負債の重大課題を優先します。第3四半期は、共同オファリングと混成チームを限定拡大し、評価制度を段階移行します。第4四半期は、実績に基づき翌年度の組織、ブランド、採用、技術投資を決めます。

一年後には、買収前の仮説を検証します。戦略からサポートまでの案件が増えたか、見積もりと粗利は改善したか、既存顧客は継続したか、デザイン・技術人材は残ったか、ブランド指名と採用はどう変わったか、時差・承認の負荷は許容範囲かを確認します。

未達を対象会社の責任だけにせず、買い手が約束した営業紹介、予算、現地権限、採用、技術基盤が実行されたかも見ます。シナジーは双方の行動で生まれます。取締役会報告に売上だけでなく顧客、人材、品質、ブランドを含めます。

38. M&Aを見送る条件を先に決める

交渉が進むほど、投入した時間を理由に成立させたくなります。譲渡企業は価格以外の撤退条件を株主で決めます。顧客秘密の不適切な開示要求、データ越境の根拠欠如、重要人材の尊重不足、ブランド価値を検証せず即時廃止する方針、資金・社内承認の不確実性、無限定の責任などです。

条件を「即撤退」「期限付き是正」「価格・契約で分配」に分けます。文化差は試行と経過措置で解けるかもしれません。素材権利の一部不備は差替え可能かもしれません。顧客承諾が得られない主要契約は価格と取引目的へ重大な影響があります。

見送った場合、秘密資料、ソース、個人情報の返却・削除、接触・勧誘、秘密保持を確認します。準備で整えた案件採算、契約、知財、権限、ダッシュボードは独立経営にも有効です。売らない選択も含め、企業価値を高める準備として進めます。

39. 経営者面談で準備する質問

買い手は経営者の一貫性と現実認識を見ます。次へ、結論、数字、根拠、未確定、対策の順で答えます。

1. なぜ今売却し、独立継続の制約は何か。
2. 顧客は何を理由に自社を選び、誰がその関係を持つか。
3. デザインと開発はどのKPIと工程で連携するか。
4. 上位顧客が離れる条件と、支配権変更条項は何か。
5. 代表ポートフォリオを開示・利用する権利はあるか。
6. 外部デザイナー・開発者の成果物は会社に帰属するか。
7. 最大の技術負債、セキュリティ、データ越境リスクは何か。
8. 誰が退職すると顧客、品質、ブランドが損なわれるか。
9. 買収後も残したい文化と、改善したい仕組みは何か。
10. ブランドを残す根拠を数値で示せるか。
11. 創業者の残留期間、役割、完了条件は何か。
12. 買い手の既存能力と具体的に何を組み合わせられるか。

「全員残る」「問題はない」「顧客は承諾する」と断定せず、確認範囲と計画を示します。分からないことは確認期限を約束し、Q&A台帳へ残します。

40. よくある質問

Q1. デザイン会社は利益が小さくても売却できますか

可能性はありますが、利益が小さい理由と将来価値を証拠で示す必要があります。先行採用、無償提案、不採算案件、単価、稼働、経営者報酬を分け、正常収益力を整理します。顧客、受注残、人材、ブランド、知財が将来キャッシュフローへどうつながるかを説明してください。

Q2. 取得価格非公表のPostlight案件から相場を推定できますか

できません。取得価格、財務、持分条件、現預金・負債、契約、将来計画が公表されていないため、倍率を逆算できません。本件は、デザイン・アプリ開発・業界対応をどう戦略的に説明したかを学ぶ材料です。

Q3. 有名企業との実績があれば高く評価されますか

顧客名だけでは決まりません。契約規模、粗利、継続、部署の広がり、再受注、支配権変更、担当者依存を見ます。顧客名と画面をM&A資料へ使えるかは契約・許可を確認し、無断掲載しないでください。

Q4. 顧客名を出せない場合、ポートフォリオをどう示しますか

業種、利用者規模、課題、担当工程、期間、チーム、方法、成果を匿名化します。公開済み、匿名、NDA後、顧客承諾、開示不可に分類し、検討段階に応じて出します。ソースや未公開画面は閲覧制限を使います。

Q5. デザインの価値を数値で説明できますか

すべてを一つの数値にする必要はありません。タスク完了、転換、離脱、問い合わせ、アクセシビリティ、承認反復、開発手戻り、継続受注など、案件の目的に合う指標を使います。基準値、施策、結果、他要因を分けます。

Q6. 開発会社がデザイン機能を持てば必ず評価が上がりますか

機能があるだけでは足りません。顧客課題から入れるか、デザインと技術が共通KPIを持つか、工程別採算が見えるか、人材が残るかを確認します。名前だけのデザイン部門や無償提案に埋もれる機能は価値が限定されます。

Q7. モダナイゼーション実績はどう示しますか

旧技術を新技術へ変えた説明だけでなく、現状分析、依存関係、データ移行、並行稼働、切替、ロールバック、停止、運用費、リリース速度の改善を示します。未知の仕様と追加作業を契約でどう管理したかも重要です。

Q8. 創業者は売却後すぐ退任できますか

個別交渉です。顧客、デザイン批評、技術判断、ブランドが創業者に依存するほど、一定期間の引き継ぎを求められやすくなります。期間だけでなく、顧客移管、後継育成、権限、完了条件を定めます。

Q9. 従業員へM&Aをいつ伝えるべきですか

取引の確実性、秘密保持、労務、退職リスクを踏まえて設計します。伝える時には、目的、当面の雇用・報酬・勤務地・ブランド、未決事項、相談窓口、次回回答日を用意します。国・地域の法令と慣行も確認します。

Q10. 全員が残ると買い手へ約束してよいですか

本人の意思確認なしに約束すべきではありません。匿名化した残留リスク、役割、報酬差、キャリア、代替・引き継ぎを示します。買い手との個別面談や金銭施策は、秘密保持、公平性、労務を踏まえて進めます。

Q11. ブランドは必ず残すべきですか

必ずではありません。指名受注、採用応募、検索、単価、評判を測り、独立、エンドース、段階、即時統合を比較します。買い手ブランドの信頼と販売力も価値です。顧客と人材への影響を根拠に決めます。

Q12. 個人のBehanceやGitHubに作品・コードがあります

ポートフォリオ掲載許可、会社・顧客の知財、秘密保持を確認します。会社管理の成果物と個人発信を分け、退職後の掲載条件も整理します。個人GitHubに会社の本番コードや鍵を置かず、法人組織へ移管します。

Q13. フォントや写真のライセンスもDD対象ですか

対象です。顧客納品、Web埋め込み、アプリ、グループ利用、改変、地域、席数が許諾範囲かを確認します。個人契約の素材を会社資産と考えず、台帳化し、不足は追加購入または差替えします。

Q14. OSSを使うと評価が下がりますか

OSS利用自体は一般的です。ライセンス、バージョン、脆弱性、改変、配布形態を把握し、顧客契約と整合しているかが重要です。SBOM、スキャン、更新責任、是正計画を用意します。

Q15. クロスボーダー買い手の利点とリスクは何ですか

新しい顧客、地域、専門家、案件規模へアクセスできる可能性があります。一方、時差、言語、法務・税、データ移転、為替、承認、文化が複雑になります。現地権限、文書、緊急連絡、評価、ブランドを契約前から設計します。

Q16. 買い手の顧客へすぐクロスセルできますか

自動的にはできません。顧客の課題、契約、情報利用、営業責任、提供人材、価格、品質を確認します。まず小さな共同案件で検証し、既存顧客サービスを悪化させない範囲で拡大します。

Q17. アーンアウトでシナジーを価格へ反映できますか

選択肢ですが、指標、会計方針、買い手の費用配賦、案件振替、営業支援、予算、権限を明確にします。譲渡企業が制御できない条件で未達になる設計を避けます。売上だけでなく粗利と顧客品質も考慮します。

Q18. 売却準備で最初にそろえる資料は何ですか

決算・最新月次、株主・持分、上位顧客、案件別売上・粗利、受注残、組織・匿名スキル、主要契約、知財・ポートフォリオ権利、技術・権限、売却目的です。不備があっても、何がないかを把握することから始めます。

Q19. 事業譲渡と会社売却のどちらがよいですか

会社全体の顧客・人材・ブランドを一体承継するか、特定事業だけを切り出すかで変わります。契約承継、従業員、知財、潜在債務、税、法域を比較し、現地専門家と検討します。常に一方が有利という一般則はありません。

Q20. 技術負債を売却前にすべて直すべきですか

すべてを直す必要はありません。セキュリティ、停止、契約違反に直結するものを優先し、残りは影響、工数、暫定策、期限を示します。買い手基盤と統合した方が合理的な項目もあります。未知の状態を減らすことが重要です。

40-1. 代表案件を一枚で説明するケースシート

買い手が数十件の作品を短時間で理解するには、案件ごとに同じ項目を持つケースシートが有効です。見た目を競う資料ではなく、顧客課題から事業成果までを比較できる形にします。

最初に、顧客の業界、対象利用者、プロダクト、契約期間、金額帯、担当範囲、チームを匿名で記載します。次に、開始時の課題と基準値、顧客が期待した成果、対象会社が提案した仮説を書きます。調査、ワークショップ、プロトタイプ、設計、実装、テスト、リリース、サポートのうち担当した工程を明示します。

意思決定欄では、採用案だけでなく捨てた案と理由を残します。たとえば利用者調査で当初仮説を修正した、技術制約により操作を変えた、アクセシビリティ基準のため表現を見直した、といった判断です。これにより、成果が偶然ではなく方法から生まれたことを示せます。

成果欄では、顧客が公開を許した定量指標と、匿名化した定性成果を分けます。数字がない場合に作らず、顧客承認、運用負担、学びを説明します。売上増加など対象会社だけに帰属できない成果は、他施策や市場要因を注記します。最後に、案件粗利、見積もり差異、手戻り、追加受注、再利用した知見、改善点を内部版へ記載します。

ケースシートには開示区分を付けます。顧客名、ロゴ、画面、ユーザー発言、KPI、コードをそれぞれ、公開、匿名、NDA後、承諾後、不可に分類します。買い手候補がアクセスした版を記録し、後から守秘範囲を追跡できるようにします。

40-2. 顧客別収益のブリッジを作る

全社売上が伸びていても、既存顧客の縮小を新規大型案件で埋めただけかもしれません。顧客別に、前年売上から更新、追加、値上げ、縮小、解約、新規を橋渡しするブリッジを作ります。現地通貨と報告通貨を分け、為替影響を独立させます。

顧客ごとに、戦略、デザイン、開発、サポートの売上と粗利を並べると、関係の広がりが見えます。デザインから開発へ進む率、開発からサポートへ続く率、同一顧客の別部署へ広がる率を測ります。ただし、契約のない見込みを継続売上へ含めません。

粗利悪化の原因を、単価、稼働、役割構成、外注、無償反復、仕様変更、再作業、クラウド費へ分けます。顧客との関係が良くても、無償作業で利益が出ないなら持続しません。値上げだけでなく、発見フェーズの別契約、レビュー上限、変更注文、チーム構成の改善を検討します。

買い手へは上位顧客だけでなく、顧客コホートを示します。初回受注年ごとに、その後何年取引し、売上・粗利がどう変わったかを見ます。一部の成功顧客ではなく、営業・提供モデル全体の再現性を判断できます。解約顧客の理由を、予算、品質、担当変更、競合、内製化、買収などに分類し、再発防止を示します。

40-3. 人材キャパシティと案件需要をつなぐ

デザイン・開発会社では、受注だけ増えても適切な人材がいなければ品質が落ちます。職種・レベル別に、FTE、顧客稼働、社内投資、休暇、採用予定を月次で並べ、受注残の必要人月と重ねます。平均稼働率だけでは、特定のシニアやモバイル技術が不足する問題を見落とします。

案件ごとに必要な役割を、戦略、リサーチ、デザイン、PM、Web、モバイル、バックエンド、QA、運用へ分けます。開始月、ピーク、終了、引き継ぎを記載します。複数案件へ同じキーパーソンを二重計上していないかを確認します。買収後の共同案件も、営業仮説と契約済みを分けます。

採用計画は入社人数だけでなく、募集、面談、承諾、入社、オンボーディング、案件配属までの時間を反映します。新入社員を初月から100％請求可能としません。メンター時間、採用担当、学習ツールを含めます。離職シナリオでは、キーパーソン、平均、下振れを分けます。

買い手との統合でグローバルデリバリーを使う場合、単価差だけで判断しません。顧客契約、データ地域、言語、時差、引き継ぎ、品質レビュー、責任者を含む総コストを試算します。対象会社の高付加価値工程と他拠点の実装を組み合わせるなら、要件・デザイン背景が失われない共同工程を設計します。

40-4. Day1に使う具体的な運営台帳

Day1計画をスライドだけで終わらせず、責任者と証跡を持つ台帳にします。列には、領域、タスク、法的期限、実施日、対象者、責任者、承認者、依存関係、状態、証跡リンク、問題、次回確認を置きます。

顧客台帳は、通知・承諾、説明者、質問、契約・請求変更、データ、次回会議を追います。人材台帳は、説明参加、個別面談、役割、アクセス、懸念、回答期限を追います。権限台帳は、GitHub、クラウド、SaaS、ドメイン、銀行、給与、ストア、監視の旧・新管理者、MFA、ログ、ロールバックを追います。

技術台帳は、直近30日のリリース、凍結期間、重大障害、証明書期限、バックアップ、ベンダー更新を記載します。財務台帳は、給与、請求、支払、税、銀行、為替、締めを記載します。広報台帳は、公式発表、Web、SNS、顧客文、採用候補者、メディア問い合わせの承認者を定めます。

台帳は個人情報と顧客秘密を含むため、全員へ開放しません。領域別に最小権限を設定し、経営統合責任者が全体進捗を見ます。完了条件を「連絡した」ではなく「承諾書を保存」「新管理者で復旧を実証」のように証拠で定義します。未完了を赤く見せるだけでなく、顧客停止・法令・人材・財務の重大度で優先します。

40-5. 独立継続・統合・下振れの三計画

譲渡企業の事業計画は、買い手の力がなくても実行できる独立継続ケースを基礎にします。既存顧客、契約済み受注、現在の採用能力、確保済み資金だけで、売上、粗利、人員、投資、資金繰りを作ります。口頭内示や買い手紹介を確定売上へ入れません。

統合ケースでは、共同営業、業界顧客、グローバルデリバリー、技術基盤など、買い手との具体的施策を追加します。それぞれ、責任者、開始、必要投資、顧客同意、採用、粗利、失敗条件を付けます。「グループの顧客へ売れる」という一行では計画になりません。

下振れケースでは、上位顧客の縮小、キーパーソン退職、採用遅延、為替、案件開始延期、粗利悪化を組み合わせます。現預金が何か月持つか、固定費をどう調整するか、顧客品質を守る最小体制は何かを示します。下振れを出すことは弱気ではなく、経営管理能力の証拠です。

三計画を月次ダッシュボードとつなぎ、どの指標が閾値を超えたら採用・投資・営業を変えるかを決めます。買い手と前提を共有すれば、アーンアウトや統合予算の議論も具体的になります。

40-6. 売却準備度を四段階で自己診断する

準備度は「資料がある・ない」だけでなく、内容の正確さ、運用、承継可能性で評価します。各論点を、未把握、把握、是正・運用、第三者検証可能の四段階にします。高得点を作ることより、低い項目のうち価値と実行へ影響するものを早く見つけることが目的です。

顧客契約なら、未把握は契約の所在も不明、把握は一覧と重要条項がある、是正・運用は更新・承諾を管理、第三者検証可能は契約台帳と会計・CRMが一致する状態です。案件粗利なら、全社損益だけ、案件集計あり、毎月レビュー、タイムシート・請求・元帳から追跡可能という段階です。

知財なら、創業者や外注者のものが混在、権利者一覧あり、契約是正と素材台帳あり、代表案件をサンプル検証済みという段階です。人材なら、人数だけ、匿名スキル表あり、副担当・引き継ぎ運用あり、経営者不在や退職を想定したテスト済みという段階です。技術なら、構成不明、負債一覧あり、優先是正・CI/CD運用あり、復旧・ロールバックを実証済みという段階です。

領域	未把握から最初に行うこと	第三者検証可能な状態
財務	月次と顧客・案件を結ぶ	元帳、工数、契約から粗利を追える
顧客	契約と売上を一覧にする	更新・承諾・集中が証拠と一致
人材	匿名スキルと役割を作る	代替・引き継ぎを実地確認
デザイン	代表案件の判断過程を残す	権利と成果をサンプル検証
技術	構成、権限、負債を棚卸し	ビルド、復旧、移行を再現
ブランド	指名・採用・検索を測る	維持・統合案をデータで比較

自己診断は経営者一人で行わず、財務、営業、デザイン、技術、人事が別々に採点し、差を議論します。経営者が「運用済み」と考えても、現場が「口頭だけ」と見る項目は属人性の兆候です。重要項目は弁護士・会計士・技術専門家にサンプル確認を依頼します。

毎月すべてを再採点する必要はありません。重大項目の是正責任者、期限、証拠を管理し、四半期に全体を見直します。売却時期が近づいても、形式的に段階を上げず、未解決を開示します。透明な低得点は、根拠のない満点より取引実行に役立ちます。

40-7. 譲渡企業が最初の30日で行う具体策

第1週は、株主・持分、直近月次、借入、上位顧客、主要人材、売却目的を一枚にします。第2週は、顧客契約、ポートフォリオ権利、外注知財、クラウド・GitHub・デザインツールの名義を点検します。第3週は、案件粗利、受注残、キーパーソン、ブランド指標を仮集計します。第4週は、専門家と手法、税、秘密保持、候補先像、改善の優先順位を議論します。

この30日で買い手へ売り込む必要はありません。むしろ資料の不足と、売却前に直すもの、交渉で開示するもの、買収後に統合するものを分けます。通常営業、採用、顧客対応を止めず、準備会議を短く固定します。経営者の希望だけでなく、顧客・従業員・株主にとって良い承継とは何かを言葉にします。

候補先へ接触する前に、社内で案件コード名、閲覧者、資料保存、メール・印刷、口頭会話のルールを決めます。デザイン会社では制作物が目につきやすいため、会議室画面や共有リンクからの情報漏えいにも注意します。誰に伝えるかは取引確度と法令を踏まえて専門家と決めます。

経営者面談の前には、デザイン責任者、技術責任者、財務責任者が同じ案件を別々に説明し、数字と役割が一致するかを確認します。営業資料では戦略から運用まで一貫しているのに、現場では工程ごとに顧客・原価・品質の定義が違うことがあります。差を隠さず、共通定義と改善期限を作ります。

買い手がデザインを営業上の飾りとして扱わず、顧客課題の発見と意思決定へ正式に組み込むかも確認します。デザイナーの稼働率だけを高めると、リサーチ、批評、方法論の更新が失われます。反対にデザインを採算管理から外すと、無償反復が増えます。案件の粗利と成果物の品質を同じ会議で確認できる運営体制が、買収後の価値を守ります。

技術側も、買い手の規模に合わせるための標準化と、対象会社が速く試す能力を分けます。顧客データ、セキュリティ、可用性には共通最低基準を適用し、試作や内部ツールには軽量な承認を残す方法があります。すべてを例外にするのでも、すべてを同じ統制にするのでもなく、リスク別のレーンを設計します。

準備開始時には、顧客から預かった情報と自社のM&A資料を同じフォルダーへ混在させないことも重要です。資料の出所、作成者、更新日、開示権限を記録し、古い版が候補先へ残らないようにします。数字を修正した場合は理由と影響範囲を示し、説明に一貫性を持たせます。買い手からの質問が増えても、営業現場が個別に回答せず、承認された窓口を通します。

また、売却準備のために研究、採用、顧客支援を不自然に止めると、短期利益は増えても将来価値を損ねます。通常経営に必要な投資と、一時的な売却費用を区別し、買い手へ正直に説明します。M&Aは決算を一瞬よく見せる作業ではなく、顧客へ価値を届け続ける組織を次の所有者へ渡す作業です。

41. 譲渡企業手数料0円で、価値の棚卸しから相談できます

デジタルデザイン・アプリ開発会社の価値は、作品集、売上、人数のどれか一つでは伝わりません。顧客課題からサポートまでの工程、デザイン・技術・業界知見の組み合わせ、顧客関係、人材、文化、ブランド、知財を、買収後も続く仕組みとして示す必要があります。

アプリ開発M&A総合センターは、譲渡企業の着手金・中間金・成功報酬を含め手数料0円です。 成約しなかった場合だけでなく、成約した場合も譲渡企業から成功報酬をいただきません。売却を決める前の案件採算、ポートフォリオ開示、知財、買い手候補、ブランド、クロスボーダーPMIの整理からご相談いただけます。

報酬を比較する際は、最低報酬、料率区分、算定基礎、着手金・中間金、消費税、サービス範囲を同じ条件で確認してください。単純な計算例では、譲渡価格5億円に5％を掛けると2,500万円ですが、実際の仲介報酬は各社のレーマン方式の基礎、最低報酬、契約条件で異なります。この例だけで特定他社の請求額を示すものではなく、単純比較はできません。参考として、ストライクの公開料金ページもご確認ください。

免責事項

本稿は、2022年6月2日のNTTデータ公式ニュースリリースと参考Excel掲載案件を基に、デジタルデザイン・アプリ開発会社の譲渡企業が準備を考えるための一般情報として作成しています。当センターが本件を仲介・助言したものではありません。公表されていない価格、財務、交渉、DD、契約、統合成果を示すものではありません。

本稿は個別の法務、税務、会計、労務、個人情報、投資その他の助言ではありません。法令、税制、契約、ライセンス、データ移転規制は国・地域と時点により異なります。具体的な取引では、各法域の弁護士、公認会計士、税理士、労務・知財・セキュリティの専門家へご相談ください。