公表案件の解説｜KATANAVI事業譲受から学ぶ金型DXのM&A

KATANAVI事業譲受を読む前に確認点があります。まず、本稿は2022年6月の公開案件を扱います。公表した会社は株式会社コアコンセプト・テクノロジーです。以下では同社を「CCT」と表記します。譲渡人はSOLIZE株式会社です。一方、金属M&Aセンターや当社の支援案件ではありません。当社は当事者から非公開情報を受けていません。そのため、本稿は公表資料を読み解く独自解説です。

本稿は公表事実と一般的な分析を分けます。まず、「開示事実」は一次資料の要約です。資料はCCTのニュースリリースを含みます。また、東京証券取引所の適時開示も対象です。基準日は2022年6月21日です。一方、「実務分析」は同種取引の一般論です。本件で実施されたDDの内容ではありません。契約交渉、移行、PMIの実施内容でもありません。そのため、未開示の売上や顧客数は断定しません。契約単価、利益、コード構成、人員移籍も同様です。

この案件の学びは譲受金額だけではありません。まず、公表された対象はKATANAVI事業です。販売と保守サービスの提供が含まれます。また、付随事業も対象です。主な事業資産には著作権と商標権が挙がります。つまり、金型工場そのものの取得ではありません。金型設計製造を支えるシステム事業の切出しです。そのため、設備や在庫中心のDDとは論点が異なります。知財、契約、保守、製品知識を確認します。さらに、データと開発環境の境界も言語化します。

KATANAVI事業譲受：本稿の読み方と結論

• 確認できる事実：CCTは2022年6月21日の取締役会でKATANAVI事業を譲り受けることを決議し、同日に契約を締結したと開示しました。
• 対象事業：KATANAVIの販売、保守サービス提供、それらに付随する一切の事業と記載されています。
• 主な事業資産：開示資料に明記されたのはKATANAVIの著作権・商標権です。
• 譲受金額：16百万円で、顧客との契約状況により変更となる可能性があるとされました。
• 予定日：公表時点の事業譲受予定日は2022年10月31日です。本稿は、この資料だけから実行完了を断定しません。
• CCTが示した目的：KATANAVIと同社のDX開発基盤「Orizuru」との親和性、ユーザー企業との契約承継による新規顧客獲得、収益性と競争力の向上です。
• 独自分析の要点：ソフトウェア事業の価値は権利名だけで決まらず、権利の範囲、実際に稼働させる資産、契約の承継可能性、保守知識、移行計画を一つの受入条件として検証する必要があります。

開示事実：KATANAVI事業譲受の全体像

以下の表は、CCT「KATANAVI事業譲受のお知らせ」と、2022年6月21日付「事業譲受のお知らせ」に記載された事項を整理したものです。なお、表中にない条件を補ってはいません。

項目	公表された内容	読み違えを防ぐ注記
譲受人	株式会社コアコンセプト・テクノロジー	開示時の証券コードは4371、グロース市場と記載
譲渡人	SOLIZE株式会社	CCTとの資本・人的関係は該当なし、取引関係としてソフトウェア開発受託の記載あり
対象	KATANAVIの販売および保守サービス提供の事業、ならびに付随する一切の事業	個別の契約・人員・データ一覧は任意開示に記載なし
主な資産	KATANAVIの著作権・商標権	「主な」と記載されており、詳細な資産明細は公表されていない
譲受金額	16百万円	顧客との契約状況により変更となる可能性、金額的影響は軽微との認識を記載
決議日	2022年6月21日	取締役会決議
契約締結日	2022年6月21日	開示資料の日程欄による
譲受予定日	2022年10月31日	公表時点の予定であり、本資料だけから完了を断定しない
当期業績への影響	2022年12月期への影響は軽微との認識	個別の売上・利益予測は記載なし

開示事実：KATANAVIは何を支援するシステムか

CCTはKATANAVIの概要を公表しています。対象は金型設計製造です。業務支援と生産管理を行うシステムと説明しました。まず、製造状況の可視化が機能に挙がります。また、作業順序徹底の支援も含まれます。データと情報の伝達支援も対象です。さらに、ID認証と自動化でミス防止を支援します。ただし、これは公表文の機能分類です。本稿は画面、性能、対応設備を確認していません。導入方式と利用範囲も未確認です。

「金型DX」という表現から、CAD/CAM、加工シミュレーション、自動見積、設備制御まで含むと推測してはいけません。つまり、KATANAVIの任意開示が示すのは業務支援・生産管理の機能概要です。製品機能の詳細を評価するには、当時の仕様書、操作マニュアル、導入構成、顧客別カスタマイズを別途確認する必要がありますが、それらは本稿が参照した公表資料には含まれていません。

開示事実：CCTが説明したKATANAVI譲受の目的

CCTは、KATANAVIが同社の製造業・建設業向けDX開発基盤「Orizuru」と親和性が高いと説明しました。また、KATANAVIのユーザー企業との契約を引き継ぐことで新規顧客の獲得にもつながるとし、総合的に収益性向上と競争力強化に資すると判断した旨を公表しています。これは譲受人が開示した目的であって、実現した相乗効果の実績値ではありません。

現在のCCTが公表する事業内容を理解する参考としてCCTの事業成長モデルがあります。しかし、現行ページの内容を2022年当時の取引条件へ遡って当てはめることはしません。KATANAVI事業譲受の事実認定は2022年6月の開示資料を優先します。

開示事実：譲渡人との関係と任意開示の限界

適時開示資料の相手先概要では、SOLIZEとCCTの間に資本関係・人的関係はないとされ、取引関係としてCCTがSOLIZEからソフトウェア開発を受託している旨が記載されています。また、関連当事者への該当もないとされています。この記載から、両社が取引前に一定の業務接点を持っていたことは読めますが、KATANAVIの開発分担、知識移転、交渉経緯まで推定することはできません。

資料は「任意開示のため、記載を一部省略」と明記しています。したがって、対象資産一覧、負債、従業員、顧客数、契約期間、収益、競合、技術構成、表明保証などが書かれていないことは、存在しないことを意味しません。KATANAVI公表案件を教材にする際は、「書かれていない」と「対象外」を区別します。

KATANAVI開示事実のタイムライン

日付	公表資料で確認できるイベント	確度
2022年6月21日	CCT取締役会がKATANAVI事業の譲受を決議	開示事実
2022年6月21日	契約書締結日	開示事実
2022年6月21日	東京証券取引所で任意開示	開示資料の日付
2022年6月22日	CCTのニュースページで案内	公式ページ掲載日
2022年10月31日	事業譲受日	公表時点の予定日

本稿が参照した二つの一次資料は、決議・契約締結時の開示です。KATANAVI事業の完了開示や最終金額は、この二資料から確認できません。そのため、以下では「公表された取引」「譲受の決議」「予定された承継」と表現し、実行後の成果を事実として扱いません。

実務分析：KATANAVIが事業譲受に適合し得る理由

ここからは一般的な実務分析です。なお、本件の非公開条件を示すものではありません。

欲しい事業単位を切り出せる

株式譲渡では株主が変わります。一方、対象会社の法人格は原則として残ります。資産、負債、契約、雇用関係も会社に残ります。事業譲渡・事業譲受は設計が異なります。まず、契約で対象事業を特定します。また、移す資産、権利、債務を選べます。そのため、一事業だけを取得する候補になります。例えば、KATANAVIのようなソフトウェア事業を切り出します。譲渡会社の他事業は残す設計です。

一方、選択できることは、境界を曖昧にしてよいことを意味しません。ソフトウェアの稼働には、プログラム著作権だけでなく、ソースコード、ビルド環境、開発ツール、第三者ライブラリ、仕様書、テスト、商標、ドメイン、顧客契約、保守履歴、問い合わせ基盤、担当者の知識が関係します。契約で移るものと移らないものを一件ずつ識別しなければ、「権利は取得したが保守できない」という空白が生じ得ます。

不要な負債を限定しやすいが、過去責任が自動的に消えるわけではない

事業譲受では引き受ける債務を定められます。そのため、他事業の負債を切り離しやすい面があります。しかし、名称だけでリスクは遮断されません。まず、製品保証と障害対応の責任を確認します。また、前受保守、返金、知財侵害も対象です。個人情報と顧客説明の責任も見ます。具体的な分担は契約、法令、個別事実で異なります。そこで、基準日前後の責任分担を定めます。さらに、求償、通知、顧客窓口も具体化します。

