--- type: guideline title: Step.4 見積りの精査 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.4 見積りの精査 情報システムの開発や運用等を委託する事業者は、情報システムを運営していくためのパートナーですので、事業者と良好な関係を維持することはとても重要です。 ただ、この良好な関係とは、決して業務の一切を事業者任せにする状態ではありません。適切な役割分担の下で緊張感を持って協働することこそが、良好な関係です。このことは、事業者が提示する見積の精査についても当てはまります。つまり、発注者側である職員が見積内容を十分に理解し、前提条件や取り得る選択肢を理解した上で、実現機能と価格のバランスを取ることが求められます。見積り金額を減らせばよいというものでもありません。必要不可欠な項目が抜け落ちてしまうと、システム開発や運用の段階で大きな問題になります。 見積りの精査は、実際には簡単なものではありません。ハードウェア、ソフトウェアの見積りには専門的知識がないとわからない横文字が列挙されていますし、人件費の工数積み上げについても、どのような観点で確認すべきか迷うことがあるでしょう。 見積り金額を適切な範囲に収めるとともに、発注者側・事業者側の双方がこの先の工程で円滑に活動ができるために、見積りを精査する具体的な方法について解説します。 ## 人件費の見積り精査 【標準ガイドライン関連箇所：第３編第３章第４節】 情報システムの設計、開発、試験等に関わる経費、アプリケーション保守や運用に関わる経費等、多くの経費はＰＭ（プロジェクトマネージャ）、ＳＥ（システムエンジニア）、ＰＧ（プログラマ）、等の人件費で構成されています。人件費の積算は、基本的に工数と単価の掛け算です。工数については、「人月」や「人日」といった単位で表されます。４人体制で15日間の作業が必要な場合は、60人日（３人月）の工数になります。そして、人件費単価が120万円/人月であれば、掛け算をして合計360万円となります。人日と人月の換算は、営業日ベースで計算するので、20人日を１人月とすることが標準的です。 見積りの中で、数十人月、数百人月といった大きな単位で一式としての工数が示されても、その中に様々な作業が混在して合算されているため、個々の作業工数の妥当性を判断することができません。まずは、工数内訳を詳細に確認できるようにしてください。 工数の内訳は、機能や作業単位で分けることが非常に重要です。時々、数百人月といった大規模作業を、工程単位（設計、開発、試験等）、期間単位（月ごとの工数等）、要員種別単位（ＰＭ、ＳＥ、ＰＧ等）で分けて、一見すると詳細な内訳として提示されることがあります。しかし、このような分け方ではこれ以上精査することが困難です。 居酒屋のコース料理に例えると、本来、料理のメニューや飲み放題の時間等のサービス内容面で金額が決まるはずなのに、料理人の人数や作業時間だけで金額を説明しているようなものです。そのような内訳では、サービス内容を調整して料金を変えることも困難ですし、サービスごとの費用妥当性を判断することも困難です。 個々の経費項目の必要性や生産性水準について精査できるようにするためには、実現する機能単位、実際に発生する作業単位での詳細工数が明記された見積が不可欠です。このような見積が提示されていない場合は、事業者に対して見積精査上の必要性を伝えた上で、必要な粒度での工数見積を取得しましょう。 ### 安易な掛け算の精査 画面、帳票等を作成、改修する際に、単純に画面数等の数量で掛け算をして工数が積算されることがあります。また、データの入力、変換等の各種作業を実施する際にも掛け算が利用することがあります。ただ、安易に掛け算を行うと、工数が過大に積算される可能性があります。 例えば、作業を共通化、自動化できる可能性があります。作業対象が10件あったとしても、作業全体工数が１つの作業工数の10倍になることはほとんどありません。作業工数の中には対象件数によらず必要となる共通部分があるため、その部分を外へ括り出すことが必要です。また、作業件数が増えた場合は自動化の工夫を行うことも有効です。ツールの作成や設定等、自動化のための準備作業に一定の工数がかかるものの１件当たりの作業工数を大幅に削減できるので、全体としての工数を下げることができます。 ### 作業重複の精査 見積書の各作業項目を見比べると、類似の名称の作業項目が存在したり、成果物が同一と思われる作業が列挙されていたりすることがあります。 例えば各種の設計を行う作業についても、見積書では方式設計、構成設計、環境設計、データ設計、機能設計、性能設計、パラメータ設計など、様々な名称が使われることがあります。これらの作業項目の名称だけでは重複有無を判断しにくいですが、各作業の成果物（ドキュメント）を明らかにすると、重複を発見しやすくなります。 また、事業者間での作業重複についても気を付ける必要があります。例えば、複数事業者協働してテストを実施する際に、それぞれに事業者がテスト工数を見積ります。ただ、実際のテスト作業においては、テスト計画書の作成、テストシナリオの準備、テスト環境等の準備、テストの日程や体制の調整といった前工程作業や、テスト結果のとりまとめ等の後工程作業を主体的に担う事業者が１社存在し、残りの事業者はその活動を支援しながら自社分の部分的な役割を担うことが多いです。この場合、工数積算においては、支援側の工数が相対的に少なくなるはずです。テスト工程だけでなく様々な工程で、事業者の作業分担を確認した上で工数のバランスを確認することが重要です。 ### 主要成果物との比較 工数の妥当性を判断する際の拠り所は、その作業によって完成する成果物の質と量です。 特に、システム開発では様々な種類のドキュメントを作成します。要件定義書、各種設計書、構築作業の設定書や手順書、テスト計画書、テスト結果報告書、運用設計書、運用手順書、マニュアル等が代表的な例になります。これらのドキュメントの作成工数は、発注者にとっても妥当性を判断しやすい部分です。 まず、各ドキュメントの「量」について、「50ページ程度」、「300ページ程度」など概算で構わないので何ページ程度の成果物を作成予定かを確認します。 次にドキュメントの「質」として、主要な構成を確認します。例えば、システム操作説明を主体としたマニュアルであれば、システムの機能構成単位で画面イメージを貼付ける構成となり作成工数も比較的少なくなるでしょう。一方で、業務面での解説を中心としたマニュアルであれば、業務上で発生する状況に合わせて情報システムの使い方を説明する形となり、作成工数も比較的多くなると考えられます。 このように、成果物であるドキュメントの量と質を確認すると、ドキュメントを作成する作業規模や難易度がわかるため、作成工数の妥当性を判断しやすくなります。 ### 開発生産性の精査 システム開発の実作業の中では、再利用できる「部品」を様々に準備した上で、それらを組み合わせて実装を行うことが中心となります。そして、このように再利用可能な部品によって体系的に構築された情報システムであれば、機能の追加や変更に際して特定の「部品」等への限定的な追加作業を行うことで十分な対応を行うことができるはずです。 前述の「Ａ．安易な掛け算の精査」とも重なりますが、画面や帳票の新規追加を行う場合においても、実作業としては限定的な作業で済む場合が多いはずです。 まずは、画面、帳票等の各機能を追加する際に、具体的にどのような作業が必要になるかを把握してみましょう。画面については、基本的な「ひな形」が複数種類存在していて、その一部を使って新規画面を構成することが多くなります。特に、既存機能と類似の画面を作成する場合は、その類似画面をベースとした上で流用開発を行うことが多いです。つまり、既存の「ひな形」や「類似画面」との相似度が高いほど、追加的な工数は少なく済むはずです。 帳票については、帳票作成に特化したミドルウェア（ツール）を利用することもあります。このようなミドルウェアを導入することで、帳票のレイアウト設計や出力制御を簡易な作業で実施できるようになります。このような帳票作成ミドルウェアを導入している場合は、そのツールを前提とした作業工数になっているかを確認することが有効です。 開発生産性を精査するためには、テストにおいて不要なテスト項目が含まれていないか確認することも有効です。例えば、機能改修を行う場合に、改修を行わない部分に対する影響がないかリグレッションテストを実施しますが、影響範囲の絞り込みが不十分であるためにテスト範囲が広すぎ、 生産性が低下している場合があります。 機能改修の特性を踏まえて、テスト自動化の検討、テスト項目の妥当性の精査、機能改修による影響範囲の特定などを適切に実施することで、効率的にテストを実施し、過剰な工数を削減することができます。 また、プロジェクトを通して見積工数の計画と実績を蓄積しておくことも重要です。このような蓄積があると、見積りを精査する際に過去の類似見積りとの比較を行うことができます。 - 注記 「情報システムの調達に係る見積標準」 - 参考3-3 見積り精査を行うにあたっての参考資料

