オンプレミス環境からクラウドへの移行プロジェクトを任されたエンジニアやPMに向けた内容です。
見積もりが最初の提示額から大きくずれてしまう案件は、珍しくありません。
見積もりが崩れる原因の多くは、クラウド技術そのものの不確実性ではなく、移行対象の範囲（スコープ）を曖昧なまま握ってしまうことにあります。
何が起きるかを整理すると、まず移行対象の機能一覧（何のサーバーを、何のDBを移すか）から着手してしまうケースが目立ちます。
この進め方は具体的に見えますが、実際に解決したい業務課題を後回しにしてしまいます。
結果として、移行完了後に「これでは現場の運用が回らない」という声が出て、追加の改修が発生します。
影響範囲も広がりがちです。
最初は一つのシステムの移行のはずが、途中で連携している周辺システムの存在が発覚し、対象が芋づる式に増えていきます。
この段階まで進むと、当初の予算内では収まらなくなり、追加の稟議や再見積もりが必要になります。
なぜ起きるか：原因を段階的に分解する
第一の原因は、業務課題の定義が曖昧なまま見積もりを取ってしまうことです。
「サーバーをクラウドに移す」というだけでは、何を改善したいのかが伝わりません。
処理が遅い、障害復旧に時間がかかる、拡張性がない、といった具体的な業務上の困りごとを言語化する必要があります。
第二の原因は、ワークフロー（業務の一連の流れ）ではなく画面や機能の一覧から検討を始めてしまうことです。
移行コストを左右するのは画面の数ではなく、承認フロー・例外処理・監査ログ・権限設計・外部システムとの連携といった裏側のロジックです。
たとえば、受注システムがCRM（顧客管理システム）と連携し、在庫システムに通知を送り、会計システムに反映される、という一連の流れがあるとします。
この流れを事前にマッピングせずに見積もりを依頼すると、後から連携部分の複雑さが判明し、工数が跳ね上がります。
第三の原因は、隠れた統合（インテグレーション）の見落としです。
業務システムは表向きのユーザー数以上に、バッチ処理・外部API・レガシーシステムとの接続を抱えていることがあります。
これらは移行計画の初期段階では見えにくく、詳細設計（テクニカルディスカバリー）を省略した案件ほど後工程で表面化しやすくなります。
第四の原因は、必須機能と「あったら良い」機能を同じフェーズに混在させてしまうことです。
最初のリリース（バージョン1）に監視ダッシュボードの高度化やAIチャットボットまで詰め込むと、スコープが際限なく広がります。
第五の原因は、稼働後の運用コストを見積もりに含めていないことです。
クラウドホスティング費用、監視ツールの利用料、サポート体制、将来の変更対応まで含めて初めて、実態に近い予算になります。
オンプレ時代の固定費感覚のまま予算を組むと、従量課金のクラウド費用や監視SaaSのライセンス費用が抜け落ちます。
自分のプロジェクトが該当するか確認する方法
以下の観点で、現在進行中または計画中の移行プロジェクトを点検してみてください。
- 業務課題を3〜4文の平易な日本語で説明できるか（できなければスコープはまだ曖昧です）
- 移行対象システムが外部と連携している箇所を、構成図やAPI一覧で洗い出せているか
- 承認フロー・例外処理・監査ログの要件を、機能一覧とは別に文書化しているか
- 「必須」と「あったら良い」を分けたバックログや要件定義書が存在するか
- 見積もりに移行後の運用費（監視・サポート・保守・将来変更）が含まれているか
確認コマンドとしては、既存インフラの依存関係を洗い出すことが第一歩になります。
オンプレサーバー上でどのプロセスが外部と通信しているかを見るには、以下のようなコマンドが使えます。
# 現在確立されている外部接続を確認する
ss -tunp | grep ESTAB
# 特定プロセスが開いている接続先を確認する
lsof -i -P -n | grep <プロセス名>これらの出力から、想定していなかった連携先（DNS名やIPアドレス）が見つかることがあります。
見つかった接続先はすべて、移行スコープの検討対象に加える必要があります。
また、既存の設定ファイルやCI/CDパイプラインの定義（docker-compose.ymlやterraformのリソース定義など）を確認し、環境変数や接続文字列に外部サービスのエンドポイントが埋め込まれていないかも点検してください。
こうした埋め込みは、移行計画のドキュメントには出てこないことが多く、実際の障害対応時に初めて発覚するケースがあります。
対策の手順
ステップ1：業務課題を先に定義する
機能一覧を作る前に、解決したい業務課題を明文化します。
主要ユーザー、現状のボトルネック、成功基準（処理時間の短縮、障害復旧時間の目標値など）を1ページ程度でまとめます。
ステップ2：ワークフローを図にする
入力元、業務ルール、ユーザー権限、出力先、例外処理の5項目を洗い出し、フロー図にします。
見積もり依頼前にこの図を提示できると、開発側の解釈のズレが大幅に減ります。
ステップ3：隠れた統合をリストアップする
上記のssやlsofでの調査結果、社内API一覧、バッチジョブのスケジューラ設定を突き合わせ、連携先を一覧化します。
データ移行（既存DBのスキーマ変換やレコード数）と認証方式（SSO・APIキー）もここで確認します。
ステップ4：フェーズを分けてスコープを固定する
必須機能のみを第一フェーズとし、それ以外は別フェーズの候補としてバックログに残します。
各フェーズの見積もりには、明示的な「対象外」項目を併記しておくと、後からの追加要求に対して線引きがしやすくなります。
ステップ5：運用コストを見積もりに組み込む
クラウドの月額利用料に加え、監視SaaS（DatadogやNew Relicなど）のライセンス費用、アラート対応の人件費、障害時のオンコール体制のコストも見積もりに含めます。
運用フェーズに入ってから「監視の予算がなかった」という事態は、障害対応の初動遅れに直結します。
まとめ
見積もりが膨らむ移行プロジェクトの多くは、技術的な難易度よりもスコープの曖昧さに原因があります。
業務課題の言語化、ワークフローの可視化、隠れた統合の洗い出し、フェーズ分割、運用コストの組み込みという5つのステップは、どれも見積もり依頼の前に完了させておくべき作業です。
まずはss -tunpやlsofで現行システムの外部接続を洗い出すところから始めてみてください。
そこで見つかった連携先の数が、当初想定していたスコープとどれだけずれているかが、見積もり精度を測る最初の手がかりになります。