kintone導入支援会社の価値は、アプリを作る速さだけではありません。顧客の業務を整理し、権限とデータを設計し、利用開始後の変更や外部連携を継続して支える仕組みにあります。M&Aでは、その仕組みを別の担当者が引き継げるかを具体的な台帳と運用記録で確認します。
このガイドは、伴走保守、アプリ設定、連携、プラグイン、業務改善人材を承継するための準備項目をまとめています。特定の売却倍率、成約事例、サイボウズの承認やパートナー資格の自動承継を示すものではありません。
アプリ構築と伴走保守を分けて継続性を説明する
kintone支援には、要件整理、アプリ構築、既存データの移行、権限設定、利用者教育、プラグイン導入、外部システム連携、運用改善があります。ノーコードで作れる部分と、JavaScriptなどのカスタマイズや外部連携が必要な部分では、技術と保守負担が違います。
| 区分 | 確認する資料 | 採算への影響 |
|---|---|---|
| 初期構築・移行 | 業務整理、アプリ数、移行対象、検収条件 | 追加要望、データ修正、操作説明に必要な時間 |
| 月額伴走・保守 | 更新実績、対応範囲、問い合わせと変更履歴 | 月額内の改修、顧客訪問、緊急対応の工数 |
| 連携・カスタマイズ | 連携仕様、コード、テスト、外部サービス | 仕様変更や障害復旧の責任と追加費用 |
| プラグイン等の提供 | 利用契約、販売・課金方式、更新、サポート | 仕入・利用料と自社報酬の区分 |
継続収益は、契約が月額であることだけで説明できません。顧客がどの改善支援を利用し、誰が対応し、どれだけ時間がかかっているかを示します。依頼内容を記録せず、経営者の判断で無償対応を重ねている場合は、買い手が利益を再現しにくくなります。
顧客の業種や地域、訪問対応、問い合わせ時間帯も整理します。遠隔支援だけで継続できる顧客と、現場での業務理解が必要な顧客では、担当交代と拠点の条件が異なります。商圏の広さだけを強調せず、継続に必要な体制を示します。
アプリ一覧を業務仕様と運用責任に結び付ける
承継対象を「顧客のkintone一式」とまとめず、顧客の利用環境、契約名義、自社のアクセス、保守対象を分けます。顧客が保有する業務データや環境は、支援会社が自由に処分できる資産ではありません。顧客との契約に基づき、支援を継続するための権限と資料を整理します。
| 対象 | 記録する情報 | 業務上の確認 |
|---|---|---|
| 環境とアプリ | ドメイン、スペース、アプリID、業務担当者 | どの業務で利用し、誰が設定を承認するか |
| データと関係 | フィールドコード、ルックアップ、関連アプリ | 項目変更が集計や他アプリへ与える影響 |
| 業務フロー | プロセス管理、通知、運用ルール、例外処理 | 承認待ち・担当不在時にも処理を続けられるか |
| 変更記録 | 設定・コードの版、テスト、変更日、承認者 | 現在の本番設定と資料の対応 |
アプリ名だけでは、依存関係を把握できません。フィールドコードやアプリIDを参照する連携、プラグイン、JavaScriptがある場合は、変更の影響を台帳へ記載します。資料がない案件は、実際の設定と利用者の業務を照合する作業時間も引継ぎ計画へ入れます。
データ移行を予定する場合は、対象データ、対応する項目、重複、関連情報、添付ファイル、検証方法、切替時刻を決めます。単にCSVを出力できることと、元の業務を移行先で再現できることは別です。業務の停止時間と切り戻し方針も顧客と確認します。
人の権限とAPIトークンの権限を別々に確認する
kintoneの権限は、アプリ、レコード、フィールドなど複数の範囲で設定できます。管理者を交代しただけで全ての利用条件が確認できたとは限りません。顧客の組織や役割に応じた権限を維持し、新担当者が実際に必要な作業を行えるかを確認します。
APIトークンを用いる連携では、トークンに設定した権限を確認します。公式ヘルプには、通常のアプリ・レコード・フィールドのアクセス権設定にかかわらず、APIトークンに設定したアクセス権が優先されることが説明されています。画面上のユーザー権限だけを見て、外部連携のデータ取得範囲を判断しないようにします。
- 連携ごとに、認証方式、実行元、対象アプリ、用途、管理者を記録する。
- APIトークンやパスワードを一般の売却資料に載せず、保管先と更新手順を示す。
- Webhookや外部サービスの受信先、障害通知、再実行の方法を確認する。
- 担当者変更や秘密情報の更新は、顧客の承認と連携のテストを合わせて実施する。
- 旧担当者のアクセスを削除する前に、定期処理と緊急対応を新体制で実行できるか確認する。
会計、顧客管理、EC、帳票などの連携は、それぞれ契約者、利用費用、サービス変更の影響を持ちます。連携先の仕様変更で作業が発生する場合に、月額保守へ含めるのか、追加費用とするのかを顧客契約と照合します。
プラグイン・カスタマイズ・テンプレートの権利と保守義務を見る
第三者製のプラグインは、購入先、契約名義、適用ドメイン、利用料、更新、サポート条件を整理します。会社を買えば、顧客のプラグイン契約や利用権を自由に変更できるとは限りません。M&A後の契約者・請求先変更が必要な場合は、提供元へ個別に確認します。
自社開発のプラグインや業種別テンプレートは、コード、設定、マニュアル、配布物を対応させます。顧客専用の成果物、汎用化できる部分、外注先の権利、第三者ライブラリを区分し、買い手が再利用できる範囲を示します。汎用化に追加の開発が必要なら、その工数を既存資産と混ぜずに説明します。
更新を続ける義務も資産と一緒に引き継ぐ
販売中のプラグインには、不具合の受付、動作確認、利用者への連絡、更新配布などの作業が伴います。自社の配布環境、ビルド手順、秘密情報の管理、問い合わせ履歴を整理し、開発担当者が不在でも対応できるかを確かめます。過去の販売数だけで収益資産と扱わず、保守工数と契約上の義務を確認します。
既存顧客のカスタマイズでは、元の実装者が誰か、修正できるコードが残っているか、どの設定変更で壊れやすいかを一覧にします。買い手に知られていない技術上の負担を減らすことが、実行後の伴走保守の安定につながります。
業務改善人材と顧客対応を最初の更新作業へつなげる
人材評価では、アプリ作成の技能に加え、顧客の業務を聞き取り、例外処理を整理し、変更内容を利用者へ説明できるかを見ます。営業・業務設計・構築・連携・保守の役割を分け、顧客ごとに主担当と副担当を記録します。経営者だけが顧客の業務背景を把握する状態は、同行と文書化で補います。
サイボウズとのパートナー関係がある場合は、対象契約、現在の体制、通知や確認が必要な事項を整理します。M&A後の資格・契約の扱いを、売り手の説明だけで確定させず、相手方と確認します。個々の技術者の技能と、会社としての契約関係は区別します。
売却準備では、顧客別損益、契約台帳、アプリと連携の台帳、権利一覧、担当技能、未解決事項を用意します。契約・財務の一般項目はWeb・IT会社M&AのDD資料ガイドで補えます。開示の段階に合わせて顧客情報を匿名化します。
実行後の初回変更では、新担当者が顧客と要件を確認し、設定変更、テスト、承認、反映、利用者説明まで進められるかを確認します。問い合わせの滞留、無償改修、連携障害、実工数も追い、顧客継続と利益の両方を見ます。引継ぎの期間、対象、経営者の支援時間、終了条件は具体化しておきます。
よくある質問
Q. 顧客のkintone環境と業務データも売却できますか？
A. 顧客が保有する環境やデータを、支援会社が自由に売却できるわけではありません。支援契約と顧客の意向に基づき、担当者、アクセス、保守の対象を引き継ぎます。
Q. 管理者を変更すれば権限の引継ぎは完了しますか？
A. アプリ・レコード・フィールドの権限や、連携に使うAPIトークンなども確認が必要です。新しい担当者と連携処理が、意図した範囲で動くことを確かめます。
Q. 自社テンプレートやプラグインは企業価値になりますか？
A. 再利用できる権利、利用実績、保守工数、継続課金、担当者の依存度によって評価が変わります。顧客専用の成果物と汎用資産を分けて整理します。
Q. 月額保守契約が多ければ安定収益といえますか？
A. 更新実績に加え、対応範囲、実工数、無償改修、外部サービス費用を確認します。月額で請求していても、担当者交代後に同じ採算を維持できるとは限りません。
確認した公式資料と相談先
権限の仕様はcybozu developer network：アプリのアクセス権、APIトークンの扱いはkintone公式ヘルプ：APIトークンを生成するを確認しました（確認日：2026年10月5日）。本稿の台帳・工程は売却準備の確認案であり、顧客環境を変更する操作手順ではありません。
編集責任：Web M&A総合センター編集部（運営：株式会社M&A Do）。個別の契約、権利、個人情報、税務については専門家と確認してください。
譲渡企業様の着手金・中間金・成功報酬は0円でご案内しています。外部専門家への報酬、税金、登記などは別途発生し得ます。条件はサービス案内で確認し、売却・資本提携の相談をご利用ください。