株式譲渡と事業譲渡の違いを一般論から確認したい場合は株式譲渡と事業譲渡の比較をご覧ください。しかし、KATANAVI事業譲受の契約条件は非公開です。一般的な長所・短所の採用は断定できません。

KATANAVIの契約承継が取引価値を左右する

ソフトウェア事業は多くの契約で支えられます。まず、継続的な保守契約と利用許諾があります。また、クラウドや外部サービス契約もあります。再委託、販売代理、開発委託も対象です。事業譲受では契約上の地位を移します。しかし、相手方同意が必要な場合があります。必要性は契約条項と法的手続で確認します。そのため、譲受日までの承継可否を調べます。承継できなければ新契約への切替えを検討します。さらに、切替えで条件が変わるかも確認します。

公表資料は譲受金額の変更可能性を示しています。条件は「顧客との契約状況」です。しかし、具体的な算式は開示されていません。顧客数、単価、同意状況も分かりません。一方、一般論では承継状況を対価へ連動できます。この設計は事業実体と価格を合わせる一案です。ただし、本件がその算式を採用したとは断定しません。そのため、16百万円を顧客数で割りません。顧客一社当たり価値も推測しません。

実務分析：KATANAVIの譲受対象を資産台帳へ落とす

以下はKATANAVIの対象物を推測したものではありません。同種取引で買い手が作る確認表の例です。

著作権という一語を成果物へ分解する

プログラムの著作権を確認するときは、製品名だけでなく、ソースコード、実行形式、データベース定義、画面、帳票、API、インストーラ、設定ツール、変換プログラム、試験コード、マニュアル、教育資料、アイコン、動画など成果物の一覧を作ります。また、各成果物に作成者、作成日、版を付けます。保管場所、権利者、第三者素材、顧客固有部分も記録します。最後に、対象資産表とリポジトリの実体を双方向に照合します。

成果物ごとに権利帰属の根拠は異なり得ます。まず、従業員が職務上作った部分を分けます。また、外部委託先が作った部分も確認します。顧客との共同開発部分も別に扱います。発注書の「成果物一式」だけでは足りません。著作権の移転範囲を確認します。さらに、二次的著作物に関する権利も見ます。著作者人格権の不行使や汎用部品も対象です。そこで、契約書、仕様書、検収、支払を対応させます。コミット履歴も照合し、弁護士と範囲を確認します。

文化庁は著作権登録の手引きを公表しています。手引きは著作権が財産権として譲渡できると説明します。また、譲渡登録の意味も解説しています。しかし、個別契約の移転範囲は別問題です。契約文言と事実関係で判断します。そのため、一般資料だけで結論を出しません。本件の任意開示には「著作権」とあります。一方、個別の登録有無は開示されていません。契約文言も推定しません。

商標権は名称だけでなく区分・地域・更新を確認する

商標権は登録単位で確認します。まず、登録番号、権利者、標章を調べます。また、指定商品・役務と区分も見ます。出願日、登録日、存続期間、更新期限も対象です。さらに、使用地域、ライセンス、質権、紛争を確認します。製品ロゴと各表記の権利者は同じとは限りません。ドメイン名やSNSアカウントも別管理の場合があります。そのため、名称の承継だけでは足りません。関連ドメインや広告アカウントも確認します。移らなければ顧客導線が切れる可能性があります。

特許庁は権利の移転等に関する手続を案内しています。対象には譲渡等による権利移転があります。また、原簿上の手続も説明しています。実務ではクロージング条件を確認します。次に、申請書類、登録免許税、原本を準備します。担当者と完了確認も日程へ置きます。しかし、本件の登録番号は公表資料から分かりません。移転登録の時期も確認できません。そのため、実施済みとは断定しません。

コードを動かすための「周辺権利」を列挙する

自社著作権だけを取得しても、第三者のライブラリ、フレームワーク、データベース、帳票エンジン、OS、クラウド、地図、フォント、画像、暗号モジュールを継続利用できなければ製品は動きません。しかし、オープンソースは無償でも無条件とは限りません。表示、ソース提供、改変、再配布の条件を確認します。さらに、商用ライセンスには譲渡禁止や主体限定があり得ます。

買い手はソフトウェア部品表を取得します。まず、名称、版、提供元を確認します。また、ライセンス、利用箇所、改変も見ます。脆弱性、契約者、更新期限も対象です。さらに、代替できるかを確かめます。自動スキャンだけでは完結しません。そこで、動的リンクと配布形態を法務・技術で評価します。顧客環境への導入方法も確認します。一方、譲受日までに移管できない部品もあり得ます。その場合、一時許諾、再契約、置換を検討します。さらに、移行サービスも選択肢です。

実務分析：顧客固有開発と標準製品を分ける

製造業向けシステムは、標準機能へ顧客固有の工程、設備接続、帳票、権限、マスター連携を追加することがあります。そのため、顧客固有コードが混在する場合は整理が必要です。別顧客への展開範囲と秘密保持を確認します。一方、重要機能を顧客が保有する場合は改修が制約されます。

同種取引では個別版の構成を確認します。まず、ブランチと機能フラグを数えます。また、設定ファイルと顧客別フォークも対象です。次に、標準版へ戻せない理由を分けます。技術的理由と契約上の理由は別です。多数の個別版には保守負担があります。売上が続いても改修工数は増え得ます。しかし、これは一般的な実務分析です。公表資料はKATANAVIの提供形態を示していません。個別開発状況も不明なため、本件の結論は出しません。

KATANAVI公表案件を踏まえた資産受入表

資産群	存在確認	権利確認	稼働確認	受入完了の例
ソース・実行物	リポジトリ、リリース媒体、ハッシュ	作成者、委託契約、第三者コード	再ビルド、テスト環境起動	買い手環境で同一版を再現
文書	仕様、設計、運用、教育、障害記録	作成主体、顧客秘密、利用範囲	文書と現行版の一致	保守担当が手順を実行
商標・名称	登録原簿、ロゴ、ドメイン	区分、地域、ライセンス、期限	顧客接点での利用	移転登録と導線切替を確認
第三者製品	部品表、契約、ライセンスキー	譲渡・再利用・配布条件	認証、更新、サポート	再契約または代替完了
顧客別資産	設定、アドオン、接続、データ辞書	帰属、秘密保持、再利用制限	顧客環境との互換	同意・移行試験・窓口通知

実務分析：KATANAVIを題材にプロダクトDDの七層を確かめる

第一層：ユーザー課題と機能の適合

金型設計製造には固有の業務があります。まず、個別受注と工程変動が生じます。また、熟練者依存と設計変更もあります。加工と測定を繰り返す場合もあります。そのため、製品デモだけでは評価できません。誰がどの課題を解くかを業務フローへ置きます。受注、設計、工程設計を確認します。さらに、調達、加工、外注、測定も見ます。修正と出荷も対象です。最後に、他システムへ委ねる範囲を分けます。

KATANAVIの公表資料は「製造状況の可視化」を挙げます。その価値は可視化する対象で異なります。一方、「作業順序徹底」には複数の実装が考えられます。推奨表示、制御、承認、警告などです。本件資料は詳細を示しません。そのため、DDでは用語を画面、入力、出力へ分けます。例外処理と顧客成果も確かめます。

第二層：製品ロードマップと保守可能性

現行顧客が利用する版、サポート終了版、開発中版、未リリース機能を一覧にします。次に、各版のリリース日と顧客数を確認します。重大障害、対応OS・DB、期限も見ます。その結果から維持する系統を決めます。最後に、行数や言語の新旧だけで価値を決めません。変更容易性、テスト、文書、要員、顧客制約も見ます。

技術的負債は、古い技術を使うこと自体ではありません。例えば、変更のたびに障害が広がる状態です。特定担当者だけがビルドできる場合も該当します。環境再現や依存製品の期限も負担です。重要項目ごとに解消費、期限、回避策、放置時影響を置きます。なお、本件の技術的負債は公表されていません。

第三層：アーキテクチャと外部接続

配置図、データフロー、ネットワーク、認証、外部IF、設備接続を確認します。次に、配置方式と顧客ごとの構成差を整理します。単一障害点、性能上限、バックアップ、ログも見ます。なお、工場には長寿命設備や閉域運用があります。一般的なWebサービスと同じ更新頻度にはできません。