参考：見積り精査を行うにあたっての参考資料

これまで本書で紹介してきたような観点で見積りを精査することが重要ですが、様々な団体がまとめている見積標準や調査報告等を参照することで、見積り手順や比較対象となる指標等を知ることができます。

本項では、見積り精査の参考となる資料の例を三つ紹介します。ただし、見積り内容はプロジェクトの前提条件や性質により変化するため、参考資料の指標等と比較して差異があったとしても、必ずしも不適切な見積りとは限りません。これらの資料に記載された指標等との差異について見積り事業者と意見交換することで、事業者による見積りの考え方と発注者の認識との違いを明らかにし、要件定義等に向けて軌道修正すべきポイントを把握することが重要です。

また、プロジェクトの中で見積り精査の精度をさらに上げるためには、プロジェクト内で発生するそれぞれの見積りについて、開発規模や生産性のデータを蓄積し、発注者側で見積りの妥当性を判断できるようにすることも重要です。

さらに、蓄積した生産性データを分析することで、例えば、ドキュメント作成に過剰な工数がかかっているなど、作業の効率性を振り返るきっかけにもできます。

  • 「情報システムの調達に係る見積標準」（一般財団法人　経済調査会 ）

本資料は、情報システムの整備・運用等に係る業務の発注者を対象として、見積りに関する基本的な考え方を示しています。見積りの精査や予算要求額の積算等での利用が想定されています。

