VR会社の売却準備完全ガイド｜XR企業の価値を高める24の実務

VR会社 売却で、一般的なIT会社より準備が複雑になる理由

VR/XR会社の価値は、決算書だけには表れません。たとえば安全教育VRの一案件には、顧客との業務委託契約、シナリオ、現場撮影、360度映像、3DCG、Unityプロジェクト、外部SDK、HMD設定、配布アプリ、利用ログ、保守契約が連なっています。買い手が取得したいのは過去の納品物だけではなく、それらを再利用し、更新し、新しい顧客へ展開できる事業能力です。したがって譲渡企業は、利益と同時に「再現可能性」と「利用可能性」を示す必要があります。

もう一つの特徴は、PoCと本導入の距離です。XR案件では、技術検証が成功しても、顧客側の端末調達、現場ネットワーク、酔いへの配慮、衛生運用、セキュリティ審査、年度予算などが障害になり、本導入へ進まない場合があります。PoCの件数だけを成長性として説明すると、買い手は本導入率や再受注率を追加確認します。売却準備では、案件を受注日や売上だけで並べず、検証、本開発、展開、運用保守という段階で整理することが重要です。

また、コンテンツ制作には複数の権利者が関わります。社員が書いたコード、業務委託先が作った3Dモデル、顧客から預かったCAD、施設で撮影した映像、購入した音源やアセットでは、使える範囲がそれぞれ異なります。「納品されたから自社のもの」「料金を払ったから自由に譲渡できる」とは限りません。権利の結論は契約ごとに確認すべきですが、少なくとも誰から、何を、どの条件で受け取ったかをたどれる状態が必要です。

実務1｜売却目的と譲れない条件を言語化する

最初に作るべきものは企業概要書ではなく、経営者自身の「目的メモ」です。資金を得たい、後継者問題を解消したい、大規模案件へ進みたい、採用力を補いたい、個人保証から離れたいなど、VR会社 売却の目的は一社ごとに異なります。目的が曖昧なまま候補企業と会うと、提示価格の高さに引っ張られ、社員の雇用、拠点の維持、ブランド、代表者の継続期間、既存顧客への対応といった本来大切な条件を後から思い出すことになります。

目的メモは「実現したいこと」「避けたいこと」「交渉できること」の三列で作ります。たとえば、仙台や札幌の開発拠点を残すことは必須、代表者の続投は二年間まで相談可能、社名は買い手の戦略次第、と整理します。社員に約束していない希望を、確約済みの条件のように説明してはいけません。現時点の希望と、買い手との合意事項を区別します。

さらに売却しない選択肢も比較します。単独成長、業務提携、少数株主の受入れ、事業の一部譲渡、採用提携などです。M&Aを唯一の解決策にせず比較した結果、それでも株式譲渡が目的に合うなら、交渉中の迷いが減ります。このメモは買い手へそのまま渡す資料ではありません。アドバイザーと認識を合わせ、候補先を選ぶための内部文書です。半年ごとに目的が変わっていないか更新すると、売却準備そのものが経営方針を整える機会になります。

実務2｜株式譲渡・事業譲渡など対象範囲を仮決めする

VR/XR事業の承継では、会社全体を対象とする株式譲渡と、特定事業・契約・資産を選ぶ事業譲渡とで、引継ぎの設計が大きく変わります。株式譲渡では法人そのものが存続するため、契約や従業員関係が基本的には法人内に残る一方、簿外債務や過去の契約リスクも含めた調査が重くなります。事業譲渡では対象を切り分けやすい反面、顧客契約、資産、従業員、許認可、アカウントなどを個別に移す必要が生じます。実際の法的効果は契約条項や手続に左右されるため、早い段階から専門家へ確認してください。

仮決めのためには、事業を「顧客」「人」「知的財産」「機材」「アカウント」「債権債務」の六群に分けます。たとえばXR受託部門だけを譲る案でも、その部門がWeb開発部門のインフラ担当や共通営業に依存していれば、帳簿上の部門だけを切り出しても運営できません。逆に、特定の自社VRサービスが独立した契約・コード・運用担当を持つなら、事業単位での承継が検討しやすくなります。

対象範囲表には、現在の所有者・契約当事者、移転の要否、相手方同意の要否、代替方法、移転予定日を書きます。「全部まとめて譲る予定だから詳細は後でよい」という考えは危険です。デューデリジェンス中に重要なSDKやストアアカウントを移せないと判明すると、スキームの再検討が必要になります。最初の段階では最終決定でなくて構いません。複数案を置き、移転難易度と税務・法務・事業継続への影響を比較できる材料を作ることが目的です。

実務3｜3年後の事業像から買い手候補を定義する

良い買い手とは、単に高い価格を出す会社ではなく、譲渡後に事業を伸ばせる条件を持つ会社です。VR会社の買い手候補には、大手SIer、Web・モバイル開発会社、映像・ゲーム会社、製造・建設向けDX企業、教育・研修会社、広告会社、HMDや機器の販売会社、地域の事業会社などがあります。同じ買い手でも、XR技術を新規獲得したいのか、エンジニア組織を獲得したいのか、既存顧客へクロスセルしたいのかで評価の焦点は変わります。

候補定義は、自社の弱みからではなく三年後の機会から逆算します。たとえば製造業向け安全教育VRの本導入を全国工場へ広げるには、全国営業、端末キッティング、保守窓口、情報セキュリティ対応が必要です。これらを持つ企業なら、自社のコンテンツ企画力と組み合わせて成長仮説を描けます。一方、買い手にもXR案件の採算管理や技術人材の処遇方針がなければ、単なる人員補充となり、キーパーソンの離職を招く可能性があります。

ロングリストには、企業名だけでなく「想定シナジー」「自社が提供するもの」「相手から得るもの」「競合・顧客との利益相反」「地域拠点への考え」「開発文化」「資金力」を記載します。公開情報から分からない点は「不明」とします。都合の良い推測を事実に変えないことが大切です。匿名打診の段階でも、自社の特徴が推測されやすい実績名や地域、特殊な技術の組合せは伏せ方を工夫し、秘密保持と候補先の妥当性を両立させます。

実務4｜経営者依存を業務別に可視化する

「社長がいなくても回ります」と口頭で説明するだけでは十分ではありません。VR/XRの中小企業では、代表者が営業、要件定義、見積り、技術判断、外注手配、顧客トラブル対応まで担うことがあります。依存を隠すより、どの業務がどの程度依存し、何か月で誰へ移せるかを示す方が、買い手は移行費用を見積もりやすくなります。

業務棚卸しは、引合い、提案、契約、制作、レビュー、納品、請求、保守、採用、評価、資金繰りに分けます。それぞれについて主担当、副担当、承認者、利用システム、頻度、手順書、引継ぎ時間を記録します。特に「顧客から社長へ直接来る相談」「見積金額を決める暗黙の感覚」「エンジンやデバイスの選定基準」「赤字案件を止める判断」は、組織図には出にくい依存です。過去三か月の社長の予定表やチャットから業務を抽出すると、自己申告だけより実態に近づきます。