設備接続には多くの要素が関係します。まず、工作機械、PLC、測定機を確認します。また、CAD/CAM、ERP、生産管理も対象です。接続には機器メーカー仕様が必要です。ドライバと通信プロトコルも確認します。さらに、顧客固有変換も見ます。接続数の多さだけで価値を決めません。再現性、契約権利、担当者知識を確かめます。テスト設備も対象です。なお、図面の論点は図面・CAD/CAMの属人化対策で解説しています。

第四層：品質保証とリリース

変更管理の証跡をサンプル機能で追います。まず、要求、設計、実装を確認します。また、レビュー、テスト、承認も対象です。配布とロールバックまで追います。次に、リリースノートとコミットを照合します。チケット、テスト結果、配布媒体も見ます。緊急修正が顧客環境だけに残る場合があります。しかし、標準版へ戻らなければ問題が再発し得ます。そのため、将来の更新経路まで確認します。

障害一覧は件数だけでなく、重大度、影響顧客、原因、暫定対応、恒久対応、再発、解決時間を見ます。しかし、分類が曖昧なら保守負担を過小評価します。未解決の既知不具合、回避手順、顧客への約束を譲受日までに引き継ぎます。

第五層：セキュリティと権限

アカウント、ID認証、権限ロール、パスワード・鍵、管理者操作、ログ、脆弱性管理、バックアップ、インシデント対応を確認します。しかし、公表文は認証方式を具体化していません。セキュリティ評価も述べていません。そのため、機能説明を安全性の証明とは解釈しません。

事業譲受では管理主体を切り替えます。まず、旧会社名義のクラウド管理者を確認します。また、コード署名証明書とVPNも対象です。共有メール、監視、ドメインも切り替えます。さらに、ライセンスサーバーも確認します。Day 1に止められない機能を分けます。一方、譲渡人が失うべきアクセスも特定します。移行期間に共同管理する項目も定めます。なお、情報セキュリティの論点は図面データ・サイバーDDの解説を参照できます。

第六層：開発・保守人材と知識

製品責任者、アーキテクト、開発、テスト、導入、保守、営業の役割をRACI表へします。しかし、誰が移籍するかは雇用・契約の論点です。本件の公表資料には記載がありません。そのため、人員が移らない場合は代替策を検討します。文書、研修、支援契約などで知識を移します。

重要なのは人数より代替可能性です。例えば、一人しか知らないビルド手順を抽出します。顧客固有設定、設備接続、契約経緯も対象です。録画や模擬障害で移転を確かめます。最後に、資料受領だけで完了にはしません。譲受側が構築、リリース、問い合わせ解決をできることが基準です。

第七層：運用コストと拡張余地

顧客別に、保守問い合わせ、障害、バージョン、個別改修、インフラ、訪問、第三者費用を整理します。しかし、売上高が同じでも保守負担は異なり得ます。古い個別版を抱える顧客には注意します。なお、本件の顧客別利益は公表されていません。収益性を推定せず、同種案件の測定項目だけを示します。

拡張余地は市場規模だけで決まりません。まず、標準機能で導入できる比率を見ます。また、設備接続の再利用性も確認します。営業チャネル、導入要員、支援能力も対象です。クロスセルにも前提があります。契約上の利用目的と顧客同意を確認します。さらに、営業関係と製品適合も必要です。公表資料は新規顧客獲得を目的に挙げました。しかし、その記述は獲得実績ではありません。そのため、目的と成果を分けて評価します。

実務分析：KATANAVIの顧客契約を承継可能性で評価する

この章は一般的なソフトウェア事業譲受の契約DDです。なお、KATANAVIの顧客数は公表されていません。契約内容と承継結果も同様です。

契約台帳と請求台帳を突き合わせる

顧客台帳には、顧客名、契約番号、製品版、拠点、ユーザー数、契約開始・終了、更新、料金、請求、入金、前受、解約、譲渡制限、変更支配、再委託、データ、知財、責任上限、準拠法を持たせます。しかし、契約書一覧だけでは口頭延長などを見逃します。そのため、直近請求と問い合わせ実績を合わせます。

一つの顧客に、ライセンス、導入、個別開発、保守、クラウド、機器が別契約で存在することがあります。そのため、顧客単位の契約束を作ります。一つだけ移してもサービスは完結しません。契約の名義と実際の利用会社がグループ内で異なる場合、利用許諾範囲と承継同意先を確認します。

譲渡・承継条項を個別に読む

まず、KATANAVIのような事業譲受では契約上の地位、債権、債務を分けます。知財とデータも同じ方法で移るとは限りません。契約譲渡に相手方の事前書面同意を求める条項、組織再編を例外とする条項、再委託を制限する条項を確認します。最後に、同意の要否は弁護士と確認します。事実関係と法令に基づき、営業慣行だけに頼りません。

同意取得表には、顧客、必要書類、通知先、交渉担当、送付日、回答日、条件変更、未回答理由を記録します。しかし、同意時に条件変更を求められる場合があります。その場合、単なる件数では価値が分かりません。元条件維持、条件変更、新規契約、非承継に分け、継続売上とコストを見直します。

保守義務と前受収益を切替日に合わせる

年額保守を前受する契約には調整が必要です。まず、譲受日後のサービス義務を確認します。また、受領済み現金の経済負担も見ます。未解決チケットと既知障害を整理します。さらに、更新権、無償修正、SLAも対象です。違約金とオンサイト支援の責任も分けます。譲渡人だけが代金を受け取る場合があります。一方、譲受人には残期間の履行が残り得ます。そのため、対価、負債、精算を整合させます。

切替日前後の問い合わせ窓口、請求名義、振込口座、サポート時間、障害連絡を顧客へ案内します。また、DNSやメール転送だけに依存しません。旧窓口への問い合わせも一定期間追跡します。重大障害時にどちらが一次対応し、どちらが技術支援するかを移行サービス契約へ置きます。

顧客集中は売上比率以外でも測る

顧客集中は売上だけで測りません。まず、保守工数と製品計画への影響を見ます。また、個別版と紹介力も対象です。解約時に共通機能を失うかも確認します。一社向け機能が他社にも使える場合があります。一方、特定顧客の要望が標準開発を支える場合もあります。そのため、売上比率以上の依存があり得ます。契約期間と更新履歴を調べます。さらに、利用者、ログイン、問い合わせを使います。最後に、これらから関係の深さを測ります。

契約承継を判定表へ落とし込む

本件の16百万円を顧客数で割り、「一社当たり価値」を推測することはできません。なぜなら、顧客数、売上、契約状態が非公表だからです。対価調整式も分かりません。公表価格から分かるのは、当初開示額と、契約状況による変更可能性が記載されたことだけです。

契約確認	Yesの場合	No・不明の場合	クロージング管理
有効な署名済み契約があるか	契約条件を台帳化	注文・請求・利用実績で関係を確認	新契約または確認書を検討
契約上の地位を承継できるか	通知・同意手順を実行	法務判断と顧客交渉	同意を前提条件・価格条件へ
前受保守があるか	残期間義務と金額を計算	請求・入金から再構成	精算、移行サービス、負債引受
未解決義務があるか	チケット・SLA・期限を引継ぎ	担当者ヒアリングと顧客確認	責任分界と求償を設定
第三者再委託が許されるか	委託先契約を整合	同意・内製化・代替を検討	Day 1体制の成立条件にする

実務分析：KATANAVIのデータ承継と個人情報を分ける

データを所有物のように一括表示しない

システムには多様なデータが含まれ得ます。まず、顧客の金型・部品情報があります。また、工程、設備、作業者の情報も対象です。ログ、問い合わせ、契約担当者も含み得ます。さらに、利用統計とバックアップも確認します。作成者と秘密情報の帰属は種類で異なります。利用目的、保存場所、削除時期も同様です。そのため、データ資産一覧を区分します。顧客業務データと個人情報を分けます。製品運用データ、統計、ログ、テストデータも分けます。

KATANAVIを題材にした事業価値分析でも、データ量だけで価値を決めません。利用権がなければ二次利用できないためです。まず、契約上の利用目的と秘密保持を確認します。匿名化、越境、再委託、保存期間も対象です。学習データや製品改善に使っていた場合、承継後も同じ利用が可能かを個別に検討します。なお、本件資料にはデータの種類がありません。利用条件の記載もありません。

個人情報は利用目的と安全管理を承継する

