この記事の目次
- この記事の結論
- 「100日」は中小PMIガイドラインにある目途で、本記事の4つの区切りは編集上の例
- 最初の100日に変えるのは停止リスクが高いものだけ。ほかは引き継いで維持し、観察する
- Day1〜7：機能開発より先に、ドメイン・サーバー・決済・ストアの権限を買い手に移す
- Day8〜30：障害・問い合わせ・請求・契約を、売り手の頃と同じ水準で回し、現状を記録する
- Day31〜60：開発体制、セキュリティ、外注先との契約を、権限を確保した後に見直す
- Day61〜100：継続率・障害・解約・運営費を追い、データを見てから改善の施策を選ぶ
- 売り手の引継ぎ期間が終わる前に、属人化した作業が残っていないか最終確認する
- まとめ
- よくある質問（FAQ）
- 出典
Webサービスやアプリを買った直後は、新機能、デザインの刷新、料金の見直しなど、やりたいことが一度に出てきます。しかし、この時期に事業を止めてしまうと、買った価値そのものが下がります。この記事は、買収後の最初の100日を、何を引き継ぎ、何を維持し、何を後回しにするかという順番で整理します。
この記事の結論
- 最初の100日は、権限の確保、運営の安定、再点検、データに基づく改善の順に進めます。 先に機能開発へ行かず、止めないことを優先します。
- 「100日」は標準日程ではありません。 中小PMIガイドラインにある目途を使った、本記事の編集上の例です。
- 売り手の引継ぎ期間が終わる前に、属人化した作業が残っていないかを最終確認します。 在籍期間は、事前に決めて書面に残します。
この記事の対象：Webサービス・アプリ・プラットフォームを買った（または買う予定の）方。売り手として、買い手が何を引き継ごうとするかを知りたい方にも使えます。
業種全体の見方（利用者数、収益化、DDの論点）は、Webサービス・アプリのM&A DATAにまとめています。この記事は、そのうち買収後の進め方だけを扱います。
「100日」は中小PMIガイドラインにある目途で、本記事の4つの区切りは編集上の例
結論： 100日は、公的なガイドラインが、体制づくり・信頼関係・現状把握などを集中して進める目途として挙げている日数です（集中して取り組む時期全体は概ね1年）。日ごとの標準日程ではないので、自社の事情に合わせて区切り直します。
中小企業庁の「中小PMIガイドライン～中小M&Aを成功に導くために～」は、M&A成立後の初日を Day.1、100日目を Day.100 と呼んでいます。M&A成立後の統合の取組を集中して行う時期（概ね1年）のうち、PMI推進体制の確立、関係者との信頼関係の構築、M&A成立後の現状把握などは「100日までを目途に集中的に実施」と書かれています。
ガイドラインに書かれているのは、この目途までです。「Day8〜30は何をする」といった日程表はありません。以下の区切りは、本記事の整理による例です。
| 区切り（本記事の例） | 主な目的 | 中心になる作業 |
|---|---|---|
| Day1〜7 | 止めない | ドメイン・サーバー・決済・ストアなどの権限を買い手に移す |
| Day8〜30 | 安定させる | 障害対応、問い合わせ、請求、契約の運営を同じ水準で回す |
| Day31〜60 | 再点検する | 開発体制、セキュリティ、外注先との契約を見直す |
| Day61〜100 | データから選ぶ | 継続率・障害・解約・運営費を見て、改善する施策を選ぶ |
同じガイドラインは、中小企業のPMIについて、財務的な成果を早期に実現することより、事業の継続や中長期の持続的な成長を目的に、数年単位で継続的に取り組む活動だと位置づけています。100日で終わる作業ではなく、その後も続く取組の最初の区切りとして読んでください。
最初の100日に変えるのは停止リスクが高いものだけ。ほかは引き継いで維持し、観察する
結論： 引き継いだ運営のやり方は、問題が見つかるまでは維持します。変えるのは、法令や事業停止のリスクが高いものから順にします。
ガイドラインは、引き継いだ事業を安定的に運営しつつ、改善すべき点に優先順位を付けて順次対応すること、特に法的リスクや事業停止リスクが高いものは速やかに対応することを挙げています。また、不利な取引条件が見つかっても、直ちに是正を求めると取引先との関係が悪化するおそれがあるとも書いています。これをWebサービスに当てはめると、次の整理になります（本記事の整理）。
| 区分 | 例 | 最初の100日の扱い |
|---|---|---|
| 引き継ぐ（買い手が持つ） | ドメイン、サーバー、ストアアカウント、決済、ソースコード、利用者・売上の記録 | Day1〜7を中心に、名義と操作権限を買い手へ移す |
| 維持する（変えずに回す） | 問い合わせ対応の流れ、課金の仕組み、既存の外注先、リリースの頻度 | 現状を記録しながらそのまま回し、問題の有無を見る |
| 変える（早めに対応する） | 権限が売り手個人に残っている箇所、バックアップが取れていない箇所、法令に関わる表示 | 停止や法令のリスクがあるものだけ、先に直す |
| 後回しにする | 料金改定、大きな機能追加、デザインの刷新、ブランド名の変更 | Day61〜100のデータを見てから、施策として選ぶ |
| 避けたい判断 | こうすればOK |
|---|---|
| 買った実感のあるうちに、料金と機能を大きく変える | 変更が利用者の離脱や問い合わせに与える影響を、データで見られる状態になってから選ぶ |
| 運営のやり方が気に入らないので、すべて作り直す | 止まると困る箇所と、直すと得をする箇所を分け、止まると困る箇所から手を付ける |
| 前の運営者の判断を否定する | 売り手に経緯を聞いて記録する（ガイドラインも、売り手や過去の取組への否定的な態度が協力関係を悪くした失敗例を挙げている） |
Day1〜7：機能開発より先に、ドメイン・サーバー・決済・ストアの権限を買い手に移す
結論： 最初の1週間の目的は、売り手がいなくなっても事業を止められない状態にすることです。権限を持つのが誰かを、一覧にして確かめます。
ガイドラインの失敗例には、売り手の経営者の承認がないと現場が判断できず業務が停滞したこと、資金管理を一手に担っていた人の退職で支払が滞ったことが載っています。Webサービスで同じことが起きやすい場所は、名義と操作権限です。次の表で、買い手が管理者になっているかを確かめます（本記事の整理）。
| 確認する権限 | 確認すること | 失うと困ること |
|---|---|---|
| ドメイン・DNS | 登録者の名義と、管理画面にログインできる人 | サイト・メール・認証が止まる |
| サーバー・クラウド | 契約者の名義、請求先、管理者権限 | 公開や課金の停止、費用の請求先のずれ |
| ストアの開発者アカウント | アカウントの名義、アプリの移管の要否 | 更新・審査・返金の対応ができない |
| 決済サービス | 契約者の名義、入金先、管理者権限 | 売上の入金先が売り手のまま残る |
| ソースコードの管理場所 | リポジトリの管理者、ビルドとデプロイの権限 | 修正が出せない |
| 外部API・メール配信・解析 | 契約者の名義、キーを再発行できる人 | 機能の停止、キーの流出時に対応できない |
| 管理画面・本人確認の手段 | 2段階認証や認証用の電話・メールの持ち主 | 買い手側では入れない |
ストアのアカウントやアプリの移管条件は、サービスごとに決まりがあります。具体的な条件と順番は、アプリ 売却 アカウント移管で整理しています。移管できるかどうかは、各事業者の規約で個別に確認してください。
| 避けたい判断 | こうすればOK |
|---|---|
| 売り手のIDとパスワードを聞いて、そのまま使う | 買い手の名義の管理者を作ってから、売り手側の権限を外す。誰がいつ操作したかが残る形にする |
| 動いているので、名義の確認は後回しにする | 名義が売り手個人のままのものを一覧にし、移管の期限を決める |
| 権限を1人にまとめる | 管理者を買い手側で複数にして、1人が不在でも止まらないようにする |
Day8〜30：障害・問い合わせ・請求・契約を、売り手の頃と同じ水準で回し、現状を記録する
結論： 引継ぎ直後は、運営の現状を見えるようにします。変更は急がず、売り手の頃の手順をそのまま回しながら記録します。
ガイドラインは、売り手の事業の現状把握の際、売り手の経営者や一部の従業員だけに属人化している業務があること、業務に関する規程や帳票がなかったり実態と違っていたりすることに注意するよう書いています。引継ぎ前のDDでは見つからないことがある、とも書かれています。Webサービスでは、次のような作業を、頻度ごとに洗い出します（本記事の整理）。
| 頻度 | 洗い出す作業の例 | 記録しておくこと |
|---|---|---|
| 毎日 | 障害の監視、問い合わせの確認、投稿・出品の審査 | 誰が、どの画面で、何を見ているか |
| 毎週 | バックアップの確認、売上・利用状況の集計、アプリの審査状況 | 手順、使う画面、判断の基準 |
| 毎月 | 請求・入金の照合、外注先への支払い、決済事業者や広告の精算 | 締め日、金額の確認方法、支払先 |
| 不定期 | 返金、退会、アカウントの削除、違反の対応 | 判断の基準と、過去の対応の記録 |
作業の洗い出しは、売り手に「何をしていますか」と聞くだけでは漏れます。ガイドラインは、担当者へのヒアリングや業務日報の確認、現場で一緒に業務を行うことで、手順を確認する方法を挙げています。Webサービスなら、売り手が実際に操作する画面を一緒に見ながら、画面共有で確かめる方法が当てはまります（本記事の整理）。
関係者への連絡も、この時期に済ませます。ガイドラインは、取引先に対して、M&A成立後すみやかに挨拶文を送る例として、成立日、譲受側の基本情報、問い合わせ先、新しい体制を示しています。提携先・外注先・決済事業者・広告の取引先には、同じ項目で連絡する形が使えます（本記事の整理）。利用者へ何を知らせるか、会員データを引き継いだあと利用目的を変えられるかは、Webサービス 売却 個人情報で整理しています。個別の判断は、弁護士に確認してください。
Day31〜60：開発体制、セキュリティ、外注先との契約を、権限を確保した後に見直す
結論： 運営が安定してから、開発の再現性、アクセス管理、外注先との役割分担を見直します。権限の確保が終わる前に始めない順番にします。
開発体制。 ソースコードから買い手側の環境でビルド・公開できるか、担当者が不在でも修正が出せるかを確かめます。コードと依存関係、権利の確認は、買収前の技術DDの観点と同じです（本記事の整理）。
セキュリティ。 米国の NIST が公表している「The NIST Cybersecurity Framework (CSF) 2.0」は、サイバーセキュリティの成果を Govern、Identify、Protect、Detect、Respond、Recover の6つの機能で整理しています。この文書は、成果をチェックリストとして示すものではなく、順序や大きさが実施の順番や重要度を意味しないとも説明しています。Identify はデータ・ハードウェア・ソフトウェア・システム・サービス・人などの資産を把握すること、Protect は認証・アクセス管理・データの保護などです。
NIST の文書は、買収後に何日目で何をするかを示すものではありません。本記事の整理では、Day1〜7で権限を確保した後に、次を見直す形に当てはめます。
| 見直す項目 | 確認すること |
|---|---|
| 資産の一覧 | サーバー、ドメイン、アカウント、外部サービス、データの置き場所が、一覧に載っているか |
| アクセス管理 | 退職した売り手側の人や、不要になった外注先のアカウントが残っていないか。管理者権限が必要な人に限られているか |
| バックアップ | 取れているだけでなく、買い手の環境で復元できるか |
| 障害・事故時の連絡 | 障害が起きたときに、誰が判断し、誰に連絡するかが決まっているか |
外注先との契約。 開発や運用を外部に頼んでいる場合は、契約の範囲と役割分担を確かめます。IPAが公開している「情報システム・モデル取引・契約書（第二版）」は、受託開発や保守運用の契約書のひな型と解説で、パッケージやSaaS/ASPを使う場合の追補版もあります。IPAの資料は、ユーザとベンダが、プロジェクトの開始に先立って、それぞれが果たす役割を認識し、具体的な役割分担を契約書で明確に定めるべきとしています。また、運用段階と保守段階は、別の契約書として扱う前提です。
このモデル契約は大企業の基幹システムの受託開発を主な前提にしたものと、中小企業ユーザ向けの追補版に分かれています。小さなWebサービスの外注にそのまま当てはめるのではなく、「どこまでが業務範囲か」「誰が何を判断するか」を確かめる項目の参考にします（本記事の整理）。
| 避けたい判断 | こうすればOK |
|---|---|
| 外注先との契約を、売り手と結んだまま放置する | 契約の当事者が誰か、買い手に引き継げるかを、契約ごとに確認する |
| 株式譲渡なので契約はそのまま続くと考える | 支配権の変動で相手方に解除権が生じる条項（ガイドラインの言う「チェンジ・オブ・コントロール条項」）がないかを確認する |
| 保守も開発も、口頭の約束で続ける | 業務の範囲、対応の時間、責任者を、書面で確認する |
契約の承継や条項の評価は、個別の事情で変わります。弁護士に確認してください。
Day61〜100：継続率・障害・解約・運営費を追い、データを見てから改善の施策を選ぶ
結論： 改善の施策は、最初の2か月で集めた数字を見て選びます。追う数字は、継続率、障害、解約、運営費の4つに絞ります。
ガイドラインは、中小企業の人員や資金には制約があり、全ての課題やリスクに対応することは必ずしも現実的ではないとして、目的を実現するために対応が必要な事項を選び、優先順位を付けて集中的に取り組むとしています。数字を絞るのも同じ考え方です。
| 追う数字 | 見る理由 | 注意 |
|---|---|---|
| 継続率 | 引継ぎで利用が離れていないかを見る | 買収前の数字と、買収後に自社で計測した数字の定義がそろっているか。定義の揃え方はアプリ 買収 MAUで整理している |
| 障害（回数と復旧までの時間） | 運営が安定しているかを見る | 買収前の記録が残っていなければ、買収後の記録を基準にする |
| 解約・退会 | 引継ぎや変更を理由とした離脱を見る | 理由が分かる問い合わせや退会時のアンケートがあれば合わせて見る |
| 運営費 | 引き継いだ費用の構造を見る | 売り手の人件費が買収後にどう置き換わるか、サーバー・外部サービスの請求先が変わっていないかを確認する |
数字を見る基準は、Day1時点の数字と、売り手が示した数字の差から作ります（本記事の整理）。売り手の数字と自社で計測した数字が合わないときは、集計の方法を確かめます。
| 避けたい判断 | こうすればOK |
|---|---|
| 数字が出そろう前に、大きな施策を決める | 4つの数字の動きを見てから、施策を1つずつ選ぶ |
| 継続率が下がったので、売り手の頃の運営が悪かったと決める | 買収の前後で、集計の方法やアプリのバージョンなど、他の要因が変わっていないかを確かめる |
| 複数の施策を同時に入れる | 1つずつ入れて、数字の変化を見分けられるようにする |
売り手の引継ぎ期間が終わる前に、属人化した作業が残っていないか最終確認する
結論： 売り手が在籍している間に、買い手が一人で回せるかを確かめます。在籍期間は事前に決め、期間内にできなかったことを、期間が終わる前に洗い出します。
ガイドラインは、売り手の経営者が引継ぎのために残る場合、役割・在籍期間を事前に合意しておくことを挙げています。失敗例には、引継ぎのための在籍期間を事前に定めていなかったため、売り手の影響力が長く残り、進めようとしていた改革の抵抗勢力になったことが載っています。また、属人化している業務では、担当者の記憶が曖昧だったり、不利な取引の発覚をおそれて意図的に引継ぎをしなかったりすることがある、とも書かれています。
引継ぎ期間が終わる前に、次の項目を確かめます（本記事の整理）。
| 最終確認 | 確かめ方 |
|---|---|
| 買い手が一人で実行できる作業 | 洗い出した作業を、売り手が見守る中で、買い手が実際に実行する |
| 売り手の個人名義のものが残っていないか | Day1〜7の一覧を見直し、名義が移っていないものを洗い出す |
| 売り手しか知らない取り決め | 外注先・提携先との口頭の約束や、例外的な対応を、一覧にして聞く |
| 問い合わせの窓口 | 利用者・取引先からの連絡先が、買い手側に切り替わっているか |
| 売り手の権限の停止 | 引継ぎが終わった時点で、売り手のアカウントの権限を外す時期を決める |
| 避けたい判断 | こうすればOK |
|---|---|
| 引継ぎ期間を「何となく」続ける | 役割、報酬、在籍期間を、事前に書面（覚書等）に明記する。見積もれないときは、半年更新のような形も検討する |
| 売り手が元気なうちは、最終確認をしなくてよいと考える | 期間の終わりより前に、買い手が実行する形で確かめる |
役割や報酬、在籍期間を定める契約の条項は、個別の事情で変わります。弁護士に確認してください。
まとめ
- 最初の100日は、権限の確保、運営の安定、再点検、データに基づく改善の順に進めます。変えるのは停止リスクの高いものだけにして、ほかは維持して観察します。
- 100日は中小PMIガイドラインにある目途で、本記事の4つの区切りは編集上の例です。サービスの規模や譲渡の方法で変わります。
- 売り手の引継ぎ期間が終わる前に、買い手が一人で回せるかを実行して確かめ、名義と属人化した作業が残っていないかを最終確認します。
自社の場合を確認する 買収を検討しているサービスの事業価値を、自社の数字で確かめたいとき → 事業価値を確認する
よくある質問（FAQ）
Q1. 買収後の「100日」は、官公庁が定めた標準の日程ですか？ A. 標準日程ではありません。中小PMIガイドラインは、PMI推進体制の確立、関係者との信頼関係の構築、M&A成立後の現状把握などを「100日までを目途に集中的に実施」と書いています。本記事の4つの区切り（Day1〜7、8〜30、31〜60、61〜100）は、この目途を使って編集部が作った例です。サービスの規模や、株式譲渡か事業譲渡かによって、区切り方は変わります。
Q2. 買収直後に、最初にやることは何ですか？ A. 機能開発より先に、事業を止めないための権限の確保です。ドメイン、サーバー、ストアの開発者アカウント、決済、ソースコードの管理場所などについて、誰の名義で、誰が操作できるかを確かめ、買い手が管理者になっていない箇所から順に移します。移管の可否と手順は、各事業者の規約で個別に確認してください。
Q3. 売り手には、買収後どのくらい残ってもらえばよいですか？ A. 期間の目安を一律には示せません。中小PMIガイドラインは、売り手の経営者が引継ぎのために残る場合、役割・報酬・在籍期間を事前に合意して書面（覚書等）に明記することを挙げ、必要な期間を見積もれないときは半年更新のような契約にする方法も示しています。在籍期間を決めていなかったために影響力が長く残った失敗例も載っています。契約条項は弁護士に確認してください。
Q4. 価格改定や機能追加は、最初の100日にしてもよいですか？ A. 禁止ではありません。ただし本記事の整理では、最初の100日に変えるのは、停止や法令上のリスクが高いものに絞り、価格や機能の変更は現状を把握してから選ぶ順番にします。中小PMIガイドラインも、全ての課題に対応するのは現実的ではないとして、優先順位を付けて取り組むとしています。利用規約や料金の変更手続は、サービスの規約に従い、専門家に確認してください。
Q5. 利用者への告知は必要ですか？ A. 一律の答えはありません。中小PMIガイドラインは、取引先に対して、M&A成立後すみやかに挨拶文を送る例（成立日、譲受側の基本情報、問い合わせ先、新体制など）を挙げています。利用者への通知が要るかどうかは、利用規約と個人情報の取扱い（利用目的の範囲など）で変わるため、個人情報保護の記事で整理した内容を確認し、必要に応じて弁護士に確認してください。
Q6. 専門家に頼むなら、どの分野を誰に頼みますか？ A. 中小PMIガイドラインは、支援機関の例として、経営統合や事業機能には中小企業診断士・経営コンサルタント、人事・労務には社会保険労務士・弁護士、会計・財務には公認会計士・税理士、法務には弁護士・司法書士、ITシステムにはITベンダーなどを挙げています。個別の判断は、案件ごとに専門家へ確認してください。
出典
- 中小企業庁「中小PMIガイドライン～中小M&Aを成功に導くために～」（令和4年3月） https://www.chusho.meti.go.jp/zaimu/shoukei/download/pmi_guideline.pdf
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」（NIST CSWP 29、2024年2月26日） https://nvlpubs.nist.gov/nistpubs/cswp/nist.cswp.29.pdf
- IPA「情報システム・モデル取引・契約書（第二版）」 https://www.ipa.go.jp/digital/model/model20201222.html
- IPA「システム開発の健全化に向けて」（情報システム・モデル取引・契約書 第二版の講演資料） https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/20250424-kouen.pdf