解消策は、社長を急に外すことではありません。顧客面談に営業責任者を同席させる、見積レビューを二名制にする、技術選定の判断ログを残す、主要顧客ごとにサブ担当を置く、といった段階的なものです。売却後も代表者が一定期間残る場合、その役割、勤務日数、権限、報酬、終了条件を曖昧にしないことが重要です。依存度が高くても、移管計画と本人の協力意思が具体的なら、単なるリスクではなく、管理可能な課題として説明できます。

実務5｜月次決算を早期化し正常収益力を示す

買い手は過去の利益だけでなく、その利益が今後も再現するかを見ます。まず直近三期の決算書、勘定科目内訳、税務申告書、直近月次試算表をそろえ、月次締めの日程と担当を固定します。検収が長いXR案件では、売上計上基準、仕掛品、外注費、端末仕入れの対応関係が見えにくくなります。案件番号を会計データとプロジェクト管理に共通で付けると、数字と現場をつなぎやすくなります。

次に正常収益力を整理します。役員の私的費用、相場と異なる役員報酬、移転費用、一時的な補助金、訴訟や事故の費用、単年度の大型案件など、将来継続しない可能性のある項目を一覧にします。ただし、利益を高く見せるために都合よく除外してはいけません。調整理由、金額、証憑、継続可能性を示し、買い手が採否を判断できるようにします。補助金を除いたら赤字になる事業は、その事実を前提に改善策を説明すべきです。

XR会社では研究開発と案件原価の境界も論点になります。汎用機能の開発、検証用HMD、展示会デモ、社内教育時間をどこへ計上しているかを明らかにします。会計処理の正否は顧問税理士等に確認しつつ、経営管理上は「顧客案件の粗利」「再利用可能な基盤への投資」「営業用デモ」の三つを分けると、買い手が将来投資を理解しやすくなります。数字の美しさより、同じルールで継続して集計できることが信頼につながります。

実務6｜案件別採算をPoC・本開発・保守に分ける

VR会社 売却で企業価値を伝える中心資料が案件別採算表です。案件名、顧客業界、目的、PoC・本開発・横展開・保守の区分、契約額、売上時期、社内工数、外注費、機材費、出張・撮影費、クラウド費、粗利を一行で追えるようにします。工数を取っていない会社は、過去を精密に作り直そうとして止まるより、まず現在進行案件から週次入力を始め、過去案件は請求・勤怠・Git履歴などから合理的な範囲で推定します。推定値には推定と表示します。

PoCは単体で低採算でも、本開発の受注率や共通部品の蓄積を含めれば戦略的価値を持つ場合があります。逆に、PoCを安く受け続けて本導入へ進まないなら、売上件数が増えても経営資源を消耗します。PoCから本開発への移行率、平均期間、失注理由、本開発後の保守率を集計してください。「技術的には成功したが顧客予算が付かなかった」「端末運用が現場に合わなかった」など、理由を分類すると提案改善にも使えます。

案件採算では、無料の追加修正やOS・SDK更新対応を見落としがちです。納品後三か月の問い合わせ時間まで含めて初めて実質粗利が見えます。また3Dモデルや基盤コードを複数案件で再利用した場合は、初回案件だけに全投資を負わせる管理と、再利用価値を別に示す管理を使い分けます。買い手に見せる際は顧客秘密を守り、必要に応じて匿名化します。目的は一案件の優劣を責めることではなく、どの種類の仕事が利益と継続受注を生むのかを経営者が理解していると示すことです。

実務7｜売上の継続性と受注残を検証する

受託開発会社の売上は案件の検収時期で大きく動くため、単年度の増減だけでは実力を読み違えます。顧客別売上を直近三年・月別に並べ、上位顧客依存度、リピート率、案件間隔、失注率を確認します。顧客名を伏せる初期資料でも、製造、建設、観光、教育、医療、広告などの業界、直接受注か二次請けか、民間か自治体関連かを区分すると、需要の特徴が伝わります。

受注残は、契約済み、発注意向書、口頭内示、提案中を混ぜません。金額、確度、予定検収月、必要工数、解約条件、前提となる顧客予算を段階別に示します。自治体・公共関連の案件では、年度予算、入札参加資格、類似実績要件、再委託承認、補助事業の採択などが受注条件になり得ます。「毎年続いている」だけで自動更新と考えず、翌年度に必要な手続を明記します。地域の観光協会や学校との関係も価値ですが、個人的なつながりに依存する場合は引継ぎ方法が必要です。

保守売上も中身を分けます。問い合わせ窓口、軽微改修、クラウド運用、端末交換、現地支援、コンテンツ更新が一つの月額に含まれると、負荷が分かりません。契約ごとの対応範囲と実績工数を比較し、赤字保守は更新時に条件を見直します。継続性は契約期間の長さだけでなく、解約率、担当者との関係、利用頻度、顧客業務への組込み度、代替コストから説明します。顧客の将来意思を断定せず、契約上の事実と譲渡企業の見通しを分ける姿勢が信用を高めます。

実務8｜運転資金・端末在庫・簿外項目を整理する

XR案件は、撮影、3DCG外注、HMD購入、クラウド費用を先払いし、検収後に入金されることがあります。売上が伸びるほど資金が先に出る構造なら、必要運転資金を月次で示します。売掛金の年齢表を作り、長期未回収、検収待ち、請求漏れを区別します。前受金がある案件では、未履行義務と対応原価を確認します。買い手はクロージング時の現預金だけでなく、通常運営に必要な資金水準を見ます。

HMD、コントローラー、センサー、カメラ、GPU搭載PC、展示什器などは、固定資産台帳と現物が一致しているか確認します。顧客へ貸与中、イベント会場、開発者の自宅、故障保管、廃棄予定を分け、型番、シリアル、購入日、保証、所有・リース、MDM登録、利用案件を記録します。箱に入った旧型端末を取得価額のまま価値ある在庫として扱うのではなく、実際に使用できる状態と将来の用途を説明します。

簿外になりやすい項目には、未消化の有給休暇、残業代リスク、解約不能なクラウド予約、個人カードで支払うサブスクリプション、外注先への追加精算、瑕疵対応、顧客から預かった機材・データがあります。問題がないと決めつけず、契約と実態を照合します。見つかった課題は隠すより、金額、原因、是正状況、再発防止を整理します。早期に発見できれば、売却直前の価格調整や交渉中断を避けるだけでなく、日常の資金管理も改善できます。

実務9｜顧客契約とチェンジ・オブ・コントロールを確認する

顧客契約は売上の根拠であると同時に、承継条件を決める重要資料です。基本契約、個別契約、発注書、仕様書、見積書、検収書、秘密保持契約を顧客単位で関連付けます。契約書が見つからない、押印済み原本と現場で使う版が違う、追加開発がチャットだけで決まった、といった状態は早めに解消します。契約台帳には契約当事者、期間、更新、解約、支払、成果物、知的財産、再委託、損害賠償、準拠法、反社会的勢力条項などの所在を記載します。

