中小企業の経営者の方から、クラウド移行のご相談をいただくことがあります。
オンプレで動いている基幹システムを AWS に移したい。社内の Excel 業務を SaaS 化したい。レガシーな PHP システムを最新の Next.js に書き直したい。
そういうご相談をいただくたびに、私たちが最初にお伝えするのは、こんな一言です。
「技術的には、できます。けれど、その前に、決めていただきたいことがあります」。
決めていただきたいこと。それは、技術選定ではありません。インフラ構成でもありません。「どのレガシーを残し、どのレガシーを捨てるか」を、今この瞬間に決めることです。
そして、これが私の経験上、クラウド移行プロジェクトで最も難しい部分です。
「全部移行」という、最も危険な発注
ある中堅製造業の社長から、こんな相談を受けたことがあります。
「うちのオンプレ環境、もう 15 年動いています。サーバーも古くて怖いし、AWS にすべて移行したい。御社で見積もってもらえますか？」
技術的な見積もりは、難しくありません。サーバー数、データ量、依存関係を聞けば、おおよその数字は出せます。
けれど、私はあえて、別の質問から始めました。
「現在動いているシステム、何個あって、それぞれ誰が使っていますか？」
社長は少し考えて、こう答えました。
「正確には、把握できていません。経理が使うやつが 1 つ、現場の生産管理が 2 つ、営業の顧客管理が 1 つ。…あと、誰が作ったか分からない『便利ツール』みたいなものが、たぶんサーバーに 10 個くらい？」
これが、クラウド移行プロジェクトで失敗する典型的な構図です。
システムは「動いている」のではなく、「育ってきた」
15 年動いているシステムは、設計図通りに作られたものではありません。長い時間をかけて、現場の必要に応じて、誰かが少しずつ機能を足し、ハックを重ね、緊急対応で修正を入れた結果、たまたま今動いている、という状態です。
その中には、5 年前に退職した人が作った「便利ツール」が動き続けています。誰も中身を理解していないが、止めると現場が回らなくなる「謎のシェルスクリプト」があります。本来は経理システムの一部として作られたはずなのに、いつの間にか営業も使い始めた「変な依存関係」があります。
これらを「全部 AWS に移行する」とは、つまり、「現状の全ての複雑性を、技術スタックを変えただけで持ち越す」ということです。
そして、ここに罠があります。クラウド移行の見積もりが「現状の機能を AWS で再現する」を前提とすると、見積もりは天文学的な数字になります。15 年分の負債を、そのまま新しいインフラに引き継ぐ作業だからです。
本当に難しいのは、「捨てる」を組織で決めること
クラウド移行で本当に難しいのは、技術選定ではありません。
「どのシステムを捨てるか」を、社内で合意することです。
そして、これが組織にとっては、技術選定よりも、何倍も困難な作業です。
理由はシンプルです。捨てるシステムには、必ず「使っている人」がいるからです。
「経理が月次決算で 5 分だけ使うシステム」を捨てるとなったとき、経理担当者は反対します。「うちは使ってる」と言います。けれど、本当にそのシステムでなければならないのか。今ある SaaS で代替できないのか。Excel で十分ではないか。
その判断を「現場任せ」にすると、誰も捨てられません。なぜなら、捨てる責任を引き受けたくないからです。
経営者が「これは捨てる」と意思決定する必要があります。それも、現場の説得を待たずに、です。
私たちが伴走する場合の進め方
クワイエットリーがクラウド移行を支援する場合、技術設計に入る前に、必ず 2 つのリストを作ります。
1 つ目: 「捨てるリスト」
- 現状動いているが、本当に必要かどうか分からないシステム
- 過去 1 年で実質的に使われていないシステム
- 機能が他のシステムと重複しているシステム
- 修正コストが、新規開発コストを超えているシステム
2 つ目: 「残すリスト」
- 確実に事業に使われているシステム
- 法務・会計上、保管義務があるデータ
- 顧客の体験に直結するシステム
リストを作る過程で、必ず社内政治が表面化します。「うちが使っている」「あれは捨てるな」「これは残せ」という声が上がります。私たちのような外部の伴走者は、その政治の中で、技術的な事実だけを冷静に提示する役割を担います。
判断するのは経営者です。でも、判断する材料を整えるのは、私たちの仕事です。
ある不動産会社のケース
実績ページにも書いたとおり、私たちはある不動産会社の物件管理システム移行を支援したことがあります。
最初の見積もりは、SIer から「3,000 万円」と提示されていました。
私たちは、500 万円で MVP を作りました。
なぜ、こんなに金額が違ったのか。
SIer は「現状の全機能を、新しいシステムで再現する」前提で見積もりを出していました。これは正しい技術判断です。けれど、私たちは別のアプローチを取りました。
「現状の全機能のうち、本当に使われているのは何ですか？」と聞きました。
社長と現場の主任にヒアリングした結果、現状システムの機能の 約 40% は、過去 1 年で誰も使っていなかったことが分かりました。
私たちは、その 40% を最初から作らないことにしました。残りの 60% を、6 ヶ月で MVP として実装し、運用しながら、残りの機能を必要に応じて追加していく方針に切り替えました。
結果、見積もりは SIer の 1/4 になりました。
そして、運用開始から 1 年経った今、お客様は「捨てた 40% のうち、追加で必要だったものは 5% だけだった」と言っています。
結び ── 「捨てる勇気」を、組織に作る
クラウド移行は、技術プロジェクトではなく、組織プロジェクトです。
技術選定の議論で時間を使うよりも、「何を捨てるか」を経営層が意思決定するために時間を使う方が、結果的にプロジェクトは成功します。
私たちが支援できるのは、その意思決定のための材料提供と、捨てた後の新しいシステムを実装することです。意思決定そのものは、お客様の経営の仕事です。
クラウド移行を検討されている方は、まずこう自問してください。
「私たちは、何を捨てる準備があるのか？」
その答えが言葉にできた瞬間、移行プロジェクトは半分終わっています。
著者プロフィール
橋本 周（はしもと しゅう）
株式会社QUIETLY 代表取締役。中小企業のクラウド移行・業務システム再構築を 30 件以上支援。