個人情報保護委員会の個人情報保護法ガイドライン（通則編）は、事業譲渡等に伴う個人データ提供や、承継前の利用目的の範囲について説明しています。しかし、実際の適用は個別事情で異なります。そのため、データマップや契約を専門家と確認します。

DD中に顧客担当者・利用者の個人データを開示する場合も、必要最小限、匿名化、閲覧権限、ダウンロード制限、ログ、案件不成立時削除を設計します。また、譲受後は管理者や問い合わせ先の変更を反映します。旧譲渡人のアクセスは移行に必要な範囲へ限ります。

移行時は完全性と削除の双方を証明する

データ移行はファイルを渡すだけではありません。まず、件数、期間、顧客、文字コードを確認します。添付、権限、ログ、鍵も対象です。移行前後のハッシュや統制合計を残します。読み取れること、業務で検索・更新できること、復元できることを受入試験します。

同時に、譲渡人側の本番、バックアップ、開発端末、チケット、メールに複製が残るかを整理します。法定保存、契約上の保管、紛争対応に必要なものと、削除すべきものを分け、削除証明またはアクセス遮断を行います。移行サービスで一時利用する場合は目的、期間、担当、返却・削除を契約化します。

実務分析：KATANAVIの16百万円という開示価格をどう読むか

売上倍率や顧客単価を逆算しない

公表資料は対象事業の売上高、営業利益、顧客数、契約期間を示していません。したがって、譲受金額16百万円から売上倍率、利益倍率、顧客一社当たり単価を逆算することはできません。対価には、対象資産、引受義務、移行支援、契約承継、税務、交渉条件が影響し得ますが、本件での内訳は公表されていません。

「金額的影響は軽微」との記載は、CCTが顧客契約状況による価格変更の影響を軽微と認識した旨、また2022年12月期業績への影響を軽微と認識した旨として読みます。しかし、対象事業に価値がないとは読めません。利益や失敗リスクの断定にも広げません。上場会社の全体規模に対する重要性と、製品戦略上の意味は別の軸です。

価格調整文言は検証可能な条件へ置き換える

一般的な契約には対価調整の方法があります。まず、顧客契約の承継数を基準にできます。また、年間契約価値、解約、同意取得も使えます。未収・前受や条件変更も候補です。ただし、どの方式でも定義が必要です。基準日時点と対象顧客を定めます。さらに、税抜・税込、更新見込、値引も明示します。返金、紛争、確認手続も対象です。顧客数だけでは小口と大口を同じに扱います。一方、金額だけでは採算や履行負担を無視します。そのため、指標は目的に合わせます。

KATANAVIの価格変更条項の算式は開示されていません。なお、記事中の例を本件へ当てはめないでください。公表案件から得られる実務上の問いは、「最終価格はいくらだったか」と推測することではなく、「顧客契約の状態を価格に結び付けるなら、何を測れば争いを減らせるか」です。

無形資産の会計・税務処理と事業価値を混同しない

事業譲受では会計・税務の検討が生じ得ます。まず、取得対価を資産と負債へ配分します。また、著作権と商標権の識別・評価を検討します。顧客関連資産とソフトウェアも対象です。のれんの扱いも確認します。しかし、適用基準と取引事実で結論は異なります。公表資料には「主な事業資産」とあります。ただし、その表現は買収会計の区分ではありません。そのため、資産区分を公表文だけで断定しません。

会計上の耐用年数や償却額は利益へ影響しますが、製品を維持・成長させる開発投資、顧客継続、技術陳腐化を直接示すものではありません。そのため、価値評価、PPA、税務、投資計画を連携させます。ただし、目的の違う数値は一つにまとめません。

説明用シナリオ：契約承継を対価へ連動させる場合

以下は完全な架空例であり、KATANAVIの顧客数、価格調整式、最終対価を示しません。例えば、架空の保守契約20件を考えます。16件は同条件で承継する設定です。2件は値下げ新契約、1件は回答待ち、1件は解約意向です。

単純な件数方式では18件を承継と数え得ます。しかし、件数と経済価値は一致しない場合があります。例えば、料金引下げ2件を考えます。年間契約価値は30％下がる設定です。未解決サポートが多い場合も負担が残ります。一方、年間契約価値方式にも限界があります。前受保守、履行原価、解約権を考慮します。更新月も確認が必要です。そのため、買い手は粗利益、移行費、解約確率を評価します。契約指標とは別に投資判断モデルを持ちます。

回答待ち顧客をクロージング後の追加対価対象とするなら、連絡期限、同条件の定義、売り手・買い手の営業努力、値引権限、紛争時資料を定めます。また、売り手と買い手の共同移行期間を置く場合があります。売り手は関係を維持し、買い手はサービスを説明します。いずれも本件で採用されたと述べるものではありません。

実務分析：KATANAVIとOrizuruの親和性を統合仮説へ変える

CCTがKATANAVIについて公表したのは、親和性が高いとの判断です。しかし、具体的な統合方式は開示されていません。開発計画と成果も同様です。以下は買い手が親和性を検証するための一般的方法です。

親和性を顧客・業務・データ・技術・販売の五面で定義する

製品同士の親和性は、同じ製造業向けというだけでは不十分です。第一に、顧客層が重なり、同じ意思決定者へ提案できるか。第二に、業務フローが連続し、一方の出力を他方が使えるか。第三に、品番、指図、工程、設備、作業者などのデータ定義を接続できるか。第四に、認証、API、配置、運用などの技術を統合できるか。第五に、営業・導入・保守体制が組み合わせ商品を扱えるかを確認します。

五つの面を実行可能な計画へ変えます。まず、仮説と必要証拠を置きます。また、責任者、期限、成功指標を定めます。例えば、既存顧客への提案を仮説にします。その場合、契約上の連絡可否を確認します。顧客課題、商談担当、製品適合も必要です。さらに、導入能力も見ます。データ連携の仮説にはAPI仕様が必要です。しかし、それだけでは足りません。マスターコード、更新時期、復旧、責任分界も確認します。

統合しない選択肢も比較する

買収後すぐに製品を一体化すると、既存顧客の安定運用を損なうおそれがあります。例えば、独立運営、販売連携、データ連携があります。共通認証、機能移植、製品統合も選択肢です。顧客価値、開発費、移行リスク、期間、保守二重化を比較し、ロードマップを決めます。

短期はブランドと製品を維持し、問い合わせ窓口と営業情報だけ連携する方が安全な場合があります。一方、依存技術の終了が迫るなら早期移行が必要です。買収を発表したから統合が前提とは限らず、顧客との約束と技術制約を基準に選びます。なお、本件が採用した方式は公表二資料から分かりません。

クロスセルは名簿移転ではなく課題適合から始める

契約を承継した顧客へ別製品を提案する場合、顧客情報の利用目的、営業連絡、秘密保持を確認します。しかし、既存契約は追加製品の需要を保証しません。ユーザー部門、IT部門、経営層それぞれの課題を把握し、現行KPIの改善と結び付けます。

クロスセルのKPIは商談数だけでなく、対象顧客の選定精度、提案から検証までの期間、導入工数、解約への影響、顧客満足を見ます。しかし、保守が不安定な時期の営業優先は信頼を損ないます。最初の目標を「サービスを途切れさせない」「問い合わせ回答を維持する」とすることも、長期の販売価値を守ります。

共通データモデルは現場用語から作る

金型製造では、型、部品、工程、指図、機械、工具、測定、改訂などの粒度が企業ごとに異なります。しかし、二製品で同じテーブル名でも意味は異なり得ます。統合チームは、現場で使う用語、識別子、版、単位、状態遷移をデータ辞書へし、変換規則を作ります。

いきなり全データを統合せず、遅延一覧、工程実績、設備状態など価値が明確なユースケースを一つ選び、読み取り連携から始めます。次に、原本の責任システムと更新権限を決めます。再送、エラー、監査ログも定め、整合性を測ります。金型DXの成否は画面の統一より、現場が同じ状態を同じ意味で使えるかに左右されます。

親和性の軸	検証質問	証拠	初期KPI
顧客	同じ課題・意思決定者へ届くか	顧客セグメント、商談、利用部門	適格顧客数、ヒアリング完了率
業務	前後工程の情報が連続するか	現行業務フロー、例外、手作業	二重入力削減、状態反映時間
データ	識別子・単位・版を対応できるか	データ辞書、サンプル、品質	結合率、エラー率、欠損率
技術	安全かつ保守可能に接続できるか	API、認証、配置、テスト	連携可用性、復旧時間
販売・運用	提案・導入・保守を一貫提供できるか	役割、技能、工数、SLA	引継完了率、一次解決率