株主や支配権の変更時に通知・同意・解除が関係するチェンジ・オブ・コントロール条項も確認します。条項があるから必ず契約が終了する、ないから何も対応不要、と一律には判断できません。取引先との関係、秘密保持、入札資格、個別契約の優先関係を含め、弁護士と手順を検討します。顧客へ早く話し過ぎれば秘密保持に影響し、遅過ぎれば信頼を損なうため、誰が、いつ、何を、どの承認を得て伝えるかを案件工程に入れます。

XR案件では、納品後の利用条件も重要です。顧客がコンテンツを永久に利用できるのか、端末台数や拠点数に制限があるのか、第三者への再配布が可能か、OS更新の対応義務はどこまでかを確認します。契約上の保守義務と実際の無償対応に差があれば、一覧にして今後の是正方針を示します。契約台帳は法律用語を並べる表ではなく、売上が継続する条件と、承継時に必要な行動を経営側が把握するための道具です。

実務10｜外注・再委託・SES契約を一本の台帳にする

VR制作では、3Dモデラー、CGアニメーター、撮影会社、ナレーター、サウンド制作者、Unityエンジニア、デバイス会社など複数の協力先が関わります。買い手は、売上を生む能力が社員にあるのか、特定外注先に依存しているのかを確認します。外注先ごとに業務内容、単価、年間発注額、担当案件、代替可能性、契約期間、秘密保持、成果物の権利、再々委託、個人情報取扱いを整理してください。

顧客との契約で再委託に事前承認が必要なのに、現場慣行だけで外注している場合は是正が必要です。自治体や大企業の案件では、再委託先の届出、作業場所、情報管理、国外アクセスなどが条件となることがあります。契約を読み、必要な承認記録があるかを確認します。承認が見つからないからといって、過去日付の書類を作るような対応をしてはいけません。事実を整理し、専門家と顧客対応を検討します。

準委任、請負、SESの呼び方だけで実態を判断せず、指揮命令、成果責任、勤務管理、偽装請負などの労務・法務面も確認します。キーパーソンが業務委託の場合、M&A後も協力する意思があるか、契約を一方的に移せるかは別問題です。重要外注先とは、秘密保持の範囲を守りながら、適切な時期に継続条件を協議します。協力会社ネットワークは価値になり得ますが、それを譲渡企業が所有していると表現せず、実績、関係期間、発注条件という検証可能な事実で説明します。

実務11｜著作権と3D・映像素材の利用範囲を確認する

XRのデジタル資産台帳には、ソースコード、シェーダー、3Dモデル、テクスチャ、CAD・BIM変換物、点群、360度映像、写真、音声、BGM、シナリオ、UI、キャラクター、ロゴを登録します。各資産について作成者、契約、対価、権利帰属、利用許諾範囲、改変、再利用、第三者提供、期間、地域、クレジット表示を記録します。ファイルがサーバーにあることと、会社が自由に利用・譲渡できることは同じではありません。

文化庁は、著作権法27条・28条の権利は譲渡対象であることが特に明示されない場合、譲渡者に留保されたものと推定されると解説しています。また著作者人格権は著作権とは別で、譲渡できません。実務では人格権を行使しない旨の条項が置かれることがありますが、条項の有効範囲や具体的な利用は個別確認が必要です。単に契約書へ定型文を追加するのではなく、誰が著作者か、職務著作の要件を満たすか、過去の外注契約で何が合意されたかを専門家と確認します。

撮影対象にも注意します。施設、文化財、展示物、製品、人物、敷地内表示には、著作権以外の許諾や契約条件が関わる可能性があります。顧客から預かったCADや商品データは、別顧客向けデモへ転用できるとは限りません。営業資料に掲載できる実績と、開発内部だけで扱える素材を区分してください。権利が不明な素材は削除・再制作・再許諾などの選択肢と費用を整理します。権利台帳が整うと、買い手は承継後にどの資産を安全に再利用できるか判断しやすくなります。

実務12｜Unity・Unreal・購入アセットのライセンスを棚卸しする

UnityやUnreal Engineを使っているという説明だけでは足りません。使用バージョン、契約主体、プラン、席数、利用者、売上・資金調達等による適用条件、プラグイン、外部SDK、購入アセット、オープンソースをプロジェクト単位で整理します。利用条件は更新され得るため、売却準備時点の公式規約を確認し、契約時に適用された版や個別契約も保存します。

Unity Asset Storeの公式FAQでは、多くのアセットは第三者パブリッシャーからライセンスを受ける構造で、Extension Assetの席数やSingle Entity・Multi-Entityなどの条件が説明されています。顧客と自社、関連会社、外部委託先が同じファイルを使えるかは、購入者、ライセンス種別、実際の開発体制で異なります。Unreal EngineのEULAも、エンジン技術とマーケットプレイス等のコンテンツを同じ扱いにはしていません。したがって「会社を買えばアセットもすべて自動的に自由利用できる」と決めつけず、対象ごとの規約・購入記録を確認します。

棚卸表には、資産名、提供元、URL、注文番号、購入アカウント、利用プロジェクト、席数、改変有無、配布形態、ソース同梱有無、更新期限、代替可能性を書きます。無料素材でもライセンスがないわけではありません。OSSではライセンス通知、ソース提供義務、組合せ条件を確認します。規約解釈に迷う場合は提供元または専門家へ確認し、その回答を保存します。買い手へは法的保証を安易に与えず、調査範囲、確認日、未解決事項を明確にした台帳を示すことが実務的です。

実務13｜Git、LFS、依存関係、ビルド手順を再現可能にする

価値のあるソースコードでも、元担当者のPCでしかビルドできなければ承継リスクが高まります。主要プロジェクトごとに、リポジトリURL、既定ブランチ、Unity・Unrealの正確なバージョン、IDE、SDK、パッケージ、環境変数、外部サービス、ビルド対象端末、テスト方法をREADMEへ記載します。新しいPCまたは隔離した環境で、別の担当者が手順どおりにビルドし、結果と所要時間を記録します。成功画面だけでなく、既知の警告や暫定対応も残します。

3Dデータや動画をGit LFSで管理している場合、オブジェクトが完全に同期されているか、容量課金、ロック運用、退職者アカウントへの依存を確認します。GitHubの公式文書では、リポジトリ移管時にコードだけでなくIssueやPull Request等が移る一方、プランによって機能が失われる場合や、一部の権限・関連サービスに注意が必要だとされています。移管機能があることと、M&A当日に何も準備せず安全に移せることは別です。Webhook、ActionsのSecrets、パッケージ、Pages、外部CI、LFS容量、支払情報を個別に確認します。

ソースコード一覧には、顧客専用、社内共通基盤、オープンソース公開、検証用、廃止予定を区分します。顧客契約上、自社に再利用権がないコードを共通基盤へ混ぜていないかも確認します。コミット履歴から個人情報や秘密鍵を消す作業は影響が大きいため、バックアップと専門知識が必要です。まずSecretsスキャンとアクセス権レビューを行い、修正計画を作ります。「一度ビルドできた」だけでなく、月次で再現テストを行える仕組みこそ、技術資産が組織に帰属している証拠になります。

実務14｜ストア・クラウド・署名鍵・ドメインを法人管理にする

