移行は簡単なほうの半分だった

要点： シンガポールのヘルステック企業が、物置を改装した部屋に置かれた保守期限切れ 4 年のサーバー 2 台で基幹システムを動かしている。復元テストは 2 年間ゼロ。取締役会がクラウド移行を承認し、移行そのものは 6 週間で終わった。しかし「パッチは誰が当てるのか、バックアップの復元は誰が確認するのか、請求書は誰が見るのか、深夜に誰が呼ばれるのか」という議論のほうがはるかに長引く。移行の成否を決めるのは、実はそちらの議論のほうである。

なぜ物置のサーバーはこれほど長く生き延びるのか

シンガポールには、ちょうど最も厄介な規模帯——おおむね 70〜110 名——のヘルスケアテクノロジー企業や医療機器企業が数多く集まっている。インフラは確実に事業を支えているのに、インフラ専任チームは存在しない、という規模帯である。この種の企業はたいてい、製品アイデアと数名のエンジニアから始まり、最初のまともな顧客を獲得し、その顧客の拡大に乗って成長してきた。そして最初の 2 年のどこかで、誰かがサーバーを 1 台買う。当時としては正しい判断だった。安く、速く、しかも製品を端から端まで理解している唯一の人物が直接管理できたからだ。

その後に起きることは、怠慢ではない。エンジニアの時間 1 時間ごとに顧客向けの作業が列をなしている会社としては、まったく合理的な振る舞いである。サーバーは動いている。ずっと動いてきた。置き換えても新機能は生まれず、新規顧客も取れず、ロードマップにも載らない。こうして判断は毎年先送りされ、先送りするたびにコストは前年よりわずかに高くなる。現金の話ではない。導入以来一度も意図的に再起動されていない一台の機械に、どれだけのものが静かに依存するようになったか、という話である。

シンガポールという文脈は、この問題を二つの点で鋭くする。第一に、商業スペースが高い。したがって「サーバールーム」はしばしばサーバールームですらない。改装した物置、給湯室脇の戸棚、あるいは家庭用エアコンを向けただけのオフィスの一角である。第二に、シンガポールのヘルステック企業はほぼ最初から地域規模で売る。一つのオフィスに 90 名という会社が、四つも五つも市場の顧客に対応していることがある。そしてその顧客たちは調達プロセスで、自社のインフラがそもそも答えるように設計されていない問いを投げてくる。

この第二の点こそが、先送りされてきた判断を取締役会案件に変える引き金になる。技術チームは 2 年間ハードウェアのリスクを訴えてきたが、動かなかった。ところが顧客の調達アンケートが「データは物理的にどこにあるか」「目標復旧時間はどれくらいか」「最後に復元テストをしたのはいつか」を尋ねた瞬間、物置のサーバーは技術問題ではなく商談上の問題になる。これが最も多く見るパターンであり、率直に言っておく価値がある。移行が承認されるのは、社内でリスクがついに理解されたからではない。社外の誰かが、会社が答えられない質問をしたからである。

シナリオ：その 2 台には実際に何が載っているのか

説明のための複合シナリオを考えてみたい。特定の顧客ではなく、この領域で繰り返し現れる案件の形から組み立てたパターンである。シンガポールのヘルスケアテクノロジー企業、従業員およそ 90 名。アジア数市場の病院グループと専門クリニックに臨床ワークフロー製品を販売している。本番プラットフォームはすでにクラウド事業者上で動いており、その部分は現代的で、よく理解されている。問題はそれ以外のすべてだ。

物置には物理サーバーが 2 台。どちらも保守期限を 4 年過ぎている。1 台目は基幹業務アプリケーション——受注管理、機器シリアル追跡、サービススケジューリング、サポートチームが参照する顧客レコードを扱う社内システム——を動かしている。導入したシステムインテグレーターは、その後 2 回買収されている。2 台目は全社が依存するファイル共有を動かしている。臨床文書のテンプレート、規制当局提出の作業ファイル、営業資料、そして 3 人しか完全には理解していない規則で整理された 10 年分のプロジェクトフォルダである。

データベースもある。1 台目のサーバー上にあり、基幹業務アプリケーションを支えており、この建物の中で誰も触りたがらない唯一のオブジェクトだ。スキーマは 6 年かけて非公式に拡張されてきた。経営陣が頼りにしているレポートが 2 本、直接このデータベースを参照している。インデックス設計を本当に理解していた人物は 2023 年に退職した。

