---
type: guideline
title: 【コラム】外部委託事業者の関わり方
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
---

# 【コラム】外部委託事業者の関わり方

サービス・業務企画は、現状の調査から始まり、最終的には業務の要件を定義するまでの作業が含まれます。これらの作業には、多くの作業量が必要となったり、業務分析や情報システムに関する専門的な知識が求められたりします。その際に、これらの作業の一部についてコンサルティング等を専門分野とする事業者に委託することも選択肢の１つです。

ただし、外部委託事業者に作業を丸投げしてはなりません。作業を進める際に、発注者として気をつけるべきポイントについて見ていきましょう。

## 事業者と役割分担して作業を進める

事業者にサービス・業務企画の作業を委託する場合、ＰＪＭＯと事業者とが「協働」して活動を進めていくことが重要です。事業者はサービス・業務企画を行うための知見を持っていますが、業務の実情を詳細に知っているわけではありません。また、ステークホルダーとの調整や作業の方針・内容の決定等、ＰＪＭＯにしかできない作業も数多くあります。

何より、成果物の内容を決定する責任は、ＰＪＭＯにあります。事業者が作成したドキュメントの内容で理解できないものがあれば、ＰＪＭＯから事業者に説明を求めましょう。

また、実際のプロジェクトでは、他の様々な事業者からの協力を得ながら作業を進めることになりますが、構築する過程における認識の相違や後から発覚する制約等によって、本来実現したかった理想と現実とにかい離が発生することが多々あります。

これらを防ぐために、ＰＪＭＯや関係職員がサービス・業務企画の各活動に細かく関与し、成果物（要件定義書や設計書等）をこまめにレビューしていく必要があります。ただし、ＰＪＭＯや関係職員のリソースに制限がある場合は、レビュー対象とする成果物や活動への関与を平準化し、一部の成果物や活動に偏らないバランスを取った関与の仕方を工夫することは有効です。

事業者に作業を委託する場合の留意点を以下に記載します。

委託時の留意点

- 全ての作業を事業者に委ねないよう、役割分担を明確にし、事業者と合意する。

- 優先順位付けや企画内容の決定等の意思決定は、発注者が責任を持って行う。

- 事業者とこまめなコミュニケーションをとり、事業者が実施できない作業（ステークホルダーとの調整等）を把握し、実施する。

- 事業者が作成する成果物をレビューし、不明点があれば事業者に対して説明を求める。

## 発注者の、要件定義への関わり方

要件定義を行う際は、発注者側が積極的に関わっていく必要があります。業務要件は情報システム要件のインプットであり、対象システムに関わる全てのステークホルダーとの調整を経て確定するものです。そのため実情を把握していない外部委託事業者に丸投げすることは、論点が曖昧なまま要件が定まったように見える事態を発生させることにつながります。業務要件が定まっていないケースでは何度も情報システム要件に変更や追加が発生し、スケジュールやコストに大きなマイナスが発生します。業務要件がしっかり定まっているプロジェクトは、それ以上の手戻りが発生しないためスムーズに進行できます。

要件定義を外部委託する際の発注者としての留意点を以下に記載します。

要件定義を外部委託する際の留意点

- 業務要件定義書は発注者が作るものです。発注者側が積極的に関わる体制を用意するよう意識して下さい。

- 具体的な役割分担を調達仕様書に記載することが重要です。
  例えば、調達時に「支援」という言葉を使ったケースでは、支援の範囲について発注者側と事業者側とで認識に差異が生まれるおそれがあります。ドキュメント作成の支援であれば、ドキュメントの初案を事業者が作成するのかどうかなど、作業レベルでの具体的な役割について調達仕様書に明示することが重要です。

- 要件定義においても、最終成果物を作成することのみにフォーカスするのではなく、重要な論点については複数の実現方式案を作成した上で、各案のメリット・デメリットを整理することが重要です。このような比較資料についても、専門的知見を持つ事業者から提示を受けることが望ましいといえます。もちろん、最終判断は発注側が行います。

デジタル・ガバメント推進標準ガイドライン

実践ガイドブック

（第３編第５章　要件定義）

目次

[１ 要件定義で職員が得た知識は貴重な財産 [7](#要件定義で職員が得た知識は貴重な財産)](#要件定義で職員が得た知識は貴重な財産)

[２ プロジェクト計画や業務要件を把握する [8](#プロジェクト計画や業務要件を把握する)](#プロジェクト計画や業務要件を把握する)

[１ ＲＦＩを理解し、必要な資料を準備する [9](#ｒｆｉを理解し必要な資料を準備する)](#ｒｆｉを理解し必要な資料を準備する)

[２ 公平性等を確保したヒアリングを行う [11](#公平性等を確保したヒアリングを行う)](#公平性等を確保したヒアリングを行う)

[３ 収集した情報を基に資料を更新する [11](#収集した情報を基に資料を更新する)](#収集した情報を基に資料を更新する)

[１ 構成要素を把握し要件を定義する [13](#構成要素を把握し要件を定義する)](#構成要素を把握し要件を定義する)

[２ 機能の優先順位は改善後の業務で判断する [15](#機能の優先順位は改善後の業務で判断する)](#機能の優先順位は改善後の業務で判断する)

[３ 一貫性をもった論理的な記載とする [16](#一貫性をもった論理的な記載とする)](#一貫性をもった論理的な記載とする)

[４ 要件定義書は継続的にメンテナンスする [16](#要件定義書は継続的にメンテナンスする)](#要件定義書は継続的にメンテナンスする)

[１ 個々の領域について要件を定める [18](#個々の領域について要件を定める)](#個々の領域について要件を定める)

[２ 必要な機能を漏れなく抽出し検討する [37](#必要な機能を漏れなく抽出し検討する)](#必要な機能を漏れなく抽出し検討する)

[３ 実現手段ではなく、求める結果を記載する [38](#実現手段ではなく求める結果を記載する)](#実現手段ではなく求める結果を記載する)

[１ 個々の領域について要件を定める [39](#個々の領域について要件を定める-1)](#個々の領域について要件を定める-1)

[２ システム方式を決定する [71](#システム方式を決定する)](#システム方式を決定する)

[１ 定義内容を関係者に共有する [72](#定義内容を関係者に共有する)](#定義内容を関係者に共有する)

[２ プロジェクト計画書に反映して最新化する [72](#プロジェクト計画書に反映して最新化する)](#プロジェクト計画書に反映して最新化する)

事例・参考の一覧

※事例には当時の役職名やシステム名を使用しているため、現在使用されていない名称が記載されている場合があります。