アプリ、Webサービス、デバイス管理の運営に使うアカウントを一覧化します。App Store Connect、Google Play Console、Meta等のデバイスポータル、AWS・Azure・Google Cloud、Firebase、GitHub、Unity Cloud、分析、監視、メール、DNS、ドメイン、決済、証明書が対象です。所有者メール、管理者、二要素認証、支払方法、更新日、契約主体、復旧連絡先を記載し、社長や退職者の個人メール・個人カードに依存しているものを法人管理へ移します。パスワードを台帳へ平文で書くのではなく、承認されたパスワード管理とアクセスログを使います。

Appleの公式案内では、アプリ移管後もレビューや評価、Bundle ID等が維持される一方、Apple PayのMerchant ID、Keychain共有、Push通知、Sign in with Apple、TestFlight、Xcode Cloudなどに個別の準備事項があります。Google Playの公式案内でも、ユーザーや評価等は移る一方、支払・収益レポート、テストグループ、統合サービスの権限設定など、移らないものや再設定が必要なものがあります。公開アプリがある会社は、アカウント移管を一行のタスクにせず、機能別のチェックリストとロールバック案を作ります。

署名鍵、APNsキー、OAuthクライアント、サービスアカウント、暗号化鍵は、漏えいすると重大なリスクになる一方、紛失すると更新不能になる場合があります。誰が保管し、どの環境が参照し、いつローテーションしたかを確認します。買い手へ渡す時期は、秘密保持とクロージング条件に合わせます。アカウントの名義変更やアプリ移管の可否・要件はサービスごとに変わり得るため、実行直前に公式情報を再確認してください。

実務15｜HMD・センサー・撮影機材の運用を台帳化する

XR会社ではソフトウェアと現物運用が一体です。HMDの型番と台数だけでなく、OSバージョン、業務用管理アカウント、MDM、キオスク設定、コントローラー、衛生カバー、充電、ネットワーク、予備機、保証、修理窓口、輸送ケースを記録します。顧客所有、貸与、リース、自社所有を分け、現物確認日と保管場所を付けます。顧客の現場へ置いた端末が、固定資産台帳上は自社倉庫にあることになっていないか確認します。

運用手順には、初期設定、アプリ配布、利用者切替、清掃、故障一次診断、交換、アップデート、回収、廃棄を含めます。展示会で数台を使う運用と、工場や学校で数十台を継続利用する運用では必要な体制が異なります。買い手が全国展開を想定するなら、キッティング一台当たり時間、故障率、予備機比率、現地出張回数、問い合わせ件数を示すと、拡大時の費用を見積もれます。

デバイスの製造終了やOS・SDK対応終了は、コンテンツの寿命に直結します。旧型端末向けアプリを残す場合は、代替端末での検証状況、移植コスト、顧客との費用負担を整理します。端末管理サービスや法人向け利用条件も契約主体を確認します。買い手に「機材も一式あります」と説明するだけでなく、誰がどの品質で運用できるのかを手順と指標で示すことで、ハードウェアを含むサービスの実態が伝わります。

実務16｜視線・音声・空間データと個人情報を整理する

XRでは、氏名やメールアドレスに加え、顔画像、音声、会話、アバター、位置、視線、モーション、身体寸法、購買、利用ログ、室内マップやカメラ映像を扱うことがあります。個人情報保護委員会の委託調査報告書も、メタバースで想定される情報としてアイトラッキングデータ、モーションデータ、音声や会話内容などを挙げています。すべてが直ちに同じ法的分類になるという意味ではありませんが、一般的なWebログより広いデータを扱う可能性を認識すべきです。

データマップには、取得項目、取得目的、本人への表示、同意、保存場所、委託先、国外取扱い、アクセス権、保存期間、削除、顧客への提供、匿名化・統計化を記載します。プライバシーポリシーに抽象的な一文があるだけでは、実装との一致を確認できません。アプリ画面、管理画面、ログ基盤、クラウド設定、問い合わせ対応を照合します。顧客の従業員データを受託処理している場合、自社が独自利用してよいとは限りません。

M&Aのデューデリジェンスで顧客データや個人データをそのまま買い手候補へ開示するのも慎重な設計が必要です。初期段階では集計・匿名化し、必要性、契約、法令、秘密保持を確認して段階的に開示します。クロージング後のデータ移行では、権限変更、ログ、バックアップ、削除証明、事故対応連絡網まで計画します。適法性の結論は個別事情で異なるため専門家へ相談し、少なくとも「何を持っているか分からない」状態をなくすことから始めます。

実務17｜キーパーソンとチーム構造を説明できるようにする

買い手が見ているのは人数ではなく、案件を完遂できる役割の組合せです。プロデューサー、PM、テクニカルアーティスト、Unity・Unrealエンジニア、Web・バックエンド、3D、UI/UX、撮影、QA、端末運用、営業の役割を整理し、社員・業務委託・協力会社のどこが担うかを示します。個人名を初期資料に出さなくても、経験年数、担当領域、主要案件、資格、育成可能性を匿名化して説明できます。

キーパーソン判定は役職だけで行いません。唯一ビルドできる人、特定顧客の要件を理解する人、外注ネットワークを動かす人、HMD運用を現場で支える人も重要です。休暇や退職でその人が一か月不在になった場合に止まる業務を確認し、副担当、手順書、レビュー体制を整えます。属人性を完全になくすのは現実的ではありませんが、買い手が依存の所在と対応期間を把握できる状態を作ります。

人事資料には雇用契約、賃金台帳、労働時間、有給、評価、リモート勤務、競業・秘密保持、発明・著作物の規程を含めます。採用難易度、離職率、採用経路、育成期間も重要です。ただし個人情報は開示範囲を制御します。M&A後の処遇を譲渡企業だけで確約しないこと、従業員へ説明する前に情報漏えいを防ぐこと、同時に説明が遅れて不信を招かないことの均衡が必要です。人を「取得対象」として扱わず、働き続けたい理由を両社で設計する姿勢が承継成否を左右します。

実務18｜顧客・従業員への説明計画を作る

説明計画はクロージング直前に作るものではありません。相手ごとに、説明の目的、時期、話者、同席者、伝える事実、まだ決まっていないこと、想定質問、次の連絡を整理します。従業員、主要顧客、協力会社、金融機関、家主、地域団体では関心が異なります。従業員は雇用・勤務地・評価・文化を、顧客は担当・契約・情報管理・保守継続を、地域関係者は拠点や連携の継続を気にします。

発表前の情報管理では、誰がM&Aを知る必要があるかを段階ごとに定めます。噂が先行すると、社員や顧客は最悪の想像をします。一方で、秘密保持を理由に現場説明を極端に遅らせれば、引継ぎ準備ができません。契約上の通知義務、労務対応、インサイダー情報に該当し得る状況などを専門家と確認し、案件固有のタイムラインを作ります。

説明文では「何も変わりません」と断言しない方が安全です。変わらない予定の事項、変える理由、協議中の事項を分けます。顧客へは、新しい営業・開発資源によって何が改善するかを具体化し、同時にデータや成果物が適切に扱われることを示します。従業員へは質問窓口と回答期限を設け、個別面談も準備します。地域の拠点を維持する方針なら、期間や条件を契約・計画へ反映できるか交渉します。言葉だけで安心を求めるのではなく、意思決定と行動で信頼を支えることが大切です。