実務分析：KATANAVIのDay 1までを逆算する

契約締結から譲受予定日までを逆算する

KATANAVI事業譲受の契約締結日から予定日までは約四か月です。しかし、この期間に何が行われたかは開示されていません。同種案件では、対象資産確定、顧客同意、知財移転、第三者契約、データ移行、システム受入、人員・知識移転、請求、サポート、告知を並行して進めます。最後に、各作業を三つの時期へ分けます。譲受日前、移行サービス、長期改善です。

Day 1の最低条件は、新機能の完成ではなく、顧客が契約どおり利用でき、障害窓口が機能し、請求・入金・ライセンス更新が止まらず、譲受人が必要な権利とアクセスを持つことです。そのため、必須条件を満たせなければ代替策を判断します。延期、段階移行、支援延長、対象除外が候補です。

カットオーバー台帳を一本化する

技術、法務、営業、経理が別々の移行表を持つと、顧客同意は済んだがライセンスキーを発行できないといった隙間が生じます。そこで、顧客か資産ごとに状態を一行へまとめます。契約、データ、技術、請求、支援、連絡が対象です。依存関係とGo／No-Go判定者を明確にします。

切替リハーサルでは、通常ログイン、管理者操作、バックアップ復元、ライセンス発行、問い合わせ受付、重大障害連絡、請求書発行を通します。また、譲渡人環境へ戻す条件と手順も決めます。実行ログ、画面、件数、時刻を残し、口頭の「問題なし」で完了させません。

移行サービス契約の出口を決める

譲渡人が一定期間、ホスティング、問い合わせ、開発、請求、メール転送などを支援することがあります。まず、サービス内容、担当、時間、料金を定めます。SLA、アクセス、知財、再委託、終了条件も明確にします。支援を受けられる安心から終了準備を後回しにすると、延長費用と依存が残ります。

各サービスに、買い手単独で実行できることを示す出口テストを設定します。例えば、ビルド支援には出口テストを置きます。買い手が再ビルドし、署名済み版を作れれば終了です。問い合わせ支援は、過去上位原因の模擬案件を解決し、エスカレーション先が明確なら終了とします。

実務分析：KATANAVIの100日PMIを具体化する

0～30日：継続性を証明する

最初の一か月は、顧客別の契約・版・窓口・未解決事項を毎週レビューします。また、重大障害、解約、請求漏れを監視します。ライセンス期限と未移行アクセスも対象です。譲受前後で問い合わせ件数や解決時間が変化したら、製品品質だけでなく窓口変更、担当知識、分類変更を確認します。

資産受入表の未完了を閉じ、リポジトリ、ドメイン、商標手続、第三者契約、バックアップを確認します。しかし、旧会社アカウントの即時削除は移行を妨げ得ます。そのため、期限と承認を設けた限定アクセスへ変えます。顧客データへの権限は最小化し、退職者・外部委託先の不要権限を停止します。

31～60日：製品と顧客の基準線を作る

顧客ごとの利用版、機能、接続、問い合わせ、保守工数を基準線にします。次に、標準版と個別版の差を可視化します。共通化候補と維持必須を選びます。売上データが利用可能なら契約価値と履行原価を結びますが、短期間の粗い配賦で解約判断をしません。

顧客ヒアリングでは、買収の説明だけでなく、製品を使う業務、止められない機能、不満、将来計画を聞きます。しかし、営業機会と保守課題は同じ面談で混ぜません。まず、継続への信頼を作ります。要望は声の大きさだけで順位付けせず、複数顧客への共通性、事業価値、実装費、リスクで評価します。

61～100日：統合ロードマップを承認する

独立維持、連携、統合の選択肢を比較し、12～24か月のロードマップを決めます。次に、依存製品の期限とセキュリティを織り込みます。法令、契約、更新月、開発能力も対象です。売上シナジー、コスト、投資、解約リスクを別の線で示し、期待だけを合算しません。

経営会議には一枚の統合報告を出します。まず、顧客継続とサービス水準を示します。また、資産受入と技術リスクも入れます。統合進捗と財務も同じ表で追います。買収価格が小さくても統制は必要です。特に、顧客の信頼やブランドへ影響する場合です。製造DX戦略への影響も確認します。一方、報告で現場保守を圧迫してはいけません。そのため、自動取得できる指標を優先します。

期間	顧客	製品・技術	事業管理	完了条件
Day 1	窓口・契約・通知	稼働、権限、バックアップ	請求、入金、責任者	サービス停止なく一次対応可能
0～30日	未解決・解約兆候	資産受入、重大脆弱性	移行サービス、週次KPI	重大な承継漏れを解消
31～60日	利用・要望の基準線	版・個別化・技術負債	契約価値と履行負担	製品別・顧客別の現状合意
61～100日	更新・提案計画	独立・連携・統合案	投資・シナジー・リスク	承認済みロードマップ

実務分析：KATANAVIのリスク登録簿をPMIへ引き継ぐ

DDで見つけた論点は、契約締結後に報告書へ閉じ込めず、リスクID、事実、影響、確率、証拠、所有者、期限、軽減策、残余リスクを付けて移行チームへ渡します。また、法務と技術が同じ事象を記載する場合があります。その場合は親子関係を付けます。

たとえば第三者ライブラリの移管不能は、法務上の使用権、技術上の置換、顧客上の停止、財務上の開発費にまたがります。そこで、一つのリスクとして統合します。短期は移行許諾、中期は置換など、時間軸で対策します。契約上補償を得ても、サービス停止は顧客関係を損なうため、運用対策は別途必要です。

リスク例	確認事実	未確認	契約対応候補	PMI対応候補
外部開発者の権利	契約・成果物・支払	全コミットの帰属	権利確認、補償、追加譲渡	コード棚卸と置換
顧客契約未同意	条項、連絡、回答	最終条件	前提条件、対価調整	新契約と顧客維持
保守知識の集中	担当、案件、文書	代替者の実行能力	移行支援、引継条件	ペア対応、模擬障害
旧環境依存	構成、契約、期限	移行所要期間	利用継続、費用分担	再構築、切替試験
データ利用制約	目的、契約、保存先	二次利用権	対象除外、同意、表明	分離、匿名化、削除

KATANAVI事業を譲り受ける買い手の資料依頼

以下は、KATANAVIのような同種案件で使える実務チェックリストです。なお、本件で実際に提出された資料は示しません。最初から全資料を無制限に求めるのではなく、重要性、秘密性、競争上の機微、取引段階に応じて、匿名・集計から個別へ段階開示します。

事業・製品

• 製品別の機能一覧、対象業務、提供方式、対応環境、リリース履歴、ロードマップ
• 標準版と顧客別版の関係、利用顧客、サポート期限、移行計画
• 競合比較、失注・解約理由、製品改善要望、重大障害、既知不具合
• 導入、教育、保守、追加開発の標準作業と実績工数

知的財産・ブランド

• 著作物台帳、ソースリポジトリ、コミット履歴、開発者、委託契約、検収証跡
• 商標登録、出願、更新、ロゴ、ドメイン、アカウント、ライセンス、紛争
• 第三者ソフトウェア部品表、オープンソース通知、商用ライセンス、再配布条件
• 顧客共同開発、顧客固有成果、秘密情報、再利用制限、著作者人格権の取扱い

顧客・契約

• 顧客・契約台帳、契約書、注文書、更新、譲渡・変更支配、解約、SLA、責任上限
• 請求、入金、前受、値引、返金、未収、保守期間、未履行義務
• 利用状況、版、拠点、ユーザー、問い合わせ、個別開発、更新見込み
• 契約承継の同意要否、連絡計画、回答状態、条件変更、代替契約

技術・運用

• アーキテクチャ、データフロー、外部接続、設備接続、認証、権限、ログ
• 開発・テスト・本番環境、ビルド、リリース、コード署名、バックアップ、復元
• 脆弱性、パッチ、インシデント、監視、障害、事業継続、災害復旧
• クラウド、データベース、ドメイン、証明書、ライセンスキーの契約名義と期限

データ・プライバシー