見積りの精査に関連する記載としては、望ましい見積書の構成や、確認すべき根拠資料が紹介されているなど、見積りの依頼から精査に至るまでの業務を体系的に知ることができます。また、「ソフトウェア開発データリポジトリの分析」に掲載されている開発工程別工数比率や技術者別参画比率を利用した見積りの手順も紹介されています。

![](../assets/ds-120-ch03-image8.png)

　出典：https://www.zai-keicho.or.jp/software_research/

  • 「ソフトウェア開発分析データ集」（独立行政法人情報処理推進機構）

本資料は、ソフトウェア開発現場でプロジェクトのデータを精査・分析する方などを想定読者として作成されており、掲載されたデータをベンチマークとして活用することができます。

![](../assets/ds-120-ch03-image9.png)

　出典： https://www.ipa.go.jp/ikc/reports/20200930.html

  • 「ソフトウェアメトリックス調査（システム開発・保守調査、IT運用コスト調査）」（一般社団法人 日本情報システム・ユーザー協会）

本資料は、開発・保守・運用プロジェクトの実態に関するデータについて、調査報告書として取りまとめられたものです。掲載されている指標は、情報システムの開発期間や工数の妥当性評価等に活用することができます。

見積り精査への活用という観点では、例えば、各工程の工数の割合について統計値が記載されており、事業者から取得した見積りの各工程の工数割合と比較することで、割合の妥当性を確認することができます。

![](../assets/ds-120-ch03-image10.png)