実務19｜技術ロードマップと陳腐化リスクを示す

買い手は現在の納品力と同時に、二、三年後の更新負担を見ます。主要製品・共通基盤ごとに、対応HMD、OS、エンジン、SDK、サーバー、データ形式、次回更新、既知の技術的負債を一覧にします。警告が多い、非推奨APIを使う、特定端末でしか動かない、CIがないといった課題を隠さず、影響、修正工数、優先度を示します。

ロードマップは夢の機能一覧ではありません。顧客要望、契約義務、保守期限、セキュリティ、収益機会に結び付けます。たとえばハンドトラッキング対応が新規売上を生むのか、単に展示映えするのかを区別します。生成AIやクラウドレンダリングなど新技術は魅力的ですが、実証段階ならそのように明記し、売上見込みを確定受注のように扱いません。過去のPoCから本導入へ進んだ条件を基に、実行可能性を説明します。

技術資産の評価では、コード行数より、保守性、テスト、自動化、ドキュメント、再利用実績、顧客課題との適合が重要です。陳腐化リスクには、端末供給、ストア審査、外部API、ライセンス価格、特定人材、GPU環境を含めます。代替案と切替費用があれば、リスクは管理可能になります。ロードマップを買い手と議論することで、譲渡後の投資方針やエンジニアの役割も具体化し、価格だけではない相性を見極められます。

実務20｜情報管理とデータルームを設計する

データルームは、資料を大量に置く共有フォルダではありません。会社、財務、税務、法務、顧客、知財、技術、人事、資産、環境・安全などの階層を作り、資料番号、版、基準日、担当、開示段階を管理します。質問と回答のログを残し、口頭回答と資料の矛盾を防ぎます。顧客名、個人情報、ソースコード、脆弱性情報は初期から全候補へ開示せず、必要性に応じて匿名化・閲覧制限・透かし・ダウンロード制限を使います。

売却準備の初期は、完全なデータルームより「不足一覧」が役立ちます。あるべき資料、現状、欠落理由、作成担当、期限、専門家確認を書きます。資料を後から修正した場合は旧版を無言で差し替えず、変更履歴を残します。買い手から誤りを指摘された際は、防御的に取り繕うより、事実確認、訂正、影響、再発防止を回答します。

セキュリティ面では、共有リンクの公開範囲、退職者権限、MFA、監査ログ、端末ダウンロードを確認します。契約で開示できない顧客情報や第三者秘密が含まれていないか、アップロード前にレビューします。ソースコードは通常のデューデリジェンスでどこまで必要かを買い手・専門家と協議し、アーキテクチャ説明、コード品質レポート、限定レビューなど段階的な代替も検討します。情報を守りながら十分な判断材料を出せる会社は、それ自体が管理能力を示します。

実務21｜買い手質問を先回りした経営者面談資料を作る

経営者面談では会社紹介より、買い手が抱く仮説に答えることが重要です。「なぜ今売るのか」「社長が抜けても受注できるか」「PoCから本導入へ何割進むか」「高粗利案件の共通点は何か」「主要エンジニアは残るか」「権利を再利用できるか」「端末保守を全国展開できるか」「買い手の顧客へ何を売れるか」を想定します。回答は結論、根拠データ、課題、対応策の順で作ります。

うまくいかなかった案件も一つは説明できるようにします。失敗を隠す会社より、原因を技術、要件、顧客予算、現場運用、採算に分け、次にどう変えたかを話せる会社の方が信頼されます。数字がない場合は推測で埋めず、集計範囲を明示します。将来計画は、確定受注、顧客との協議、経営者の目標、買い手とのシナジー仮説を別々に表示します。

デモは、見栄えだけでなく事業性を説明します。誰のどの課題を解き、導入前後で何が変わり、必要端末と運用費はいくらか、どの部分を別顧客へ再利用できるかを示します。秘密保持のため顧客素材を出せない場合は、許諾済みデモや模式図を使います。買い手の質問に即答できない時は、確認期限を伝えて後日回答します。経営者面談は売り込みの場であると同時に、譲渡企業が買い手の文化、意思決定速度、投資姿勢を確認する相互評価の場です。

実務22｜価格だけでなく条件総額を比較する

複数の提案を比べる際、表面上の株式価値だけを見ると判断を誤ります。現金・有利子負債の扱い、運転資金調整、役員貸付・借入、退職金、アーンアウト、役員報酬、再投資、少数株式の残存、税金、アドバイザー費用を含め、手取りとリスクを比較します。アーンアウトは将来成果に応じて対価を得られる可能性がある一方、指標、会計方針、買い手の経営判断、代表者の権限によって実現性が変わります。専門家と条項を精査します。

条件比較表には、雇用、拠点、ブランド、代表者の役割、設備投資、開発予算、意思決定権、競業避止、顧客契約、個人保証の解除も入れます。高値でも広い競業避止や長い拘束があれば、経営者の将来に大きく影響します。買い手が提示するシナジーも、担当役員、予算、実行時期がなければ願望にとどまります。

評価額には唯一の正解があるわけではありません。利益、純資産、類似取引、将来キャッシュフローなど複数の考え方があり、小規模な非上場会社では個別性が大きくなります。「VRだから必ず高倍率」「エンジニア一人当たりいくら」といった単純な相場表だけで決めず、自社の正常収益力、顧客継続性、技術・権利、人材、成長投資の必要額から交渉材料を作ります。価格と確実性、スピード、承継後の姿を同じ表で比較することが重要です。

実務23｜最終契約・経営者保証・表明保証を確認する

基本合意後も、価格、前提条件、補償、クロージング実務が残ります。最終契約では、譲渡側（株式譲渡では売主）が対象会社の状態について表明し保証する事項、違反時の補償、期間、上限、免責、開示事項を確認します。デューデリジェンスで伝えたから自動的に免責されるとは限らず、契約上どのように扱われるかが重要です。知的財産、OSS、個人情報、労務、税務、顧客契約など、XR会社に関係する事項を弁護士と照合します。

中小企業庁の中小M&Aガイドライン第3版は、最終契約の不履行や経営者保証の扱いを含むトラブルと対応を解説しています。経営者保証を解除・移行する想定なら、金融機関との手続、必要書類、実行時期、未実行時の対応を具体化します。「買い手が対応する予定」という口頭理解だけにせず、専門家と契約・クロージング条件を確認します。

クロージングチェックリストには、株券・株主名簿、機関決議、代金、登記、印章、通帳、契約原本、アカウント権限、鍵、機材、保険、従業員・顧客通知を含めます。ただしSecretsや個人データの移管は、権限とタイミングを厳格に分けます。契約を理解せず「専門家に任せた」としないことが大切です。経営者自身が、何を約束し、どのリスクが残り、いつ義務が終わるのかを説明できるまで確認します。

実務24｜30・60・90日の統合・承継計画を作る