• データ分類、保管場所、利用目的、保存期間、削除、委託先、越境
• 個人情報台帳、プライバシーポリシー、同意、事故、開示請求、安全管理
• 顧客秘密、図面、工程、設備情報のアクセス、持出し、二次利用、匿名化
• 移行対象、対象外、変換、完全性確認、旧環境削除、法定保管

人員・移行

• 役割別体制、技能、属人業務、採用、外注、稼働、重要担当者の継続可能性
• 業務手順、運用記録、教育資料、引継項目、逆説明、模擬障害
• Day 1計画、カットオーバー、顧客通知、問い合わせ、請求、移行サービス
• 未完了条件、責任者、期限、Go／No-Go基準、ロールバック

資料は受領件数で管理せず、判断したい問いへ結び付けます。例えば、単に「著作権契約を受領済み」としません。必要な権利の有無を結論欄へ置きます。不足資料がある場合は、不足の理由、代替証拠、残るリスク、契約・PMIでの対応を記載します。

KATANAVIの経営者・製品責任者・顧客担当への質問

譲渡人経営者に聞くこと

なぜ今この事業を切り出すのか、譲渡後に残る事業との境界はどこか、共有資産・共有人員・共有顧客は何か、譲受人が単独運営するために欠けるものは何かを聞きます。また、将来計画だけでなく過去の中止機能を見ます。保守負担と顧客との未解決事項も確認します。回答は取引ストーリーとして受け止めつつ、契約、データ、現場へ照合します。

価格交渉と知識開示が対立しないよう、問題を発見した担当者が不利益を受けない対話を作ります。例えば、「課題はないか」より具体的に聞きます。復旧が長い障害、一人対応の顧客、次回更新の依存製品が対象です。

製品責任者・開発者に聞くこと

顧客が製品を選ぶ理由、止まると最も困る機能、標準版から外れる顧客、次の重大期限、再ビルドに必要なものを聞きます。また、画面デモでは正常系だけを見ません。通信断、権限誤り、設備停止、ロールバックも確認します。ソースコードの説明は設計意図と変更履歴に重点を置きます。

「古いが安定している」「新しいが未検証」「文書はないが自動テストが厚い」など、単純な成熟度点数では扱えない状態があります。そこで、リスクを発生可能性と顧客影響へ分けます。検出可能性と復旧時間も評価します。担当者の主観と、障害・コミット・テストの実績を並べます。

営業・保守担当に聞くこと

正式契約にない約束、無償対応、価格据置、次回更新の懸念、顧客側のキーパーソン、導入成果を聞きます。また、顧客満足を売上だけで判断しません。問い合わせの感情、遅延、停止、代替検討も見ます。承継通知で顧客が最も心配する点を把握し、説明資料とFAQへ反映します。

保守担当には、問い合わせ分類、一次解決率、エスカレーション、夜間休日、再現環境、顧客アクセス方法を聞きます。また、共有パスワードや個人端末を確認します。口頭の緊急連絡もDay 1前に管理します。属人的な顧客関係を否定せず、複数担当化と記録へ移します。

説明用ケース：架空の金型工程管理ソフトを譲り受ける

ここからの会社、製品、数値はすべて架空で、KATANAVIおよびCCT・SOLIZEとは無関係です。例えば、買い手B社が架空のM事業を譲り受ける設定です。対象は金型工程管理ソフトです。対象一覧には「プログラム著作権、製品名商標、顧客契約、保守資料」と記載され、顧客は12社と説明されました。

説明用の架空例では技術DDを行いました。現行版には外部委託の接続モジュールがありました。しかし、委託契約は成果物の利用許諾だけです。第三者への譲渡は明確ではありませんでした。また、ビルドは商用ライブラリへ依存していました。契約名義は譲渡人です。コード署名証明書も譲渡人名義でした。そのため、「著作権一式」だけで受入完了にしません。外部委託先との権利確認を条件にします。さらに、再契約と買い手名義での再ビルドも条件にします。

架空例の契約・保守・Day 1を検証する

説明用の架空例では顧客契約を調べました。12社のうち8社は書面同意が必要です。また、2社は年度更新の注文書だけでした。残る2社は販売代理店経由です。一方、売上は12社へ均等ではありません。上位2社が半分を占めます。そのうち1社は旧OS版を利用していました。そのため、買い手は承継社数だけで調整しません。同条件で承継する年間契約価値を使います。さらに、旧版移行費は投資モデルで別に評価します。

この架空例では保守記録も確認しました。問い合わせの四割を一人の技術者が処理していました。また、設備接続の障害手順は未文書化でした。技術者の移籍は前提ではありません。そこで、三か月の移行サービスを設けました。週二回のペア対応も行う設定です。さらに、上位20障害の模擬復旧も実施します。終了条件は資料受領ではありません。買い手担当がログから原因を特定します。最後に、テスト環境で修正版を出せることを確認します。

この架空例のDay 1は無停止でした。しかし、買い手は直ちに基盤を統合しませんでした。まず、60日で顧客版と契約を整理しました。次に、工程進捗の連携を一社で検証しました。連携は読み取り専用です。また、統合期待を価格へ全額織り込みませんでした。顧客同意と標準化率を確認しました。さらに、開発能力も確かめました。その後、確認結果に応じて投資を増やしました。この例は資産、契約、知識、統合順序を一体で示します。

KATANAVI公表案件を踏まえた売り手の切出し準備

共有物を分離し、対象・対象外・一時提供を決める

事業が会社全体の開発基盤、人事、経理、クラウド、営業、オフィスを共有している場合、単独事業としての境界を作ります。まず、恒久移転、対象外、一時提供へ分けます。対象外のものには代替策が必要です。共有契約の一部だけを移せない場合は、新規契約の費用と期間を早めに確認します。

コード、文書、チケット、メールを製品名検索だけで抽出すると漏れます。そこで、担当者、リポジトリ、顧客から棚卸しします。契約とインフラも使い、重複と欠落を処理します。対象外の他製品コードや顧客秘密が混入していないかも確認します。

顧客との信頼を承継計画の中心に置く

顧客通知には複数の目的があります。まず、必要な法的同意を得ます。また、サービス継続への不安を減らします。担当、製品計画、データも説明対象です。問い合わせと請求の窓口も示します。ただし、説明の時期と内容には制約があります。秘密保持、上場会社開示、契約に従います。そのため、譲渡人と譲受人で説明を統一します。一方だけの説明に偏ってはいけません。現行課題と将来体制の双方を伝えます。

未解決障害や無償約束を通知前に台帳化します。しかし、問題を隠して承継後に発覚すると信頼を失います。その損失は価格影響を超え得ます。重要問題には、顧客説明、暫定対応、恒久対応、費用負担、責任者を付けます。

知識移転を作業として見積もる

担当者の善意に依存せず、引継項目、所要時間、資料、実演、受講者、完了試験を計画します。また、顧客別説明、環境構築、リリースを含めます。障害、請求、契約更新も対象です。通常業務と引継ぎが同時に発生するため、必要工数と優先順位を経営が確保します。

売り手の準備は、欠点を消して見せることではありません。つまり、判明事項と不明事項を一貫して示します。誰がいつ解消するかも明記します。買い手が不確実性へ大きな割引を置くのは、課題が存在する場合だけでなく、課題の範囲を測れない場合です。

KATANAVI公表案件を踏まえた買い手会議の問い

• 取得したい顧客課題と製品機能は、契約上・技術上・運用上、実際に譲受可能か
• 著作権・商標以外に、単独運営へ不可欠な資産・権利・知識は何か
• 顧客契約が承継されない、または条件変更された場合の下方ケースは何か
• Day 1に止めてはならないサービスと、Go／No-Go条件は何か
• 旧環境・譲渡人・重要担当者への依存は、いつ、どの試験で解消するか
• セキュリティ、データ利用、第三者ライセンスの重大未解明事項は何か
• 独立維持、連携、統合の各案で、顧客価値、投資、期間、解約リスクはどう変わるか
• 公表された戦略目的を、どのKPIでいつ検証し、未達時に何を見直すか

KATANAVIのような案件の意思決定資料では、事実と仮説を分けます。未解明事項も別欄へ置きます。しかし、仮説を事実のように示すと前提がずれます。契約条項、予算、PMIへ影響します。本稿の構成も同じ理由で、開示事実と実務分析を分離しています。

KATANAVI公表案件から金属加工会社が学ぶこと

工場の価値と、工場を動かすソフトウェア事業の価値は別に切り出せる