バックアップは動いている。この一点が、状況を実際より安全に見せている。バックアップジョブがあり、完了し、誰かが昔つくったダッシュボードに緑のチェックが付く。欠けているのは、テストされた復元である。誰かが意図的にそのバックアップからシステムを復元し、結果が使えることを確認したのは 2 年以上前。しかもそれを実施した人物は、常設のプロセスの一環としてではなく、単発の作業として行った。つまりこれはバックアップではない。バックアップについての仮説である。

そして最後に、エンジニアが 1 名。悪いエンジニアではない——むしろたいてい非常に優秀だ——この環境を構築あるいは引き継ぎ、なぜ物事が今の形になっているのかを知る唯一の人物である。この環境が落ちずに来たのは、この人がいるからでもある。同時にリスクの観点では、リストの中で最も重い単一項目でもある。そして本人を含め、全員がそれを分かっている。

この状況が実際に生む問題

個々の問題を並べるのは難しくない。厄介なのは、それらが複合することだ。一つひとつが他を直しにくくする。だからこの種の環境は、外部の出来事が押し出すまで凍りついたまま動かない。

• 保守期限切れのハードウェアと、予備部品の道筋がないこと。 4 年前のサーバーは上品に壊れてはくれない。ディスク、コントローラ、電源が飛んだとき、問いは「修理に何日かかるか」ではなく「この世代の交換部品が今週シンガポールに存在するか」になる。予備戦略はない。このハードウェアが今も現役である前提が、そもそもなかったからだ。
• この負荷を想定していない空調と電源。 家庭用エアコンが維持するのは人が快適な室温であって、連続負荷下のサーバー吸気温度ではない。故障時に安全側に倒れることもない。電源はオフィスの一系統で、近くに挿さっている何かと共用している。UPS はあるかもしれないが、そのバッテリーが今も保つかどうかは、たいてい誰も知らない。
• 動いてはいるが一度も復元されたことのないバックアップ。 繰り返す価値がある。このシナリオ全体で最も過小評価されているリスクだからだ。バックアップソフトが成功を報告するのは、ジョブが走ったという事実だけである。データが完全であること、アプリケーションが起動すること、データベースがマウントできること、事業が許容する時間内に復旧が終わること——そのいずれも保証しない。
• 営業チームが今まさに問われはじめたデータ所在の問題。 データはどこにあるのか、誰がアクセスできるのか、どの契約条項の下でか、契約終了時に何が起きるのか。これらは顧客の調達アンケートに現れ、物置を指差して信頼できる回答をすることはできない。これは IT の懸念にとどまらず、成長に対する商業上の制約である。
• 知識の単一点。 構成を理解しているのは 1 人だけ。ドキュメントは「かつて一部が書かれた」という意味では存在する。障害発生時にそのエンジニアが休暇中なら、復旧時間を決めるのは技術ではなくなる。
• そもそも復旧目標が定義されていない。 基幹業務アプリケーションなしで事業が何時間持つのか、どれだけのデータ損失なら許容できるのか——誰も問われたことがない。この二つの数字がなければ、設計の議論はすべて工学ではなく意見の応酬になる。

このうち二つは特に注意に値する。移行の際に最もスコープを誤りやすい項目だからだ。未検証バックアップの問題は、クラウドに移しても消えない。一度も復元されていないクラウドバックアップは、一度も復元されていないオンプレミスのバックアップと、まったく同じだけ未証明である。そして知識の単一点の問題は、良くなる前にまず悪化する。移行期間中、そのエンジニアは平時以上に代替不能になるからだ。

本当に重要な判断：リフト&シフトか、リプラットフォームか

移行が承認されると、技術的な議論はすぐに一つの問いに収束する。どちらかを明らかな正解として提示するより、トレードオフを正直に並べたほうがよい。

リフト&シフトは、既存サーバーをそのままクラウドの仮想マシンとして再現する。速く、実行コストが低く、プロジェクトリスクが最小で、たいていアプリケーションに一切触らずに済む。同時に、問題もそのまま保存する。同じ文書化されていない構成、同じ非公式に育ったスキーマ、同じ OS バージョン、同じ誰も理解していないデータベースが、場所を変えて月額課金で動くだけだ。リフト&シフトはハードウェアリスクと空調リスクと物置を取り除く。運用リスクは一つも取り除かない。