M&Aは契約締結で終わりません。Day1、30日、60日、90日の計画を、顧客、人材、開発、財務、IT、広報に分けます。Day1は指揮命令と連絡先、給与・請求、緊急障害対応、情報アクセスを止めないことを優先します。30日までに主要顧客とキーパーソンの対話、アカウントと権限の確認、案件採算の共通ルールを整えます。60日までに共同提案、技術共有、重複ツールの方針を決め、90日までに最初のシナジー施策を評価します。

統合を急いで社名、チャット、評価、開発手法を一斉に変えると、現場が顧客対応より社内作業に追われます。残すもの、統合するもの、後で決めるものを区別します。VR/XRチームの創造性や小回りを残しつつ、買い手の営業、セキュリティ、福利厚生、品質管理を利用する設計が必要です。両社の用語や見積方法が違う場合、共同案件一つで試してから標準化します。

KPIは売上だけでなく、キーパーソン定着、顧客継続、ビルド成功、問い合わせ応答、共同提案件数、案件粗利、従業員サーベイを置きます。責任者と会議頻度を決め、課題を譲渡企業側・買い手側の責任論にしない仕組みを作ります。経営者の引継ぎ期間には、顧客紹介、判断基準、地域関係、採用、トラブル事例を組み込みます。統合計画が具体的であるほど、買い手は承継コストを理解でき、譲渡企業も社員・顧客に現実的な説明ができます。

売却準備を90日で始める実行ロードマップ

1〜30日｜事実を集める

• 目的メモと譲れない条件を経営者が作る
• 直近三期・直近月次の財務資料をまとめる
• 顧客、案件、契約、外注、従業員、機材、アカウントの台帳を作る
• 主要プロジェクトを三つ選び、コード・権利・採算の欠落を確認する
• 欠落資料を「ないまま」にせず、不足一覧へ記録する

この段階では見栄えより網羅性を優先します。担当者を責めず、会社の情報がどこにあるかを可視化します。売却の意思が固まっていなくても、財務と技術資産の棚卸しは日常経営に役立ちます。

31〜60日｜重要リスクを直す

• 案件別工数と採算の記録を開始する
• 個人所有の重要アカウントを法人管理へ移す
• 別担当者によるクリーンビルドを実施する
• 主要外注契約と著作権条項を専門家と確認する
• 社長依存の高い業務に副担当と手順を置く

全部を直せない場合は、顧客売上、サービス継続、法令・契約違反、情報漏えいに直結する項目を優先します。修正前の状態、実施内容、残課題を記録すると、買い手への説明にも使えます。

61〜90日｜買い手が検証できる形にする

• 事業概要、案件採算、顧客継続性、組織、技術資産を一つのストーリーにまとめる
• データルームの開示段階と権限を設計する
• 買い手候補のロングリストとシナジー仮説を作る
• 想定質問へ、根拠資料を添えて回答する練習を行う
• 売却しない選択肢との比較を再確認する

90日で売却を完了させるという意味ではありません。最初の90日で「判断できる会社」に変える計画です。準備状況、買い手探索、交渉、審査の期間は会社ごとに異なります。急ぐ理由がある場合ほど、情報の正確性と秘密保持を犠牲にしない進行が必要です。

買い手に伝わるVR/XRデータルームの基本構成

この表は一般例です。資料を開示する前に、個人情報、顧客秘密、第三者情報、契約上の開示制限を確認してください。初期打診では匿名・集計情報にとどめ、候補先の検討が進んだ段階で必要な資料を追加する設計が現実的です。

VR会社 売却で避けたい7つの失敗

1. 売上を案件数だけで説明する：PoC、本導入、保守を分けず、将来の再現性が見えなくなります。
2. コードがあるから権利もあると考える：外注契約、顧客素材、購入アセットの条件確認が必要です。
3. 個人アカウントを直前まで放置する：ストア、クラウド、ドメイン、署名鍵が移せず、運営停止につながり得ます。
4. 問題資料を削除して見せない：後の発覚は価格以上に信頼を損ない、表明保証の問題にもなります。
5. 社員へ将来条件を独断で確約する：買い手と合意していない処遇を約束すると混乱を招きます。
6. 最高価格だけで独占交渉へ進む：資金確実性、文化、拠点、投資計画、契約条件を総合比較すべきです。
7. 契約締結をゴールにする：顧客・人材・技術の承継が実現して初めて事業価値が保たれます。

業種別に見るVR/XR会社の企業価値と承継論点

同じUnityプロジェクトでも、顧客業界によって価値の源泉と引継ぎ方法は違います。売却資料を「VR制作実績」で一括せず、顧客業務、導入条件、継続費用、規制・許諾、買い手が拡大できる単位に分けます。以下は典型例であり、各社・各案件の契約や法令を個別に確認してください。

製造業・インフラの安全教育、技能訓練

製造・インフラ向けVRでは、危険場面を安全に反復できること、熟練者の判断をシナリオ化できること、多拠点へ同じ教材を配布できることが価値になります。譲渡企業は、対象作業、教育目標、評価方法、導入人数、事故・ヒヤリハット情報の扱い、現場監修、HMD運用を整理します。「リアルな映像」を強調するだけでなく、受講前後で理解度や手順遵守がどう変わったか、顧客が測定している指標があれば示します。効果を測っていない場合は、印象で数値を作らず未測定と明記します。

承継では、工場内撮影の許可、設備CAD、製造ノウハウ、作業者の映像、顧客ごとの安全基準が重要です。ある工場用の危険場面を別会社へ転用できるとは限りません。共通化できるエンジン部分と、顧客秘密を含むコンテンツを分離します。端末を閉域環境で使うのか、クラウド配信するのか、現場でアップデートできるのかも確認します。買い手が全国顧客を持つ場合、コンテンツ開発だけでなく、キッティング、現地教育、故障交換、利用ログ報告まで提供できる体制が成長価値になります。

建設・不動産・設備の可視化、合意形成

建設・不動産向けでは、BIM・CADからの変換、実寸感、設計変更への追随、施主・施工者・利用者の合意形成が価値です。モデルを一度美しく作る能力だけでなく、元データ更新時の差分反映、軽量化、命名規則、座標、マテリアル、版管理の手順が再現できるかを示します。案件別採算には、初回変換、修正回数、顧客レビュー、現地計測、端末設置を分けます。無制限の設計変更を固定価格へ含めていないか確認します。

顧客から受け取る図面やBIMには機密性があり、完成物を営業デモへ使えるとは限りません。設計者、施工者、施主、撮影者など関係者との契約を確認します。点群や空間スキャンは建物内部、セキュリティ設備、位置情報を含むことがあるため、保存場所とアクセス権を整理します。買い手が建設DXや不動産販売の顧客を持つなら、VR単体ではなく、見積、図面管理、販売、遠隔打合せと接続できる点を共同成長仮説にします。

観光・文化財・地域プロモーション