KATANAVIの公表案件には特徴があります。金型工場の株式取得ではありません。金型設計製造を支えるシステム事業の譲受です。そのため、金属加工M&Aの価値を広く考えられます。価値の源泉は設備や土地だけではありません。受注や技能者だけとも限りません。例えば、工程ルールをソフトウェアへ実装できます。また、設備接続、原価・納期判断も実装できます。品質記録も同様です。これらは運営ノウハウと無形資産の両面を持ちます。

社内Excelやマクロだけでは事業価値を断定できません。まず、第三者へ提供できる権利が必要です。また、再現可能な導入と継続保守も求められます。顧客契約とセキュリティも確認します。担当者以外が理解できる文書も必要です。そのため、将来譲渡したいツールは平時から管理します。作成者と権利を台帳へ置きます。さらに、版、利用部署、外部部品も記録します。顧客データの有無も区分します。

業務知識を製品へ変えるには標準と個別の境界が必要

金型製造は個別性が高く、顧客ごとの工程・設備・承認に合わせる必要があります。しかし、すべてを個別コードにすると拡張しません。その知識自体は競争力です。標準データモデル、設定で吸収できる差、個別開発の条件、標準版への還元ルールを持つことが、製品事業としての再現性につながります。

M&Aの売り手は、顧客ごとのカスタマイズ一覧を欠点として隠すのではなく、標準、設定、アドオン、フォークへ分類します。一方、買い手は個別化の多さだけで否定しません。再利用権と保守費の回収可能性を見ます。

DXの価値は「可視化した」先の意思決定で測る

製造状況を画面へ表示しても、担当者が遅延を認識するだけでは成果は限定的です。そこで、変更者と期限を定めます。工程順序、外注、設備、納期の変更が対象です。さらに、成果指標を測ります。システム導入前後の定義を合わせ、繁忙度や製品構成の影響を分けます。

作業順序の徹底も、現場の裁量をすべて排除することではありません。しかし、計画から外れる合理的な理由もあります。緊急修理、材料遅延、設備故障を記録し、再計画へ返します。M&A後に機能を統合する場合は、売り手製品が持つ現場の例外知識を失わないよう、ユーザー観察と履歴分析を行います。

顧客契約は財務資産であると同時に移行プロジェクトである

継続契約は将来収益の入口ですが、事業譲受では承継同意、請求切替、データ管理、窓口、SLAを一社ずつ移す必要があります。また、対価連動だけでなく顧客説明を用意します。安心して同意できる運営体制も必要です。契約同意の遅れを法務だけの作業とせず、経営・営業・製品が共同で扱います。

売り手にとっては、署名済み契約、注文、請求、入金、保守が一致する台帳が価値を説明します。一方、買い手には顧客名簿だけでは足りません。継続理由、約束、履行負担が重要です。

KATANAVI案件で公表資料から言えないこと

公表案件の解説では、情報の空白を業界知識で埋める誘惑があります。なお、以下の事項は二つの一次資料に記載がありません。そのため、本稿では結論を出しません。

• KATANAVI事業の売上高、利益、顧客数、契約単価、解約率
• 16百万円の評価方法、価格調整の算式、最終的な支払額
• ソースコード、開発環境、データ、ドメイン、マニュアルなど個別資産の承継範囲
• 従業員の移籍・出向、外部委託先、移行サービス、知識移転の内容
• 顧客ごとの承継同意、契約条件、前受保守、未履行義務
• 技術構成、セキュリティ水準、障害、技術的負債、第三者ライセンス
• Orizuruとの具体的な連携方法、開発時期、統合費用、営業成果
• 2022年10月31日の実行完了、予定変更、完了時点の対象・価格

「公表されていない」と記すことは、問題があったと示唆するものではありません。なお、任意開示は記載範囲を絞る場合があります。当事者が非公開で調査した可能性もあります。本稿は、空白を一般的なDD質問へ変換することを目的とします。

KATANAVI公表案件を自社M&Aの教材にする五段階

第一段階：資料の性質と基準日を固定する

資料ごとに作成目的と情報範囲は違います。例えば、ニュース記事と適時開示は同じではありません。有価証券報告書、登記、取材も区別します。まず、一次資料を保存します。次に、発行者、日付、ページを記録します。任意・法定と予定・実績も分けます。また、検索要約だけで数値を転記しません。二次メディアからは当事者資料へ戻ります。本件の基準はCCT公式ページです。さらに、2022年6月21日付任意開示も基準にします。

後日更新された会社情報を、過去の取引時点へ無条件に当てはめません。しかし、現在の説明は2022年の対象事業を証明しません。当時の統合計画も同様です。逆に当時の予定が後に変更された可能性もあるため、事実を使う目的に応じて後続開示を探します。

第二段階：一文を「主体・行為・対象・時点・確度」へ分解する

「CCTがKATANAVIを取得した」では曖昧です。まず、事業譲受の決議か実行済みかを分けます。また、全資産の取得かも確認が必要です。本件の主体はCCTです。行為は事業譲受の決議と契約締結です。対象は公表された対象事業です。時点は2022年6月21日です。一方、譲受日は予定として記載します。そのため、この表現管理で断定を減らせます。

「主な事業資産」は、列挙された資産が重要であることを示しますが、完全な資産一覧とは限りません。一方、「業績への影響は軽微」は当期業績への認識です。製品価値や戦略効果まで軽微とは言えません。修飾語を落とさず引用趣旨を要約します。

第三段階：事実表と空白表を別に作る

事実表には資料で確認できる項目だけを置き、空白表には意思決定に必要だが未公表の項目を置きます。そこで、空白へ業界平均や推測値を入れません。自社案件で求める資料へ変換します。本記事で売上・顧客数・最終価格を推定せず、契約台帳、資産受入、価格調整定義の質問へ展開したのはこのためです。

空白はリスクの存在を意味しません。例えば、公表目的に照らして省略された可能性があります。表現は「確認できない」「記載がない」とし、「不足していた」「管理されていなかった」とは書きません。特に、対象会社の評判へ影響する公表案件で重要です。

第四段階：一般論には反証条件を付ける

「事業譲受は必要資産を選べる」という一般論にも、共有資産を分離できない、契約同意を得られない、重要人材が移らないという反証があります。また、クロスセル仮説にも成立条件があります。利用目的、顧客課題、導入能力、信頼が必要です。一般論を書くときは、成立条件と失敗条件を並べます。

反証条件は、自社案件のDD手続になります。例えば、親和性の仮説は五つに分けて検証します。顧客、業務、データ、技術、販売が対象です。検証できない部分はシナジーをゼロまたは段階的に置き、買収後のマイルストーンで投資を解放します。

第五段階：価格比較ではなく意思決定テンプレートへ変える

公表価格は、規模、対象、負債、競争、税務、時期が違えば直接比較できません。そこで、公表資料から四つの問いを自社案件へ移します。資産、対価、目的、予定と成果が対象です。すると、公表案件を模倣するのではなく、検証漏れを防ぐテンプレートとして使えます。

読み解き段階	KATANAVI公表資料での例	自社案件への変換
資料固定	2022年6月21日付任意開示	版・基準日・予定／実績を管理
文の分解	決議、契約、予定日を分離	主体・対象・時点・確度を記載
空白の識別	売上・顧客数等は未公表	推測せず資料依頼へ変換
反証	親和性の成果は未公表	五面の統合仮説を検証
実務化	契約状況による価格変更可能性	測定指標・算式・証拠を定義

KATANAVI公表案件を踏まえた取引前後チェック

• 公表資料とデータルーム資料を分け、出典・日付・版を記録した
• 事業、資産、負債、契約、人員、データの対象・対象外・共有を一覧化した
• 「主な資産」という表示だけでなく、単独運営に必要な全要素を確認した
• 現行リリースの全コードについて権利帰属と第三者条件を確認した
• 商標、ロゴ、ドメイン、証明書、アカウントの名義と切替日を確認した
• 買い手環境でビルド、テスト、リリース、復元を再現した
• 顧客別の契約束、承継同意、条件変更、前受、未解決義務を整理した
• 価格調整指標に基準日、対象、算式、証拠、紛争手続がある

KATANAVI公表案件を踏まえ承継後まで確認する

