提案初期に出したAWS移行の概算が、実績と大きくずれる——SIerなら誰もが通る道です。外れる理由は単価の読み違いより「費目の抜け」にあります。二次請けの現場目線で、どこが構造的に抜けるのかを具体的に分解し、外さないための見積もりの型まで整理します。

01なぜ「提案時の概算」は外れるのか

AWS移行の提案初期、まだ現行環境の中身も見えないうちに「ざっくりいくら」を出す——SIerなら誰もが通る場面です。そして受注後、実績と概算のギャップに現場が苦しむ。これも、あるあるです。

概算はもともと情報が足りない時点で出す数字なので、多少外れるのは当然です。問題は、外れ方に再現性のある構造があること。二次請けとして大手SIerの案件を設計から移行まで回してきた実感で言うと、乖離の主因は「読みが甘かった」より「見積もりの対象そのものが抜けていた」ケースが圧倒的に多い。

現場のコツ：概算が外れたとき、単価の高い安いを議論しても遅い。振り返るべきは「何を数えて、何を数え忘れたか」です。単価のズレは数割ですが、費目の抜けは丸ごと数十パーセント効いてきます。

この記事では、二次請けの現場目線でどこが構造的に抜けるのかを具体的に並べ、最後に「外さないための見積もりの型」までまとめます。読者はSIerのエンジニア／リーダーを想定しています。

02「サーバ台数 × 単価」の罠

概算でいちばんやりがちなのが、現行のサーバN台にインスタンス単価を掛けて足すやり方です。速いし説明もしやすい。ですが、これは本番相当の1環境ぶんしか見ていないことが多い。

この掛け算からは、たとえば次のものが抜け落ちます。

さらに厄介なのがスペックの読み替えです。オンプレの物理スペックをそのままEC2のインスタンスタイプに写すと、たいてい過剰になります。逆にRDSやFargateなどマネージド前提に切り替えると、そもそも単価の構造が変わる。どのサービスに寄せるかで金額が動くので、AWS・Azure・GCP・オンプレ サービス対応表のような観点で、まず「何に載せ替えるか」を握ってから数える必要があります。

現場のコツ：「台数×単価」は概算の出発点としてはアリですが、そのまま提出用の数字にしないこと。非機能・環境数・周辺課金・ライセンスの4点を係数ではなく明示の行として足す——これだけで初期の乖離はかなり減ります。

03「移行そのものの工数」を見落とす

金額のインパクトがいちばん大きいのに、いちばん抜けやすいのがここです。箱（サーバ）を作る工数は見積もりやすい。一方で「今動いているものを、止めずに移す」ための工数は目に見えにくく、概算からごっそり漏れます。

実際の移行プロジェクトで人手を食うのは、だいたい次のような作業です。

構築フェーズはIaCや自動化でどんどん速くなりました。ところが調査・調整・リハーサルは今も人手のままで、ここが工数の山として残ります。「作る」ばかり見て「移す」を数え忘れると、概算は簡単に外れます。

現場のコツ：現行が誰にも分からない——移行案件で最頻出のリスクです。概算の段階で「現行ドキュメントの有無」を前提条件として書き出すだけで、後の調査工数が読めるようになります。分からないなら「分からない」を前提に明記しておく。

04運用・保守フェーズのコストが見えていない

提案書は初期構築に目が行きがちで、移行後のランニングと運用保守が薄くなりがちです。ですが顧客が長く払い続けるのはこちら側。ここが見えていないと、TCOの比較で足元をすくわれます。

見落とされやすいのは大きく2つです。まずクラウド利用料は使った分だけ増えるという性質。転送量、スナップショットやログの保持、監視まわりの費用は、運用が始まってからじわじわ効いてきます。オンプレの「買い切り」感覚のまま定額で見ると外れます。

もう一つが運用体制のコストです。監視、パッチ適用、コスト最適化、問い合わせ一次対応、インシデント対応。二次請けの場合は運用が元請け側という切り分けも多いですが、SLAや当直の想定を握らないまま概算を出すと、範囲の解釈違いで後から揉めます。

現場のコツ：運用フェーズを語るときは、金額だけでなく「止まったら1時間あたりいくら損か」まで顧客と目線を合わせておくと、可用性への投資判断が早くなります。感覚で議論せず、まず一度は概算してみるのがおすすめです。

可用性やダウンタイムの費用感、転送時間の目安といった非機能まわりの当たりを素早く付けたいときは、無料の計算ツール（SLA・CIDR・転送時間・ダウンタイムコスト）のような道具で数字にしてしまうと、提案時の会話が具体的になります。

05「安く見せて後で泣く」構造

