---
type: guideline
title: Step.3 見積り依頼
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.3 見積り依頼

正確な情報を伝えれば、正しい見積りが返ってくる。

確かにそのとおりなのですが、これを行うことは容易ではありません。そもそも正確な情報がない中で見積らなければいけない状況も多く、そのことに苦労しているのではないでしょうか。

また、情報システムに関する作業内容や製品選定は、専門的な知識がないと正確に理解することが難しいため、事業者から提示された見積りを精査することが難しいという実感を持っているかもしれません。

まずは、情報システムの見積りの特性を理解した上で、どのように見積り依頼を行えばよい情報を入手することができるかを解説していきます。

## 見積り依頼書の作成

【標準ガイドライン関連箇所：第３編第３章第４節】

プロジェクトの初期の段階で事業者に見積りをお願いするときに、細かい粒度の見積りを求めて嫌がられたり、協力を得られなかったりしたことがありませんか？また、見積りの比較検討の際に、比較のための編集作業に大変な労力を割いたことがありませんか？

事業者に見積りを依頼するときに工夫をしておくと、後で見積りを比較したり精査したりする際に苦労をしなくて済みます。見積りを依頼する際のポイントを見ていきましょう。

### 要件が未確定な部分を明確にする

見積りを依頼するタイミングによっては、情報システムに求める機能や前提条件等について、詳細な内容が決まっていないこともあります。例えば、プロジェクト初期段階の見積りでは、十分な現状把握や要件の検討ができていないこともあります。また、新しい制度を導入する場合や、既存の制度を変更する場合等においては、制度自体の方向性や内容が、見積り依頼時期にはまだ定まっていないこともあります。

見積りを依頼する場合は、見積りの対象や前提条件を明確にすることが大前提ですが、サービスや業務を開始する時期の１年ほど前に見積りを依頼する必要があるため、現実的には上述した例を含めて、未確定な部分が発生することもあります。

見積りの対象や前提に未確定な内容がある場合、次の点に留意してください。

未確定な内容がある場合に気をつける点

- 見積りを依頼する要件の中で詳細が未確定な箇所には、**<u>未確定である旨</u>**、その理由、どのタイミングで詳細化できる予定であるかを記述する。

- 未確定な箇所については、できるだけ**<u>複数の対応案</u>**を示し、それぞれの対応案に対して見積り金額を把握できるように見積り依頼を行う。また、見積り前提が変わった際の影響範囲（見積り金額だけでなく、工期や連携先情報システムへの影響等を含めた全体的な影響）について事業者に確認する。

- 未確定な箇所を**<u>一覧にまとめる</u>**。後述するプロジェクトの概要の前提条件・制約として記述する。

ただし、大前提としての注意点ですが、精度の高い見積りを取得するために、まずは、見積り前にできる限り詳細を決定するようにしてください。

### プロジェクトの状況によって内訳粒度を変える

見積りは、サービス・業務の内容や情報システムが提供する機能等の要件が明確になればなるほど精度が上がっていくものです。特に、プロジェクトの初期段階の見積りは、実際にかかる費用と見積りは大きくかい離していることが一般的です。

一方で、見積りを行う事業者にとっては、見積りに求める粒度が細かくなればなるほど見積りにかかる労力が高くなります。サービス・業務企画の内容や情報システムの要件の大半が未確定の段階で粒度の細かい見積りを求めても、詳細な根拠がないため、想定条件を設定した上での按分計算等により、見た目だけ細かくするだけの結果となってしまいます。結果として事業者は無駄な労力を消費し、ＰＪＭＯは精査に必要以上の時間を使ってしまうことになりかねません。また、見積り算出に係る負荷を敬遠して、事業者から見積りの協力すら得られないことも往々にしてあります。

見積り内訳は細かい粒度であるほど精査を行いやすくなりますが、要件が十分に精査できていない段階で見積り内訳だけを細かく要求することにも無理があります。プロジェクトのシチュエーションに合わせて適切な粒度を検討することが重要です。

- 表3-7

シチュエーションごとの見積り粒度の設定例