• 個人情報、顧客秘密、図面・工程データの利用目的と移行を確認した
• 譲渡人側に残る複製、バックアップ、アクセスの削除・保管を設計した
• 重要担当者が移らない場合の知識移転と完了試験を用意した
• Day 1の顧客窓口、障害、ライセンス、請求、入金をリハーサルした
• 移行サービスごとに内容、料金、SLA、アクセス、終了条件を定めた
• 既存顧客の安定と製品統合の優先順位を分けた
• 独立・連携・統合の選択肢を顧客価値、費用、期間、解約で比較した
• 売上シナジーを顧客同意、導入能力、実現費用、時期で検証した
• 未解明事項を契約、価格、条件、PMIのいずれかへ明示的に渡した
• 予定日と完了実績、開示目的と実現成果を混同していない

M&A全体の工程にこのチェックを配置する場合は金属加工会社M&Aの進め方もご参照ください。なお、必要な証拠と権限は案件段階で変わります。開示、基本合意、DD、最終契約、実行を分けます。

KATANAVI事業譲受のよくある質問

Q1．このKATANAVI案件は金属M&Aセンターの支援実績ですか

いいえ。なお、当社の支援実績ではありません。CCTとSOLIZEが公表した案件を、公開情報だけに基づいて独自に解説しています。また、当社は非公開資料やDD報告書を保有しません。契約書とPMI情報も同様です。

Q2．事業譲受は2022年10月31日に完了したのですか

参照した2022年6月21日付資料は、2022年10月31日を「予定」と記載しています。そのため、本稿は二資料だけから完了を断定しません。完了の有無や最終条件を確認する場合は、当事者の後続開示や正式資料を別途確認する必要があります。

Q3．譲受金額16百万円は安いのですか

公表資料に対象事業の売上、利益、顧客数、負債、移行条件、価格算式がないため、高い・安いを判断できません。また、全社業績への影響と戦略価値は分けます。「軽微」を同じ意味で読んではいけません。

Q4．価格が顧客契約状況で変わるとは、何件承継したという意味ですか

具体的な件数や算式は開示されていません。例えば、契約数、契約価値、同意条件を使えます。しかし、本件の採用方式は推測できません。記事中の価格調整例は同種取引の一般論です。

Q5．著作権と商標権を取得すればソフトウェア事業を運営できますか

それだけで足りるとは限りません。例えば、コード、第三者ライセンス、実行環境が必要です。契約、データ、文書、保守知識も対象です。開示資料の「主な事業資産」と、実際の資産明細・受入条件を分けて確認します。

Q6．事業譲受なら顧客契約は自動的に移りますか

契約条項や法的関係によって、相手方同意や新契約が必要となる場合があります。そのため、契約上の地位、債権、債務を個別に確認します。データも分け、弁護士の助言を受けます。本件の個別同意状況は公表されていません。

Q7．ソフトウェアDDではソースコードレビューだけで十分ですか

十分ではありません。例えば、製品課題、契約、権利、構成を評価します。セキュリティ、品質、運用、データ、人材も対象です。良いコードでも契約を承継できない、または重要知識が移らなければ事業継続に影響します。

Q8．Orizuruとの親和性が高いなら統合効果は確実ですか

公表資料はCCTの判断と目的を示しますが、成果を保証するものではありません。そこで、親和性を顧客、業務、データへ分けます。技術、販売、運用も分け、KPIや費用を検証します。本稿は実現した統合効果を示していません。

Q9．顧客データは事業譲受で自由に使えますか

自由に使えるとは限りません。まず、個人情報の利用目的と顧客契約を確認します。秘密保持、データの性質、委託関係も対象です。承継前の目的を超える利用には追加対応が必要となる場合があるため、個人情報・法務の専門家へ相談します。

Q10．重要な開発者が移籍しない場合、取引を断念すべきですか

必ずしもそうではありませんが、知識を移す代替策が実行可能かを試します。例えば、文書、ペア作業、研修を組み合わせます。模擬障害や委託継続も使い、単独運営を完了基準にします。

Q11．買収後すぐに自社プラットフォームへ統合すべきですか

顧客安定、技術期限、統合効果によります。例えば、独立維持、販売連携、データ連携を比較します。段階統合と機能移植も候補です。買収成立を統合の理由にせず、顧客価値とリスクを基準に選びます。

Q12．小規模なソフトウェア事業でも大規模なDDが必要ですか

取引規模に合わせて効率化できますが、Day 1に必要な権利、顧客契約、データ、ビルド、保守は省けません。そこで、現行リリースと重要顧客へ調査を絞れます。重大障害と重要担当も見て、不確実性を契約とPMIへ渡します。

Q13．売り手はいつから切出し準備を始めるべきですか

譲渡検討前から資産・権利・契約台帳を整えるのが理想です。まず、候補探索前に共有資産と顧客同意を把握します。外部委託権利、重要担当、移行期間も確認します。準備期間が長いほど、買い手の不確実性と顧客への混乱を減らしやすくなります。

Q14．公表案件の記事を自社評価の根拠に使えますか

参考にはできますが、価格の直接比較には向きません。なぜなら、対象資産、収益、顧客、契約が異なるためです。技術、時期、買い手戦略も違います。公表案件からは、確認項目と取引構造の考え方を学び、自社データで個別評価します。

KATANAVIの一次資料・公的参考資料

• CCT「KATANAVI事業譲受のお知らせ」：決議、製品概要、譲受目的、予定日を確認した公式ニュースです。
• CCT「事業譲受のお知らせ」（2022年6月21日）：対象事業、主な事業資産、16百万円、相手先概要、日程、業績影響を確認した任意開示です。
• 文化庁「著作権に関する登録をお考えの方へ」：著作権譲渡と登録制度の一般的な参考資料です。
• 特許庁「権利の移転等に関する手続」：商標を含む登録権利の移転手続に関する公式案内です。
• 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」：事業承継に伴う個人データ取扱いの一般的な確認先です。

一次資料は公表時点の記載を正確に読むためのものです。なお、後続の法改正や現行サービスは最新版で確認します。取引完了状況には追加開示も必要です。

まとめ：KATANAVIを動く状態で受け入れる

KATANAVI事例から読める事実を整理します。まず、CCTは2022年6月21日に事業譲受を決議しました。譲渡人はSOLIZEです。対象は販売・保守と付随事業です。また、主な資産は著作権と商標権です。譲受金額は16百万円と公表されました。予定日は2022年10月31日です。さらに、Orizuruとの親和性を目的に挙げました。顧客契約承継による新規顧客獲得も説明しました。収益性と競争力の向上も目的です。しかし、これを超える条件や成果は二資料から断定できません。

KATANAVI事業を動く状態で受け入れる

実務では権利名や価格だけで価値を決めません。まず、コードをビルドできる状態を確認します。また、顧客契約を承継できるかを見ます。データは適法かつ安全に扱う必要があります。問い合わせへ答える体制も必要です。さらに、製品を改修できる状態まで受け入れます。金型DXのシナジーも製品名だけでは作れません。顧客、業務、データの接点を検証します。技術と運用の接点も確認します。その後、検証結果を計画へ変えます。

KATANAVIの公開案件は、価格比較より自社M&Aの質問設計へ活用してください。自社ソフトウェアの資産台帳、顧客契約、第三者権利、重要担当、データ、Day 1を今から整理すると、譲渡時の説明力だけでなく、日常の事業継続力も高められます。

KATANAVIの公表目的と成果を時系列で分ける

公表時点の目的と買収後の成果は分けます。まず、予定された承継の完了有無を確認します。また、価格条件の変更も調べます。顧客継続と製品連携の実現も対象です。しかし、これらは後続資料で確認すべき事項です。公式開示や当事者説明を時系列で見ます。後から得た情報を当初既知とは扱いません。そのため、当初仮説、実行、結果を三段階で残します。最後に、この記録を別案件の判断へ生かします。

免責事項：本稿は公表資料に基づく一般情報を提供します。根拠は公表資料であり、独自の実務解説を含みます。CCTやSOLIZEの委託・確認は受けていません。当社が本件を支援した事実もありません。また、未公表の契約条件やDDを推認しません。取引実行や統合成果も保証しません。さらに、投資、法務、会計、税務を推奨しません。知財、個人情報、セキュリティ判断も同様です。実際の案件では最新の一次資料を確認してください。そのうえで、弁護士、公認会計士、税理士へ相談してください。弁理士や情報セキュリティ専門家も対象です。なお、架空例は実在の企業、製品、数値と無関係です。