月間6000万PVのインフラが教えたM&Aのリスク

Webサイトを作り、ユーザーが増え、アクセスグラフが劇的に伸びていく高揚感。それは多くの開発者が夢見る最高の瞬間です。しかし、華やかなフロントの数字の裏側では、決まって「インフラ（サーバー）の悲鳴」が響き渡ります。

私自身、Web2.0の黎明期に単身でコミュニティサイトを立ち上げ、最終的に月間6000万PVという途方もないトラフィックを捌くまでに至りました。しかし、その道のりは決して平坦なものではありません。ロリポップから始まり、Xserver、VPS、専用サーバー、そして負荷分散へと乗り換えていく過程は、ナレッジもドキュメントもない中で手探りで地雷を踏み抜いていく「血の気が引くようなインフラ戦記」そのものでした。

そして現在、私はM&Aプラットフォームの代表として多くの売却案件に触れていますが、この「どのサーバー環境でシステムを構成しているか」という事実は、M&Aにおける『買い手への引き継ぎやすさ』と『売却価格（資産価値）』に直結する極めて重要な要素となります。

本記事では、机上の空論ではない泥臭い6000万PVのサーバー乗り換えの歴史を余すところなくお伝えし、買い手と売り手の双方が絶対に知っておくべき「M&Aにおけるインフラ引継ぎのリアル」をお話しします。

Web2.0黎明期、初心者セットからの過酷なスタート

全ては「ロリポップとムームードメイン」から始まった

時計の針を少し戻しましょう。当時はmixiが上場したばかりの頃で、ユーザー自身がコンテンツを生成する「CGM（Consumer Generated Media）」や「Web2.0」という言葉が最先端のトレンドとして持て囃されていました。現在の日本国内では完全に下火になってしまいましたが、コミュニティサイトを構築するための「XOOPS（ズープス）」というオープンソースの動的CMSが非常に強力なツールでした。

右も左も分からない状態でのオープン当初、私が選択したインフラは、最もメジャーな初心者セットである「ロリポップ（レンタルサーバー）」と「ムームードメイン」の組み合わせでした。月額数百円から始められる手軽さは、個人開発者にとって魔法の切符のように思えました。

動的CMSの洗礼。数十人で「激重」になる恐怖

しかし、ロリポップの格安な料金は、あくまで「静的なHTMLページ」や「小規模なブログ」を想定したものでした。アクセスがあるたびにデータベースへアクセスし、動的にページを生成するXOOPSのような重いシステムでは話が変わります。

サイトを公開し、ユーザーが数十人集まった時点で、あっという間にサイトは「激重」になりました。クリックしてからページが開くまでに数秒から十数秒待たされる。掲示板やコミュニティにおいて「レスポンスの遅さ」は致命傷です。「このままではユーザーが離れてしまう」という強烈な焦燥感から、私のインフラ乗り換えの旅が始まりました。

逃げ込んだXserver。夜23時に訪れた「完全沈黙」

次なる移転先として選んだのは、ロリポップよりもはるかにスペックが高いことで知られていた「Xserver（エックスサーバー）」でした。移転直後は見違えるほど快適になり、「これで当分はインフラの心配をしなくて済む」と胸をなでおろしました。

しかし、コミュニティサイトには特有の「ピークタイム」が存在します。多くのユーザーが帰宅し、PCの前に座る夜23時前後です。

徐々にユーザー数が増え、23時頃にアクティブなオンラインユーザーが「100人」を超えた瞬間、悪夢は起きました。サーバーが過負荷に耐えきれず、サイトが完全に反応しなくなってしまったのです。ブラウザは真っ白なロード画面のままで、更新ボタンを押しても何も返ってこない。共有サーバーの限界（他の同居ユーザーへの影響を防ぐためのリソース上限）に達してしまった瞬間でした。

限界を超えて。専用サーバーと「負荷分散」の孤独な戦い

自由と引き換えのVPSと、データセンターの「専用サーバー」

共有サーバー（ロリポップやXserver）では、どれだけ設定をいじりたくても権限がありません。「他のユーザーの影響を受ける」という共有マンションのような環境からの脱却が必要でした。

そこで、OS自体がユーザーごとに割り当てられ、ある程度の自由（ルート権限）が効く「VPS（仮想専用サーバー）」へと移行しました。さらにサイトへのアクセスが増大し、常時数百人がサイト内にいる状態になると、VPSのリソースでも捌ききれなくなり、ついにデータセンターに物理的なマシンを借りる「専用サーバーのレンタル業者」を使う次元へと突入しました。さすがに自らデータセンターに入館してラッキング（機器の設置）をすることはできませんでしたが、自分専用の物理サーバーを手に入れたことで、インフラの自由度は飛躍的に増しました。

同居する「WebとDB」の限界と、嵐のようなダイレクトメッセージ

専用サーバーを手に入れても、インフラとの死闘は終わりません。当初は1台の物理サーバーの中に「Webサーバー（Apache等）」と「DBサーバー（MySQL等）」が共存する構成で運用していました。しかし、ユーザー数が増えるとPHPを処理するWeb側のCPU使用率が異常なほど高止まりし始めます。

さらに追い討ちをかけたのが、掲示板サイトに備わっていた「ダイレクトメッセージ（DM）機能」です。数百人のユーザーがリアルタイムにメッセージをやり取りし、毎日少なく見積もっても数千件〜数万件のレコード書き込み（INSERT）が発生します。参照だけでなく激しい書き込みが発生するため、DB側の負荷も天井を叩き始めました。WebとDBがお互いのリソースを食い合い、悲鳴を上げ始めたのです。