リプラットフォームは、対象の形そのものを変える。自前運用のデータベースの代わりにマネージドデータベースサービス、ファイルサーバーの代わりにマネージドファイルサービス、ローカルアカウントではなくプラットフォームによる ID とアクセス管理。時間がかかり、実行コストも高く、組織がうまく無視してきた問題——たいていは誰も記録していなかったアプリケーションの依存関係——を表に出す。しかし、その後に運用しなければならないものの数を本当に減らす。

決め手になるのはたいてい技術ではなく、そのアプリケーションがあと何年生きるかである。基幹業務アプリケーションが 18 か月以内に置き換え予定なら、リプラットフォームはほぼ費用の無駄だ。そのまま持ち上げてハードウェアリスクだけ外し、工数は後継システムに回すほうがよい。5 年後もまだ動いているなら、リフト&シフトは利息付きの先送りであり、リプラットフォームの作業は条件がより悪く、当時を知る人員がより少ない状況で、後からやることになる。

実務上、この形の環境は多くの場合分割して扱われる。ファイル共有とデータベースはマネージドサービスへリプラットフォームする。運用負担が実際にそこに集中しているからだ。一方、基幹業務アプリケーションはそのまま持ち上げ、判断を後回しにする。これは妥協ではなく正当な帰結である——ただし、それが誰かの意図的な判断であり、「後で決める」項目に日付が付いている場合に限る。

Brocent の視点：移行が変えるのは「どの障害を誰が持つか」

「クラウド移行」は、開始日と終了日と予算を持つプロジェクトとして語られる。その語り方こそが、その後しばしば訪れる失望の原因である。移行は第一義的には技術イベントではない。運用責任の分布の変更である。そしてその再配分が明示的に決められなければ、責任は以前やっていた人——つまり、すでに手一杯で、しかも以前より理解の浅い環境を運用することになった同じエンジニア——に既定値として戻る。

カットオーバー後、次の四つの問いが、この移行が本当にリスクを下げたのかを決める。

• 誰がパッチを当てるのか。 OS、アプリケーションランタイム、データベースエンジン。クラウド事業者は仮想マシンの下のプラットフォームにはパッチを当てるが、仮想マシンの中身には当てない。これはリフト&シフト後に最も多い誤解であり、その結果、移行 1 年後のほうが移行前よりパッチ状況が悪い環境が生まれる。
• 誰がバックアップの復元を検証するのか。 バックアップを設定する人ではなく、定期的に実際に復元を実行し、復元されたシステムが使えることを確認する人である。答えが「誰も。でも今はプラットフォーム上だから」であれば、未検証バックアップの問題はデータと一緒に移行されただけだ。
• 誰が請求額が倍になる前に確認するのか。 クラウドコストは初日の位置に留まらない。障害対応でインスタンスが拡大され、そのまま戻されない。スナップショットが溜まる。テスト用に立てた環境が用途より長生きする。名前のある担当者と月次レビューがなければ、最初の不愉快な驚きはたいてい 4 か月目から 9 か月目のあいだに来る。
• 深夜に誰が呼ばれるのか。 午前 2 時、システムは今や別の場所にあり、それを理解している人物には連絡がつかない。一人の個人で終わるエスカレーション経路は、エスカレーション経路ではない。

この四つに答えていない移行は、会社のリスクを下げていない。リスクの置き場所を変え、月額請求を一つ増やし、少なくとも歩いていって眺めることのできた物理的な箱という安心材料を取り除いただけである。

正しく設計された運用モデルはどう見えるか

代替案は、より多くの技術ではない。カットオーバー後に発見するのではなく、カットオーバー前に合意された常設責任の集合である。

• パッチ適用を意向ではなく常設サービスとして。 定義されたメンテナンスウィンドウ、OS と仮想マシン内コンポーネントを含む定義されたスコープ、そして「何を適用し、何を延期し、なぜ延期したか」を示すレポート。パッチ管理は Brocent のマネージド IT プランで全ティアに含まれる 13 項目の一つであり、24/7 監視やヘルプデスクと並ぶ。追加オプションではなく基準線である。
• 緑のチェックではなく、テストされた復元を。 Brocent のクラウドマネージドバックアップは、サービスコマンドセンターによる 24×7 のバックアップジョブ監視と、バックアップ完全性を検証する定期的な復旧訓練を中核に据えている。「成功を報告するバックアップ」と「復元できることが証明されたバックアップ」の違いこそ、このサービスの存在理由そのものである。イミュータブルバックアップを含むバックアップ／DR も、同様に全プランティアに含まれる。
• バックアップ構成を意図して選ぶ。 このサービスは四つの文書化されたモードを定義している。ローカル完全＋重要データのみクラウド、ローカル完全＋全データクラウド、双方向完全冗長、そしてクラウドのみ。物置を後にする企業はたいていクラウドのみのモデルに落ち着くが、それは明示された復旧目標を伴って選ばれた立場であるべきで、たまたまそうなった既定値であってはならない。
• 担当者名と月次サイクルを伴うコストガバナンス。 適正サイジングのレビュー、孤立リソースの整理、月次のコスト・パフォーマンスレポート。Brocent のマネージドクラウドサービスは適正サイジングによりクラウドの無駄を 20〜40% 削減することを目標としているが、これは誰かが実際に定期的に請求書を見ている場合にのみ達成できる。
• 一人で終わらないエスカレーション経路。 明確な応答コミットメントを伴う階層型サポート。それによって社内エンジニアは、あらゆる障害で本人が起きていなければならない人ではなく、事業の文脈を理解している人に戻れる。

