オンプレミスとクラウド、業務システムはどこに置く？設備更新前の比較方法

設備の名前より、同じ仕事と利用拠点をそろえる

「サーバーをクラウドへ移す」とだけ書くと、アプリ、認証、資料の保管、営業所との接続が同じ範囲に含まれるか分かりません。設備更新の見積もりと、アプリだけを移す月額料金では、そもそも比較する仕事が違う場合があります。現在どの拠点の誰が何を使い、何が止まると困るかから整理します。

この例の共通の仕事は、複数拠点から業務アプリと保存資料を利用することです。業務担当がログインし、必要な記録を検索し、資料を開いて仕事を続ける流れを、両案で確かめたい仕事として示します。入力や更新が必要な仕事があるなら、その操作と、他の拠点へ反映される結果も比較に含めます。

• 業務責任者は、使う時間帯と止まったときの影響を伝える

  どの仕事がどの締切へ影響するか、代わりの手順で続けられるかを説明します。全システムを同じ重要度にせず、業務ごとに確認します。

• IT担当は、アプリを動かすために必要なものを対応させる

  アプリの保存先だけでなく、認証、DB、資料、定期処理、接続先を確かめます。古い構成図や担当者の記憶だけなら、いつの情報かと、まだ確認できていない範囲を残します。

• 発注担当は、両案へ同じ比較条件を渡す

  含める仕事と拠点、利用の条件、比較する期間を明示します。設備やサービスが異なる案でも、読者が続けたい仕事を同じ基準で評価できるようにします。

最初から全社の資料を完全にそろえることだけを目的にせず、まず重要な業務アプリを一つ選び、その利用者と関連する仕組みをたどります。分からないつながりは、アプリの管理担当、ネットワークの担当、提供会社など、確認できる相手へ具体的に尋ねます。未確認の一覧を、確認済みの構成図へ変えないことが大切です。

オンプレミス・クラウド・認証・DBの役割を分ける

ここで使う言葉は、置き場所を比べるための役割として理解すると読みやすくなります。製品の詳しい設定や、移行する作業手順を決める記事ではありません。

オンプレミス

自社で用意・管理するサーバーなどの設備にシステムを置く方法です。実際の設置先、設備の保守、設定や運用を委託する範囲は個別に確認します。自社設備という言葉だけで、全作業を社員が行うとは限りません。

クラウド

提供事業者の計算・保存などのサービスを利用する方法です。今のアプリを仮想サーバーへ移す案と、クラウドのDBなどを利用するために作り替える案では、必要な作業が変わります。何を利用する構想かを確認します。

認証

ログインする利用者などを確かめる仕組みです。業務アプリを移しても、認証が自社設備のままなら、その認証と通信が必要かを確かめます。認証の置き場所と、アプリの置き場所を分けて読みます。

業務アプリとDB

業務アプリは、記録を検索・登録するなど、利用者が仕事を行う仕組みです。DBはデータベースの略で、その仕事に使う記録を保存・検索するための仕組みです。アプリとDBがやり取りできることも、利用の条件になります。

拠点接続

営業所や本社などと、業務アプリ・認証・資料を利用する場所の間の通信です。どの拠点がどこへ接続し、通信が止まったときに何が使えなくなるかを確認します。

バックアップと復旧

必要な情報を保存することと、障害後にシステムを使える状態へ戻すことです。保存があるという説明だけで、同じ条件の業務を再開できた結果とは扱いません。

一部をクラウドへ移し、自社設備も使うような組み合わせを、ハイブリッドと呼ぶことがあります。組み合わせ自体が採用の答えになるのではなく、何をどちらに置き、その間にどの通信と運用が必要かを具体的にします。クラウド案だから自社の設備や担当作業が全てなくなるとは考えません。

二つの置き場所の案と、未確認の条件を並べる

自社設備案はアプリとDBを自社へ置く構想、一部移行案はアプリとDBを同じ移行単位でクラウドへ移す構想です。認証の残し方と次の質問も並べ、接続・復旧・費用の未確認を共通して確かめます。どちらも計画案で、接続や移行を実施した結果ではありません。

