クラウド移行を外注する方法（発注手順とベンダー選びのやり方）

クラウド移行を「外注」すべき理由と、最初に決めるべきこと

クラウド移行は、サーバーをクラウドに置き換えるだけでは終わりません。ネットワーク、セキュリティ、データ移行、運用監視、障害対応、コスト管理まで含むため、社内に専門家がいない場合は外注（ベンダー依頼）が現実的です。特に情シスが少人数の企業や、兼務が多い中小企業では、移行中のトラブル対応が通常業務を圧迫しがちです。

一方で、丸投げは危険です。なぜならクラウドは「毎月の利用料」で動くため、構成や設定を誤ると移行後にコストが膨らみ続けるからです。外注成功のコツは、技術を理解することよりも「意思決定のポイントを押さえること」です。

移行を検討し始めたら、最初に次の3点を決めてください。

• 目的：老朽化対策、BCP（災害対策）、拠点増、性能改善、セキュリティ強化、開発スピード向上など
• 範囲：全システム一括か、会計・基幹・ファイルサーバーなど段階的か
• 制約：停止できない時間帯、個人情報の扱い、監査要件、予算上限、移行期限

例えるなら、引っ越し業者に依頼するときに「どこに」「いつまでに」「何を運ぶか」が曖昧だと見積がブレるのと同じです。クラウド移行も、要件が曖昧だとベンダー提案が比較できず、価格も品質もコントロールできません。

外注前に社内で準備すべきインプット（棚卸し・要件・優先順位）

ベンダー選定や見積の精度は、発注側が出せる情報量で決まります。専門知識がなくても、業務側の情報を集めれば十分戦えます。まずは棚卸し（現状把握）を行い、ベンダーに渡せる「前提資料」を揃えましょう。

最低限、次の情報があると見積と提案が具体化します。

• 対象システム一覧：名称、利用部門、利用人数、重要度（止まると困る度）
• 現行環境：サーバー台数、OS、DB、ミドルウェア、保守契約、ネットワーク構成（分かる範囲で可）
• データ量：ファイル総量、DBサイズ、日次増分、バックアップ方式
• 連携：他システムとのデータ連携、バッチ処理、外部サービス（決済、メール、SaaS）
• 運用：誰が何をしているか（アカウント発行、権限、月次処理、監視、障害時対応）
• 非機能要件：可用性、性能、セキュリティ、ログ、監査、復旧目標

また、クラウド移行には大きく分けて「そのまま移す」「一部作り替える」「全面的に刷新する」という選択肢があります。専門用語ではリフト＆シフト、リプラットフォーム、リファクタリングなどと呼ばれますが、重要なのはどこまで手を入れるかで費用と期間が激変する点です。

判断の目安として、次のように優先順位をつけると合意形成が早まります。

• まず止められない基幹は「最短で安全に移す」
• 頻繁に改修する業務アプリは「移行と同時に改善する」
• 既にSaaSで代替できる領域は「移行より置き換えを検討する」

ここまで準備できれば、ベンダーから出てくる提案が「どのクラウドを使うか」だけでなく、「運用設計」「セキュリティ」「移行手順」「体制」まで揃った現実的な内容になります。

発注手順：相談〜要件整理〜RFP〜見積比較〜契約〜実行の流れ

クラウド移行の外注は、発注プロセスをきちんと踏むほど失敗が減ります。特に、相見積（複数社比較）をする場合は、同じ条件で比較できるようにRFP（提案依頼書）を用意するのが有効です。難しければ、1〜2枚の「要望整理シート」でも構いません。

実務で使える標準的な流れは次の通りです。