<table style="width:97%;">
<colgroup>
<col style="width: 45%" />
<col style="width: 51%" />
</colgroup>
<thead>
<tr>
<th style="text-align: center;">シチュエーション</th>
<th style="text-align: center;">粒度の設定例</th>
</tr>
</thead>
<tbody>
<tr>
<td>情報システムを<strong><u>新規</u></strong>に構築する場合</td>
<td><p>粒度：大</p>
<p>主要な機能の単位等で必要工数や金額の提示を依頼する。詳細な実現方法等については、機能の向上やコストの低減を含めて事業者からの提案の余地を含めた粒度とする</p></td>
</tr>
<tr>
<td>既存情報システムの改修や機能追加等を行う場合（前提となる要件が<strong><u>不明確</u></strong>）</td>
<td><p>粒度：中</p>
<p>法改正の詳細条件が不明な中で予算要求を行う必要がある場合等においては、対応する範囲について前提条件を置いた上で、改修等に必要となる大まかな作業単位で工数の内訳を求める</p></td>
</tr>
<tr>
<td>既存情報システムの改修や機能追加等を行う場合（前提となる要件が<strong><u>明確</u></strong>）</td>
<td><p>粒度：小</p>
<p>必要となる作業が明確であるため、改修対象となる画面数、帳票数、バッチ処理数等を事前に分析した上で、必要な作業を詳細な粒度で積算するように内訳を求める。</p></td>
</tr>
</tbody>
</table>

### 見積りフォーマットを指定する

一般的に、事業者は各社独自の見積りフォーマットを使って見積りを行います。複数事業者から見積りを取得した後、発注者側が各社の見積りを比較して差異を確認することになりますが、見積りフォーマットがバラバラだと比較や事業者への問い合わせに大変な労力を要します。

無駄な労力を使わないよう、見積り依頼時に見積りフォーマットを指定しましょう。各府省で見積りフォーマットを準備していれば、それを有効活用してください。

なお、複数事業者に見積り依頼を行う際は、見積りフォーマットの表頭（最初の１行目にあるヘッダ部分）だけを指定するのではなく、表側（最初の１列目）に主要な作業項目や機能を指定しておくことを推奨します。見積り結果を受領した後で各社の見積り内容を比較する際に、合計金額だけでなく内訳単位で比較を行うことができるからです。また、同じ内訳単位で比較して金額の差が大きい場合は、その理由を事業者に再確認することで、金額水準や見積り条件を見直すことができるようになります。

- 図3-3

見積りフォーマット（アプリ開発）の例

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

### 工程の名称の違いをなくす

複数の事業者へ同一内容の情報を提供しても、回答する事業者によってその情報の捉え方が異なることがあります。例えば「詳細設計」という作業名称は、事業者によって呼び名が違ったり実施する内容が異なったりすることが多々あります。見積り依頼時に工程の名称と工程の示す作業範囲を指定すると、受領した見積りの比較検討が楽になります。

標準ガイドラインで定義する工程と事業者各社が用いる工程の名称の比較は、「第７章表7-1標準ガイドラインと各社が定義する工程の比較」をご参照ください。

### 見積り手法に注意する

見積りを客観的に評価するためには、検証可能な計算式により見積根拠を明らかにしておく必要があります。

作業工数（人件費）の見積り方法は、発生する作業単位で必要な人数と期間を算出して足し上げる「積み上げ法」が実務的にはよく見られますが、その他にもシステムの開発規模から見積りを行うＬＯＣ法、ＦＰ法等があります。

- 参考3-1

ＬＯＣ法による工数見積り

<table style="width:97%;">
<colgroup>
<col style="width: 96%" />
</colgroup>
<thead>
<tr>
<th><p>参考：ＬＯＣ法による工数見積り</p>
<p>類似情報システムや過去の開発実績を基に、アプリケーション（プログラム）のステップ数を類推し、アプリケーションの規模を見積もる手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数となります。</p></th>
</tr>
</thead>
<tbody>
</tbody>
</table>

- 参考3-2

ファンクションポイント法（ＦＰ法）による工数見積り

<table style="width:97%;">
<colgroup>
<col style="width: 96%" />
</colgroup>
<thead>
<tr>
<th><p>参考：ファンクションポイント法（ＦＰ法）による工数見積り</p>
<p>アプリケーションの規模を測定する手法の一つで、アプリケーションが持つ機能数（内部論理ファイル、外部インタフェースファイル、外部入力、外部出力、外部照会の各機能の数）を洗い出し、洗い出した機能を複雑さによって重み付けをして、集計した値にシステム特性を加味する方法によって、そのアプリケーションの規模を見積る手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数になります。</p></th>
</tr>
</thead>
<tbody>
</tbody>
</table>