設備更新案と一部クラウド移行案を、同じ仕事について並べたものが以下の図です。枠は比較する配置の範囲を表し、稼働中の構成図や実際の接続を示すものではありません。クラウド案の「同じ移行単位」は、一緒に検討するまとまりであり、同じ一台のサーバーへ置くと確定した意味ではありません。

保存資料の具体的な配置や、アプリとの関連も棚卸しで確認する事項です。クラウド案の図に資料の保管先が描かれていないからといって、移行対象外や対応不要と決めつけません。今回どこまでを見積もり、何を残すかを、提供側と自社の担当へ尋ねます。

この状態で比較できるのは、どこに置く構想かという違いと、次に何を聞く必要があるかです。性能、費用、復旧、担当が未回答のため、どちらが優れているかはまだ確定できません。次の確認では、両案へ同じ仕事と利用条件を示して回答を求めます。

アプリ・DB・認証・保存資料のつながりを確かめる

業務アプリは、その画面だけで動いているとは限りません。ログインに使う認証、記録を保存するDB、添付資料の保存先、別のシステムへ送る定期処理などが必要な場合があります。これらを依存関係と呼びます。置き場所が変わっても、仕事に必要な相手とやり取りできるかを確認します。

1. 業務担当と、利用の流れをたどる

   ログインし、対象の記録を検索し、保存資料を開くまでの操作を確認します。登録や更新、印刷、定期集計など、必要な仕事があるなら追加します。アプリの名前だけでなく、誰がどの結果を必要としているかを書きます。

2. アプリの管理担当と、つながる相手を対応させる

   どのDBや認証、資料、外部サービスが必要かを、構成資料や現在の利用状況から確かめます。図に載っていない通信がないか、定期処理や特定の時間帯だけ使う接続も質問します。

3. 両案で、何がどこに残り、何を移すかを明示する

   同じ仕事に必要なものを、一方だけ対象外にしないようにします。自社とクラウドに分かれる部分では、通信の条件と運用の担当を具体化します。資料や説明だけの部分は、その根拠と確認待ちを残します。

このクラウド案では認証を当面自社に残す構想なので、業務アプリがその認証へ接続する条件や、認証側の設備・保守も比較対象に残ります。「アプリを移すから、自社のサーバー費用はなくなる」という前提を先に置かないようにします。将来認証を移す場合も、その時期や方法、費用が今の案に含まれるかは別に確認します。

現行アプリが使う製品の版、ライセンス、提供元のサポート条件も尋ねます。現在の動かし方をそのまま別の場所へ移すのか、設定や作り替えが必要なのかで、移行の範囲と確認方法が変わるためです。この記事の計画案は、特定の製品構成の動作を保証する設計図ではありません。

営業所から同じ仕事を行い、接続と待ち時間を確かめる

置き場所が変わると、営業所からアプリや認証、DBへ至る通信の経路が変わる場合があります。自社設備案でもクラウド案でも、拠点の回線や接続機器、経由する場所を確認します。クラウドは必ず速い、自社設備なら通信の問題はないという分け方はできません。

確認するのは回線の通信量だけではありません。遅延は、通信の応答を待つ時間のことです。画面を開く間にアプリとDBが繰り返し通信する場合などは、その待ち時間が仕事の操作にどう影響するかを、実際に使う条件で確かめます。一般的な通信速度の説明だけでは、業務画面の待ち時間まで分かりません。

• どの営業所から、どの操作を試すか

  ログイン、検索、資料を開く操作など、両案で同じ仕事を使います。利用する端末、時間帯、同時に使う条件をそろえ、測れた範囲と、まだ試せない範囲を分けます。

• どの相手まで、接続できるか

  アプリの入口だけでなく、認証、DB、資料へ至る必要な通信を確かめます。現行の認証を自社へ残す案では、その経路が切れたときに何が使えなくなるかを質問します。

• 回線や接続機器が止まったとき、何が起きるか

  代わりの接続方法、切り替える担当、業務を続ける条件を確認します。予備の回線があることと、必要な仕事を続けられた試験結果を区別します。

これは質問の例で、現時点の試験結果ではありません。試す前に、業務責任者と、何をもって仕事に使えると判断するかを相談します。提供側のデモの結果を、自社の営業所・回線・利用条件で確認した結果へ置き換えないようにします。