1. 事前相談（30〜60分）：現状・目的・制約を共有し、移行の方向性（段階移行か一括か）を仮決め
2. 現状調査（アセスメント）：システム棚卸し、リスク洗い出し、概算費用とスケジュールの提示
3. 要件整理：移行対象、停止許容、セキュリティ要件、運用体制、移行後のToBe像を明確化
4. RFP配布・提案依頼：前提条件、スコープ、成果物、期間、体制、見積の前提を書面化
5. 見積比較・評価：金額だけでなく、作業範囲、体制、運用費、リスク対応を比較
6. 契約：準委任/請負の切り分け、成果物、検収条件、変更管理、SLAの確認
7. 設計〜移行〜テスト〜切替：移行リハーサル、戻し手順（ロールバック）、運用引継ぎまで実施

ポイントは、最初に「現状調査（アセスメント）」を別フェーズとして発注することです。いきなり本番移行の請負にすると、ベンダーは不確実性を価格に上乗せするか、見積を甘くして後から追加費用になりやすくなります。調査→計画→実行を分けることで、費用とリスクを分解して管理できます。

なお契約形態は、調査や要件整理は準委任（工数精算）になりやすく、移行作業は請負（成果物）になりやすい傾向があります。どちらが良い悪いではなく、変更が起きやすい工程は準委任の方が現実的です。発注側は「どこまでが固定で、どこからが追加か」を事前に合意しておきましょう。

ベンダー選びのやり方：比較軸と、提案で必ず確認するチェックリスト

クラウド移行のベンダーは、SIer、クラウド専業、開発会社、MSP（運用事業者）など多様です。選び方を間違えると「移行はできたが運用が回らない」「セキュリティ監査で指摘が出る」「請求が読めない」といった問題が後から出ます。ここでは、技術の細部ではなく、提案書で見抜ける比較軸に絞ります。

まず、比較軸（評価項目）を決めましょう。

• 実績の近さ：同業種・同規模・同程度の制約（停止不可、個人情報、監査）での移行経験
• 体制：誰がPMか、設計者は誰か、運用担当はいるか、属人化しないか
• 設計思想：コスト最適化、セキュリティ、可用性のバランスが説明できているか
• 運用まで含むか：監視、障害一次対応、パッチ適用、バックアップ、月次レポート
• 透明性：見積の前提、作業範囲、除外事項、追加費用条件が明確か

次に、提案で必ず確認したいチェックリストです。面談時にそのまま質問として使えます。

• 移行方式：段階移行の切替手順があるか、停止時間の見積根拠はあるか
• 移行リハーサル：本番前に検証環境で何回リハーサルするか、手順書は残るか
• 戻し手順：不具合時にオンプレ/旧環境に戻す条件と手順が明文化されているか
• セキュリティ：権限設計、ログ、暗号化、脆弱性対応、運用ルールまで含まれるか
• コスト：クラウド費用の内訳（固定/変動）、コスト監視・上限アラート設計があるか
• 運用移管：運用手順書、監視項目一覧、障害時の連絡フロー、引継ぎ研修があるか

価格比較の注意点として、移行費用（初期）だけでなく、運用費用（毎月）とクラウド利用料（従量）を合わせたTCOで見ましょう。特にクラウドは、構成次第で費用が変動します。「月額いくらになりそうか」を試算して説明できるベンダーは、運用視点が強い傾向があります。

見積の読み方：費用が増えるポイントと、RFPに書くべき条件

クラウド移行の見積は、専門用語が多く「何にいくらかかるのか」が見えづらいことがあります。発注側が押さえるべきは、見積の粒度と前提条件です。見積が一式表記だらけだと、範囲外が出たときに追加費用になりやすくなります。

見積は、少なくとも次のように分解されているか確認しましょう。

• 調査・要件整理：現状調査、課題整理、移行計画、基本方針
• 設計：クラウド構成、ネットワーク、権限、バックアップ、監視、セキュリティ
• 移行作業：環境構築、データ移行、アプリ設定変更、DNS/証明書対応
• テスト：結合、性能、障害試験、切替リハーサル
• 切替・運用移管：本番切替、初期安定化、手順書、教育
• 運用：監視、障害対応、改善提案（任意）