プラットフォーム選定そのものについての正直な答えは、「顧客がどこにいるかによる」である。Brocent のクラウドソリューションは Azure と Microsoft 365、AWS、Alibaba Cloud、Tencent Cloud をカバーする。後者二つは、成長経路に中国本土を含む企業にとって特に重要だ。中国では ICP 準拠のホスティングが好みではなく実務上の制約になる。東南アジア向けに販売するシンガポール企業なら、プラットフォームの判断はたいてい素直である。しかしロードマップに中国が入るなら、二度移行しないためにも早めに決めておく価値がある。

三つの選択肢を、正直に比較する

• オンプレミスに留まる。 コストは既知、移行プロジェクトなし、完全な統制。その代償は、予備部品の道筋がない老朽ハードウェア、この負荷を想定していない空調と電源、知識の単一点、そして商談を落とし続けるデータ所在の回答である。顧客がインフラについて尋ねてこない企業なら擁護できる立場だが、ヘルステックではますます稀な立場でもある。
• DIY クラウド。 柔軟性は最大、第三者依存なし、設計の完全な自由。その代償は、これまで分担されるか静かに無視されてきた運用作業のすべてが、明示的に自社のものになることだ。パッチ適用、復元検証、コストレビュー、監視、時間外エスカレーション。インフラエンジニアが 1 名の 90 人規模の会社では、この選択肢は「技術的には成功した移行」と「置き換えた物置より悪い運用状態」を同時に生むことが最も多い。
• マネージドクラウド（Brocent モデル）。 移行の計画と実行に加え、カットオーバー後の運用モデルを定義する。全プランティアに含まれる常設サービスとしてのパッチ適用と監視、ダッシュボードのチェックではなくスケジュールされた復旧訓練を伴うバックアップ、月次のコスト・パフォーマンスレポート、担当者名のある階層型エスカレーション。その代償は、月額コストを伴う商業関係であること、そして復旧目標を暗黙のままにせず定義するよう会社に求めることである。これは手間だが、それこそが要点でもある。

ここからどう進めるか

物置の 2 台が保守期限を過ぎており、最後の復元テストが現在の技術責任者の入社より前だというなら、次に有用なのは移行提案書ではない。正直な棚卸しである。各サーバーで何が動いているか、何がそれに依存しているか、事業は何を失うことなら許容できるか、各システムなしでどれだけ運営を続けられるか。これらの答えが設計を決める。それなしの移行計画は、図面の付いた当て推量にすぎない。

Brocent は 2007 年からアジアでマネージド IT とクラウドの案件を手がけ、2021 年からはシンガポールに本社を置いている。この具体的なパターンの経験もある。買収の過程にあったグローバル医療テクノロジー企業に対し、Azure と Microsoft 365 E5、Intune、ID 基盤、地域横断の端末更新にわたるクラウドアーキテクチャ設計と長期のマネージドインフラ支援を提供した案件である。プラン構成と各ティアの内容はマネージド IT サポートで確認できる。物置に実際に何が置かれているかを話したい場合は、お問い合わせください。

よくある質問

リフト&シフトとリプラットフォーム、どちらを選ぶべきですか。

技術ではなく、そのアプリケーションの残存寿命で決めてください。おおむね 18 か月以内に置き換えられるシステムならリフト&シフトです。ハードウェアリスクを安く外し、工数は後継システムに投じます。5 年後もまだ動いているなら、運用負担を抱えている部分——通常はデータベースとファイル共有——をリプラットフォームしてください。そうしなければ、同じ作業を後になって、より切迫した時間の中で、当時を知る人員がより少ない状態で行うことになります。片方を持ち上げ、片方を作り替えるという分割した結果は一般的であり、まったく正当です。