止められる時間、戻せる時点、復旧の結果を分ける

同じアプリの置き場所を選ぶには、障害時にどこまで仕事を戻せればよいかもそろえます。設備が二拠点にあること、クラウドに復旧サービスがあることだけで、必要な認証とデータを使って業務を再開できるとは限りません。

仕事を止められる時間

業務へどの程度の停止を許容できるかという条件です。計画した切り替えで止める時間と、障害後に再開したい時間は、理由と状況を分けて聞きます。障害後の復旧時間の目標はRTOと呼ばれますが、この例では値を決めていません。

戻せるデータの時点

どの時点までの記録が戻ればよいかという条件です。許容するデータの古さはRPOと呼ばれます。最後の保存後に追加した記録をどう確かめるかも業務へ関係します。止められる時間とは別の条件です。

復旧を試した結果

必要な環境へ戻し、認証、記録、資料、業務の操作がどこまで使えたかという結果です。復旧の目標やサービスの説明があることと、試験で確認したことを分けます。

業務責任者へは、使えない場合に誰のどの仕事が止まるか、締切や代わりの作業は何かを確認します。IT担当と提供側へは、アプリやDBだけでなく、認証、資料、接続のどこまでが復旧の対象かを尋ねます。これにより、片方の案だけが一部の設備の復旧時間を示している比較を避けられます。

試験を頼む場合は、想定する障害と、再開までに確かめる仕事を両案でそろえます。認証は自社に残る構想なので、クラウド側のアプリを戻しただけでログインできるとは扱いません。自社の認証や回線が使えない場合に、何が必要かを確認します。

この例の復旧結果は両案とも未確認です。具体的な復元試験の計画を作る段階では、バックアップから戻し、業務再開を確かめる計画表を使えます。移行当日の順番や戻す判断を決めるなら、システム刷新の切替・確認・復旧条件の決め方へ進みます。本稿では、その前の配置案の採否を比べる条件として復旧を扱います。

更新・監視・問い合わせを誰が担うか確認する

設備をどこへ置くかと、誰が日々の仕事を行うかは分けて確認します。クラウドへ移しても、利用者の設定、アプリやデータの管理、問い合わせへの対応など、自社や委託先に残る仕事があります。何が提供事業者の範囲で、何を自社が行うかは、使うサービスと契約に沿って確かめます。

• 日常の設定と利用者への対応

  誰が利用者の追加・権限の変更を頼み、誰が作業を確認するかを整理します。営業所からの「ログインできない」「資料が見つからない」という問い合わせをどこへ集めるかも決めます。

• 更新と、更新後の業務確認

  サーバーやアプリ、DB、認証、接続機器などのうち、何を誰が更新するかを尋ねます。提供側で作業が終わった後に、自社がどの仕事を確かめるかも比較へ含めます。

• 異常を見つけ、必要な相手へつなぐ仕事

  何を監視し、誰が通知を受け、どの担当が原因を調べるかを確認します。複数の提供元にまたがる場合も、自社の窓口と調整する役割を残します。通知や初回の返事を、業務が復旧した結果へ読み替えません。

• バックアップと復旧の確認を続ける仕事

  保存の対象や設定の変更、試験の結果、残る課題を誰が見直すかを尋ねます。配置が変わった場合には、認証や接続を含む再開条件へ影響がないかも確かめます。

自社の認証を残すクラウド案では、その設備や担当の仕事も比較に残ります。一方、自社設備案でも外部へ保守を頼むなら、社内の窓口や確認する作業がなくなるわけではありません。両案の作業を、担当者が引き受けられる条件と合わせて並べます。この原票では運用担当も未確認です。

会社の情報をどこへ保存し、誰が閲覧・変更できるかという社内条件も、置き場所の比較へ反映します。必要な資料や管理条件は社内の責任者へ聞き、提供側にどう満たすかを確認します。個々の法令や契約の適用、製品の安全性が、この一般的な比較だけで確定するものではありません。

同じ期間と対象で、初期・継続・運用の支出を比べる