観光XRでは、地域の物語、場所、季節、住民、文化資源を理解して制作する能力が価値です。自治体、DMO、観光協会、文化施設、交通、商店など多くの関係者が関わります。譲渡企業は、誰が企画・監修し、どの許可を得て、公開期間と更新責任をどう定めたかを整理します。補助事業で作られたコンテンツは、補助金の条件、財産処分、成果物の扱い、報告義務を確認します。翌年度も同じ予算が付くと断定せず、年度ごとの契約と継続要因を示します。

文化財、寺社、展示物、地域住民、出演者の映像には、著作権以外の利用条件も関わり得ます。撮影許可が「当該イベントの期間中」に限定されていれば、恒久サービスや別媒体へ転用できない可能性があります。位置連動ARでは、現地の安全、歩行導線、通信、GPS精度、端末貸出、外国語対応、問い合わせ窓口も運用資産です。買い手が全国営業を持っていても、地域で築いた関係を短期間で置き換えられないため、代表者や地域担当が誰へ、どの順序で関係を引き継ぐか計画します。

教育・研修・学校向けコンテンツ

教育向けでは、面白さだけでなく、学習目標、指導案、評価、教員が運用できる簡便さ、端末台数、授業時間への適合が価値です。単発イベントと、授業・企業研修へ組み込まれた継続利用を分けます。アカウント発行、受講履歴、教材更新、サポート、端末清掃に必要な時間を測り、ライセンス売上と運用原価を示します。児童・生徒が利用する場合、学校・保護者との説明、年齢、健康・安全、個人情報の扱いを案件ごとに確認します。

買い手がLMS、研修会社、出版社、学校ネットワークを持つなら、XRコンテンツを既存教材・受講管理と統合できる可能性があります。ただし教材内の写真、文章、音声、キャラクターの権利が、別プラットフォーム配信や改変を許すか確認します。教員個人との関係だけに依存している導入は、学校組織の承認や年度予算に移せるかが継続性の論点です。導入校数だけでなく、実利用回数、更新率、教員研修の負荷を説明します。

医療・福祉・ヘルスケア分野

医療・福祉向けVRでは、教育、リハビリ、心理支援、施設案内など目的によって必要な検証と規制が異なります。「医療に使える」と広く表現せず、誰が、どの場面で、何の目的に使い、医療機器該当性や広告、専門家監修をどのように確認したかを示します。臨床的な効果を公表する場合は、研究設計、対象、限界、根拠を確認し、営業上の感想と科学的な効果を混同しません。

患者・利用者の顔、音声、身体動作、症状、診療情報に関わるデータは、特に慎重な管理が必要です。取得しない設計にできるデータは取得せず、取得目的、アクセス、保存期間、委託、削除を記録します。HMDの衛生、転倒、酔い、介助、緊急停止の運用もコンテンツと一体です。買い手が医療機関との関係を持っていても、サービスの適法性や安全性が自動的に保証されるわけではありません。専門家・顧客と確認し、未検証の用途を成長計画へ確定事項として入れない姿勢が価値を守ります。

小売・ショールーム・不動産販売

小売やショールーム向けでは、体験から商談・購買へつながる導線、商品データの更新、店舗スタッフの運用、アクセス解析が価値です。展示会用の一度きりの演出と、商品入替に合わせて継続更新できる基盤を分けます。体験者数だけでなく、商談化、滞在、比較、問い合わせなど顧客が重視する指標を確認します。指標が取得できない案件では、ログ追加の費用とプライバシーへの影響を検討します。

商品3D、ブランド、店舗写真、出演者、BGMは利用媒体と期間を確認します。顧客が提供した高精細CADを自社製品へ転用してはいけません。WebAR、スマホ、店頭HMDなど複数端末を使う場合、どのコードとコンテンツが共通で、どこに個別対応があるかを示します。買い手がECやCRMを持つなら、XRを独立した「体験」で終わらせず、商品情報、在庫、予約、顧客管理へ接続する共同提案を具体化できます。

イベント・ロケーションベース体験

イベント、アミューズメント、展示施設では、多人数運用、回転率、安全、現地ネットワーク、設営撤去が収益を左右します。コンテンツの見栄えが良くても、一人の設定に時間がかかる、スタッフが常時付き添う、故障時に止まるなら横展開は難しくなります。一時間当たり体験人数、必要スタッフ、消毒・充電、予備機、エラー率、現地対応日数を測ります。売上がイベント制作費だけか、保守、ライセンス、更新、機材レンタルへ継続するかを分けます。

会場、主催者、出演者、スポンサー、機材会社との契約期間が終了した後、コンテンツをどこまで再利用できるか確認します。安全事故や体調不良の対応記録、保険、年齢・身長制限、注意表示も承継対象です。買い手がイベント営業を持つ場合は提案件数が増える可能性がありますが、現地運用能力がボトルネックになります。制作チームと運営チームを別々に評価し、必要な協力会社との継続契約を確認します。

M&A交渉中も本業を弱らせない経営管理

M&Aの検討が始まると、経営者と管理責任者は資料作成、質問回答、面談に時間を取られます。その結果、営業、採用、請求、案件レビューが遅れ、交渉開始時より業績が悪化することがあります。まず案件対応とM&A対応の役割を分け、週に使う時間の上限、回答担当、専門家への確認経路を決めます。買い手の質問は一つの台帳で受け、同じ資料を何度も作らないようにします。重要な顧客納期と月次締めは、交渉予定より先にカレンダーへ固定します。

予算は、通常計画、下振れ、交渉長期化の三つを置きます。M&Aが成立する前提で採用や投資を止めると、成約しなかった場合に競争力を失います。一方、買い手に良く見せるため無理に売上を前倒ししたり、必要な保守を先送りしたりしてはいけません。通常の経営判断を続け、例外的な支出・値引き・契約は記録します。月次で受注残、現預金、売掛、稼働、粗利、退職意向を確認し、重大な変化はアドバイザーや買い手へ適切に共有します。

情報を知る社員を必要最小限にする一方、一人へ負担を集中させません。秘密保持の範囲内で、財務、法務、技術、人事の資料責任者を分けます。噂や不安が生じた場合の回答方針も用意します。交渉が中断しても会社が自立して運営できることが、結果的に譲渡企業の交渉力を守ります。M&Aを特別プロジェクトとして管理しつつ、本業の顧客価値を最優先することが大切です。

VR/XR会社に合うM&A支援者を選ぶ確認項目

支援者を選ぶ際は、成約件数や知名度だけでなく、VR/XR受託の案件採算、ソフトウェア・コンテンツの権利、エンジニア組織、アプリ・クラウド移管を理解できるかを確認します。一般的な会社概要だけを作り、技術資産を「システム一式」と記載する支援では、買い手へ独自価値が伝わりません。反対に技術だけを評価し、顧客契約、財務、労務を軽視するのも危険です。必要に応じて法務、会計、税務、労務、技術の専門家と連携できる体制を見ます。

契約前に、仲介かFAか、誰から報酬を受けるか、着手・月額・中間・成功報酬、最低報酬、専任、契約期間、解約、テール、相手方手数料、利益相反、候補先の選定方法、情報漏えい時の対応を確認します。手数料が高い・低いだけでなく、何の業務が含まれるかを比較します。中小M&Aガイドライン第3版も、支援内容・質と対価、相手方手数料を含む確認の重要性を示しています。重要事項説明を受け、分からない条項は署名前に質問します。