　出典：https://juas.or.jp/library/research_rpt/swm/
## ハードウェア等の見積り精査 【標準ガイドライン関連箇所：第３編第３章第４節】 ハードウェア、ソフトウェアの借料や保守経費は、経費全体の中で大きな比率を占めます。 まずは、大前提として製品単位での価格内訳を入手してください。予算要求段階では「一式」等の形で大括りの見積が事業者から提示されることもありますが、一式の状態ではそれ以上に金額の精査を行うことができません。新規に整備する情報システムであっても想定する製品に基づいて金額を積算しているはずなので内容を確かめるべきですし、既存情報システムに対する改修や更改等の案件であればなおさら詳細な積算内訳を求めることが重要です。 - 参考3-4 ハードウェア・ソフトウェアの見積りの記載例

参考：ハードウェア・ソフトウェア等の見積りの記載例

製品単位で、数量、借料、保守料の内訳が示される形が一般的です。

製品については、「ＷＥＢサーバ 一式」といったグループ単位で金額が示されることもありますが、できるだけＷＥＢサーバを構成する本体部分やオプション部分も含めて詳細内訳を入手するようにしてください。

＜ハードウェアの見積り記載例（サンプル）＞

![](../assets/ds-120-ch03-image11.png)

＜ソフトウェアの見積り記載例（サンプル）＞

![](../assets/ds-120-ch03-image12.png)

※ 上述の見積り記載例は、特定の事業者を想定したものではなく、借料等の金額も架空のものです。
### 製品単価を精査する まず、主要な製品について定価や実勢価格との差異を確認してみましょう。 ハードウェアについては、オープン価格として定価（希望小売価格）を明示的にしていない製品もありますが、多くのハードウェアについてはWebサイト等で定価を確認することができます。また、製品名称や製品番号等をキーワードにしてWebサイトを検索すると、各種販売代理店等による実際の販売価格を把握することができます。代理店によって販売条件（納期、納品場所条件、各種サポート条件、支払期限、支払方法、キャンセルポリシー等）が異なるため販売価格の最安値と単純に比較することは合理的ではありませんが、調査した販売価格の水準（実勢価格）と取得した見積価格とのかい離が大きい場合は、その理由を営業担当者に確認すると良いでしょう。 ソフトウェアについても、まずは同様に定価や実勢価格との比較を行ってみましょう。ライセンス数の精査については後述します。 また、同一製品で異なる単価設定になっていないか、過去に受領した見積りと比べて同一（類似）製品の価格が高くなっていないか等、製品単価を比較してみましょう。 ### 高額な製品を中心に、必要性を精査し他製品と比較する 次に、見積り内容を分析して、どのような製品が高額となっているかをつかみましょう。１つの製品が突出して高額な場合もありますし、低額な製品（部品）が多数計上された合計で高額となっている場合もあります。 そして、高額な製品についてはその必要性を確認しましょう。例えば、ストレージ装置が高額となっているならば、容量（記憶できるサイズが何ＴＢか）、性能（読み書きの速度等）、機能（複製、圧縮、冗長性確保等のための諸機能）等について内容を確認し、他製品との比較検討を行い、当該製品が必要以上のスペックになっていないか確認します。 全ての製品について必要性の確認を行うのは大変な作業ですが、高額な製品から順番に突合せを行うことで、効率的に価格構成上の主要部分を精査することができます。 ### ソフトウェアライセンスを精査する ソフトウェアのライセンスの考え方は各社各様であり、課金単位も様々です。サーバに導入するソフトウェアについては、サーバ台数又はサーバに搭載されているＣＰＵ数を単位とするものが比較的多い状況です。他方、利用するＰＣの台数、利用するユーザの数、ユーザの最大同時接続数、利用するデータ量など、利用形態に対して課金する形態もあります。 いずれのライセンス形態であっても、サーバ台数、ＣＰＵ数、ＰＣ台数、利用ユーザ数等の実際の使用状況（あるいは使用予定状況）に比べて過剰なライセンスが積算されていないかを確認しましょう。 また、特にＣＰＵ数を単位とするライセンスについては、現行情報システムの瞬間的なピークだけを捉えて必要数を積算していないか、実際のＣＰＵ使用率の推移を確認してみてください。夜間バッチ、バックアップ等の目的で業務時間外に短時間だけＣＰＵ使用率が高くなっていても、通常の業務時間のＣＰＵ使用率が低ければ、基本的にそのピークに合わせる必要はありません。 ### 保守料を精査する 保守料は、保守サービスの前提によって価格が変わります。保守サービスの対応日（週末の有無当）、対応時間帯、故障発生時の駆け付け時間、サービスの各種オプションの有無等が価格に影響する代表的な要素です。 一般的な機器については、保守サービスの条件に応じた年間保守料が設定されています。まずは、Webサイト等でこれらの保守料を調べて、見積内容と比較してみましょう。 また、全ての機器に、良い条件の保守サービスを一律にかけるべきであるか検討してみましょう。全ての機器を定期保守（故障発生頻度にかかわらず定額で対応を行う方式）でオンサイト対応（故障時に現地で修理・交換を行うサービス）でなくても、スポット保守（故障発生都度に修理対応料金を払う方式）やセンドバック対応（故障時に故障製品を指定先に送付し、代替品が交換で送付されるサービス）で十分な場合もあります。 いずれにしても、保守金額は条件によって大きく変わり得るものなので、前提条件やサービス内容を確認して、必要十分な水準になるように検討しましょう。 ## 複数事業者の見積りの比較 【標準ガイドライン関連箇所：第３編第３章第４節】 複数事業者から見積りを取得した場合は、その内容について比較を行います。 比較に際しては、合計金額だけで比較するのではなく、主要な経費項目の単位で比較を行うことで事業者の得意分野、不得意分野等を把握することができます。 - 参考3-5 三点見積りによる予算要求額の算出