自社設備の購入額と、クラウドの一か月分の料金だけを比較しても、同じ期間の支出にはなりません。まず、比較する開始・終了の時点と、対象の仕事・設備・利用量をそろえます。何年間を比較するかは、設備更新の予定や社内の判断条件から確認します。本文では一律の年数や架空の料金を置きません。

最初に必要な作業と設備

設備の調達・設定、移行の調査、設計、接続の準備、試験など、始める前に何の支出があるかを聞きます。既存の設備を残す案なら、残る対象と更新時期も確かめます。

使い続ける料金

設備の保守や利用料、保存容量、利用量、ライセンスなどを、同じ前提と期間へそろえます。クラウド料金が利用量で変わる部分は、想定した量と変動する条件を明記してもらいます。

拠点とシステムの接続

回線、接続機器、クラウドへの通信、データの転送など、今回必要な経路の費用を確認します。通信のために残す自社設備や、別契約の費用を含むかも尋ねます。

自社と委託先の運用

監視、更新、問い合わせ、確認などの作業を誰が行うかと合わせて支出を読みます。自社の人が行う作業も、担当の確保や教育など、用意する条件を別に残します。

保存・復旧・並行利用

バックアップや復旧の仕組み、試験、必要な待機環境を含むかを聞きます。切り替えまで旧設備と新環境を両方使う期間があれば、その支出と、旧側を止められる条件も確認します。

将来の変更と利用終了

容量や利用者、構成が変わったときの料金条件、価格改定、情報を取り出して別の環境へ渡す作業を尋ねます。将来の価格や為替を記事が予測し、得になる案を決めることはしません。

見積もりには、比較期間、利用量、通貨・税の表示、含む作業と含まない作業、費用を見積もれない条件を添えてもらいます。「自社に残す認証の費用を除いたクラウド案」と「認証を含む設備更新案」なら、同じ対象へそろえ直します。支出の時期と総額の比較、会計・税務の扱いは別の判断なので、必要な条件は社内の担当へ確認します。

アプリを作る作業そのものの費用を整理したい場合は、システム開発の対象範囲と初期・継続支出を整理する方法を確認してください。保守の見積もりの作業や応答条件を詳しく比べるなら、保守費用の範囲と応答・復旧条件を読む方法を使えます。本稿では、配置案の比較から必要な内訳が抜けていないかを確認します。

回答と試験結果を反映し、採用・保留を判断する

提供側から回答が来たら、比較票のどの欄を、何の根拠で更新するかを分けます。構成の説明、見積もり、実際の接続や復旧の試験は、それぞれ分かる範囲が違います。資料の版と確認した条件を残し、同じ拠点・アプリ・操作へそろえて評価し直します。

採用の候補として判断できる状態

必要な仕事と依存関係、実際に試した接続や復旧の範囲、残る設備と運用担当、同じ期間の支出が分かる状態です。残る条件も社内の判断者へ示し、会社の手続きに沿って採否を決めます。配置案の採用と、契約・実際の移行の完了を分けます。

保留する状態

認証とアプリの接続、必要な待ち時間、復旧、自社へ残る運用、費用範囲などに未回答があり、判断材料が足りない状態です。質問先、必要な回答、回答後に何を試すかを決め、保留する範囲を明記します。

条件が合わず、見直しが必要な状態

自社に必要な仕事・停止の条件・運用体制へ合わないと確認した場合です。構成や作業範囲を変える代案があるかを尋ね、確認した理由を残します。未回答だけを、実現不可や不合格へ置き換えません。

必要な条件がまだ分からない場合も、資料の整理や、別の拠点・担当への確認は進められます。判断できる項目と保留する項目を分けることで、全体を曖昧にしたまま採用することや、全ての調査を一括して止めることを避けられます。

同じ対象と確認条件で、回答を比べる

共通の仕事・拠点・期間・確認条件を両案へ示し、回答と試験結果を対応付けて比べます。未確認は未確認として残し、計画の記載と実際に試した結果を分けます。

条件を更新したら、アプリ、認証、接続、復旧、支出のどこへ影響したかを確かめます。必要な試験と見積もりを同じ版へそろえ、未確認が残る理由も判断者へ渡します。比較票を記入したことを、実際の設備更新や移行が終わった記録にはしません。