支援者へ任せきりにせず、候補先ごとの打診理由と反応を譲渡企業が把握します。機密性の高い実績をいつ、誰へ、どの形式で出すかを合意します。支援者が「必ず高く売れる」「何か月で確実に成約する」と断定する場合は根拠を確認します。良い支援者は、売却しない選択肢や課題も伝え、経営者が判断できる材料を整えます。

自社の売却準備度を5段階で診断する

準備の進み具合は、資料の枚数ではなく、第三者が検証して事業を継続できるかで評価します。次の五段階を財務、顧客、技術、権利、人材、アカウントの各領域に当てはめてください。会社全体を一つの点数にせず、領域別に弱点を見つけることが目的です。

1. レベル1・個人の記憶：数字、契約、ビルド、顧客経緯を担当者だけが知り、資料の所在が不明です。最初の行動は、問題を直すことより所有者と保存場所を一覧にすることです。
2. レベル2・資料はあるが分断：会計、案件管理、Git、契約が別々に存在し、案件番号や資産名で結び付けられません。共通IDと台帳を作り、同じ案件の売上・工数・権利をたどれるようにします。
3. レベル3・説明可能：経営者と担当者が、顧客継続、案件採算、技術構成、権利、依存を根拠資料とともに説明できます。ただし担当者以外の再現テストや承継訓練は十分でない状態です。
4. レベル4・第三者が再現可能：副担当が見積・運用・ビルドを実行し、欠落と例外が記録されています。個人アカウント依存が解消され、顧客・社員・アカウントの移行計画を日程へ落とせます。
5. レベル5・成長へ接続：買い手の顧客・能力と自社資産を結ぶ共同案件、投資、責任者、KPIが具体化し、単なる現状維持を超えた承継計画を比較できます。

全領域をレベル5にしてから相談する必要はありません。顧客売上が大きいのに契約がレベル1、主要製品があるのにビルドがレベル2といった、事業停止へ直結する差を優先します。月に一度、証拠となる資料とテスト結果を添えて更新します。自己採点を高く見せるより、未解決事項、責任者、期限が明確である方が買い手との対話に役立ちます。

相談前の6か月で企業価値を守る三つの改善

低採算案件を断つのではなく、採算条件を設計し直す

赤字案件を一斉にやめると売上と顧客関係が急変します。まず見積と実績の差を、要件追加、3D修正、端末、現地、保守、PMに分けます。PoCでは検証項目と終了条件を定め、本開発の見積を自動的に拘束しないようにします。無償修正は回数と期間を契約へ反映し、追加要望の承認者を決めます。顧客へ単純な値上げを求めるだけでなく、不要機能を減らす、共通部品を使う、端末運用を別サービスにするなど、顧客成果を保ちながら粗利を改善します。買い手には、過去の赤字を隠すのではなく、原因別の改善後実績を示します。

単発売上を、更新理由のある継続関係へ変える

すべてを月額課金にすれば企業価値が上がるわけではありません。顧客が継続して必要とする更新、OS・SDK検証、端末管理、利用分析、コンテンツ追加、問い合わせを定義し、その原価とSLAを設計します。利用されていないサービスを自動更新で残すより、顧客業務へ定着した理由を示せる方が健全です。契約更新率、利用回数、追加拠点、問い合わせ、解約理由を測ります。買い手の既存サービスと統合する余地も、顧客の同意やデータ条件を無視せず整理します。

技術的負債をゼロにせず、返済計画を見える化する

売却前に全プロジェクトを最新化するのは、費用と障害リスクの面で現実的でないことがあります。顧客利用、セキュリティ、ビルド不能、端末終了へ直結する負債を優先し、影響が小さいものは理由と対応時期を記録します。エンジン更新では、元の安定版をタグとバックアップで残し、テスト端末と受入条件を決めます。依存パッケージ、警告、既知不具合、回避策を一覧にし、担当者以外が理解できる説明を付けます。「負債なし」と断定するより、範囲、優先度、必要工数が明確な会社の方が買い手は投資計画を立てやすくなります。

この三つの改善は短期的に利益を作って見せる操作ではありません。顧客価値、社員負荷、技術品質を同時に整え、単独経営でも持続する会社へ近づける施策です。改善前後の定義を変えず、数値と判断記録を残してください。

買い手向け初期説明資料を10ページで組み立てる

初期説明は、分厚いデータルームの索引ではなく、買い手が「なぜ検討するか」「次に何を確認するか」を判断する資料です。顧客秘密と個人情報を伏せ、次の順序で作ると、技術紹介だけ・財務紹介だけへ偏りません。

1. 会社と譲渡目的：沿革、拠点、株主、検討理由、実現したい承継を一枚にします。危機を隠さず、成長課題と対応させます。
2. 顧客課題と提供価値：VR、AR、MRという名称より、誰のどの業務を改善するかを業界別に示します。
3. サービス構成：企画、PoC、本開発、3D・映像、端末、クラウド、保守のうち、自社が担う範囲を図示します。
4. 売上と正常収益力：三期推移、月次、調整項目を示し、補助金や一時案件を区別します。
5. 案件ポートフォリオ：PoC、本開発、横展開、保守の件数・売上・粗利・移行率を同じ定義で示します。
6. 顧客継続性：上位依存、リピート、契約、受注残を匿名化し、経営者依存と引継ぎを説明します。
7. チーム：職種、スキル、副担当、採用、定着を示し、個人名と処遇情報は開示段階を管理します。
8. 技術・権利資産：再利用基盤、ビルド、エンジン、外部資産、権利台帳の整備状況と未解決を示します。
9. 成長機会：買い手の顧客・営業・隣接技術と接続する共同案件を、必要投資を含めて複数案示します。
10. 希望条件と次の確認：社員、拠点、代表者、ブランドの希望を確定条件と分け、次のデューデリジェンス範囲を提示します。

初期資料へ非公表顧客名、ソースコード、社員氏名、パスワードを入れません。数値には基準日と集計定義を付け、予測は前提を記載します。相手ごとに数字を変えて良く見せるのではなく、共通の事実資料に相手別シナジーを追加します。買い手からの質問で説明が伝わらなかった箇所を記録し、資料の構成と日常の経営管理を改善します。

まとめ｜企業価値を高める準備は、売却を決める前からできる

VR会社 売却の成否を分けるのは、派手なデモの数ではありません。売上が利益へ変わる仕組み、顧客が継続する理由、第三者が開発・運用できる手順、コンテンツを利用し続けられる権利、社員が次の環境で力を発揮できる計画です。24項目のうち、いま不足しているものが多くても問題ありません。欠落を認識し、重要度を決め、記録を始めることが最初の企業価値向上です。

準備では、事実、推測、将来目標を混ぜないことを徹底してください。公開資料や社内資料で確認できる事実、経営者の見通し、買い手との共同仮説を分ける会社は、交渉でも信頼を得やすくなります。そして価格、社員、顧客、地域、技術の将来を一つの条件として比較し、自社に合う承継を選ぶことが重要です。