参考：三点見積りによる予算要求額の算出

三点見積りとは、例えば５つの事業者から見積りを取得した際に、最高額と最低額を除外した３者で平均して算出した額を指します。見積り経費項目ごとに三点見積りを行い、総合計したものを予算要求額とします。

三点見積りは、金額だけではなく、工数や期間の算出にも適用できます。
- 注記 ベアメタルとは、ユーザから申し込みがあると、あらかじめ事業者のデータセンターに用意された物理サーバを割り当てて利用可能とするサービスのこと。 一般的なクラウドサービスに対応していないソフトウェアも利用できる、リソースを専有できて他の利用者の影響を受けないなどのメリットがある。 一方で、利用に当たって初期コストがかかる場合がある、サーバを仮想化しておらず共用できないため、リソースを柔軟に変動させることができないといったデメリットがある。 - 事例3-5 クラウドサービスの見積りの精査

事例：クラウドサービスの見積りの精査

標準ガイドラインでは、情報システム関係予算の要求に当たって、原則としてクラウドサービスの利用を前提とした見積りも取得することを定めています。

これを受け、各府省でクラウドサービスの導入事例が増えていますが、見積りの取得の過程では、従来のオンプレミスを継続した場合とクラウドサービスを利用した場合の比較が適切に行われていない例も散見されます。以下に、実際にあった不適切な比較の事例をご紹介します。

  • 割高なクラウドサービスが選定されている

クラウドサービスは国内外含め様々なものが提供されています。その中でも利用料が割高なクラウドサービスの利用を前提としている場合には、見積額全体も高額になるケースが多くなっています。見積り事業者自身やそのグループ企業でクラウドサービスを提供している場合は、他のサービスより割高であっても当該クラウドサービスの利用を想定した見積りがなされることが多くなります。このため、割安なクラウドサービスも比較対象として見積もるよう求めたり、現行事業者だけでなくクラウドサービスの導入実績が多い事業者を含めた複数事業者から見積りを取得したりすることが重要です。

  • 適切ではない価格体系を前提としている