国内最大規模のXOOPS。「前例なき負荷分散」への挑戦

「このままではサーバーが落ちる」。その恐怖と戦いながら、私はついに1台のサーバー構成を捨てました。

まずは「WebサーバーとDBサーバーを物理的に分ける（分離）」ことから始め、次に「Webサーバーを複数台構成にしてロードバランサーで振り分ける」、さらに「DBサーバーも複数台構成（レプリケーション等）にする」という段階的な拡張を実施しました。

当時、XOOPSを使ったサイトでそこまでのトラフィックを捌いている事例はおそらく国内最大規模であり、ネットを探しても「XOOPSの分散ナレッジ」なんてものはどこにも存在しませんでした。海外の文献を読み漁り、自分で調べながら、夜食のカップ麺を啜って負荷分散のテストを繰り返す。まさに血のにじむような泥臭い努力の連続でした。

クラウド全盛の現在と、消えない「見えない苦労」

あの頃の苦労が嘘のよう？クラウド（AWS等）の恩恵

私が血を吐く思いで物理サーバーの分離とロードバランサーの構築を行っていた時代に比べ、今は信じられないほど素晴らしい時代になりました。AWSやGCP（Google Cloud）などの「クラウド」がインフラの常識となったからです。

クラウドであれば、わざわざ業者に物理サーバーの発注をする必要もなく、数クリックでサーバーを複製し、トラフィックに応じて自動的にスケールさせることができます。無料枠で色々試すことも可能です。「あの時の苦労はなんだったのか…」と思ってしまうほど、本当にインフラ構築は楽になりました。

これから初めてクラウドを使ってシステムを運用するのであれば、設定が複雑なフルスペックのAWSよりも、まずは手軽にVPS感覚で使い始められる「Amazon Lightsail」から始めるのが、学習コストの観点でも非常におすすめです。

華やかな画面の裏側にある「インフラ保守へのリスペクト」

インフラの構築が手軽になったとはいえ、「システムを止めずに保守し続ける苦労」がなくなったわけではありません。トラフィックの異常検知、セキュリティパッチの適用、バックアップの監視。すべてが「誰かの見えない努力」によって支えられています。

M&Aプラットフォームでは、こうした見えない泥臭い努力を完全に無視し、「月利100万円です！引き継ぎも簡単！」と煽るだけの業者が山ほどいますが、私はそうした表面的な評価を絶対に許しません。

究極の「技術的DD」。M&Aにおけるサーバー構成と引き継ぎリスク

小規模サイトなら最強？「ロリポップ・Xserver」の意外なメリット

これまでの苦労話を踏まえた上で、M&A（サイト売買）という観点から「サーバー構成」を評価しましょう。

実は、M&Aにおける「サーバー構成の良し悪し」は、インフラの強さとは全く別のベクトルで評価されます。それは「買い手の引き継ぎやすさ（学習コスト）」です。

大規模化には向かないと語った「ロリポップ」や「Xserver」などの共有サーバーですが、実は小規模なサイトのM&Aにおいては最強のメリットを発揮します。管理画面が圧倒的に分かりやすく設計されているため、非エンジニアの買い手であってもアカウントの譲渡・引き継ぎが非常に簡単だからです。「高度な技術的知識がなくても買える」ということは、買い手の母数が広がり、結果的に売却しやすくなることに繋がります。

引き継ぎの最大の壁「専用サーバー・VPSの属人化リスク」

逆に、M&Aにおいて最も「買い手に敬遠される（資産価値が下がる）」リスクを抱えているのが、私がかつて格闘したような「VPS」や「専用サーバー」での手組み構成です。

売り手である前オーナーが、コンソール画面からミドルウェアの設定を手打ちでチューニングしまくったサーバーは、もはや「その人にしか分からないブラックボックス」です。十分なドキュメント（構成図や設計書）が残っていない場合、サーバー運用の知識がない買い手は、構成を把握することも、トラブル時に稼働を再開させることも不可能です。いくら売上が高くても、「属人化」という巨大なリスクにより、適正な価格での売却は非常に困難になります。

M&Aの最適解は「クラウド主流（AWS/GCP）」である理由

結果として、現代のM&A市場において最も資産価値が高く評価されやすいのは、小規模から大規模まで柔軟に対応できる「AWSやGCPなどの主要クラウド」で構築されたシステムです。

使っている企業や技術者が圧倒的に多いため、仮に買い手自身が非エンジニアであっても「運用保守を外部のエンジニアに委託しやすい（ドキュメントや知見が世の中に溢れているため学習コストが低い）」という絶大なメリットがあります。さらに、クラウドのIAM（権限管理）を活用すれば、物理的なアカウントごとの譲渡も安全かつスムーズに行えます。

「どんなサーバーで動かしているか」は、単なる技術の問題ではなく「誰に売れるか」というM&Aの根幹に関わります。私たちRIKKA M&Aは、表面的な売上だけでなく、こうした「裏側のインフラアーキテクチャの引き継ぎリスク」までを、GitHub等を用いた技術DDによって徹底的に可視化・評価します。だからこそ、売り手は自分の実務の努力を正当に評価され、買い手は地雷を買わずに済むのです。