ここまでは「うっかり抜ける」話でしたが、現場にはもう一つ、意図的に薄く見せてしまう力学があります。受注優先です。競合と数字を並べられる提案では、低い概算のほうが通りやすい。人情としては分かります。

ただし抜いた分は消えず、必ずどこかで顕在化します。追加要求という形か、赤字という形か、あるいは品質を削るという形で。そして最後に効いてくるのが信頼の毀損です。「最初は安かったのに」は、次の受注をいちばん遠ざける言葉です。

二次請けの立場では、元請けの薄い概算がそのまま降りてくることがあります。前提を確認しないまま飲むと、抜けた工数を現場が丸かぶりする。数万円・数人月といった規模感の話ではなく、プロジェクトそのものが赤字化しかねません。

現場のコツ：薄い概算を渡されたら、値切りではなく前提の差分で会話する。「この金額は本番1環境・非機能なし・現行調査ゼロの前提です」と根拠を添えて早めに上げれば、責任の押し付け合いを避けられます。持論ですが、安い数字より外れない数字のほうが、長い目で見れば信頼になります。

06外さないための「見積もりの型」

では、どうすれば外しにくくなるか。特別なことはなく、抜けを構造的に防ぐ型を持つだけです。現場で効いている4点を挙げます。

特に効くのが移行方式を先に握ることです。そのまま移すのか、マネージドに載せ替えるのか、作り替えるのか——方式が違えば工数は桁で変わります。方式が曖昧なまま金額だけ先に出すと、まず外れます。

現場のコツ：SLA・RTO/RPOやCIDR、転送時間、ダウンタイムのコストは、勘で置かずツールで一度数字にしてから前提に書くと精度が上がります。無料の計算ツール（SLA・CIDR・転送時間・ダウンタイムコスト）を提案の下ごしらえに使ってみてください。載せ替え先の当たりを付けるならサービス対応表も合わせてどうぞ。

07まとめ — 「単価」ではなく「抜け」を疑う

AWS移行の概算が外れる本当の理由は、単価の読み違いより費目の抜けにあります。「台数×単価」が拾えていない非機能・環境数・周辺課金、そして見えにくい移行工数と運用保守。この構造を知っているだけで、外し方はだいぶ減らせます。

やることはシンプルです。前提を明文化し、段階で見積もり、不確実性はバッファとして見せ、非機能は数値で握る。そして移行方式を先に決める。安く見せる誘惑に負けず、外れない数字を出すことが、結局いちばん信頼につながります。

EMWは札幌のAWSコンサルとして、大手SIerの二次請けで設計から構築・移行・運用まで実務で回してきました。概算の作り込み、アセスメント、移行計画の精査を、御社の案件と工程に合わせて一緒に整えます。「安いのに外れる見積もり」ではなく「根拠があって外れない見積もり」を、現場目線で。

08よくある質問（FAQ）

提案時の概算見積もりは、どのくらい外れるものですか？

一概には言えません。乖離の大きさは「移行方式・環境数・非機能の要求水準」で桁が変わります。リホスト中心で環境が少なければブレは小さく、リプラットフォームや厳しい可用性要件が絡むと大きく振れます。精度を上げたいなら、概算のまま突き進まず、短いアセスメント（現行調査）を挟んで前提を確定させるのが結局いちばん近道です。

どの費目が一番抜けやすいですか？

経験上、抜けやすいのは「移行そのものの工数（現行調査・依存関係の棚卸し・切替リハーサル・切戻し計画）」と「運用・保守フェーズのコスト」、そして「非機能（冗長化・バックアップ・監視・セキュリティ）」の3つです。箱（サーバ）を作る費用は比較的見積もりやすいのに対し、移すための人手と運用は目に見えにくく、概算から漏れがちです。

概算段階で精度を上げるには、何をすればよいですか？

まず前提を文書に落とすことです。対象と対象外、環境数、非機能の目標値（SLA・RTO/RPO）、移行方式を明文化するだけで、抜けの多くは見えてきます。その上で「概算→アセスメント後に精査」の段階見積もりに切り替え、不確実性が高い項目にはバッファを前提として明示します。曖昧なまま一本の数字を出さないことが肝心です。

二次請けとして、元請けから降りてきた薄い概算にどう対処すべきですか？

そのまま飲まないことです。抜けている前提（環境数・非機能・移行方式・運用範囲）を洗い出し、差分と根拠を早めに文書で上げます。着手してから「聞いていない」を積み上げると、赤字も炎上も現場が引き受けることになります。数字を握る前に前提を握る——これが二次請けで身を守る唯一の型だと考えています。

AWS移行の概算づくり・アセスメント・移行計画の精査でお困りなら、御社の案件と工程に合わせて一緒に整えます。「安いのに外れる見積もり」を、根拠があって外れない見積もりへ。

相談する
← ブログ一覧へ戻る