当社のデータは物理的にどこに置かれますか。

それは移行が決めることではなく、御社が下す設計判断であり、いかなるワークロードを動かすよりも前に確定しておくべきものです。主要なプラットフォームはいずれもワークロードを特定リージョンに固定でき、シンガポールはどのプラットフォームでも十分にカバーされています。重要なのは、その答えが文書化されていること、営業チームが調達アンケートで顧客に伝えている内容と一致していること、そしてバックアップと複製がどこにあるかも計算に入っていることです。後者は主系と別リージョンにあることが多く、同じくらい見落とされがちです。特定の構成が特定の規制上の義務を満たすかどうかは、御社の法務顧問と所管当局が判断すべき事柄です。データがどこにあり、アクセスがどう統制されているかは説明できますが、その適合性の判定は当社が行うものではありません。

移行後、パッチ適用は誰の責任になりますか。

契約書に責任者として書かれた側です。クラウド事業者は仮想マシンの下のプラットフォームにパッチを当てます。仮想マシン内の OS とその上で動くすべては、どこかに委託していない限り御社の責任のままです。マネージドの取り決めであれば、パッチ管理は Brocent の全プランティアに含まれる項目の一つで、定義されたメンテナンスウィンドウと、適用済み・延期分のレポートが伴います。DIY の取り決めであれば担当は御社のエンジニアであり、当然のものとして前提にするのではなく、明示的にスケジュールし工数を確保すべきです。

バックアップが本当に機能していると、どうすれば分かりますか。

定期的に復元し、結果が使えることを確認するしかありません。他に方法はありません。完了したバックアップジョブが証明するのはジョブが走ったことだけで、アプリケーションが起動すること、データベースがマウントされること、事業が許容する時間内に復旧が終わることは何も証明しません。Brocent のクラウドマネージドバックアップがまさにこの理由で定期的な復旧訓練を含み、24×7 のジョブ監視を併せて提供しているのはそのためです。この記事から一つだけ持ち帰るなら、これにしてください。クラウドについて何を決めるにせよ、今四半期のうちに最重要システムの復元テストを予定に入れることです。

クラウドは、すでに所有しているサーバーより高くつきますか。

すでに支払い済みのハードウェアの購入価格と比べるなら、たいていは高くつきます。ただしその比較は有用ではありません。意味のある比較には、これから買わざるを得ない交換ハードウェアのコスト、現在さらされているダウンタイムのコスト、そしてデータ所在の回答が影響している商談の商業的コストが含まれます。確かなのは、ガバナンスがなければクラウドコストは上方に漂うということです。障害対応で拡大されたインスタンスが戻されず、スナップショットが溜まり、テスト環境が用途より長生きします。数字を正直に保つのは適正サイジングと月次のコストレビューであり、Brocent のマネージドクラウドはまさにその規律によってクラウドの無駄を 20〜40% 削減することを目標としています。

社内エンジニアの役割はどうなりますか。

経験上、これこそが皆さんが本当に気にしている問いであり、正直な答えは「たいてい役割は良くなる」です。消えるのは差別化されない運用負荷——パッチ適用、バックアップダッシュボードの監視、午前 2 時に対応できる唯一の人物であること——です。残り、そして広がるのは、御社の事業を知っていることが必要な部分です。製品がどう動くか、顧客が何を必要としているか、どの週にどの社内システムが最も重要か、そしてどう良いアーキテクチャ判断を下すか。マネージドの取り決めは、エンジニアをより有能にし、より代替不能でなくすべきです。順序はこのとおりです。

この規模の移行にはどれくらいかかりますか。

この形の環境——サーバー 2 台、基幹業務アプリケーション、ファイル共有、データベース——であれば、よく計画された移行は月単位ではなく週単位で測られます。Brocent が手がける同種の Microsoft 365 およびクラウド移行案件も、要件分析から本番稼働まで通常 2〜6 週間です。ただし重要なのはカットオーバーの期間ではありません。その後の運用モデル——パッチの所有者、復元テストの頻度、コストレビュー、エスカレーション——を合意するまでにどれだけかかるかです。カットオーバー前にそれらを決める企業は、このプロジェクトを一度で終えます。先送りする企業は数か月後に、リスクを減らしたのではなく移動させただけだったと気づく傾向があります。