上司から「そろそろクラウドを検討してくれないか」と言われたとき、その背景には具体的な出来事があります。
もっとも多いのは、ベンダーからの保守終了通知でしょう。封筒を開けて日付を確認し、カレンダーを見て、残りの時間を数える。そこから「どうするか」の検討が始まります。次に多いのが、更新見積もりの金額です。前回の調達時とは為替も部材価格も変わっており、同等構成でも見積額が想定を上回る。稟議に出す前に、別の選択肢を探しておきたくなります。
もう一つ、あまり表には出ないものの、実際には大きな要因になっているのが人の問題です。長年サーバーを見てきた担当者が異動する。あるいは、保守を担ってくれていた地元のベンダーが体制を縮小する。「触れる人がいなくなる」という状況が現実味を帯びたとき、自社で機器を抱え続けることへの不安が一気に高まります。
こうした状況で「クラウドにすれば解決するのでは」という話が出るのは、ごく自然な流れです。ただ、その期待がどこまで妥当なのかは、検討の入口では判断がつきません。
本記事は、クラウド上にサーバーを構築するための手順書ではありません。クラウドに置くかどうかを含めて、社内で判断するための整理です。管理画面の操作やコマンドについては各サービスの公式ドキュメントのほうが正確ですので、そちらに委ねます。
検討を進める前に、一度切り分けておきたいことがあります。社内で「サーバー構築」と呼ばれているものは、実際には性格の異なる 3 つの話が混ざっていることが多いのです。
どれが正しいという話ではありません。案件ごとに答えが変わりますし、1 つの案件の中で 3 つが混在することもあります。ただ、混ざったまま議論すると、比較すべきものが噛み合わなくなります。
これまで存在しなかった用途のために、サーバーを用意するケースです。新しい業務システムを動かす、検証環境を作る、部門から要望のあった仕組みを立ち上げる。既存環境からの引き継ぎがないぶん、要件を白紙から設計できます。
自由度が高い反面、比較対象がないため「これで十分なのか」の判断がつきにくいという難しさもあります。
このタイプに当てはまるサイン
移行元となる既存サーバーが存在しない
利用者数や処理量の見込みが、まだ数字で固まっていない
「まず小さく始めて様子を見たい」という話が出ている
すでに稼働している環境を、別の場所に載せ替えるケースです。実務では、このパターンがもっとも多いのではないでしょうか。
難しさは、動いているものを止めずに移す点にあります。既存システムとの連携、データ量、切り替え時の業務停止時間。新規構築にはない制約が、いくつも付いてきます。「そのまま移すのか、この機会に作り替えるのか」という判断も、ここで発生します。
このタイプに当てはまるサイン
保守終了や機器の老朽化が、検討のきっかけになっている
移行対象のシステムが、他の仕組みとデータをやり取りしている
「いつ切り替えるか」の調整先が、社内に複数ある
3 つ目の選択肢です。そして、検討からもっとも抜け落ちやすい選択肢でもあります。
サーバーを立てて自社で運用するのではなく、その機能を提供しているサービスを利用する。メールなら Microsoft 365 や Google Workspace、ファイル共有ならクラウドストレージ、データベースならマネージドのデータベースサービス。「サーバーを構築する」という前提を一度外してみると、そもそも自前で持つ必要がない用途が含まれていることは珍しくありません。
特にメールと DNS は、外部公開が絡むと運用の難易度が上がるため、マネージド寄りの選択が現実的なケースが多い領域です。一方で、社内限定のファイル共有や、既存の業務システムと密に連携している用途では、自前で構える合理性が残ります。
このタイプに当てはまるサイン
移行対象の用途が、一般的なもの ( メール、ファイル共有、Web 公開など ) である
社内に独自の作り込みがほとんどない
運用に充てられる人員が、現時点で確保できていない
サーバー単体の話として検討を進めると、後から想定外の作業が発生することがあります。サーバーは 1 台で完結する存在ではなく、周辺の仕組みとつながって動いているためです。
たとえば、社内のサーバーをクラウドに 1 台移すとします。このとき同時に動くのが、認証、回線、バックアップの 3 つです。
認証については、これまで社内の Active Directory で管理していたアカウントを、クラウド上のサーバーからどう参照するのかを決める必要があります。回線については、社内 LAN で完結していた通信がインターネット側を通るようになるため、帯域と経路の見直しが発生します。バックアップについては、取得先も復元手順も変わります。
さらに、監視をどこから行うのか、端末側のセキュリティー対策との関係をどう整理するのか、といった論点も続きます。
これらは別々の担当や別々の契約で管理されていることが多く、サーバーの検討時には視界に入りにくい部分です。移行計画を立てる段階で、「サーバーを動かすと、他に何が動くのか」を一度線でつないで確認しておくと、後戻りが減ります。
ここからが本記事の中心です。クラウドに置くかどうかを判断する際、実務で迷いやすい論点を 5 つに整理しました。
各項目の末尾に、移す判断に傾く目安と、残す判断に傾く目安を併記しています。ただし、これは目安であって基準ではありません。複数の項目で判断が割れることは普通にありますので、そのときは業務への影響が大きい項目を優先して考えてみてください。
障害が起きたとき、その業務は何時間止まってよいのか。データはどの時点まで戻せればよいのか。RTO ( 復旧時間目標 ) と RPO ( 復旧時点目標 ) と呼ばれる考え方ですが、ここが数字で決まっていない案件は、実は少なくありません。
「止まったら困る」では設計ができません。「困る」の中身が、30 分なのか半日なのか 3 日なのかで、必要な構成もコストも大きく変わるためです。
そして重要なのは、この数字を情報システム部門だけで決めないことです。業務部門と経営層を巻き込んで合意しておかないと、障害発生時に「なぜこんなに時間がかかるのか」という話になります。
移す判断に傾く目安：復旧時間を短くしたいが、自社で冗長構成を組む余力がない
残す判断に傾く目安：拠点内で完結する処理で、通信断があっても業務が継続できる必要がある
ここは稟議で必ず問われる部分です。そして、技術的な検討からはもっとも抜けやすい部分でもあります。
まず、減価償却です。「クラウドに移しましょう」と提案を持っていったところ、経理から「あのサーバー、まだ償却が 2 年残っていますよ」と指摘される。よくある場面です。除却損の扱いも含めて、財務側と早い段階ですり合わせておく必要があります。
次に、保守契約の残期間です。年間契約が来年 3 月まで残っているなら、その期間はコストが二重に発生します。移行時期を数か月ずらすだけで、無駄な支出を避けられることもあります。
そして、ライセンスの持ち込み可否です。Windows Server やデータベース製品などは、クラウド上で使う際のライセンス条件が、オンプレミスとは異なる場合があります。既存のライセンスをそのまま持ち込めると思っていたら追加費用が必要だった、という事態は避けたいところです。
この 3 点は、いずれも技術部門だけでは確認しきれません。経理、購買、ベンダー窓口を巻き込んで、早めに整理しておくことをおすすめします。
移す判断に傾く目安：償却が終わっており、保守契約の更新時期が近い
残す判断に傾く目安：償却が数年残っている、またはライセンス条件の確認が取れていない
クラウド上のサーバーは、インターネットまたは専用線を経由して利用します。当たり前のようですが、この前提が業務要件と噛み合わないケースがあります。
確認したいのは、社内から発生する通信量、拠点間の接続方式、そして閉域が求められる業務の有無です。取引先との契約や業界のガイドラインで、データの所在や通信経路が指定されていることもあります。
もう一つ、見落とされやすいのがデータ転送にかかる費用です。クラウドからの送信データ量に応じて課金される仕組みが一般的で、大量のファイルを日常的にやり取りする業務では、想定以上の金額になることがあります。
移す判断に傾く目安：拠点が分散しており、社内オンリーの構成に無理が出ている
残す判断に傾く目安：閉域要件がある、または大容量データを日常的に扱う
クラウドを使うとき、事業者と利用者のあいだには役割の線が引かれています。責任共有モデルと呼ばれる考え方で、この線の位置は契約書やサービス仕様に明記されています。どこからが自社の担当かは、契約前に確認できる情報です。ここで迷うことは、実はあまりありません。
難しいのは、線の位置を知っていることと、その内側を担えることが別だという点です。
線より内側には、たとえば OS の更新をいつ適用するか、アカウントにどこまでの権限を与えるか、ログをどれくらいの期間残すか、といった判断が並びます。どれも一度決めれば終わりというものではなく、業務の変化や人の入れ替わりに応じて、繰り返し見直しが必要になるものです。
検討段階で確認しておきたいのは、こうした判断を下せる人が社内に何人いるか、という一点に尽きます。1 人しかいない状態で本番運用に入ると、その人の予定が、そのまま環境の可用性になります。休暇を取りにくい、という形で現れることもあります。
移す判断に傾く目安：機器の交換や電源・空調の管理といった、物理的な作業の負担を減らしたい
残す判断に傾く目安：権限設計や更新適用を判断できる人が、現時点で 1 人しかいない
ここも稟議で必ず問われる部分です。
オンプレミスの費用は、購入時にまとまった金額が動き、その後は保守費という形で読みやすく推移します。一方、クラウドは使った分だけ支払う従量課金が基本です。この違いは、単に「初期費用が安い」という話にとどまりません。
年度予算という仕組みとの相性が、まず問題になります。月々の請求額が変動するため、期首に組んだ予算との差分が発生します。次に、部門按分です。複数の部門で使っているリソースの費用を、どう振り分けるのか。ここが決まっていないと、月末に経理と揉めることになります。
対策としては、リソースにタグを付けて用途や部門を識別できるようにしておくこと、予算アラートを設定して閾値を超えたら通知が飛ぶようにしておくこと、そして使っていないリソースを定期的に棚卸しすることの 3 点です。
いずれも構築前に決めておかないと、後から遡って整理するのが非常に手間になります。
費用を比べる際に、もう一点。従量課金は「使った分だけ」の仕組みですが、これは裏返せば「常に使っていれば、常に課金される」ということでもあります。
稼働に波がある業務では、この仕組みが効きます。夜間や休日に止められる検証環境、繁忙期だけ増強したいシステム。使わない時間を減らせるほど、有利になります。
逆に、24 時間動き続ける基幹系や、外部との大容量のデータ授受が日常的に発生する用途では、この仕組みが働く余地がありません。そうした構成では、総額でオンプレミスを上回る結果になることもあります。
安いか高いかは、稼働のかたちで決まる — この見方で自社のシステムを分類すると、どれをクラウドに寄せるべきかが見えやすくなります。
移す判断に傾く目安：数年おきにまとまった投資判断を迫られる構造から抜けたい
残す判断に傾く目安：稼働が安定しており、変動費より固定費のほうが管理しやすい
判断軸を整理したうえで、実際の進め方を見ていきます。各工程には、後から効いてくる「見落とされやすい論点」がありますので、そこを中心に触れます。
現在稼働しているサーバー、OS のバージョン、ミドルウエア、データ量、保守期限、ライセンス、そして各システムの依存関係を書き出します。規模にもよりますが、2 〜 4 週間を見ておくと現実的です。
見落とされやすい論点：担当者の頭の中にしかない情報です。「この設定はこういう理由でこうなっている」という背景が、どこにも記録されていない。この状態で移行に入ると、設計段階で前提が崩れます。棚卸しの段階で、なぜその設定なのかまで含めてヒアリングしておくと、後の作業が楽になります。
システムごとに、どう扱うかを決めます。選択肢は大きく 3 つです。
見落とされやすい論点：全部を一度に移さない、という前提です。まず影響の小さいシステム ( 社内ツール、検証環境など ) から移して運用のノウハウを溜め、その後に基幹に近いものへ広げる。この順序が、結果的にもっともリスクを抑えられます。
ネットワーク構成、権限設計、バックアップ、監視、命名規則とタグの体系を決めます。
見落とされやすい論点：既存システムとの依存関係です。「このシステムを移すと、どこに影響が出るのか」を洗い出さないまま設計に入ると、移行当日に想定外の停止が発生します。特に、複数のシステムがデータを受け渡している構成では、事前の整理が欠かせません。
データを移し、動作を確認し、業務を切り替えます。
見落とされやすい論点：戻す判断を、いつまでに、誰が下すか。切り戻し手順を用意しておくことは前提として、当日に効いてくるのは判断期限のほうです。「何時までに正常性が確認できなければ旧環境に戻す」という線を先に引いておくと、迷っている間に停止が長引く事態を避けられます。
手順書、監視ルール、変更管理、障害対応フローを引き渡します。
見落とされやすい論点：引き継ぎ資料を、引き継ぐ側ではなく受け取る側が書く、という方法もあります。構築した本人が書くと、本人にとって自明なことは省略されがちです。受け取る側が書き、それを構築者が確認する形にすると、分からない箇所が自然に浮かび上がります。
3 つの形を、判断軸で横に並べます。
|
観点 |
オンプレミス継続 |
クラウド |
ハイブリッド |
|
費用のかかり方 |
更新時にまとまった投資 |
月々変動 |
領域ごとに分かれる |
|
増やしたいときの待ち時間 |
機器調達に数週間〜数か月 |
短時間 |
領域による |
|
物理的な保守作業 |
自社とベンダー |
事業者側 |
切り分けの設計が必要 |
|
データがどこにあるか、聞かれたときに答えられるか |
自社で把握 |
契約と設定の確認が前提 |
業務単位で分けられる |
|
法令・取引先要件 |
制約に合わせやすい |
要件の確認が必要 |
領域ごとに対応 |
|
担当者が 1 人辞めたときの影響 |
機器の中身が分からなくなる |
権限とアカウントが分からなくなる |
影響範囲の特定に時間がかかる |
|
費用の説明しやすさ |
年度予算に載せやすい |
按分ルールの整備が前提 |
— |
既存機器の償却が残っており、当面の投資を抑えたい
閉域での運用が業務要件として求められている
稼働が安定しており、リソースの増減がほとんど発生しない
拠点の回線が細く、クラウド利用が現実的でない
利用者数や処理量の変動が大きい
拠点が分散しており、社内オンリーの構成に無理が出ている
機器の調達リードタイムが業務のスピードに合わない
物理保守に充てられる人員が確保できない
機微なデータはオンプレミス、それ以外はクラウド、という切り分けが必要
段階的な移行を前提に、一定期間は併存させたい
表の中で、あえて「担当者が 1 人辞めたときの影響」という行を入れました。どの形を選んでも影響はゼロにならない、という点は押さえておきたいところです。形を変えることで、失われる知識の種類が変わるだけとも言えます。
ここは、ベンダーの資料では触れられにくい部分かもしれません。ただ、検討段階で共有しておかないと、移行後に「思っていたのと違う」という話になります。
クラウド移行は、運用の対象がハードウエアからアカウントとポリシーに変わることであって、運用がなくなることではありません。
具体的に、移した後も残るものを挙げます。
OS・ミドルウエアのパッチ判断：適用するか、業務影響を見て見送るか。この判断は自社に残ります
権限管理：誰にどこまでの権限を与えるか。人事異動のたびに見直しが必要です
コスト管理：月次で利用状況を確認し、不要なリソースを止める。オンプレミスにはなかった作業です
監査対応：設定状況やアクセスログについて、社外に説明する責任は変わりません
利用者からの問い合わせ：「つながらない」「遅い」を最初に受け止める役割は、社内に残ります
加えて、移行前には存在しなかった作業も出てきます。
分かりやすいのは、契約の把握です。管理画面から数クリックでリソースを増やせる手軽さは、裏を返せば、情報システム部門を通さずに環境が増えていくということでもあります。ある月の請求内訳を経理から回されて、見覚えのない項目に気づく。規模の大小を問わず起こることです。
次に、選択の可逆性です。特定の事業者の機能に合わせて作り込むほど、日々の運用は楽になります。ただ、その分だけ、後から別の選択肢に移る際の負担は大きくなる。移行直後に意識する必要はありませんが、価格改定やサービス方針の変更が起きたときに、この差が効いてきます。
そして、理解の維持です。外部に任せる範囲が広がると、社内には「何を頼んでいるか」は残っても、「どう動いているか」が残りにくくなります。見積もりを受け取ったとき、その金額が妥当かどうかを社内で検証できるか。ここが判断の目安になります。
「移したのに、思ったより仕事が減らなかった」という声が出るのは、担当者の努力が足りないからではありません。減る作業と、残る作業と、新しく増える作業がある。この構造を、検討段階で共有しておくことが、後の落差を小さくします。
「今は動いているから、しばらくこのままで」という判断は、短期的には合理的に見えます。実際、無理に動かして問題を起こすより安全な場面もあります。
ただ、この選択が続くと、いくつかの負債が静かに積み上がっていきます。派手な事故として現れないぶん、気づいたときには選択肢が狭まっているというのが、この問題の厄介なところです。
|
現在の症状 |
1 〜 2 年後に起きやすいこと |
経営層への説明のしやすさ |
|
保守終了機器の稼働継続 |
故障時に部品が調達できず、復旧が数日単位になる |
停止してから説明することになり、事後対応になりやすい |
|
復元テストを数年実施していない |
いざ戻そうとして失敗し、データが戻らない |
「バックアップは取っています」と報告してきた分、説明が難しい |
|
担当者 1 名への依存 |
異動・退職と同時に、設定変更の判断が止まる |
人の話になるため、投資判断として通しにくい |
|
構成図・手順書の不在 |
外部に相談しようにも、現状を説明できない |
見積もりが取れず、比較検討そのものが始まらない |
いずれも、発生してから対処すると選択肢が限られます。故障してから慌てて手配すると、比較検討の時間が取れず、提示された条件で決めざるを得なくなる。この構造は、規模を問わず起こります。
先送りは、それ自体が一つの意思決定です。意識的に選んでいるのか、判断を保留しているだけなのか。ここを区別しておくだけでも、社内の議論は変わってきます。
ここまでの内容を、チェックリストにまとめました。社内での稟議準備や、外部への相談前の整理にお使いいただける粒度を意識しています。
☐ サーバー、ストレージ、ネットワーク機器の一覧と、それぞれの導入年・保守期限
☐ OS とミドルウエアのバージョン、サポート終了時期
☐ 各システムの依存関係 ( どれが止まると、どこに影響するか )
☐ バックアップの取得状況と、直近の復元テスト実施日
☐ ライセンスの種類と、クラウドへの持ち込み可否
☐ 既存機器の減価償却の残存状況、保守契約の残期間
☐ 監視アラートの通知先が、現在の担当者になっているか
☐ 直近 1 年の障害履歴と、そのときの対応内容
☐ 今回の検討の目的 ( EOL 対応、運用負荷軽減、拠点対応、費用構造の見直しなど )
☐ 業務ごとの RTO・RPO と、経営層との合意状況
☐ セキュリティー要件 ( 法令、取引先要件、社内規程 )
☐ 構築フェーズに充てられる社内工数
☐ 運用フェーズを担う人員と、その役割分担
☐ 深夜・休日の一次対応の所在
☐ 予算規模 ( 初期費用と、運用期間の総コスト )
☐ 内製する範囲と、外部に任せる範囲の想定
☐ 費用の部門按分ルールと、予算アラートの設定方針
☐ 既存機器の退役計画 ( データ消去、廃棄、リース返却 )
☐ 移行時に許容できる業務停止時間
☐ 切り戻しの判断期限と、その判断者
☐ 移行後のドキュメント整備の担当
このリストは、埋めることが目的ではありません。実際に書き出してみると、たいてい 3 分の 1 ほどが「確認しないと分からない」で止まります。その止まった箇所こそが、社内だけでは判断できない領域です。 どこで止まったかをメモしておくと、外部に相談する際、そのまま論点として渡せます。
移行が終わった環境を、半年ほど経ってから見に行くと、気づくことがあります。新しい基盤の上で、以前と同じ問題が再現しているのです。
たとえば、あるサーバーの通信許可設定に、用途の分からないルールが 1 行だけ残っている。移行の際、消してよいか判断がつかず、そのまま引き継いだ。これは機器を新しくしたことでは解決しません。「なぜその設定なのか」が記録されていないという状態が、場所を変えて存続しているだけだからです。
同じことが、障害時の連絡先にも、変更申請の承認ルートにも、定期点検の頻度にも起こります。いずれも構成の問題ではなく、決めごとが文書になっていないことの問題です。基盤を新しくしても、決めごとは自動的には生まれません。
そして最後に残るのが、線引きの曖昧さです。どこまでを情報システム部門が見て、どこからを業務部門が担い、どこから先を外部に依頼するのか。ここが「そのつど相談」で回っている間は、担当者が変わるたびに同じ確認が繰り返されます。むしろ、環境が新しくなったぶん、確認に時間がかかるようになることさえあります。
外部の支援を活用するという選択肢も考えられます。設計・構築だけでなく、運用設計や資料の整備まで含めて相談先を選ぶと、構築後の運用が回りやすくなるという見方はできます。
ただし、外部に任せたからといって、社内の役割整理まで自動的に進むわけではありません。業務上の優先順位を決めるのも、止めたくない業務を判断するのも、社内に残る仕事です。構築、運用設計、人の役割整理の 3 つが揃って初めて、現場の課題が動き始める — この前提を持って検討に臨めるかどうかで、5 年後の運用の姿は変わってきます。
ケースによります。機器の調達、電源や空調の管理、物理的な故障対応といった作業は、事業者側に寄せられます。この部分の負担は確実に軽くなります。
一方で、OS やミドルウエアのパッチ適用の判断、アカウントと権限の管理、コストの確認と最適化、そして利用者からの問い合わせ対応は、引き続き自社に残ります。加えて、複数のクラウドサービスを使い始めると、その組み合わせを把握する手間も新たに発生します。
「運用がなくなる」のではなく、「運用の対象が変わる」と捉えていただくのが実態に近いと思います。物理的な作業が減るぶん、設計と管理の比重が増える、という感覚です。
この問いに単年度の数字で答えると、後で苦しくなることがあります。クラウドの費用は月々変動しますし、移行初年度は旧環境と並行稼働する期間の費用も乗るためです。
実務的には、比較の土俵を変える形で説明するのが現実的です。「年間の費用が下がるかどうか」ではなく、「5 年間で必要になる支出の合計と、そのかたち」で示す。オンプレミス継続なら数年後にまとまった更新投資が発生しますが、その金額は今の時点では確定していません。一方、クラウドは月々の変動幅が読みにくい。どちらも不確実性を抱えている、という前提を先に共有しておくと、議論がかみ合いやすくなります。
そのうえで、金額以外の判断材料 — 復旧までの時間、担当者が 1 人辞めたときの影響、調達にかかる待ち時間 — を並べて示す方法もあります。
規模と対象システムの数によりますが、おおまかな目安としては次のようになります。
現状の棚卸しに 2 〜 4 週間。移し方の決定と設計に 1 〜 2 か月。影響の小さいシステムでの試行に 1 か月程度。本番システムの移行に 2 〜 6 か月。合計で、半年から 1 年程度を見ておくと、無理のない計画になります。
短縮したい場合、削られやすいのは棚卸しと試行です。ただし、この 2 つを飛ばすと、本番移行で想定外の依存関係が見つかり、結果的に期間が延びることがあります。急ぐ場合ほど、対象を絞って範囲を小さくするほうが確実です。
急ぐ前に、3 つの選択肢を並べて比較することをおすすめします。同等品にリプレースする、延長保守で当面をしのぐ、構成そのものを見直す ( クラウド化を含む )。
期限に追われて動くと、比較検討の時間が取れず、本来やるべきだった構成の見直しが後回しになりがちです。逆に、通知が届いた時点で少しでも時間の余裕があれば、その期間を判断材料の整理に充てられます。
まずは「いつまでに何を決める必要があるか」を逆算し、検討に使える時間を確保することが先決です。
棚卸しからです。
サーバーの一覧、保守期限、OS のバージョン、データ量、依存関係、バックアップの状況。これらを書き出すだけでも、判断の土台ができます。外部に相談する場合も、この情報がないと具体的な提案は返ってきません。
そのうえで、本記事のチェックリストで空白になっている領域を確認してみてください。空白が多い部分ほど、後の工程で判断が止まりやすい箇所です。
サーバーをクラウドで構築するかどうかの判断は、技術の比較だけでは決まりません。本記事で整理した要点を、4 点にまとめます。
「サーバー構築」を分解する。 新しく立てるのか、今あるものを移すのか、そもそも自前で持たないのか。この切り分けが、比較の出発点になります
既存資産と体制から逆算する。 償却の残存、保守契約、ライセンス条件、そして運用に充てられる人員。技術要件より先に、ここが判断を規定します
移した後に残るものを、先に共有する。 パッチ判断、権限管理、コスト管理、監査対応。これらは移行では消えません
先送りも、一つの意思決定として扱う。 意識的に選んでいるのか、判断を保留しているだけなのか。ここを区別しておくだけで、社内の議論は変わります
唯一の正解はありません。同じ業種、同じ規模でも、既存資産の状況と運用体制が違えば、最適な選択は変わります。本記事の判断軸とチェックリストが、自社の状況を整理する手がかりになれば幸いです。
なお、判断材料の整理や、構築後の運用設計まで含めて検討する場面では、外部の知見を借りるという選択肢もあります。
横河レンタ・リース株式会社は日本ヒューレット・パッカード社の Platinum パートナーとして、サーバー、ネットワーク、クラウドを含むITインフラの知見をもとに、業務環境に合わせた構築、移行、運用支援のご相談を承っています。「まず現状を整理したい」「方式選定の判断材料が欲しい」といった段階からでも、お気軽にお問い合わせください。