費用が増えやすいポイント（追加になりやすいポイント）は概ね決まっています。

• 想定外の依存関係：古いシステム同士の連携や、特定端末だけの特殊設定
• 停止できない要件：夜間・休日の切替、二重運用期間の増加
• セキュリティ・監査対応：ログ保全、権限の棚卸し、証跡整備、脆弱性診断
• データ移行の難易度：容量が大きい、増分が多い、整合性チェックが複雑
• 運用設計の不足：監視未設計→障害対応が後追いで追加作業になる

これらを抑えるため、RFP（または要望整理シート）に書くべき条件を明文化します。

• 成果物：構成図、手順書、運用設計書、アカウント/権限表、監視一覧、バックアップ設計
• 前提：移行対象、除外範囲、停止許容、作業時間帯、利用部門の協力範囲
• 変更管理：追加要件の扱い、見積再提示のルール、承認フロー
• 品質基準：テスト項目、受入条件、切替判定基準、ロールバック条件

発注側が「分からないのでお任せ」になりやすいのは運用設計です。しかし、移行後のトラブルは運用の穴から起きます。見積段階で運用の成果物を要求することが、長期的なコストとリスクを下げる最短ルートです。

移行プロジェクトを失敗させない運用・体制づくり（丸投げ防止の実務）

クラウド移行の外注でありがちな失敗は、「ベンダーは作業したつもり、発注側は理解していないまま検収」という状態です。これを避けるには、意思決定と情報共有の仕組みを最初に作ります。専門知識よりも、会議体と成果物の管理が重要です。

おすすめの体制・進め方は次の通りです。

• 社内の窓口を一本化：情シスまたは業務責任者が窓口になり、質問・回答のルートを統一
• 週次の定例：進捗だけでなく、課題・リスク・判断事項を必ず議題に入れる
• 課題管理表：課題の期限、担当、影響、対応方針を一覧化して合意する
• 切替判定会：本番切替のGo/No-Goを、要件とテスト結果で判断できる形にする

特に重要なのが「誰が最終判断するか」です。例えば、停止時間の延長を許容するか、追加費用をかけて冗長化するか、運用を内製するか外注するかなど、クラウド移行には経営判断が混ざります。ここが曖昧だと、ベンダーは保守的な（高価な）提案をしやすくなります。判断者と判断基準を先に決めるだけで、プロジェクトは驚くほど進めやすくなります。

また、移行後の運用で現場が困るのは「問い合わせ先が分からない」「障害の一次切り分けができない」「費用の見方が分からない」の3点です。これを防ぐため、引継ぎで最低限カバーしたい項目です。

• 運用手順：日次・週次・月次の作業、アカウント管理、権限付与のルール
• 監視：アラートの種類、優先度、対応手順、連絡フロー、夜間対応の有無
• コスト管理：請求の内訳、増えたときの原因の見つけ方、アラート設定

クラウドは移行して終わりではなく、運用で価値が決まります。だからこそ、外注でも「運用を設計し、見える化し、引き継ぐ」ことを契約と成果物に入れましょう。

まとめ

クラウド移行を外注で成功させるには、技術の細部を理解することよりも、発注の進め方とベンダー比較の軸を持つことが重要です。まず目的・範囲・制約を整理し、棚卸し情報を揃えることで、提案と見積の精度が上がります。次に、調査（アセスメント）と実行を分け、RFPで条件と成果物を明文化すれば、相見積でも比較しやすく、追加費用のリスクも下げられます。

ベンダー選びでは、価格だけでなく、移行方式、戻し手順、セキュリティ、運用設計、コスト監視まで説明できるかを確認してください。最後に、週次定例・課題管理・切替判定などの会議体を整え、丸投げにならない情報共有と意思決定の仕組みを作ることが、移行後の安定運用に直結します。「移行後に困らない運用」を含めて発注するのが最短の成功ルートです。