理想的な状態は、見積り依頼時に発注者側が見積り手法を指定し、同じ手法を前提に複数の事業者の見積りを比較できることです。

ただし、事業者もそれぞれ自社の標準的な見積り手法に基づいて経験を培ってきています。そのため、見積り手法を限定的に指定することによって見積り精度が落ちたり、事業者の協力を得にくくなったりすることもあります。見積り手法の指定が難しい場合は、事業者が選択する見積り手法で積算することになりますが、その際においても算定根拠となる計算式や基礎数値は明記するように依頼してください。

LOC法でもＦＰ法でもプロジェクトの中で過去の生産性指標を蓄積することを推奨します。発注者と事業者が共通の物差しで開発規模や生産性を測定し共有することによって、見積金額の妥当性を評価しやすくなると共に、見積もり根拠を対外的にも説明し易くなります。

### できるだけ詳細な要件を書く

以上のような注意点を参考にしながら、見積り依頼書を作成してください。

事業者が詳細な根拠に基づいて正確な見積りを作成できるように、開発する情報システムに求める機能要件（機能一覧、画面一覧、帳票一覧、外部インタフェース一覧等）と非機能要件（の機能要件を整理して、提示しましょう。

なお、現行情報システムに対する改修の場合は、システムの規模を参考にできるため、現行情報システムのＬＯＣ値やファンクションポイント数を、参考資料として提示します。

## 事業者への見積り依頼

【標準ガイドライン関連箇所：第３編第３章第４節】

予算要求時点の見積りは、調達時の見積りとは違い事業者の受注に直結しないため、事業者も大きな労力を割きづらく、事業者の見積り協力を得にくいことや、意図にそぐわない見積りとなることがあります。

事業者から欲しい見積りを取得するためには、協力してくれる事業者を効率的に探し、資料では伝わりにくい意図を対話によって的確に伝えていくことが大切です。

事業者から良い見積りを効率的に取得するポイントを見ていきましょう。

ポイント

- 見積り依頼できる事業者が見つからない又は少ない場合は、ＰＭＯ等に協力を依頼する。

- 事業者の見積り精度を上げるために、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝える。そのためには、説明会・ヒアリング等を積極的に活用する。

### 見積りしてくれる事業者を探す

見積りは、原則として、複数の事業者から取得し、取得結果を比較・検討する必要があります。見積りを依頼できる事業者が見つからないときは、ＰＭＯ、デジタル庁に相談してください。

また、事業者から見積り辞退の回答を得たときは、その理由を確認し、情報不足や調達内容の制約等、見直しが可能な事項は見直しを検討しましょう。

留意事項

- 事業者を選定する際は、事業者間に資本関係がないことを確認してください。資本関係がある場合、見積りの客観性の問題があったり、利害関係から見積りを辞退されたりする可能性があります。

<!-- -->

- 注記

  モダン技術とは、令和 4 年度現在であれば、マイクロサービスアーキテクチャ、API、クラウドネイティブ、マネージドサービスのみによる構成等の新しい技術のこと。

クラウドサービスを利用して、モダンな情報システムを構築する場合は、モダン技術に明るい事業者に依頼しましょう。
現行システムがオンプレミスであり、既存事業者が見積もった場合、オンプレミスと同様の構築手法を前提とした見積りが提示される可能性があります。そのため、モダン技術に明るい事業者も含めて見積りを依頼し、提出された見積りの前提や技術的な妥当性等の情報を比較の上、より良い見積りを採用しましょう。
「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に見積り取得時の留意点を記載しているので、見積りを依頼する前に確認し、適切な事業者を選定するようにしましょう。

### 見積り事業者と対話して、発注者の意図を正しく伝える

特に、プロジェクト初期段階のサービス・業務企画や情報システムの要件が粗い場合は、資料だけではプロジェクトの趣旨や実現したい内容、欲しい見積りの粒度等が伝わりにくく、結果として発注者の意図に合わない見積りとなり、双方にとって無駄な労力となることもあります。

事業者の見積り精度を上げるためにも、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝えることは重要です。そのために、事業者への説明会を開催したり、見積り内容に対するヒアリングを行ったり、様々なコミュニケーションを通して発注者の意図を正しく伝えましょう。