使った分だけ支払う従量課金の価格体系によって無駄なコストを抑えられることがクラウドサービスのメリットの一つですが、一定の利用量を超えると複数年予約型割引※を採用したほうが安くなる場合があります。

ある府省では、24時間週7日利用されることが想定されているにも関わらず複数年予約型割引を採用していない高額な見積りが事業者から提示されていました。（※1年以上の長期利用予約することで割引が受けられる仕組み。）

一方で、24時間週7日情報システムを稼働する必要がない業務もあります。オンプレミスの場合は、サーバの稼働時間が運用等経費に影響しないことを背景として単純にサーバを24時間週7日稼働しているケースが多いです。

クラウド環境を従量課金の価格体系で利用する場合は、サービス利用料はサーバの稼働時間に影響を受けます。そのため、一定の時間クラウド環境を停止してサーバの稼働時間を抑えることで、サービス利用料を低減することができます。したがって、見積り時にはオンプレミスを踏襲した24時間週7日の稼働を前提としがちですが、夜間等に稼働が必要でないサーバについては、業務に支障がない業務終了後から翌営業日の早朝までを停止する前提で見積りを依頼することも検討しましょう。

  • 不確定要素に対して過剰な費用が上乗せされている

業務内容に不確定な要素がある場合、事業者がリスクを見込んで見積りが高額となる可能性があります。ただし、それが適切な範囲なのかは確認が必要です。

ある府省では、クラウドサービスへ移行する場合の環境構築費用がオンプレミスを継続する場合の1.5倍の金額で見積もられました。事業者に原因を確認したところ、クラウドサービスと省内WANとの接続において、作業や費用の見通しが十分ではないままの状態で、オンプレミスと比較して大きな金額を見積もったとの回答がなされました。そのため、省内WANとの接続に必要な作業について、精査を求めました。

  • 現行システムの構成のまま移行している

オンプレミスで構築した情報システムをクラウドサービスへ移行する場合、現行システムの基盤部分を同じ構成（オンプレミス）のままで更改するのと比較して整備経費が高額になる場合があります。

ある府省ではオンプレミスとクラウドサービスの比較といいながら、オンプレミスの構成をクラウド環境にそのまま持ち込み（現システムへの影響を最小限にするという理由でベアメタルのクラウドサービスを採用）、オンプレミスの構築費用に加えてクラウド利用量を上乗せする形で比較し、クラウドサービスの長所を全く活かしていない事例がありました。

クラウドサービスの長所を活かせるように改修を加えてからクラウドサービスに移行すると、整備経費は高額となりますが、運用費用は下がり、長期的に見るとコスト削減につながる可能性があります。短期的に発生する経費だけでなく、情報システムのライフサイクル全体を考慮した見積り比較を行うことが必要です。

  • 各種費用を二重計上している

クラウドサービスによっては、特定のソフトウェアのライセンス料をクラウドサービス利用料に含んだオプションがあります。

ある府省で事業者に見積りを依頼すると、ソフトウェアライセンス料込みのクラウドサービス利用料を計上した上で、さらにそのソフトウェアのライセンス料・保守料を追加で見積もっており、二重計上になっていることがありました。このような不要な費用が見積もられていないか、見積りを精査することが必要です。

  • 災害対策環境が本番環境と同じ構成となっている

社会的な影響が大きなシステムなど、特に高い可用性が求められるシステムでは、大規模災害によって本番環境が復旧不可能となった場合に備えて、代替環境である災害対策環境を設置することがあります。

ある府省で事業者に見積りを依頼すると、本番環境と同じ構成で災害対策環境を常時稼働させる前提で見積もられており、見積額が高くなる原因となっていました。災害対策環境を本番環境と同一の構成とするのではなく、本番環境よりも冗長性を省いた限定的な構成としたり、常時稼働ではなく、ウォームスタンバイやコールドスタンバイとしたりして、復旧する目標に応じた適切な水準とすることで費用を抑えることができます。

  • 過剰なスペックで見積もられている

リソースの性能や容量が大きければそれだけ高額になるのは、クラウドサービスでも同様です。クラウドサービスでは、ディスク容量だけでなく性能（IOPS）も選ぶことができます。性能の高い製品ほど高額になりますが、ある府省では、数百TBものディスクが、すべて当該クラウドサービスの最高スペックで積算されており、見積もり額の大部分を占めていました。

リソースの性能や容量は、要件にあったものが選定されているか精査する必要があります。

クラウドサービスは正しく利用することで、大幅なコスト削減を実現できる可能性がありますが、本事例のように、事業者にクラウドサービスを前提とした見積りを依頼しても、必ずしもシステムの特性を踏まえて安い金額で見積もってもらえるとは限りません。オンプレミスを継続するケースなどと比較して割高になっている場合には、本事例のように、見積りが適切に行われているか、内訳を精査して妥当性を確認する必要があります。

しかし、このような精査には専門的な知識が必要となることも多いため、事業者が出した見積りに疑問がある場合には、PMOに相談することも検討しましょう。
- 参考3-6 クラウドサービス特有の料金体系 - 注記 ウォームスタンバイ、コールドスタンバイとは、本番機の障害発生時に予備機に切り替えることで信頼性を向上させる手法であり、ほかにホットスタンバイがある。 ホットスタンバイ、ウォームスタンバイ、コールドスタンバイの順に切替えが早い。 なお、災害対策環境をウォームスタンバイやコールドスタンバイとすると、大規模災害発生時には同環境が設置された拠点に利用が集中してリソースを確保できないおそれがある。そのため、システムの特性や目標復旧水準を踏まえた検討が必要となる。 - 注記 IOPSとは、１秒間あたりに入出力できる回数のことで、性能指標の一つ。 IOPSはInput/Output Per Secondの略。

参考：クラウドサービス特有の料金体系

適切に利用することで情報システムのコストを削減できる可能性があるクラウドサービスですが、オンプレミスとは料金体系が異なるため、思わぬところでコストが増大しないように注意しましょう。

例えば、クラウドサービスによっては、クラウド環境から外部へ送信するデータの量に応じて課金される場合があります。動画配信サービスのように極端にデータのダウンロードが多いシステムにおいて、このような点を考慮せずにクラウドサービスを採用してしまうと、想定外に大きなコストが発生するおそれがあります。本番環境と災害対策環境など、異なる拠点間でデータ同期を行う場合にこの課金が適用される点にも注意が必要です。

また、クラウドサービスでは、データに対するアクセスの容易さや価格の異なる様々なストレージから必要なものを選択することができます。オンプレミスでは磁気テープに保存していたバックアップデータも、バックアップやアーカイブでの利用を想定した安価なストレージに保存することができ、管理も容易になります。このようなストレージの種類を考慮せず、古いバックアップデータやログデータなどの即座にアクセスする必要のないデータまで頻繁なアクセスを想定したストレージに保存してしまうと、同じデータ容量でも高額な利用料となるおそれがあります。

そのほかに、バースト機能の使用にも注意が必要です。バースト機能を使用すると、一時的に、あらかじめ定められたリソースの使用率（ベースライン）を超えてリソースを使用することができます。ただし、バースト機能の使用には限り（クレジット）があり、クレジットがなくなると、リソースの利用率がベースライン以下まで低下するか、追加で使用するために追加料金の支払いが必要となります。バースト機能を使用する前提で性能試験をして、本番運用時にはクレジットを消費してしまって思った性能が出ないなどといったおそれがあります。

単純にクラウドサービスに移行すれば自動的にコストが減少すると考えず、情報システムの特性と、クラウドサービスの料金体系を踏まえて検討することが必要です。